SOA简介
SOA是一种架构风格，是分布式服务发展过程中的产物。在分布式服务刚被提出时就预见的一些困难点，譬如服务之间的松耦合、注册、发现、治理，隔离、编排等，在SOA时代针对这些问题，甚至是针对“软件开发”这件事本身，都进行了更具体、更系统的探索。
- 更具体
主要体现在尽管SOA本身还是属于抽象的概念，而不是特指某一种具体的技术，但此时SOA具有更强的操作性，已经不能简单的视为一种架构风格，而是一套软件设计的基础平台。它拥有领导制定技术标准的组织；有清晰软件设计的知道原则，譬如服务的封装性、自治、松耦合、可重用、可组合、无状态等；明确了采用SOAP作为远程调用协议，依靠SOAP协议族来完成服务的发布、发现和治理；利用企业服务总线（如ESB）的消息管道来实现各个子系统之间的交互，令各个系统在ESB的调度下无须相互依赖就能相互通信，实现了服务的松耦合。在这一套成体系的可以相互精密配合的技术组件支持下，若仅从技术可行性这一个角度来评判的话，SOA可以算是已经成功解决了分布式环境中出现的主要技术问题了。 - 更系统
这个主要是指SOA的宏大目标，它的终极目标是希望总结出一套自上而下的软件研究方法论。它想做的不仅仅关注技术，还关注研发过程中涉及的需求、管理、流程和组织。如果这个目标达成，那软件开发就有可能从此迈进工业化生产阶段。但是很遗憾，这个愿景没有实现，甚至SOA本身都沉寂下去了。
SOA最终偃旗息鼓原因是多方面的。首先，SOAP协议过于严格的规范定义带来过度的复杂性，而构建在SOAP基础之上的ESB等诸多上层建筑，进一步加剧了这种复杂性，使得SOAP逐渐被边缘化。其次，SOA过于严格规范，不但限制服务架构的自由，而且使它注定成为少数系统阳春白雪式的精致奢侈品，它可以实现多个异构大型系统之间的复杂集成交互，却很难作为一种具有广泛普适性的软件架构风格进行推广。
微服务简介
微服务刚开始确实是作为SOA的一种轻量化的补救方案而被提出的。它指的是一种专注于单一职责的、与语言无关的细粒度的Web服务。时至今日，仍然有人认为微服务就是SOA的一种变体，没有什么新鲜的东西。不过，微服务经过十几年发展，这种看法明显有失偏颇，某种层度上甚至可以说完全错误。
现代微服务的概念：微服务是一种通过多个小型服务组合构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的变成语言、不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信和运维。
微服务的九个核心的业务与技术特征：
- 围绕业务能力构建
这里强调了**康威定律*的重要性：设计系统的组织往往被组织的架构所限制，最终设计的结果是这些组织的沟通结构的副本，换句话说，软件系统的架构设计需要符合设计它的团队组织的沟通结构。这种结论不是某个团队、某个公司的巧合，而是必然的演化结果。高效的沟通一定发生在团队内部，而非跨团队之间。当团队、产品磨合稳定之后，团队和产品就会拥有一致的结构。 - 分散治理
这里是指服务对应的开发团队有对服务运行质量负责的责任，也有不受外界干预地掌握服务各个方面的权利。当然这里所说的是团队有这个权利，但是实际操作中可能并不会一定这么做。毕竟统一的技术栈会为公司带来更低的沟通成本和金钱成本。微服务不提倡也并不反对这种统一，但在选择之前一定要做好选择带来额各种后果的准备。微服务更加强调的是在确实需要技术异构时，应能够有选择“不统一”的权利。 - 通过服务来实现独立自治的组件
之所以强调通过“服务”而不是“类库”来构建组件，是因为类库在编译期静态链接到程序中，通过本地调用来提供功能，而服务是进程外组件，通过远程调用来提供功能。 - 产品化思维
避免将软件研发视作要去完成某种功能，而是视作一种持续改进、提升的过程。在微服务中，要求每个人都具有产品化的思维，关心整个产品的全部方面是具有可行性的。 - 数据去中心化
微服务明确提倡数据应该按领域分散管理、更新、维护、存储。我们知道同一个数据实体在不同的领域服务的视角里，它的抽象是不同的。数据去中心化可以很好的解决不同领域服务修改同一实体时，因为相互影响而导致的服务独立性丧失的问题。 - 强终端弱管道
微服务中强调弱管道。这几乎是直接反对SOAP和ESB的通信机制。
ESB可以处理消息的编码加工、业务规则转换等；SOAP有几十个WS-*协议族在处理事务、一致性、认证授权等一系列工作，这些构建在通信管道上的功能也许对某个系统中的某个一部分服务是有必要的，但对于另外更多的服务则是强加进来的负担。如果服务需要某种通信能力，就应该在服务自己内部进行解决，而不是在通信管道上一揽子处理。 - 容错性设计
我们要接收这样的现实：服务无法做到永久稳定，而是总是会出错的。所以“断路器”这类设施，在实际生产中是必备的组件，是服务可靠性的必须支撑点。可靠系统完全可以可能由会出错的服务组成，这是微服务最大的价值所在。 - 演进式设计
容错性设计承认服务会出错，演进式设计者承认服务会被报废淘汰。一个设计良好的服务，应该是能够报废的，而不是期望得到长生。假如一个系统中出现不可更改、无可代替得的服务，这并不能说明这个服务有多么的优秀、多么重要，反而是一种系统设计上脆弱的表现，微服务追求的是自治、隔离，也是反对这种脆弱性的表现。 - 基础设施自动化
因为微服务架构下运维额服务对象数量是单体架构的数量级备，使用微服务的团队更加依赖于基础设施的自动化。
微服务架构的好处和弊端
微服务的好处：
- 使大型的复杂应用程序可以持续交付和持续部署
- 每个服务都相对较小并容易维护
- 服务可以独立部署和扩展
- 微服务架构可以实现团队耳朵自治。更容易实验和采纳新技术
- 更好的容错性
微服务的弊端：
- 服务的拆分和定义是一项挑战
- 分布式系统带来的各种复杂性，是开发、测试和部署变成更加困难
- 当部署跨越多个服务的功能时需要谨慎地协调更多的开发团队
- 开发者需要思考到底应该在应用的什么阶段使用微服务架构
SOA和微服务的区别和联系
SOA和微服务最直接的联系就是它们都是面向服务的架构风格。微服务是追求更加自由的架构风格，摒弃了几乎所有SOA里可以摒弃的约束和规定。有人会有疑问，如果没有了统一的规范和约束，以前SOA解决的那些分布式服务的问题，岂不是一下子都重现了吗？的确如此，对于服务的注册发现、跟踪治理、负载均衡、故障隔离、认证授权、伸缩扩展、传输通信、事务处理等问题，微服务中不再有统一的解决方案。
微服务所追求的这种自由其实是把双刃剑。一方面，微服务的这种自由给了单个服务足够的权利来根据自身所面临的分布式中的问题来选择对应的解决方案，而不必背负SOA那种百宝袋般的沉重的包袱。但另一方面，这种自由也对架构能力的要求提升到了前所未有的高度。我们知道，技术架构者的第一职责就是决策权衡，有利有弊才需要决策，有取有舍才需要权衡，如果架构者本身的知识面不足以覆盖所需要决策的内容，不清楚其中的利弊，恐怕将无可避免地陷入选择困难症的境遇之中。
我们还可以从更具体的角度去分析两者的区别：
- SOA和微服务架构通常采用完全不同的技术栈
SOA应用常常选用重量级的技术，如SOAP和ESB。SOA常使用ESB进行服务集成，ESB是包含了业务和消息处理逻辑的智能管道。而微服务架构设计的应用程序倾向于使用轻量级、开源的技术。服务之间往往采用哑管道（例如消息代理）进行通信，使用类似REST或gRPC这类轻量级协议。 - SOA和微服务架构在处理数据的方式上也不尽相同
SOA引用一般都有一个全局的数据模型，并且共享数据库。相反地，微服务架构中每个服务都有属于它自己的数据库。更进一步，每一个服务一般都拥有属于它自己的领域模型。 - SOA和微服务架构的服务规模不同
SOA和微服务架构之间的另一个重要区别，就是服务的尺寸（规模）。总得来说，SOA善于集成大型、复杂的单体应用程序。微服务架构中的服务虽然不是必须要做到很小，但是通常都比较小。很显然，“比较下”仍然是一个相对概念，并不是一个可量化的指标。事实上，微服务架构中的服务的大小确实也没有可量化的指标去遵循，但是我们可以从另一个方面–微服务的边界确认和具体的业务规模，来最终确定微服务架构中的服务的大小。 - SOA和微服务架构中服务抽象方式不同
微服务中抽象服务时，围绕的是业务能力，或者业务领域；SOA抽象服务时，通常围绕的功能和技术能力。