您现在的位置是：首页 > 文章详情

9 月关停线下数据库，申通系统全面迁移到阿里云

日期：2020-06-20点击：395收藏

云栖号资讯：【点击查看更多行业资讯】
在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！

2019 年 12 月，申通技术总架构师醉易在接受媒体采访时表示申通现有的技术架构无法满足快速增长的业务需求，“从内部看，基于传统架构的数据孤岛效应明显导致信息不能共享，业务模式创新受阻，从外部看，包裹流转如何借助数据技术和 IoT 等技术提升效率日益成为核心议题。”为了补齐这些技术短板，申通做出了一个决定：全面上云！

申通是第一个全面上云的快递企业，转眼半年过去了，上云的进程如何了？上云之后的效果如何？…为了搞清楚这些问题，我们采访了申通上云的负责人、菜鸟梧桐项目技术专家周金龙。

申通上云的进程如何？

与其它行业相比，快递公司业务系统中最核心的两个数据要素是订单和扫描轨迹，几乎所有的实操型系统都需要依赖着这两种数据，而围绕订单与扫描的系统自然就成为了核心系统。申通上云的策略也是先从这两类核心系统入手，先将核心应用和数据迁移到云上，然后再逐步将其它依赖系统迁移上云，从而完成全部系统上云。

2019 年 5 月初，申通开始和阿里云团队沟通迁移上云的需求，预计今年 9 月会关停所有本地数据库，完成整个上云项目。

据悉，申通上云项目的挑战在于既要去 Oracle，又要完成上云。如何把成千上万行代码的存储过程全部理解并重新使用 Java 代码完成；面对日均上亿增量数据的系统，如何在不影响业务的情况下将系统迁移上云.

揭秘申通上云的关键阶段

从 2019 年 5 月到至今，申通整个上云过程可以划分为四个关键阶段：

第一阶段：核心系统上云，构建 DevOps 平台及监控系统

2019 年 5 月到 11 月，申通从零开始搭建了混合云网络架构，并基于 Kubernetes 搭建了 DevOps 平台及监控体系，同时，完成了核心系统的迁移上云。这一阶段迁移上云的系统包括订单系统、巴枪系统和时效系统，它们的共同特点是数据量巨大，对性能和稳定性的要求苛刻。

第二阶段：备战双十一，全链路压测

为了备战 2019 年的双十一购物节，申通项目引进了全链路压测平台，全覆盖了 17 条 A 机链路。据悉，在大促前的 40 天内一直不间断地对系统进行全链路压测，对 AB 级链路中超过 25 个系统的应急预案进行了多次全民压测，预演了双十一期间可能出现的所有问题。

2019 年双十一，申通第一次将核心系统运行在公有云上，并成功经受住了这么大流量的考验。

第三阶段：全站上云

双十一的成功给予了申通很大的信心，也就有了文章开头提到的，申通技术总架构师醉易在 2019 年 12 月宣布全面上云。

除了业务系统上云，申通还搭建了自动化测试平台和成本管控系统，通过自动化测试平台可以极大提升系统上云的效率，不用担心因为代码质量问题导致上云故障；通过成本管控系统可以有效发现预算费用发生在哪，更有针对性地优化架构，降低云成本。

据悉，今年 618 申通全部链路都会运行在公有云上。

第四阶段：关停存量服务器及下线数据库

当所有的应用及数据都迁移上云之后，还有一件很重要的事情就是关停现有的存量应用服务器并下线 Oracle 数据库。

据悉，到 2020 年 9 月，申通会关停全部的云下数据库，彻底完成上云项目。

整体来看，申通上云项目包括两个比较关键的路径，一是构建云上基础架构和云原生技术体系，二是将具体的系统迁移上云。

为了使得 IT 系统能够专注在业务上，申通构建了云上基础架构和一套云原生体系，包括了混合云的网络规划设计、K8S 集群的规划设计、微服务的调用规范、PAAS 层的一些规范设计等等。

而具体的系统上云步骤又可分为两个部分：

改动较小的系统上云：这部分的工作量主要集中在去 Oracle，通常这类系统是在代码改造之后，在 PaaS 平台完成功能的全量业务回归、上线前压测，如果确定功能与性能没有问题，就可以顺利切换上云。
改动较大的系统上云：这类系统往往需要结合业务做重构，申通的做法是基于云组件重新进行技术选型，应用了目前比较成熟的阿里云组件，例如 HBase、RDS、Flink 等等，开发人员只需集中于业务适配改造，无需关注底层组件的搭建调优等。

申通电子面单系统的云原生改造

申通全量系统都是基于阿里云组件构建设计的，包括 RocketMQ，ES，Redis 等常用中间件，PolarDB，RDS、DRDS 等云原生数据库。除了云原生组件之外，申通也完成了应用的容器化改造，全量 Java 应用运行在容器中，采用 Kubernetes 作为业务的基础设施，利用 Kubernetes 中的组件来解决服务发现、负载均衡、流量接入等问题。

接下来，我们以电子面单系统为例来看一下申通是如何进行云原生改造的。

据了解，原先的申通电子面单系统共包括近百个应用、数百个实例、数十个存储过程及触发器。整个系统的业务实现基本是靠存储过程、触发器，非常难维护。

电子面单系统的云下架构

2019 年 11 月，电子面单系统开始迁移上云，技术团队重构了整个系统，将与面单库存相关的核心功能做了业务抽象层，定义了关键能力：库存查询、库存发放、面单获取等，将业务逻辑放到了代码中。出于存量数据记录、增量数据存储以及业务查询的需要，电子面单系统还采用了 DRDS+RDS 架构进行分库分表。

电子面单系统的云上架构

经过两个月的代码开发和功能测试，申通电子面单系统完成了云原生改造，应用容器数量降到了十几个实例，应用也收敛到了个位数，整体系统的维护成本大大降低。

成本与稳定性是申通上云的重点

通常企业上云会关注三个方面：研发效率、成本和稳定性，而申通主要关注的是后两个方面，如何通过技术降低成本，如何保证上云之后的稳定性？

周金龙表示：“从现在的日账单来看，排名靠前的是大数据平台，以其中的一个 Project 为例，之前每天的费用大概在 5000 左右，现在通过技术降本，每天只需要 200 元。”

针对云上系统的稳定性，技术团队也采取了多种措施来保障：

代码质量：通过分析历史故障，技术团队发现大量的故障都是因为代码缺陷或者业务没有回归全导致的。所以在代码质量治理方面做了很多功课，例如在持续集成环节强制跑系统的业务用例、核心系统发布之前必须做 CR 等等；
容量问题：在应对大促以及运营高峰时，将链路压测作为常态化，通过压测获得较为准确的容量数据，并提前做好资源准备；
数据库治理：主要是解决慢 SQL 的问题，技术团队研发了一款慢 SQL 分析及预检工具，在提交代码之后，就可以分析出可能存在的慢 SQL，提前发现问题；
强化监控，针对核心系统做全景监控，尽可能覆盖到基础架构、依赖的中间件等等。

当然，申通上云也经历了很多“故事”，周金龙和我们分享了与容器服务、数据同步相关的两个“小插曲”。

第一个是容器服务对应的安全组必须是企业安全组，因为普通安全组会有 2000 个 POD 的上限，一旦集群中的容器超过了上限，就无法创建；第二个是数据在从 RDS 向 Oracle 数据回写时会遇到 NOT NULL 问题，应用程序在云上写了一个空字符串到 RDS 里面，结果数据写不回 Oracle，导致两边数据不一致。这个问题是 RDS 跟 Oracle 在处理空字符串上的处理方式不一致导致的。

出现问题并不可怕，有时甚至会是一件好事，因为这些趟过的坑最终会成为可借鉴的经验，成为上云的最佳实践。

在回顾整个申通上云项目时，周金龙表示最重要的是做好这四件事情：研发层面，帮助研发同学提升从代码构建到代码交付的速度；代码质量层面，保证上线的代码尽可能少出 Bug，最好是在测试环节就可以把代码问题发现并解决掉；稳定性层面，保证线上发生的事情可以快速发现、快速定位、快速恢复；成本层面，确保上云不会给企业带来成本压力。