作者： 黄浩

2018 年 11 月 22 日

二十年来，整个分布式系统架构的演进，从 C/S 到 B/S，再到分布式系统，当前广泛使用的是网格计算和云计算，包括目标、定位、场景。

菜鸟乃至阿里在全球化进程中，也面临着全球分布式架构问题，以及仓储系统中独特场景下云计算能力的不足。菜鸟资深技术专家 黄浩 老师目前带领团队在设计规划菜鸟下一代分布式系统架构，结合传统云计算 PaaS/BaaS 以及边缘计算能力，将其应用在全球多域体系中。

黄浩老师工作了 17 年，目前是 TOGAF 认证架构师，菜鸟程序员联合会首任主席，现为菜鸟仓储技术部及自动化技术团队负责人。2001 年起就在 Java 中间件、分布式系统架构浸染多年，在企业架构、中间件、分布式系统设计与云计算架构有非常丰富的经验。2016 年主导推进菜鸟混合云架构，建立全球多域混合云架构，成为整个阿里巴巴云化模式的样板和方向。

当前分布式技术架构举例：微服务

常见微服务架构，其前端流量入口采用负载分片模式。应用层常见是采取一级网络 (通过配置推送的软负载) 或者二级网络 (通过应用网关负载隔离) 模式。阿里是使用前者，百度、新浪使用后者，主要取决于微服务的展现形式 (RPC or Rest-API)，差异是是否需要一个专职配置中心。为保证请求无状态地实现迁移，所以使用共享数据节点 (存储各种形式的临时或中间数据) 的形式实现。数据节点往往采用分片的主备模式。

当前分布式应用架构举例：应用分层架构

这是比较广泛采用的架构模式，前面使用 CDN，后面有分布式缓存，服务端使用前后端分离，或者 Node.js / Rest-ful。应用层通过 ElasticSearch 让数据库去刷索引，实现大量的查询和读服务。中间使用大量消息系统进行相互的联系。这种架构模式的优点是可以应用横向扩张，都是独立的应用，很容易 Docker 化。

阿里分布式系统架构举例：单元化、混合云

阿里全国多站点的布局带来一个问题，例如广州的站点出现问题，所有访问广州的客户都会受到影响。这就需要多活的站点，多地可以自由无感切换。**单元化架构使用到了配置数据同步，每个单元扮演对等节点，为所有的节点提供服务，从业务服务角度，所有站点均对等隔离，按照流量分离的方式分别不同的用户提供服务。**开始的时候通过流量负载的方式，底层通关管理节点把配置数据之间、核心数据之间进行同步。从管理配置角度，中心站点担任管理节点，负责管理单元节点及分发配置。

菜鸟混合云架构：双写双机房

在 2015 年的时候，推出了菜鸟混合云架构，它和传统混合云有点不同。菜鸟混合云分为两个部分，**一是独立的混合云机房；二是双写双机房，再加一套混合云就是同城三机房。**其策略是保证本身的集群应用调用，在默认情况下是本机房调用。但是在资源紧张的情况下，要做弹性，扩容云上机房，说明有些应用要访问云上机房，而底层进行配置的数据同步，以及数据库之间强一致同步写。 整个菜鸟在阿里是第一个实现基于混合云的同城三机房模式。

关于微服务的困局挑战

阿里算是最早践行微服务理念的公司，仅菜鸟就有超过 1000+ 的单体应用，并且还在逐年增多。黄浩老师说，阿里从微服务架构里获得了很多好处，也踩过很多不可避免的坑。微服务并非是一种架构或者架构理念（或者说它只是一个技术架构应用方法），它的初心是降低复杂度提高系统的柔性，而实际是，如果缺乏清晰的架构理念和设计 (包括业务架构与应用架构)，它带来的结果只会是没有架构。

菜鸟在实践微服务架构过程中也遇到过很多问题， 例如资源绑定与限制，效率瓶颈，缺乏总体架构。实际业务场景的跨多个服务诉求；网状的调用及同步依赖关系；容器化背后开发与资源的绑定；极大量的远程调用；爆炸式增长的碎片化应用；

黄浩老师也说，跨服务之间的应用横向调度，微服务广泛应用，应用是网状架构，密密麻麻的节点，很难分清楚。其中最大的性能问题就是远程调用问题，

下一代架构的目标与挑战

在反思之后，下一代架构的要解决什么问题呢？黄浩老师说主要有 5 点：

  1. 应用的开发与部署环境和位置无关性 (Cloud Foundry)
  2. 更大范围分布式数据可信存储及一致性保障 (Block Chain 最核心的技术加密，分布式账本，分布式异地存储，阿里目前也在实践)
  3. 容器化技术，网格计算能力 (Edge/Grid Computing)
  4. 事件驱动架构的回归 (阿里在尝试 Reactive Stream)
  5. 全球化网络化对等架构模式

Reactive：淘宝应用架构实践

Reactive 是引导淘宝未来 10 年发展的技术架构，它的特点是响应式的编程方式，另一个特点是事件驱动的架构。同时也能看到 EDA 的回归，基于事件响应模式和异步处理。通过事件框架实现应用依赖间解耦。

流式编程处理也是架构的未来方向，符合 Reactive-Stream 规范的流式调用，传统串行应用调用和开发模式的升级。

微服务升级：菜鸟应用实践

对于菜鸟来说，首先要做的事情的是解耦，将开发和资源的分离。关于 Application Container 的定义，它不是简单的使用 Spring Cloud 或者 Spring Boot。例如定义模块，模块是可以独立地进行服务，也可以组合。**在分布式框架中间，当远程调用服务的时候，是可以判断远程应用是不是在本地环境内，如果是，就可以不用经过网络，只经过网络端口；只经过数据层，但不经过物理层；实际上是不占用整个带宽的。**另外，如果能识别出这两个应用都在一个环境内，就可以本地方法调用。网络状态下可以清清楚楚将模块组成架构，耦合关系不紧密，而且是分层的，第一个域是 Business domain，此业务域里各应用之间是分布式的网状关系。

异地多活：菜鸟基础架构实践

去年菜鸟做的异地多活完全改变了主从模式，**主从模式是 masters load 是活的，slave load 是备份的。而异地多活则是对等节点，用到了数据库层面的 X-Cluster 同步，正所谓三地五副本，有些内容是强一致性写到其他几个副本里。**此外还有异地异步备份副本。通过消息路由跨域传输实现多机房异地多活，可以在任意时间秒级切换系统。

云 + 端：菜鸟网格计算方向

黄浩老师最后指出，IoT 很火，**但真正意义的 IoT，是每个物体都像一台电脑，每台电脑的关系是，能相互之间可控组网，二是逐级联系。 菜鸟物流分为线上和线下两部分，线上应用和线下行为的不一致，线下端的数据不可能全部放到云端。 菜鸟现在在做边缘计算节点利用网格计算的思路，成为计算