快递行业核心业务系统云原生化上云技术详解

随着云计算的快速发展和成熟，越来越多的企业正在把自己的核心系统向云上迁移，从而享受云计算带来的技术红利。IDC发布的《全球云计算IT基础设施市场预测报告》显示：2019年全球云上的IT基础设施占比超过传统数据中心，成为市场主导者。在技术层面，云计算在成本、稳定、安全和效率层面已经远超传统IT。对于企业而言，上云后综合成本下降一半，稳定性有10倍以上提升，安全性更是提升50倍。这些信号都在标志着以云计算为基础的数字化时代全面到来。

申通快递创建于1993年，是国内较早经营快递业务的民营快递品牌。与很多同行一样，早期的信息系统建设也采用外包承接的方式运作。2016年年底，申通快递正式登陆深交所。作为快递行业巨头之一，申通上市的目的，除了要把业务规模做大外，很重要的一点是要在技术上下功夫，打造公司核心的竞争力，构建行业的高生态壁垒，抵抗“外敌”入侵。

2019年年底，申通选择全面迁移至阿里云，也因此成为业内首个全面上云的快递企业。这次全面上云，不只是变革基础架构，更是对研发模式的一次重要变革。今年6月，申通通用云原生计算平台被云原生开源产业联盟、CNCF基金会联合选为“2020年度云原生应用十大优秀案例”之一。以下是关于申通快递核心业务系统云原生化上云的详解，

1、为什么要用云原生应用架构？

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

申通以前使用线下机房作为计算及数据存储平台，随着业务量的快速增长，原有的IT系统遇到了一些瓶颈，比如软件交付周期过长，大促保障对资源的要求高、系统稳定性差等。从申通内部看，基于传统IOE架构构建的系统无法支撑业务高速增长后的数据量膨胀，受限于容量订单系统，只能保留3~6个月的信息查询，且无法对历史包裹进行在线搜索，相关应用都会受阻。从外部看，包裹流转如何借助数据技术和IoT等技术来提升效率日益成为快递行业的竞争焦点。

云原生技术天然适合解决传统应用升级缓慢、架构臃肿、不能快速迭代等问题。具体来看，云原生有四点优势是企业迫切需要的，一是速度快，通过云原生技术可以做到业务快速上线部署，这就在市场需求多变的竞争中抢得了先机；另外，在业务爆发式增长的时候，云原生可以对资源的需求做到开箱即用。

二是提升业务的稳定性。通过监控埋点、业务日志收集、链路监控等手段可以保证业务系统在快速迭代过程中保持稳定性。依赖Kubernetes为核心的数据中心，通过应用编排、业务故障自愈的能力让整个系统更稳定。

三是节省资源。通过对计算资源的水位监测，结合业务的峰值情况，当发现资源利用率偏低时，采用降配规格及数量，降低整个资源的费用。相比于一次性投入租建机房及相应的维护费用，使用公有云成本投入更低。利用公有云低成本的硬件、无需关注基础设施、零交付周期的优势，结合容器技术可以做到业务实时按需动态伸缩资源。

四是采用微服务架构，将之前臃肿的架构进行合理拆分，再结合容器编排的能力做到持续交付，可以让企业成功转型成为一家Devops驱动的公司。
正是看中了云原生技术为企业带来的优势，最终申通选择核心系统以云原生化的方式上云。

2、申通云原生应用架构设计路线

申通原来的IT架构是基于VMware+Oracle数据库的架构，与阿里云原生团队沟通后，决定采用基于Kubernetes的云原生架构体系。对应用服务架构进行，主要做了程序代码改造升级和引入云原生数据库。

程序代码改造升级

申通程序代码改造升级主要两部分升级，一是应用容器化，跟虚拟机比起来，容器可以同时提升效率和速度，让其更适合微服务场景。引入容器技术，解决了环境不一致的问题，保证应用在开发、测试、生产环境的一致性。二是微服务改造，原来，申通的很多业务是基于Oracle的存储过程及触发器完成，系统之间的服务依赖也是依靠数据库OGG同步完成。这么做带来的问题就是系统维护非常困难，稳定性非常差。通过引入Kubernetes的服务发现来做微服务方案，按业务域进行拆分，使整个系统更易于维护。

引入云原生数据库方案

通过引入OLTP和OLAP型数据库，将在线数据与离线分析逻辑拆到两种数据库中，不再完全依赖Oracle。这就解决了在历史数据查询场景下Oracle支持不了的业务需求。综合考虑申通业务和技术特点，最终选择了阿里云ACK+神龙+云数据库的云原生解决方案，实现核心应用搬迁上阿里云。申通云原生应用技术框架如下图所示。

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

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

在平台层，申通基于Kubernetes打造的云原生PaaS平台如下图所示。

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

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

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

云原生应用服务特点

1、 API接口化

API接口化应用场景主要有两个，一是封装Kubernetes管控API：包括创建StatefulSet，修改资源属性，创建Service资源等，通过封装这些管控API，可以通过一站式的PaaS平台来管理在线应用。二是云原生业务系统，云上的业务系统封装了各类云资源的API，如封装SLS的API，将在线数据写入SLS再跟Maxcompute或Flink集成。封装OSS的API，方便在应用程序中将文件上传。

2、应用和数据迁移

云上的业务系统及业务中间件都是通过镜像的方式部署，应用的服务通过Service发现，全部的在线应用（300+）对应的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。通过引入监控体系主动发现业务问题，快速解决故障。监控采集示意如下图所示。

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

技术创新点

1、从虚拟机到Kubernetes

相比于通过虚拟机来运维应用，Kubernetes可以将各类资源定义成描述文件，整个应用环境通过容器的方式统一，避免环境不一致的风险。通过修改副本数即可轻松完成应用容器的扩缩容操作。Kubernetes提供了一个非常容易的机制来帮助用户打包应用，并且能快速部署到任意一个环境中，实现快速扩容、缩容的目的。

2、从单体应用到微服务

单体架构，系统与系统之间是紧耦合模式。随着代码库的不断加大，添加或者改变单体应用程序的功能就变得越来越复杂。而微服务架构是松耦合状态，每一个团队做一个服务，每个服务执行一个功能，系统与系统之间是相互独立的状态，可以让不同的团队开发不同的服务，通过轻量级的API调用来实现服务与服务之间的串联。对某个服务进行扩展，只扩展单个系统就能实现，修改代码也不影响其他应用。

3、基于Terway让Pod和ECS网络处于同等地位

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

4、定义三套接入环境及三套业务环境

定义三套环境主要是为了解决研发环境的问题，定义日常、预发、生产环境，方便研发做测试回归；定义三套业务环境主要是为了网络接入方便，这样内部应用可以走内部接入，从网络隔离上面保护系统。

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