共计 5019 个字符，预计需要花费 13 分钟才能阅读完成。
起源 | 阿里巴巴云原生公众号
作者 | 溪恒、遥方
一年一度的“双 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. 服务网格
引入服务网格来优化目前的微服务架构，对立微服务调用的协定，实现全链路追踪和监控，晋升研发和运维的效率。