结论：微服务是SOA发展出来的产物，它是一种比较现代化的细粒度的SOA实现方式。
MSA vs SOA
1.ESB(enterprise service bus)
从名称就能知道，它的概念借鉴了计算机组成原理中的通信模型——总线，所有需要和外部系统通信的系统，统统接入ESB，岂不是完美地兼容了现有的互相隔离的异构系统，可以利用现有的系统构建一个全新的松耦合的异构的分布式系统。
但，实际使用中，它还是会有很多的缺点，首先就是ESB的本身就很复杂，大大增加了系统的复杂性和可维护性。其次就是由于ESB想要做到所有服务都通过一个通路通信，直接降低了通信速度。
而在现代的微服务中，使用轻量级的通信机制，每个服务有自己的处理逻辑，它知道它要找的服务在哪里，不需要在通信的链路上做什么。
2. 服务化的概念和服务的尺寸
SOA的出现其实是为了解决历史问题：企业在信息化的过程中会有各种各样互相隔离的系统，需要有一种机制将他们整合起来，所以才会有上边所述的ESB的出现。同样的，也造成了SOA初期的服务是很大的概念，通常指定的一个可以独立运作的系统（这样看，好像服务间天然的松耦合）。这种做法相当于是「把子系统服务化」。
而微服务没有历史包袱，轻装上阵，服务的尺寸通常不会太大，关于服务的尺寸，在实际情况中往往是一个服务应该能够代表「实际业务场景中的一块不可分割或不易分割的业务实体」。将服务的尺寸控制在一个较小的体量可以带来很多的好处。
3. 通信协议
如今越来越多的工程开始使用RESTful来作为API的设计的基础，但仅仅几年前还有大把的API使用SOAP、WSDL等基于XML的重量级协议的Web Service。这点和上文说到的2点其实大同小异，仔细想想，它们都是由于历史原因造成的，同样的，通信协议经过这些年的发展，现在主流的基本上了两种：
文本协议使用最广泛的多是基于HTTP的RESTful规范
轻量级二进制协议Thrift、Protobuf，或者任何自定义的轻量级协议
MSA的优势
1.服务粒度比较小，实现简单,更易于实现低耦合、高内聚
2.分布式部署，可独立维护
3.在某个服务的压力大的时候可以加实例实现水平扩展
4.更易于关注实际业务场景