微服务架构似乎跟SOA非常相似，或者说，根本就是同一个东西，只是换了一个名称而已。
二者本质上都是组件化，将一个大系统拆分成若干个独立的小系统，再通过接口和服务组合起来。
不同之处在于粒度不一样：SOA面向较大型项目，分拆成多个应用；或者是将原本存在的多个应用，通过公共服务和接口而接合起来，组成一个大型系统；而微服务架构则是将单个应用再分割，分割成若干个微服务。
这样做的可取之处，或者是出发点，无非就是为了
1、系统逻辑架构清晰
2、提高复用性
3、提高开发效率
由于各个组件或服务有相对独立性，在开发过程中利于分开开发，提高效率；4、方便单独部署
但凡事有利有弊：
1、由于组件或服务数量多，交互和依赖增多，提高了整个系统的复杂度
2、同时组件之间存在依赖，降低系统的稳定性；如果被众多依赖的服务或组件出问题，系统可能瘫痪。
3、本来在系统内可以很方便访问的东西，可能改为调用服务，降低了系统的效率
4、整体部署复杂，本来只部署一个，现在N个
为什么会发展出微服务这种模式呢？如果搞过java web项目可能就比较容易理解。java web项目，可以搞成一个war包，扔在tomcat的webapps里。这个war包，里面就包含了一个网站项目的所有，包括逻辑、页面，样式，脚本，十分符合微服务架构描述中的一个“巨大应用”的特征。
那么将这个大war包，拆成若干个小war包，每个小war包可以直接复用，或者交由不同团队开发，肯定非常的快速、敏捷。接着是快速部署，微服务和docker应该是绝配。这样就可以进行所谓的AB测试了。就是同一个功能开发出AB两份，经测试、对比，从中选一份。微服务跟互联网息息相关，符合互联网应用快速迭代、不断试错的要求。
我在网上搜了许多有关微服务与SOA的区别的文章，每篇文章都非常的长，说了一大通，根本不能三言两语明确指出区别在哪里。这恰恰说明，二者其实区别不大。SOA中的大项目与微服务架构中的大应用，其界限是模糊的。
以上，是个人对微服务的一点理解。