SOA架构、微服务架构、Service Mesh分析

本文目标：搞清楚什么是SOA架构、微服务架构，两者区别是什么？Service Mesh是什么，跟微服务有什么关系？

提到SOA架构（Service-Oriented Architecture，面向服务架构），就一定会讲到ESB（Enterprise Service Bus，企业服务总线）。ESB作为SOA中的核心概念，首先我们就来看看ESB是什么，以及它在SOA架构中扮演的角色。

在企业计算领域，企业服务总线是指由中间件基础设施产品技术实现的、 通过事件驱动和基于XML消息引擎，为更复杂的面向服务的架构提供的软件架构的构造物。企业服务总线通常在企业消息系统上提供一个抽象层，使得集成架构师能够不用编码而是利用消息的价值完成集成工作。

上面是WIKI中对ESB的定义，加上《企业服务总线》文章中对ESB的描述，画了一个ESB使用的场景。

在图中，Service A是企业内部的请假服务，当员工请假申请审批通过之后，Service A会发送请假审批的结果以及相关数据到ESB（通过消息）。在ESB内部，Router会根据消息中携带的数据做路由，如果属于B子公司的员工，会被分发到SQL Transform进行转换，最终被写入到DB；如果属于C子公司，会被分发到CSV Transform进行转换，最终变成csv文件上传到FTP上。Service B和Service C都是员工出勤统计报表服务，分别属于子公司B和子公司C，数据输入的格式不同（DB/CSV文件）。

在上面的场景中，ESB提供了3个功能：

以上3个功能组合，实现了三个不那么“一致”的Service A B C服务的集成，同时服务与服务之间是松耦合的。这里先记住两个关键词：服务集成和松耦合。后面可以与微服务架构对比着看。

微服务架构在名字中也有服务两个字，SOA是面向服务架构。这两个服务是一个意思吗？先抛一个个人观点：微服务中的服务与面向服务架构中的服务本质上是同一种东西，都是对外开放的、供他人使用的能力，区别在于服务的粒度大小，划分服务的维度有所不同。那微服务架构与SOA架构是否是同一个概念？我觉得不是，下面以我待过的某电商网站举个例子。

之前在某电商网站工作过一年多，入职时整个网站所有功能都在一个工程中，工程代码差不多有10G，即使在公司内网想要clone到本地也要不少时间。所有业务线都在上面做开发，因为是同一个工程，每个业务线没有自主发布权，只能每天定时线上发布一次。每次发布都是灾难：代码冲突、代码合并导致的BUG，经常因为其中一个功能有bug，导致整个发布流程阻塞，所有新功能无法上线。随着业务发展，公司领导自然也意识到问题的影响越来越严重，于是拍了解决方案，就一个字：拆。按代码分层（web层、服务层）、业务线（交易、促销、会员等）把代码拆成独立的工程。于是就有了下面的微服务架构。

原本统一的工程被拆成了多个服务（图中只是服务依赖关系举例，没画出微服务基础组件）。业务代码变得可扩展、易维护，提高了开发效率。所以微服务的本质是拆，采用微服务架构目的是通过拆分实现业务的可扩展和易维护。

SOA架构的目标是把企业内部的基于不同协议、数据结构的服务集成起来。而微服务架构的目的是提高系统的可扩展性、降低维护成本、提高研发效率。

Martin Fowler在描述微服务之间通讯时提到过"Smart endpoints and dumb pipes"（Microservices）。

Applications built from microservices aim to be as decoupled and as cohesive as possible - they own their own domain logic and act more as filters in the classical Unix sense - receiving a request, applying logic as appropriate and producing a response. These are choreographed using simple RESTish protocols rather than complex protocols such as WS-Choreography or BPEL or orchestration by a central tool.

而SOA中的ESB就是一个典型的Smart pipes，知道协议类型、知道数据结构、知道如何路由、知道如何转换。

在SOA架构中，基础技术组件主要是ESB。在微服务架构中是服务发现、注册、监控等等（其中一部分是跟ESB有重合的，例如服务注册）。

Service Mesh（服务网格）是2018年真正火起来的一个名词。上面提到微服务需要一套基础技术组件来支撑，Service Mesh就是其中一种组件的实现方式，更广为人知的可能是Dubbo等框架。先来看一下istio（Service Mesh的一种实现）给出的架构图。

下面是传统Dubbo的架构图。

两者使用方式上的对比。

Service Mesh对比Dubbo等传统RPC框架，主要的变化是：从直接依赖SDK，变为sidecar模式。业务与Service Mesh是两个独立的进程，业务不感知Service Mesh的存在。当产生服务调用时（以restful协议为例），消费端只会感知到http://xxx.com/api/orders。Service Mesh会拦截请求并转发到Proxy，之后Proxy根据Pilot中获取的服务配置将请求转发到真正的服务提供端。

《Dubbo在Service Mesh下的思考和方案》一文中详细讲解Dubbo在Service Mesh化中的一些思考，看完收获满满。

以上是元旦期间一些关于SOA架构、微服务架构的学习与思考，希望能给有需要的朋友一些帮助，也欢迎各位同行一起探讨。