二十年来，整个分布式系统架构的演进，从 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 点：

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

Reactive：淘宝应用架构实践

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

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

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

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

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

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

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

黄浩老师最后指出，IoT 很火，但真正意义的 IoT，是每个物体都像一台电脑，每台电脑的关系是，能相互之间可控组网，二是逐级联系。菜鸟物流分为线上和线下两部分，线上应用和线下行为的不一致，线下端的数据不可能全部放到云端。**菜鸟现在在做边缘计算节点利用网格计算的思路，成为计算容器，既能承担局域网的路由和网关，同时成为万物计算节点，它和中心节点的差异只是计算能力的差异，而不是它自身的环境、架构、结构上的差异，这就是菜鸟网格计算正在推进的方向。

12 月 7 日在北京国际会议中心举办的 ArchSummit 全球架构师技术峰会上，菜鸟网络的技术专家们也会分享近来菜鸟在技术上的新研究成果，包括 CTO 谷雪梅老师也会来分享“菜鸟 IoT 战略和智慧物流的实践”内容。

创作场景

菜鸟，下一代分布式体系架构的设计理念