SOA这个词汇有二义性：

    1. 一层含义是指面向服务架构(Service Oriented Architecture)这种架构风格；
    2. 另一层含义是指多年前IBM/SAP/Dell/Oracle等公司搞的SOA解决方案，例如BPEL + SCA + SDO这套东西，以及Enterprise Service Bus(ESB)、WebSphere Process Server（WPS）、WebSphere Integration Developer（WID）、WebSphere Message Broker（WMB）等产品。

    你可以认为前者是一种Style，后者是一套Specification + Implementation。微服务可以被视作是SOA架构风格的另外一种实现方式。所以其实我们要对比的是SOA和以前IBM/Oracle等公司搞的SOA的区别。为了叙述方便，下文中的SOA均指IBM/SAP/Dell/Oracle的SOA产品。
    核心区别一句话：微服务是更加去中心化的SOA
    十多年前提出SOA其实就是为了解耦，解耦的本质就是为了去中心化，但是SOA有个很大的问题是，按照SOA的思路这些系统总会在某个环节上走向集中，所以去中心化做得很不彻底。

    • 最开始的时候，大家都猛搞ESB，觉得总线好牛逼，流程编排好强大。问题在于系统在开发阶段就走向集中了，服务模块中没有业务，所有的业务逻辑都在ESB中通过BPEL来组装。组装好的流程再交给Struts等Server端MVC框架调用。导致系统开发、集成、测试都很痛苦，存在一个流程编排的Team来掌握所有业务行为，这群人需要具备架构设计、流程分析、系统分析的能力，所以他们很贵，人数也很少，但是所有业务变化都跟他们有关系，所以他们很容易变成最大的组织瓶颈。以前搞这类系统的时候WPS在刀片机上重启一次需要40-60分钟，部署几次内存就会溢出需要重启，每天要重启N次，真是不堪回首的过去。
    • 后来大家觉得ESB太烦人了，又难用、又超级耗资源，所以好多人不想再用，我们就开发SCA服务就行了，业务行为往前推，放到Struts Controller里去，你看是不是有点像微服务的搞法了？但是这样的系统还是会在打包环境走向集中，打出一个巨大的EAR包。没错，那时候还在用EJB 2.0，WAR包是不行的。
    • 再后来大家觉得打成一个EAR包也很烦，部署起来不方便，代码版本也不好管，如果有人在Dependency上乱整造成Class loading的问题，那真是人神共愤令人发指。所以后来大家就想拆成多个WAR或者EAR，各搞各的呗，需要集成的时候我们就走SOAP吧。你看又有点像微服务了。但即使这样做，系统还是会在DB层面走向集中。那个年代大家觉得事务是绝对神圣不可侵犯的。哪像现在年轻人成天乱搞！
    • 你可能会说，那把DB也拆开吧，就彻底去中心化了。没错！完全拆开、从前通到后肯定比较爽啊，关起门来自己玩就行了。但是要支撑这种做法，你需要做很多技术准备啊，这套东西做完了，你也就搞出一套微服务了。
    • 彻底的去中心化之后，你的系统结构和开发团队结构就变得非常灵活，你可以根据业务架构、企业组织架构来设计你的系统和团队，所以微服务架构可以视作康威定律的技术基础。

    1.SOA架构和微服务架构的区别
    首先SOA和微服务架构一个层面的东西，而对于ESB和微服务网关是一个层面的东西，一个谈到是架构风格和方法，一个谈的是实现工具或组件。
    1.SOA（Service Oriented Architecture）“面向服务的架构”:他是一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在于操作系统进程中。各个服务之间 通过网络调用。
    2.微服务架构:其实和 SOA 架构类似，微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。
    微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想

    2.ESB和微服务API网关。
    1.ESB（企业服务总线），简单 来说 ESB 就是一根管道，用来连接各个服务节点。为了集 成不同系统，不同协议的服务，ESB 做了消息的转化解释和路由工作，让不同的服务互联互通；

    image.png

    2.API网关:API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。

    image.png

    image.png

    3.SOA架构特点：
    系统集成：站在系统的角度，解决企业系统间的通信问 题，把原先散乱、无规划的系统间的网状结构，梳理成 规整、可治理的系统间星形结构，这一步往往需要引入 一些产品，比如 ESB、以及技术规范、服务管理规范；这一步解决的核心问题是【有序】
    系统的服务化：站在功能的角度，把业务逻辑抽象成 可复用、可组装的服务，通过服务的编排实现业务的 快速再生，目的：把原先固有的业务功能转变为通用 的业务服务，实现业务逻辑的快速复用；这一步解决 的核心问题是【复用】
    业务的服务化：站在企业的角度，把企业职能抽象成 可复用、可组装的服务；把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力；“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。第三步，则是以业务驱动把一个业务单元封装成一项服务。这一步解决的核心问题是【高效】
    4.微服务架构特点：
    1.通过服务实现组件化

    • 开发者不再需要协调其它服务部署对本服务的影响。

    2.按业务能力来划分服务和开发团队

    • 开发者可以自由选择开发技术，提供 API 服务

    3.去中心化

    • 每个微服务有自己私有的数据库持久化业务数据
    • 每个微服务只能访问自己的数据库，而不能访问其它服务的数据库
    • 某些业务场景下，需要在一个事务中更新多个数据库。这种情况也不能直接访问其它微服务的数据库，而是通过对于微服务进行操作。
    • 数据的去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的数据库技术（SQL、NoSQL等）。在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理。

    4.基础设施自动化（devops、自动化部署）
    Java EE部署架构，通过展现层打包WARs，业务层划分到JARs最后部署为EAR一个大包，而微服务则打开了这个黑盒子，把应用拆分成为一个一个的单个服务，应用Docker技术，不依赖任何服务器和数据模型，是一个全栈应用，可以通过自动化方式独立部署，每个服务运行在自己的进程中，通过轻量的通讯机制联系，经常是基于HTTP资源API，这些服务基于业务能力构建，能实现集中化管理（因为服务太多啦，不集中管理就无法DevOps啦）。
    5.主要区别：

    image.png