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

来源 | 阿里巴巴云原生公众号

做者 | 溪恒、遥方

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

申通是目前国内最大的物流公司之一，为了解决 “双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. 服务网格

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