很多时候会听到微服务、SOA、ESB之间有着联系也有着区别，最近在看一本《企业IT架构转型之道》，仅以本文写下自己的理解。

“烟囱式”的架构

公司老的IT架构属于传统的“烟囱式”架构，也就是每个业务线之间由不同的开发团队独立建设，技术栈不同，互不联系。

image.png

这样的架构有几个主要的弊端：

1. 重复开发。每个业务线中间同样的模块会重复开发，比如会员营销模块，A业务线要建一个会员营销系统，B业务线也要建一个会员营销系统，这会造成很大的开发资源浪费；
2. 技术栈不统一。可能A系统用的是Spring MVC, B系统用的就是Spring Boot/Cloud。这会造成公司内部IT架构无法统一规划，且技术能力难以积累的问题；
3. 数据分布广，格式不统一，导致数据难以打通。A系统的会员存在A系统的MySQL库中，B系统的会员存在B系统的Oracle库中，如果要识别A系统中的001会员和B系统中的002会员是同一个人，也许只能在数仓中实现了。

总结：这样的架构的好处就是可以互不影响地独立部署独立迭代了，适合业务线较少且比较独立的公司采用。

SOA

SOA 全称是: Service Oriented Architecture，中文释义为 “面向服务的架构”它是一种设计理念，其中包含多个服务， 服务之间通过相互依赖最终提供一系列完整的功能。各个服务通常以独立的形式部署运行，服务之间 通过网络进行调用。

SOA架构图

SOA的核心理念为：松耦合带来的服务重用，通过服务编排助力业务的快速响应和创新。

ESB（企业服务总线）

简单来说 ESB 就是一根管道，用来连接各个服务节点。ESB的存在是为了集成基于不同协议的不同服务，ESB 做了消息的转化、解释以及路由的工作，以此来让不同的服务互联互通。从名称就能知道，它的概念借鉴了计算机组成原理中的通信模型——总线，所有需要和外部系统通信的系统，统统接入ESB，岂不是完美地兼容了现有的互相隔离的异构系统，可以利用现有的系统构建一个全新的松耦合的异构的分布式系统。ESB做了消息的转换解释与路由等工作，让不同的服务互联互通。

传统的ESB的服务调用方式是，每一次服务的调用者要向服务提供者进行服务交互请求时都必须通过中心的ESB来进行路由。
每一次服务交互的路线是：

服务调用者-->ESB（接收服务请求）-->服务提供者（服务处理）-->ESB（服务提供返回结果）-->服务调用者（服务返回）

传统的ESB

经过服务总线路由过的服务交互，共出现4次网络会话创建和数据传输。传统企业服务总线的架构就暴露出“硬伤”，例如，10台ESB服务器有一台实例出现了问题，无法正常提供服务路由的能力，服务路由压力就落在了剩下的9台ESB服务器上，原本由出问题的那台服务器提供的服务路由职能就分摊到了剩下的9台上，每台的负载水位就超过88%，个别服务器可能更高，在服务器处于高水位运行的时候，出现问题的概率会大增。导致其他服务器也不堪重负而“罢工”。

“雪崩”事故后，故障恢复的时间和成本非常高昂，因为传统的一台一台重启服务器已经不能进行故障的恢复，因为一旦服务启动起来，前端的访问洪流会立即再次压垮启动后的服务器，唯一正确的方式是先切断前端应用对企业服务总线的服务请求，让这10台服务器全部启动后，在开放服务请求，这样才能恢复系统的运行。

而“去中心化”服务架构中服务交互，一次服务的调用只有2次网络会话创建和数据传输，在网络上的开销整整减少了一半，如下图：

去中心化

正因为如此，更推荐使用“去中心化”的服务架构。

正确理解ESB在SOA中的作用

平心而论，ESB的确是SOA中一个非常重要的集成层组件（Integration Layer），不论是OpenGroup发布的SOA参考架构，还是几大主流SOA供应商（参考IBM通过参考架构实施SOA解决方案 ，Oracle与F5的SOA参考架构，Microsoft的BizTalk ESB Toolkit中对ESB的定义），都将ESB置于SOA架构的核心位置。

事实上，ESB在SOA中扮演着重要的角色，在技术层解决了SOA的整合问题，耦合了应用与应用之间的集成逻辑，使得SOA更灵活，更易于扩展，更敏捷。有了ESB，新建的服务消费者应用程序不需要关心服务的提供者在哪里，使用何种通讯协议，与其交互的数据是怎样的……，它只需向ESB发出请求，使用开放的、标准的通讯协议。相反，若某个可重用的价值较大的服务位于某一个遗留系统中，而由于种种原因，该遗留系统不能在短期内重写，此时ESB可以架起该服务与其使用者之间沟通的桥梁。当然，ESB的作用远不止这些，业内也有很多讨论，本文不再赘述。

然鹅，ESB和SOA存在其缺点：
ESB架构虽然能够屏蔽内部服务变化对外部的影响， 但是服务的功能是“稳定”的，也就是说服务对外提供的功能是基本不变的，其接口设计是自顶向下的设计，在接下来的时间里，就几乎没有新的服务功能的增加和提升。
但是，服务是最不需要“业务稳定”的，服务需要新的业务不断接入来达到对自身的“滋养”。

从SOA到微服务

SOA的出现其实是为了解决历史问题：企业在信息化的过程中会有各种各样互相隔离的系统，需要有一种机制将他们整合起来，所以才会有上边所述的ESB的出现。同样的，也造成了SOA初期的服务是很大的概念，通常指定的一个可以独立运作的系统（这样看，好像服务间天然的松耦合）。这种做法相当于是「把子系统服务化」。
而微服务没有历史包袱，轻装上阵，服务的尺寸通常不会太大，关于服务的尺寸，在实际情况中往往是一个服务应该能够代表「实际业务场景中的一块不可分割或不易分割的业务实体」。将服务的尺寸控制在一个较小的体量可以带来很多的好处：

• 更易于实现低耦合、高内聚
• 更易于维护
• 更易于扩展
• 更易于关注实际业务场景

SOA与微服务区别

Java中的微服务

在Java的生态中，已经有很多十分成熟的，可以拿来实现MSA的中间件，比较出名的有：

• Spring全家桶
  用起来很舒服，只有你想不到，没有它做不到。

• Dubbo
  很多国内的企业还在用，可以支持RESTful风格的API，但更多的还是会使用Dubbox的默认的基于RPC的API，调用远程API像调用本地API一样。这样做无疑带来了很多优势，但同时其基于接口的方式增加了服务间的耦合，怎么说呢，各有利弊。(上个月成为了apache top-level project)

• Thrift（需要自己实现一些基础的东西）。
  通常，MSA的实现通常要满足下面几个条件：

• 服务足够的小，需要根据自己的实际需求决定服务的大小。

• 服务可以独立开发、部署、测试。

• 使用轻量级通信方式。

• 数据分离

参考文章：
平台、中台与康威定律 - 传统企业IT架构转型的辛酸史
The Apache Software Foundation Blog