一直在谈微服务，你知道分布式多中心架构是什么吗

每天都在谈SOA和微服务，但你真的理解什么是服务吗？

服务的技术架构之争

服务应该去版本化，不管是微服务还是SOA。

任何架构的调整只是拆了东墙补西墙，无法解决效率问题。

先厘清服务治理与组织架构的关系，再来谈微服务吧。

由于我们一直从事的是传统企业的架构改造工作，所以对新兴的互联网企业如何实施微服务架构并没有实践过。在写这一章之前，我在架构群里和曾经实施过微服务架构的互联网企业的架构师进行了交流，结果是深深的失望。我看到互联网企业为了快而失去的那些我觉得必不可少的能力，看到了以“简单即美”为借口的粗糙。

为此，我重写了这一章。在这之前的章节是将整个架构割裂开来，分别孤立的来探讨分析。这一章我希望能尽我所能融合传统服务体系与微服务于一体，构造一个平衡的、安全的、易于扩展的、易于维护的、高效的企业内服务架构。

企业内的集成架构

企业内部对待新建系统和存量系统在技术上的需求是不同的，往往已经建好的系统希望尽可能的稳定不进行大的架构和技术改变，同时还希望这些存量系统能够尽可能的发挥作用；而新建的系统则希望在稳定可靠的基础上尽可能的采用先进的技术和架构，以适应未来的发展不会很快落后过时。这样的一种策略，必然的造成企业内部系统都是异构的，所以从长期看我们关注异构系统之间的应用集成架构，从短期看我们关注当期的新建系统的统一应用开发架构。

去中心架构不适合应用集成

企业内部的应用集成架构的需求是将现存的所有异构服务系统通过非侵入的适配技术手段进行整合，并对服务的消费者按需的提供接口。应用集成架构的这种需求决定了去中心架构不能适用。

去中心架构在集成架构中并无实际的意义，因为传统的应用在没有集成之前就已经是去中心架构的点对点网状连接，正是这种异构系统之间杂乱的点对点网状连接才催生了集成架构的出现。如果强行的将集成适配器分散到每一个应用形成应用前置的话，相当于为每一个应用独立的部署了一套ESB，这样做除了增加开销之外完全看不出有什么实际的价值。

即便我们不考虑实际的价值，去中心的集成架构还是需要一个物理上的调度中心用以实现可能需要的服务组合。因为在任何一个应用的适配前置上都不具备实现组合的合理性（虽然应用架构师可以强行的选择在某个或某几个前置上实现）。

系统安全对去中心架构的限制

我们在第四章讨论本征服务的时候给出了一个本征化后的微服务架构图，如下：

我说看着细细的蓝线条觉得不够优雅，这里我们来看看传统企业的部署架构示意图：

其实，我是鼓足了勇气来质疑这一件事情，在写这篇文章之前我咨询了做互联网的朋友们，确信了在互联网企业中是没有DMZ区的，所有的应用都是混杂在一个区的，包括数据库（当然，由于作者没有互联网公司的从业经验，而通常互联网公司都是自己做架构设计，所以我也没有机会参与互联网公司的架构设计，这一切只是道听途说）。DMZ的具体作用相信大家都明白，当然不明白的可以去找一下相关的资料。因为安全原因一般WEBUI层都是部署在DMZ区的，我不想为了微服务而打破这一优良的设计，所以第四章的图就变成这样：

这幅图里为了方便我把网关和组合服务容器放到了一起，其实他们可以分开部署（这不重要），重要的是这个架构已经回归了ESB中心交换模式。其实传统的SOA架构最终在企业内部也是这样的，因为客户数据的安全性永远是第一位的。

那么我们担心的淘宝级交易量怎么解决？我想说的是，牺牲客户数据安全性来换取效率是绝对不可取得，几千个应用部署在一个区内，怎么也无法保证每个应用都是坚固可靠、无懈可击的，一旦肉机被攻破那么灾难就来了，甚至恶意的程序员可以人为的制造肉机，这根本就防不住的。

如果无法提高算法效率，又无法通过削弱安全指标来提升效率，那么就只能拿资源来换了。为了保证客户的利益，钱是要舍得花的，要么就别做这个业务。

通过分区多中心来降低集中负载

上图中，通过将业务按条线进行不同的分区，每个分区用独立的ESB集群进行集成。这样，每个前端系统调用后台服务的时候，就可以把访问压力分散到不同的分中心上，从而通过增加资源来提高访问效率。

通过数据冗余来提高查询类服务效率

通常，一个优秀的商业ESB产品可以产生从几毫秒到十几毫秒的系统延迟，对于大多数应用几十到几百毫秒的业务处理时间来说影响是微小的。但是当应用的处理时间缩短到几毫秒、同时又要求海量的并发能力的时候（比如简单查询），集成架构带来的延迟就变得无法忍受了（除非科技进步导致微秒级别的ESB成为现实）。

传统的应用架构下通过数据集成的方式形成ODS、数据仓库和数据集市来解决数据的查询、报表和在线分析等实时或非实时数据类请求对业务系统带来的压力；互联网模式采用读写分离的方式来解决类似的实时数据查询的问题。所以，在上述架构中我们也提到短路的方式可以用数据集成架构来替代。

用ODS的方式解决实时数据的查询相比较于用读写分离的方式来说，具有明显的缺陷：

1、ODS存储的数据范围过大，而读写分离针对的是有海量查询需求的数据，所以数据的命中率更高，这样在利用冗余来提高效率方面比ODS的性价比更高。

2、ODS方式需要应用改变查询逻辑从而增加系统间的耦合度，大多数应用只会关注自己的数据库，如果在应用内部采用访问ODS的方式来提高查询效率的话，会造成应用依赖于外部的数据库，从而造成从开发到运行整个应用生命周期内的效率降低。

造成前后台大量交互问题的根源在于”前端展现系统需要后台服务系统的数据”。为什么会这样呢？其实，这是OOAD给我们带来的误区。传统的面向对象的方法告诉我们，我们会把属性和方法封装成一个对象，以便于针对对象的一致性操作，于是我们会给“客户”这个对象封装上创建和查询两个方法，这非常符合直观的逻辑。但是，这样做真的合理吗？

从面向服务的方法来看，查询客户信息这样的服务真的不一定要客户信息系统来实现，实际上任何一个系统来实现这个服务都是可能的。在现实社会中，每个人的信息在各个地方都存在不同的副本，比如在派出所存在，在人才中心存在，在你所在的公司也存在，其实当有人需要查询你的个人信息的时候，基本会采用就近查询的原则。面向对象的方法给我们造成一个误区，这个误区就是所有的行为都是和实体封装绑定的，所以我们实现服务的时候也是将行为依附于实体。在这里顺便给大家推荐一个架构交流群：617434785，里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源。相信对于已经工作和遇到技术瓶颈的码友，在这个群里会有你需要的内容。

其实，现实社会的做法是，（信息）行为会更靠近需求者和使用者。换句话说，我们应该在前端应用里建立要展现数据的副本，并在前端系统中提供查询服务，因为只有前端系统才会更加频繁的使用这些服务，简单的说你们公司会给你建立个人信息副本，否则就要不断的去户籍所去查询你的信息，我确信这不是开玩笑。如下图，在前端系统建立对象经裁剪的的副本，就消除了系统间海量查询的需求。

不过需要注意的是，由于WEB层都在DMZ区，将查询库放在DMZ区带来数据安全的风险，这个我们前面已经讲到了。所以，通过这种方法只能解决非关键数据的查询效率问题。

企业内分布式多中心架构

上图是保险行业某大型企业的真实案例，在架构改造的咨询过程中，我们根据客户的现状和未来的发展方向，提出了以能力建设和消费为主要业务目标的分布式架构。

通过分布式服务中心，将企业的内部业务能力、传统合作伙伴提供的能力、数据能力以及互联网整合的第三方能力统一起来，建立全新的互联网生态圈，使得无论是内部的、外部的、合作伙伴的还是来自互联网的开发者都能够方便的了解和使用这些能力，帮助企业生态圈的快速建设和扩展。

在运行时，原本相互孤立的互联网区、外联区和内网区存在的服务可以通过全局路由的形式被方便的访问，在逻辑上成为一个整体；在管理和治理上，所有的服务都按照统一的流程在一套管理平台上进行管理和治理。

能力中心的基本逻辑结构

逻辑上，能力聚合中心分为三个主要的部分，各部分通过队列进行异步通信：

Out：服务（接出）容器

Out是服务实体或服务适配器的部署容器，可以认为是服务的实现者。在全局，逻辑上一个服务只有一个实现者（多个实现者可以认为是服务的集群方式）。

In：服务（接入）容器

In是服务API（适配器）的部署容器，为了实现S++的服务访问位置和协议透明，在Out容器中的服务实体是无法被中心外部的物理消费者直接访问的，Out中的服务通过在In中发布多种不同的API，来适应采用不同的访问协议的服务消费者。

为了实现服务访问地址透明，每个中心的In容器（如有必要）既可以发布本中心部署的服务API，也可以发布其他中心部署的服务的API，所以无论消费者从任何一个中心的渠道接入，都可以透明的访问全局所有的服务。

Router：服务路由器

为了实现服务访问地址对消费者透明，能力中心必须实现消费者无论从那个渠道接入，都可以透明的访问全局任何一个服务，所以全局路由器必须维持全局服务的路由地址表，将In接入的服务请求正确的路由到服务所部署的Out容器。

基本上，每个中心都是由这样的逻辑组件作为基础运行平台的。除了基础运行平台外，每个中心会根据自己的业务需求，增加其他的组件，比如外联平台会有一整套完备安全组件；互联网开放平台提供自服务的开发者门户、主数据交换中心提供数据准实时同步能力等等。

互联网开放平台

开放平台用于向互联网应用开放企业内部的服务，以及引入互联网上的第三方服务，系统应能抵御互联网各类网络攻击，建立应用授权认证机制和隔离机制，具备完善的故障隔离机制，保证系统平稳运行。开放平台是基于云架构进行构建，主要包括以下功能模块：

开发者门户：平台提供开发者门户，作为开发自服务的界面，包含开发者注册、社区、应用和服务的管理等；

服务网关：提供针对服务的路由，协议转换、流量控制、日志流水等管理。

OAuth授权：提供对用户访问资源的的开放授权协议。

运维监控平台：平台提供统一的管理监控平台，完成平台相关参数的设计，各类申请的审核以及服务、应用的监控和统计分析。

我们在互联网开放平台中引入了微服务，微服务应用会被部署在PaaS私有云中实现应用的动态扩展。所有的微应用都会挂接到API网关上，并由API网关对内对外提供微服务的路由，这个架构与我们前面提出的理论架构是基本一致的。

理论上，所有的应用都可以部署到PaaS云上，但为什么实际上不这么做呢？因为传统应用过于庞大，不利于PaaS的动态响应，同时由于传统应用提供不了本征化的服务，会导致云环境伸缩策略过于复杂，并降低云环境的可靠性。本文的最后一个章节，我们会去讨论PaaS云的问题。

其余各中心能力简介

外联能力中心主要提供企业与传统合作伙伴互联互通的能力，通常都是通过专有的通信渠道进行链接，使用各自不同的安全协议和报文格式。

主数据能力中心主要对内外部应用提供主数据发布和同步能力，采用服务主题订阅的模式，保证异步送达到数据消费者系统。消费者在本地形成数据副本，从而减小对业务系统和网络的压力，并提高查询效率。

组合服务中心提供基于业务服务的全局和局部组合能力，并将组合后的流程作为新的服务发布出来供渠道调用。组合服务中心并不一定是一个真实的物理中心，他可以内嵌于各个物理中心内部。

小结

本章用一个实际的案例，介绍了分布式多中心架构，限于篇幅原因很多设计和实现细节无法展开来讲。

分布式多中心架构是一个非常灵活的架构，可以根据客户的实际情况进行任意的裁剪。为适应客户不同的组织架构，服务治理采用可现场定制的治理流程，能同时适应注册制和核准制两种模式。并且，S++与分布式多中心架构的结合，赋予了微服务新的特性和更广阔的前景：

1、微服务本征化，彻底实现微应用解耦，并大大简化微服务开发和运维的难度。

2、S++服务组合容器使得基于服务的流程编排更简单、易于维护，甚至业务人员可以直接使用。

3、S++的彻底的业务与技术分离，使得微服务的治理更加简单，从而实现真正的业务敏捷。

4、S++并行组合的理论，将赋予微服务更高的性能和事务一致性保障，从而使得微服务可以更广泛的应用于各个领域。

5、分布式多中心的架构与S++的结合，不但避免了去中心架构难以管理的问题，更保证了系统的安全性和效率。

最后，我们将在最后一章节探讨S++化的微服务如何帮助PaaS环境实现基于服务质量的高灵敏度动态伸缩能力，从而能够快速的响应突发网络并发的冲击。