分布式系统漫谈【陆】_SOA和微服务

上篇文章：分布式系统漫谈【伍】_远程调用

上文我们提到，系统间大量的接口调用我们需要考虑很多事情，比如：

1.访问权限问题；

2.版本控制问题；

3.性能问题；

4.访问控制问题；

等等问题。如此说来，对服务接口进行治理已经刻不容缓了。这就要提到SOA。

SOA

SOA(Service-Oriented Architecture)，中文全称面向服务架构。它不是一种技术，而是一种解决问题的思考方式。它旨在搭建一种粗粒度、松耦合的以服务为中心的架构，接口之间通过定义明确的协议和接口进行通信。那么什么是服务呢？我们可以依据单一职责原则(Single Responsibility)来尝试解释：

把因相同原因而变化的东西聚合到一起，把因不同原因而变化的东西分离开。

而这些可以聚合到一起的可以说就是一个服务。对于一个业务系统而言，我们也可以先简单地根据业务的边界来确定服务的边界。

回过头来总结一下，那么SOA就是一个包含多个服务，服务之间通过配合对外提供一系列功能的架构。每个服务独立部署，服务之前通过网络调用。

那么SOA的落地实现有哪些呢？

ESB

ESB全称为Enterprise Service Bus，即企业服务总线，是用于设计和实现网络化服务交互和通信的软件模型。

具体来说，它也是一台服务器(或集群)，部署在不同服务中间。服务需要先在ESB上注册，这样其他服务调用该服务时，需要先请求到ESB服务器，ESB从已注册的服务列表找到提供该服务的服务器地址完成转发，该服务接到请求处理完毕后，也先返回到ESB服务器上，再由ESB服务器返回到调用方。

ESB的调用图大概如下图：



看到这里很多人不禁要提问，为什么服务间的调用要经过ESB，这样实现的目的是什么？请求经过ESB中间件，ESB可以对其进行一些处理，比如：

1.协议转换
如果调用方和被调用方提供的接口协议不同，那么经过ESB中间件时可以完成转换；

2.消息格式转换
同上，ESB中间件可以完成诸如Json格式转换为XML保温参数的操作；

3.服务监控和治理
包括服务的注册、安全、版本、优先级等；

4.服务集成和编排
可将多个服务通过ESB编排成为一个新的服务；

其实说到这里，我们不难发现其实ESB设计的初衷可能就是当一个企业有多套新老基于不同技术栈实现的系统时，为了能整合它们的服务，ESB提供出来了一套成熟稳定、兼容易用的中间件进行协调。

但是ESB本身有没有缺点，当然还是有的。正如上文所说，ESB主要想解决的是企业内部多系统服务调用的问题，如何把这套架构拿到高并发访问的互联网系统上去实践，那么就会出现很严重的问题，比如雪崩效应：

当使用ESB企业服务总线时，比如部署10台，高并发流量到来后当1台挂了，流量就分配到了剩下的9台；如果再挂，就是8台，直到一台不剩全挂。而且重启时，不能按照传统方式一台一台重启，因为重启一台，流量全上直接干挂。只能切走流量，然后十台重启好后再开启流量。

那么这样的问题如何避免呢？

微服务

微服务最早由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。

简单来说，微服务就是一组独立开发、可配置、可运行和可维护的子服务，子服务之间通过良好的接口定义通信机制，通常使用RESTful风格的API(HTTP+JSON)进行通信。结构图如下所示：



由上图可得知，微服务是去ESB总线、去中心化和分布式的，尽量不设置中心化的管理服务，最差也需要在中心化的管理服务宕机时有替代方案和设计。

微服务之间的通信和交互只能依赖定义良好的接口，通常使用RESTful样式的API或透明的RPC调用框架，不要使用数据库或缓存进行交互，因为：

1.除了接口契约，增加了数据存储契约；

2.上游的数据格式发生变化时，可导致下游的处理逻辑出现问题；

3.多个服务共享一个资源服务，对资源服务的运维难以划清职责和界限；

4.双机房分离部署时，要考虑服务和资源的路由情况；

微服务和SOA的关系

微服务是服务化架构的延续，一脉相承
如文章开头所说，SOA就是一个包含多个服务，服务之间通过配合对外提供一系列功能的架构。每个服务独立部署，服务之前通过网络调用。而这与微服务的设计思路不谋而合。个人理解，微服务就是基于SOA架构体系，在互联网应用上的一个更好的落地实现。


微服务部署在多台机器，而SOA部署在单机一个大war包

这个也比较好理解。微服务拆分的维度是服务，而SOA首先解决的是多个业务系统之间的调用。相当于微服务要比SOA更细化一些。


微服务中的服务是细粒度的，而SOA中服务通常是粗粒度，主要强调的是契约的规范化
正如前面所说，SOA解决的最重要的问题就是多个不同技术栈实现的系统之间交互问题，所以它更多的要强调规范化才能方便治理。而微服务势必是从业务系统拆分处理二次开发的(或从头开发)，真正的目的是通过对微服务进行水平拓展解决传统的单体应用在业务急剧增长时遇到的问题，而且由于拆分的微服务系统中专业的人做专业的事情，高内聚低耦合。

关于微服务，我们还将面临许多问题，这将在下文中进行讨论。