烟囱式到SOA再到微服务烟囱式到SOA再到微服务

很多时候会听到微服务、SOA之间有着联系也有着区别，最近在看一本《企业IT架构转型之道》，仅以本文写下自己的理解。
“烟囱式”的架构公司老的IT架构属于传统的“烟囱式”架构，也就是每个业务线之间由不同的开发团队独立建设，技术栈不同，互不联系。大多数的架构会被打包成为war包并且被部署到Apache Tomcat Web容器中，整个结构趋于传统的单体架构，业务逻辑耦合在一个项目中。

文章图片
image.png
这样的架构有几个主要的弊端：

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

总结：这样的架构的好处就是可以互不影响地独立部署独立迭代了，适合业务线较少且比较独立的公司采用。
SOA SOA 全称是: Service Oriented Architecture，中文释义为 “面向服务的架构”它是一种设计理念，其中包含多个服务，服务之间通过相互依赖最终提供一系列完整的功能。各个服务通常以独立的形式部署运行，服务之间通过网络进行调用。

文章图片
SOA架构图 SOA的核心理念为：松耦合带来的服务重用，通过服务编排助力业务的快速响应和创新。
在SOA时代，有两种SOA的主要实现方式，分别是Web Service 和ESB。
Web Service Web Service使得运行在不同的机器及操作系统上的服务的相互发现和调用称为可能，并且可以通过某种协议交换数据。
下面是Web Service的工作原理图。

文章图片
从上图可以看到，每个服务之间是对等的，并且互相是解耦合的。通过WSDL定义的服务发现接口进行访问，并通过SOAP协议进行通信（SOAP协议通常是在HTTP/HTTPS上传输XML实现的协议），但是每个服务都要依赖中心化Web Service 目录来发现存在的服务。
Web Service存在的问题如下：

依赖中心化的服务发现机制。
使用SOAP协议，而SOAP协议通常用XML格式来序列化通信数据，由于XML格式数据冗余太大，导致SOAP协议太重。
服务化管理和治理设施并不完善。

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

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

文章图片
传统的ESB
经过服务总线路由过的服务交互，共出现4次网络会话创建和数据传输。传统企业服务总线的架构就暴露出“硬伤”，例如，10台ESB服务器有一台实例出现了问题，无法正常提供服务路由的能力，服务路由压力就落在了剩下的9台ESB服务器上，原本由出问题的那台服务器提供的服务路由职能就分摊到了剩下的9台上，每台的负载水位就超过88%，个别服务器可能更高，在服务器处于高水位运行的时候，出现问题的概率会大增。导致其他服务器也不堪重负而“罢工”。
“雪崩”事故后，故障恢复的时间和成本非常高昂，因为传统的一台一台重启服务器已经不能进行故障的恢复，因为一旦服务启动起来，前端的访问洪流会立即再次压垮启动后的服务器，唯一正确的方式是先切断前端应用对企业服务总线的服务请求，让这10台服务器全部启动后，在开放服务请求，这样才能恢复系统的运行。
正确理解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再到微服务】微服务架构倡导将软件应用设计成多个可独立开发、可配置、可运行和可维护的子服务，子服务之间通过良好的接口定义通信机制，通常使用 RESTful 风格的 API 形式来通信，因为RESTful 风格的 API 通常是在 HTTP 或者 HTTPS 通道上传输 JSON 格式的数据来实现的， HTTP协议有跨语言、跨异构系统的优点，当然，也可以通过底层的进制协议、消息队列协议等进行交互。这些服务不需要中心化的统管理，每个服务的功能可自治，并且可以由不同的语言、系统和平台实现。
微服务的架构如下图所示：

文章图片

我们看到微服务架构的些特点与 SOA 服务化架构相似，事实上微服务架构与 SOA服务化架构并不冲突，它们一脉相承，却略有不同：

目的不同
微服务使用系列的微小服务来实现整体的业务流程，目的是有效地拆分应用，实现敏捷开发和部署，在每个微小服务的团队里，减少了跨团队的沟通，让专业的人做专业的事，缩小变更和法代影响的范围，并达到单一微服务更容易水平扩展的目的。
SOA 服务化涉及的范围更广些，强调不同的异构服务之间的协作和契约，并强调有效集成、业务流程编排、历史应用集成等，典型代表为 Web Service 和ESB。
部署不同
微服务将完整的应用拆分成多个细小的服务，通常使用敏捷扩容、缩容的 Docker 技术来实现自动化的容器管理每个微服务运行在单的进程内，微服务中的部署互相独立互不影响。
SOA 服务化通常将多个业务服务通过组件化模块方式打包在 War 包里，然后统部署在一个应用服务器上。
服务粒度不同
微服务倡导将服务拆分成更细的粒度，通过多个服务组合来实现业务流程的处理，拆到职责单一，甚至小到不能再进行拆分。
SOA对粒度没有要求，在实践中服务通常是粗粒度的，强调接口契约的规范化，内部实现可以更粗粒度。

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

Spring全家桶
用起来很舒服，只有你想不到，没有它做不到。
Dubbo
很多国内的企业还在用，可以支持RESTful风格的API，但更多的还是会使用Dubbox的默认的基于RPC的API，调用远程API像调用本地API一样。这样做无疑带来了很多优势，但同时其基于接口的方式增加了服务间的耦合，怎么说呢，各有利弊。(上个月成为了apache top-level project)
Thrift（需要自己实现一些基础的东西）。
通常，MSA的实现通常要满足下面几个条件：
服务足够的小，需要根据自己的实际需求决定服务的大小。
服务可以独立开发、部署、测试。
使用轻量级通信方式。
数据分离