微服务架构是团队面对互联网产品爆发式增长的最优选择，要解决的是快速迭代、高可靠和高可用等问题，把复杂度很高的产品拆分成一些较小的模块，并遵循康威定律，每一个模块用5-9个小团队来维护，这样可以减少沟通成本，提高协作效率，更好地实现快速迭代和弹性扩展。
采用微服务架构改造，引入各种复杂性，如部署工作量的增加、复杂链路的监控难题，这就是为微服务而微服务，只会得不偿失。在实施的过程中不能简单的使用某些个微服务框架或者组件一蹴而就，而是需要将业务、技术和运维有机结合起来，配合同步实施，并且在此过程中还需要趟过很多的坑才能够取得成功。
复杂业务拆分可能无法一步到位，因为复杂，每个业务并不一定只能拆成一个组件，庞大的业务拆分出相对独立和庞大的业务，但如果业务较小而又比较多，且类型相似也可以不用着急拆分。
举网易考拉的例子，工程数量由最初的 7 到后来的 150+ 再到目前的 400+，都是根据实际情况决定的。中间的状态，可能不是严格意义上的微服务架构，但属于分布式服务架构——不过这不是那么重要，重要的是符合业务发展阶段的需求。医院的急诊，既看发热又看胃痛，固然分工没那么精细，但我们也不能说就是错的。
分布式是什么？
对于分布式架构，我们根据设计期的架构思想和运行期的不同结构分为：面向服务架构、分布式服务架构、微服务架构。
1.面向服务架构︰以业务服务的角度和服务总线的方式(一般是WebService与ESB）考虑系统架构和企业IT治理;
2.分布式服务架构：基于去中心化的分布式服务框架与技术，考虑系统架构和服务治理;
3.微服务架构∶微服务架构可以看做是面向服务架构和分布式服务架构的拓展，使用更细粒度的服务和一组设计准则来考虑大规模的复杂系统架构设计。
统的企业集成领域的EAI架构模式，本身还是各个系统独立部署，但是各系统之间的部分业务使用特定的技术打通了，因此我们可以看做是单体和分布式之间的过渡状态。
分布式服务架构与微服务架构概念的区别与联系
分布式：分散压力。
微服务：分散能力。
分布式：不同模块部署在不同服务器上;
作用：分布式解决网站高并发带来问题;
集群：相同的服务;
多台服务器部署相同应用构成一个集群;
作用：通过负载均衡设备共同对外提供服务;
SOA［组装服务/ESB企业服务总线］;
业务系统分解为多个组件，让每个组件都独立提供离散，自治，可复用的服务能力;
通过服务的组合和编排来实现上层的业务流程;
作用：简化维护，降低整体风险，伸缩灵活;
微服务［找到服务/微服务网关open API］;
架构设计概念，各服务间隔离（分布式也是隔离），自治（分布式依赖整体组合）其它特性（单一职责，边界，异步通信，独立部署）是分布式概念的跟严格执行;
SOA到微服务架构的演进过程;
作用：各服务可独立应用，组合服务也可系统应用。
