作者: 黄浩

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,是每个物体都像一台电脑,每台电脑的关系是,能相互之间可控组网,二是逐级联系。 菜鸟物流分为线上和线下两部分,线上应用和线下行为的不一致,线下端的数据不可能全部放到云端。 菜鸟现在在做边缘计算节点利用网格计算的思路,成为计算