如果说，快递行业上半场的竞争拼的是规模、服务乃至价格，进入下半场，快递企业们还需要比拼硬核的技术实力。
随着云计算的快速发展和成熟，越来越多的企业正在把自己的核心系统向云上迁移，从而享受云计算带来的技术红利。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 集群带来的风险。
云原生应用服务特点
API 接口化
API 接口化应用场景主要有两个，一是封装 Kubernetes 管控 API：包括创建 StatefulSet，修改资源属性，创建 Service 资源等，通过封装这些管控 API，可以通过一站式的 PaaS 平台来管理在线应用。二是云原生业务系统，云上的业务系统封装了各类云资源的 API，如封装 SLS 的 API，将在线数据写入 SLS 再跟 Maxcompute 或 Flink 集成。封装 OSS 的 API，方便在应用程序中将文件上传。
应用和数据迁移
云上的业务系统及业务中间件都是通过镜像的方式部署，应用的服务通过 Service 发现，全部的在线应用（300+）对应的 Pod 及 Service 配置均保存在 PaaS 平台里面，每个应用历史版本对应的镜像版本都保存到系统中，可以基于这份配置快速构建一套业务生产环境。数据迁移如下图所示。
通过 DTS 工具将业务系统的数据从 IDC 存储及增量迁移到云上。在线数据稳定地存储在云原生的数据库上面，如 OLTP 类型的 RDS、PolarDB 支撑高并发的实时处理，OLAP 类型的 ADB 支持海量数据分析。同时对于小文件存储保存在 OSS 上面。引入 NAS 做共享存储介质，通过 Volume 直接挂载到神龙节点来实现应用数据共享。
服务集成
云原生 PaaS 服务集成如下图所示。
持续集成通过 Git 做版本控制，利用云效的持续集成功能实现了云原生应用的构建、编译及镜像上传，全部的业务镜像均保存在云端的镜像服务仓库，底层是 Kubernetes 集群作为整个业务的计算资源。其他集成的服务包括：
日志服务，通过集成日志服务方便研发人员方便定位业务及异常日志。
云监控，通过集成监控能力，方便运维研发人员快速发现故障。
服务接入，通过集成统一的接入，整个应用流量可做到精细化管理。
弹性伸缩，借助 ESS 的能力对资源进行动态编排，结合业务高低峰值做到资源利用率最大化。
服务高可用
ACK 集群多层级高可用示意如下图所示。
架构说明：
支持多可用区部署架构，由用户自定义分配比例。
容器集群内故障迁移。
AZ 故障整体容器迁移。
Kubernetes 集群通过控制应用的副本数来保证集群的高可用。当某个 Pod 节点出现宕机故障时，通过副本数的保持可以快速在其他 Worker 节点上再启新的 Pod。通过引入监控体系主动发现业务问题，快速解决故障。监控采集示意如下图所示。
在同一个 Pod 里面部署了两个容器，一个是业务容器，一个是 Logtail 容器。应用只需要按照运维定的目录将业务日志打进去，即可完成监控数据采集。
技术创新点
从虚拟机到 Kubernetes
相比于通过虚拟机来运维应用，Kubernetes 可以将各类资源定义成描述文件，整个应用环境通过容器的方式统一，避免环境不一致的风险。通过修改副本数即可轻松完成应用容器的扩缩容操作。Kubernetes 提供了一个非常容易的机制来帮助用户打包应用，并且能快速部署到任意一个环境中，实现快速扩容、缩容的目的。
从单体应用到微服务
单体架构，系统与系统之间是紧耦合模式。随着代码库的不断加大，添加或者改变单体应用程序的功能就变得越来越复杂。而微服务架构是松耦合状态，每一个团队做一个服务，每个服务执行一个功能，系统与系统之间是相互独立的状态，可以让不同的团队开发不同的服务，通过轻量级的 API 调用来实现服务与服务之间的串联。对某个服务进行扩展，只扩展单个系统就能实现，修改代码也不影响其他应用。
基于 Terway 让 Pod 和 ECS 网络处于同等地位
优势：不依赖 VPC 路由表，就能打通网络，节点规模不受路由表 Quota 限制；不需要额外为 Pod 规划 Overlay 的网段；混合云专线打通也无需额外配置路由；可以直接将 POD 挂到 SLB 后端；性能高，相比于社区的 Flannel 提升至少 10%。
定义三套接入环境及三套业务环境
定义三套环境主要是为了解决研发环境的问题，定义日常、预发、生产环境，方便研发做测试回归；定义三套业务环境主要是为了网络接入方便，这样内部应用可以走内部接入，从网络隔离上面保护系统。
三套接入环境包括公网接入、办公网接入、内网接入。
公网接入：适合于跟外部客户对接，通过统一的证书卸载，收敛公网 IP。
办公网接入：适合于有敏感接口的对接，只允许指定源 IP 的请求，通过网络 ACL 让整个应用访问更安全。
内网接入：适合于业务之间及混合云架构下 IDC 的业务调用云上应用，内部调用性能更高也更安全。
三套业务环境包括测试环境、预发环境、生产环境。
测试环境：全部的云资源都是给测试环境使用，可以采用低配资源来满足功能回归测试。
预发环境：准上线环境，连接生产环境的资源进行发布前最后一次功能验证。
生产环境：实际运行环境，接收真实流量处理业务请求。
应用收益
申通通过云原生化的方式上云，在成本、稳定性、效率、赋能业务四个方面效果显著。
成本方面：使用公有云作为计算平台，不必因为业务突发增长的需求，而一次性投入大量资金成本用于采购服务器及扩充机柜。在公共云上可以做到随用随付，对于一些创新业务想做技术调研非常方便。用完即销毁，按量付费。另外云产品都是免运维自行托管在云端，可以节省人工运维成本，让企业更专注于做核心业务。
稳定性方面：云上产品都是提供至少 5 个 9 以上的 SLA 服务，而自建的话稳定性差不少。另外有些开源的软件可能还存在部分功能上的 bug 影响了业务。另外在数据安全方面云上数据可以做到异地备份，阿里云数据类产品的归档具有高可靠、低成本、安全性、存储无限等特点，让企业数据更安全。
效率方面：借助跟云产品的深度集成，方便研发人员完成一站式研发、运维工作。从业务需求立项到拉分支开发，再到测试环境功能回归验证，再部署到预发验证及最后上线，整个持续集成可以做到分钟级。排查问题方面，研发直接选择所负责的应用通过集成的 SLS 日志控制台快速检索程序的异常日志，定位问题。免去了登录机器查日志的麻烦。
赋能业务：云上组件有 300 多种，涵盖了计算、AI、大数据、IoT 等诸多领域，可以节省业务创新带来的技术成本。目前，申通每天处理订单量在千万级别，处理物流轨迹在亿级别，每天产生的数据量在 1T，使用 1300+个计算节点来实时处理业务。
结束语
企业上云已经是大势所趋。申通核心系统云原生化上云，系统稳定性大幅提升，对于用户的体验也更好了，之前很多业务功能无法实现，现在基本都可以支持。全面上云，除了业务上的价值，还推动了申通内部的技术体系创新，云服务让 DevOps 一体化的良性循环成为可能，运维团队未来除了承担线上保障的责任，还会将更多精力投入到研发支撑工具的创新上。
云原生被企业接受之后，落地的过程仍然要面临一些挑战。但是云原生技术带来的资源成本降低、研发运维效率提升等巨大价值，会驱动企业迎接这些挑战。云原生已经成为释放云价值的最短路径，使用云原生上云，基于容器和服务网格等标准界面和混合云方案，将极大的降低迁云复杂度，使企业可以更快迁移到云上标准服务。通过云原生上云，最大化使用云的能力，高效的社会分工，使企业聚焦于自身业务发展，相信将成为企业的共识。
作者：周金龙（遥方）
中国开源发展研究分析 2022
本次报告为开发者，技术管理者，开源社区运营、市场，开源办公室工作人员带来信息上的增量以及对开源趋势、...
评论