其实服务化架构已经可以解决大部分企业的需求了，那么我们为什么要研究微服务呢？先说说它们的区别；
- 首要目标不同：SOA首先要解决的是异构应用的服务化；微服务强调的是服务拆分尽可能小，最好是独立的原子服务。
- 服务依赖：传统的SOA服务，由于需要重用已有的资产，存在大量的服务间依赖；微服务的设计理念是服务自治、功能单一独立，避免依赖其他服务产生耦合，耦合会带来更高的复杂度。
- 服务规模：传统SOA服务粒度比较大，多数会采用奖多个服务合并打成war包的方案，因此服务实例数比较有限；微服务强调尽可能拆分，同时很多服务会独立部署，这将导致服务规模急剧膨胀，对服务治理和运维带来新的挑战。
- 架构差异：微服务化之后，服务数量的激增会引起架构质量属性的编号，例如企业集成总线ESB（实总线）逐渐被P2P的虚拟总线替换；未来保证高性能、低延时，需要高性能的分布式服务框架保证微服务架构的实施。
- 服务治理：传统基于SOA governance（治理）的静态治理转型为服务运行态微治理、实时生效。
- 敏捷缴费：服务由小研发团队负责微服务设计、开发、测试、部署、线上治理、灰度发布和下线，运维整个生命周期支撑，实现真正的DevOps。
总结：量变引起质变，这就是微服务架构和SOA服务化架构的最大差异。
-
微服务架构强调业务系统需要彻底的组件化和服务化，一个组件就是一个产品，可以独立对外提供服务
-
微服务不再强调传统SOA架构里面比较重的ESB企业服务总线
-
微服务强调每个微服务都有自己独立的运行空间，包括数据库资源。
-
微服务架构本身来源于互联网的思路，因此组件对外发布的服务强调了采用HTTP Rest API的方式来进行
-
微服务的切分粒度会更小
总结:微服务架构是 SOA 架构思想的一种扩展，更加强调服务个体的独立性、拆分粒度更小。
MVC架构：当业务规模很小时，奖所有功能都部署在同一个进程中，通过双机或者前置负载均衡器实现负载分流；此时，用于分离前后台逻辑的MVC架构是关键。
RPC架构：当垂直应用越来越多，应用之间交互不可避免，将核心和公共业务抽取出来，作为独立的服务，实现前后台逻辑分离。此时，用于提高业务复用及拆分的RPC框架是关键。
SOA架构：随着业务发展，服务数量越来越多，服务生命周期管控和运行态的治理成为瓶颈，此时用于提升服务质量的SOA服务治理是关键。
微服务架构：随着敏捷开发、持续交付、DevOps理论的发展和实践，以及基于Docker等轻量级容器(LXC)部署应用和服务的成熟，微服务架构开始流行，逐渐成为应用架构的未来演进方向。通过服务的原子化拆分，以及微服务的独立打包、部署和升级，小团队敏捷缴费，应用的交付周期将缩短，运维成本也将大幅下降。