申通快递 双11 云原生应用实践

作者 | 溪恒、遥方

一年一度的 “双11” 大促中，交易额每年都在刷新，承接这些交易商品的快递包裹的数量也在成倍增长。这些快速的增长对物流系统带来了巨大的挑战，让物流管理更加敏捷来应对 “双11” 成为了必须解决的问题。

最开始.jpg

申通是目前国内最大的物流公司之一，为了解决 “双11” 的技术挑战，申通在物流场景引入 IOT、大数据和 AI 等先进和创建的技术手段，通过不断的技术快速迭代，使得物流资源得到有效的配置，推动了物流行业的发展。

快速的技术迭代带来了对 IT 基础设施的挑战，申通近年来全面将传统应用切换使用云原生架构，通过云原生架构实现应用的快速迭代、稳定的高可用、资源的动态扩缩容来支撑起快速的技术创新。

上云前，申通使用线下机房作为计算及数据存储平台，一到双11 资源需求就膨胀，大促之后则闲置浪费；上云和云原生化后，几乎全部的资源都是按量购买，使用云原生技术快速扩缩容，双11 前快速扩容，双11 释放，真正做到了开箱即用，不产生一天浪费。与去年双11 当天相比，今年 11 月 1 到 3 日，在业务量大幅提升的情况下，IT 投入反而降低了 30%。上云的成效显著。

申通云原生化架构的背景

目前申通正在把业务从 IDC 机房往云上搬迁，核心业务系统目前已经在云上完成流量承接。原有 IDC 系统帮助申通早期业务快速发展，但也暴露了不少问题，传统 IOE 架构，各系统架构的不规范，稳定性，研发效率等都限制了业务发展需求。

随着云计算在国内的越发成熟，更多的企业在把自己核心系统往云上搬，享受云计算带来的技术红利。在跟阿里云多次技术交流之后最终确定阿里云为唯一合作伙伴，为申通提供稳定的计算、数据处理平台。

采用云原生应用架构的诉求/驱动力

快递公司是非常典型的云边一体架构，实操环节很重。大量的业务逻辑下沉到边缘，所以申通在上云改造过程中，也在尝试做云边一体化的架构升级。通过云边一体，可以让开发在同一个平台上面完成云上业务及边缘侧的业务开发。同时快递公司还有典型的大数据处理场景，全网每天会新增几亿条扫描数据，需要对这些数据进行实时分析，对数据的处理要求非常高。

之前使用线下机房作为计算及数据存储平台的方式，使申通在业务增长过程中遇到了一些瓶颈，比如软件交付周期过长、大促保障对资源的要求、系统稳定性挑战等等。而云原生技术就是来解决传统应用升级缓慢、架构臃肿、不能快速迭代等方面的问题。正是看中了云原生技术能够给我们带来的价值才驱使我们转为使用公有云作为主要计算资源。

站在企业的角度来看，在这样一个快速多变的时代，云原生给我们带来的价值也正是企业最需要的：

唯快不破。这里的“快”有两层含义，一是业务应用快速上线，通过云原生技术可以做到快速上线部署；二是在业务爆发式增长的时候，对资源的需求要做到开箱即用。
稳中求变。业务稳定性永远是第一位。通过监控埋点，业务日志收集，链路监控等手段保证了在快速迭代过程中业务系统的稳定性。
节省资源。通过对计算资源的水位监测，结合业务的峰值情况，当发现资源利用率偏低采用降配规格及数量，降低整个资源的费用。相比于一次性投入租建机房及相应的维护费用，使用公有云成本投入更低。
开拓创新。采用微服务架构，将之前臃肿的架构进行合理拆分，再结合容器编排的能力做到持续交付。让企业成功转型成为一家 DevOps 驱动的公司。

申通云原生架构历程

1. 云原生化技术改造

原架构是基于 Vmware+Oracle 数据库的架构，通过上阿里云全面转型基于 Kubernetes 的云原生架构体系。应用服务架构重构主要分两部分：

1）程序代码改造升级

应用容器化

跟虚拟机比起来，容器能同时提供效率和速度的提升，让其更适合微服务场景。所以我们引入容器技术。通过应用容器化解决了环境不一致的问题，保证应用在开发、测试、生产环境的一致性。

微服务改造

原先很多业务是基于 Oracle 的存储过程及触发器完成的，系统之间的服务依赖也是走的数据库 OGG 同步完成。带来的问题就是系统非常难维护，也非常不稳定。通过引入 Kubernetes 的服务发现来做微服务方案，按业务域进行拆分，让整个系统更易于维护。

2）引入云原生数据库方案

通过引入 OLTP 跟 OLAP 型数据库，将在线数据与离线分析逻辑拆到两种数据库中，取代之前完全依赖 Oracle。特别是在处理历史数据查询场景下解决了 Oracle 支持不了的业务需求。

2. 云原生技术框架设计

整体架构

架构阐述：

基础设施

全部的计算资源取自阿里云的神龙裸金属服务器，Kubernetes 搭配神龙服务器能够获得更佳性能及更合理的资源利用率，云上资源可以按量付费，特别适合大促场景，大促结束之后资源使用完释放。相比于线下自建机房和常备机器，云上资源操作更方便，管理成本也更低。

流量接入

共有 2 套流量接入，一套是面向公网请求，另外一套是服务内部调用。域名解析采用云 DNS 及 PrivateZone。借助 Kubernetes 的 Ingress 能力来做统一的域名转发，这样可以节省公网 SLB 的数量便于运维管理。

3. 平台选择

整体的云原生 PaaS 平台基于阿里云容器服务 Kubernetes 版（ACK）打造：

平台特点：

测试、集成、预发、生产统一环境，打通 DevOps 闭环
天生资源隔离，机器资源利用率高
流量接入可实现精细化管理
集成了日志、链路诊断、Metrics 平台
统一 APIServer 接口和扩展，天生支持多云跟混合云部署

4. 应用服务层设计

每个应用都在 Kubernetes 上面创建单独的一个 NameSpace，应用跟应用之间是资源隔离。通过定义各个应用的配置 Yaml 模板，当应用在部署的时候直接编辑其中的镜像版本即可快速完成版本升级，当需要回滚的时候直接在本地启动历史版本的镜像快速回滚。

5. 运维管理

线上 Kubernetes 集群都是采用了阿里云托管版容器服务，免去了运维 Master 节点的工作，只需要制定 Worker 节点上线及下线流程即可。同时上面跑的业务系统均通过我们的 PaaS 平台完成业务日志搜索，按照业务需求投交扩容任务，系统自动完成扩容操作。降低了直接操作 Kubernetes 集群带来的风险。

申通云原生应用服务特点

1. API 接口

我们的应用场景主要有 2 块：

封装 Kubernetes 管控 API

包括创建 StatefulSet、修改资源属性、创建 Service 资源等等，通过封装这些管控 API 方便通过一站式的 PaaS 平台来管理在线应用。

云原生业务系统

我们云上的业务系统封装了各类云资源的 API，比如：封装 SLS 的 API、将在线数据写入 SLS 再跟 Maxcompute 或 Flink 集成。封装 OSS 的 API，方便在应用程序中将文件上传。

2. 应用和数据迁移

我们云上的业务系统及业务中间件都是通过镜像的方式部署，应用的服务通过 Service 发现，全部在线应用对应的 Pod 及 Service 配置均保存 PaaS 平台里面，每个应用历史版本对应的镜像版本都保存到系统中，可以基于这份配置快速构建一套业务生产环境。

数据迁移示意图：

通过 DTS 工具将业务系统的数据从 IDC 存储及增量迁移到云上。在线数据稳定地存储在云原生的数据库上面，如 OLTP 类型的 RDS、PolarDB 支撑高并发的实时处理，OLAP 类型的 ADB 支持海量数据分析。同时对于小文件存储保存在 OSS 上面。引入 NAS 做共享存储介质，通过 Volume 直接挂载到神龙节点来实现应用数据共享。

3. 服务集成

以云原生 PaaS 示意：

服务集成阐述

持续集成通过 Git 做版本控制，利用云效的持续集成功能实现了云原生应用的构建、编译及镜像上传，全部的业务镜像均保存在云端的镜像服务仓库。底层是 Kubernetes 集群作为整个业务的计算资源。其他集成的服务包括：

日志服务，通过集成日志服务方便研发人员方便定位业务及异常日志。
云监控，通过集成监控能力，方便运维研发人员快速发现故障。
服务接入，通过集成统一的接入，整个应用流量可做到精细化管理。
弹性伸缩，借助 ESS 的能力对资源进行动态编排，结合业务高低峰值做到资源利用率最大化。

4. 服务高可用

ACK 集群多层级高可用示意图

架构说明：

支持多可用区部署架构，由用户自定义分配比例
容器集群内故障迁移
AZ 故障整体容器迁移

Kubernetes集群通过控制应用的副本数来保证集群的高可用。当某个 Pod 节点出现当机故障时，通过副本数的保持可以快速在其他 worker 节点上再启新的 Pod。

5. 监控

主动发现业务故障，通过引入监控体系主动发现业务问题，快速解决故障。

监控采集示意图

在同一个 POD 里面部署了两个容器：一个是业务容器；一个是 Logtail 容器。应用只需要按照运维定的目录将业务日志打进去，即可完成监控数据采集。

技术/应用服务创新点

1. 从虚拟机到 Kubernetes

相比于通过虚拟机来运维应用，Kubernetes 可以将各类资源定义成描述文件，整个应用环境通过容器的方式统一，避免环境不一致的风险。通过修改副本数即可轻松完成应用容器的扩缩容操作。

2. 基于 Terway 让 Pod 和 ECS 网络处于同等地位

优势：

不依赖 VPC 路由表，就能打通网络，节点规模不受路由表 Quota 限制
不需要额外为 Pod 规划 Overlay 的网段
混合云专线打通也无需额外配置路由
可以直接将 POD 挂到 SLB 后端
性能高，相比于社区的 Flannel 提升至少 20%

3. 定义三套接入环境及三套业务环境

架构示意图

1）三套接入环境

公网接入：适合于跟外部客户对接，通过统一的证书卸载，收敛公网 IP
办公网接入：适合于有敏感接口的对接，只允许指定源 IP 的请求，通过网络 ACL 让整个应用访问更安全。
内网接入：适合于业务之间及混合云架构下 IDC 的业务调用云上应用，内部调用性能更高也更安全。

2）三套业务环境

测试环境：全部的云资源都是给测试环境使用，可以采用低配资源来满足功能回归测试。
预发环境：准上线环境，连接生产环境的资源进行发布前最后一次功能验证。
生产环境：实际运行环境，接收真实流量处理业务请求。

应用效益

1. 成本方面

使用公有云作为计算平台，可以让企业不必因为业务突发增长的需求，而一次性投入大量资金成本用于采购服务器及扩充机柜。在公共云上可以做到随用随付，对于一些创新业务想做技术调研是非常方便。用完即销毁，按量付费。另外云产品都是免运维自行托管在云端，可以节省人工运维成本，让企业更专注于做核心业务。

2. 稳定性方面

云上产品都是提供至少 5 个 9 以上的 SLA 服务，而自建的话稳定性差不少。另外有些开源的软件可能还存在部分功能上的 bug 影响了业务。另外在数据安全方面云上数据可以做到异地备份，阿里云数据类产品的归档高可靠、低成本、安全性、存储无限等特点，让企业数据更安全。

3. 效率方面

借助跟云产品的深度集成，方便研发一站式完成研发、运维工作。从业务需求立项到拉分支开发，再到测试环境功能回归验证，再部署到预发验证及最后上线，整个持续集成可以做到分钟级。排查问题方面，研发直接选择所负责的应用通过集成的 SLS 日志控制台快速检索程序的异常日志，定位问题。免去了登录机器查日志的麻烦。赋能业务：

4. 赋能业务

云上组件有 300 多种，涵盖了计算、AI、大数据、IOT 等等诸多领域，这样可以节省业务创新带来的技术成本。

总结和后续展望

目前申通已经使用云原生技术快速的将基础设施迁移到云上，使用云原生技术解决了双十一成本预算问题，服务监控问题，服务接入和负载均衡等问题，让双11 的快递高峰能够更低成本、更稳的方式应对。

对于类似于申通这样的传统企业数字化转型和上云来说，使用云原生技术内置的弹性、监控、负载均衡和服务发现等能力，可以大幅降低企业研发和运维人员的迁云的成本，让企业的研发和运维人员只需要关心业务研发和迁移，而无需管理大量的基础设施迁移成本。可以说是企业上云的最佳路径。

将来申通还在持续的利用最新的云原生技术继续优化基础设施和业务系统，下一步将会结合云原生技术进一步的降低成本和提升业务稳定性：

1. 实时的弹性调度

申通的快递业务是非常典型周期性业务，使用云原生技术的实时的弹性调度能力可以让每天的业务高低峰都能自动弹性伸缩。可能再节省一大笔的资源成本。

2. 智能运维和安全生产

结合云原生的细粒度的监控能力，结合 AIOPS 技术，对系统和业务的指标做到自动分析诊断，从而让异常事件做到及时发现和处理。

3. 服务网格

引入服务网格来优化目前的微服务架构，统一微服务调用的协议，实现全链路追踪和监控，提升研发和运维的效率。