《快递行业云上技术服务白皮书》——4. 快递行业技术服务最佳实践——4.1 核心业务上云最佳实践——4.1.2 云原生应用架构优势（上） https://developer.aliyun.com/article/1224274?groupCode=supportservice

4.1.2.3 引入云原生数据库方案

通过引入OLTP和OLAP型数据库，将在线数据与离线分析逻辑拆到两种数据库中，不再完全依赖Oracle。这就解决了在历史数据查询场景下Oracle支持不了的业务需求，这里主要推荐使用阿里云的Polardb，主要理由如下：

1)支持容量百T的扩容，不用再分库处理，数据量大的，dms提供直接把数据备份到OSS上（OSS的存储成本极低）。

2)分布式数据库，可以做读写分离，且共用一个存储节点，（但注意，有踩坑，这里还是会有部分延迟低，在10ms内）。

3)读节点可以动态扩容，最多扩充到15个读节点（大促期间，可以开启动态扩缩容能力，当cpu超过80%，自动扩容，否则缩容）。

4)当前这里的数据库选型推荐主要基于历史经验，也可以选择RDS-MYSQL作为在线数据处理。

4.1.2.4 云原生Pass服务集成

云原生Pass服务集成如下图所示：

图9：云原生Pass服务集成图

持续集成通过Git做版本控制，利用云效的持续集成功能实现了云原生应用的构建、编译及镜像上传，全部的业务镜像均保存在云端的镜像服务仓库，底层是Kubernetes集群作为整个业务的计算资源。其他集成的服务包括：

日志服务：通过集成日志服务方便研发人员方便定位业务及异常日志。

云监控：通过集成监控能力，方便运维研发人员快速发现故障。

服务接入：通过集成统一的接入，整个应用流量可做到精细化管理。

弹性伸缩：借助ESS的能力对资源进行动态编排，结合业务高低峰值做到资源动态分配。

4.1.2.5 容器服务集群高可用架构

ACK集群多层级高可用示意如下图所示：

图10：ACK集群多层级高可用示意图

架构说明：

•容器集群内故障迁移。

•AZ故障整体容器迁移。

Kubernetes集群通过控制应用的副本数来保证集群的高可用。当某个Pod节点出现宕机故障时，通过副本数的保持可以快速在其他Worker节点上再启新的Pod。

通过引入监控体系主动发现业务问题，快速解决故障。监控采集示意如下图所示。

图11：监控采集示意图

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

云原生应用架构改造后的技术架构图如下：