服务拆分方法论

微服务是当下非常热门的话题，微服务发展到现在，已经不再单单局限于微服务架构本身，还与容器化、DevOps等新的理念相结合，成为当前移动互联网时代最先进的业务架构解决方案，能更好地迎合移动互联网业务快速迭代的要求。 本篇文章中我主要探讨的是什么时候适合微服务改造，如何做服务拆分等问题。

微服务适用场景

这些年关于服务拆分的理论层出不穷，在我看来我们首先需要搞明白起点和终点，然后还需要考虑的因素与坚持的原则。什么是起点和终点呢？第一种由于历史原因，公司的产品不得不从传统应用架构转为微服务架构，第二种原因呢就是马上开发一个全新的系统，需要用上微服务架构(当然不排除是BOSS装B，要追求新技术，因为微服务比较潮流嘛)。我们自己无论如何还是需要审视一下起点，也就是现有的架构是个什么样子，要考虑是否真的需要转成为微服务架构。至于终点呢，以一言蔽之：好的架构不是设计出来的，而是进化出来的，而且是一直在演进，生命不息，进化不止。吾生也有涯，而知也无涯。

我们可以看看Dubbo架构路线图：从单一应用架构 -> 垂直应用架构 -> 分布式服务架构 -> 流动计算架构

微服务与SOA之间就只是差了个ESB企业服务总线，如果此时的已经是SOA的架构，那么此时需要关心的也就是ESB了。从单体应用迁移到微服务架构的过程中，需要关注的重点是不一样的。微服务系统很可能是异构的，那么当前Java在整个系统中的占比是多少呢，有没有已经包含了服务注册与发现相关的组件呢，负载均衡的组件是弃用还是保留，如何以最小的代价切换过去。不过我们最需要优先考虑的就是，这个系统是否真的那么适合用微服务架构呢？在我看来，下列业务形态是不适合使用微服务架构的：

1、系统中包含很多很多强事务场景的不适合使用微服务架构。因为微服务是分布式的，如果是强事务场景，是不适合用微服务架构的。
2、业务相对稳定，迭代周期长。比如系统本来就是