云原生架构实战案例及优化解决方案

╰半夏微凉° 2023-09-28 13:16 28阅读 0赞

# 前言 #

随着云计算的普及与云原生的广泛应用，越来越多的从业者、决策者清晰地认识到「云原生化将成为企业技术创新的关键要素，也是完成企业数字化转型的最短路径」。因此，具有前瞻思维的互联网企业从应用诞生之初就扎根于云端，谨慎稳重的新零售、政府、金融、医疗等领域的企业与机构也逐渐将业务应用迁移上云，深度使用云原生技术与云原生架构。面对架构设计、开发方式到部署运维等不同业务场景，基于云原生架构的应用通常针对云的技术特性进行技术生命周期设计，最大限度利用云平台的弹性、分布式、自助、按需等产品优势。借助以下几个典型实践案例，我们来看看企业如何使用云原生架构解决交付周期长、资源利用率低等实际业务问题。

# 案例一：申通快递核心业务系统云原生化上云案例 #

**背景和挑战**

作为发展最为迅猛的物流企业之一，申通快递一直积极探索技术创新赋能商业增长之路，以期达到降本提效目的。目前，申通快递日订单处理量已达千万量级，亿级别物流轨迹处理量，每天产生数据已达到 TB 级别，使用 1300+ 个计算节点来实时处理业务。

过往申通快递的核心业务应用运行在 IDC 机房，原有 IDC 系统帮助申通安稳度过早期业务快速发展期。但伴随着业务体量指数级增长，业务形式愈发多元化。原有系统暴露出不少问题，传统 IOE 架构、各系统架构的不规范、稳定性、研发效率都限制了业务高速发展的可能。软件交付周期过长，大促保障对资源的特殊要求难实现、系统稳定性难以保障等业务问题逐渐暴露。

在与阿里云进行多次需求沟通与技术验证后，申通最终确定阿里云为唯一合作伙伴，采用云原生技术和架构实现核心业务搬迁上阿里云。2019 年开始将业务逐步从 IDC 迁移至阿里云。目前，核心业务系统已经在阿里云上完成流量承接，为申通提供稳定而高效的计算能力。

**云原生解决方案**

申通核心业务系统原架构基于 Vmware+Oracle 数据库进行搭建。随着搬迁上阿里云，架构全面转型为基于  
Kubernetes 的云原生架构体系。其中，引入云原生数据库并完成应用基于容器的微服务改造是整个应用服务架构重构的关键点。

• 引入云原生数据库

通过引入 OLTP 跟 OLAP 型数据库，将在线数据与离线分析逻辑拆分到两种数据库中，改变此前完全依赖 Oracle 数据库的现状。满足在处理历史数据查询场景下 Oracle 数据库所无法支持的实际业务需求。

• 应用容器化

伴随着容器化技术的引进，通过应用容器化有效解决了环境不一致的问题，确保应用在开发、测试、生产环境的一致性。与虚拟机相比，容器化提供了效率与速度的双重提升，让应用更适合微服务场景，有效提升产研效率。

• 微服务改造

由于过往很多业务是基于 Oracle 的存储过程及触发器完成的，系统间的服务依赖也需要 Oracle 数据库  
OGG 同步完成。这样带来的问题就是系统维护难度高且稳定性差。通过引入 Kubernetes 的服务发现，组建  
微服务解决方案，将业务按业务域进行拆分，让整个系统更易于维护。

综合考虑申通实际业务需求与技术特征，最终选择了「阿里云 ACK+ 神龙 + 云数据库」的云原生解决方案，从而实现核心应用迁移上阿里云。

![请添加图片描述][9fd1dbd701564888b1b52caaa75848ec.png]

**架构阐述**

基础设施，全部计算资源取自阿里云的神龙裸金属服务器。相较于一般云服务器（ECS），Kubernetes 搭配神龙服务器能够获得更优性能及更合理的资源利用率。且云上资源按需取量，对于拥有大促活动等短期大流量业务场景的申通而言极为重要。相较于线下自建机房、常备机器，云上资源随取随用。在大促活动结束后，云上资源使用完毕后即可释放，管理与采购成本更低，相应效率。

流量接入，阿里云提供两套流量接入，一套是面向公网请求，另外一套是服务内部调用。域名解析采用云 DNS  
及 PrivateZone。借助 Kubernetes 的 Ingress 能力实现统一的域名转发，以节省公网 SLB 的数量，提高运维管理效率。

**平台层**

基于 Kubernetes 打造的云原生 PaaS 平台优势明显突出。

打通 DevOps 闭环，统一测试，集成，预发、生产环境；

天生资源隔离，机器资源利用率高；

流量接入可实现精细化管理；

集成了日志、链路诊断、Metrics 平台；

统一 ApiServer 接口和扩展，天生支持多云跟混合云部署。

**应用服务层**

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

**运维管理**

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

**应用效益**

成本方面：使用公有云作为计算平台，可以让企业不必因为业务突发增长需求，而一次性投入大量资金成本用于采购服务器及扩充机柜。在公共云上可以做到随用随付，对于一些创新业务想做技术调研十分便捷。用完即释放，按量付费。另外云产品都免运维自行托管在云端，有效节省人工运维成本，让企业更专注于核心业务。  
稳定性方面：首先，云上产品提供至少 5 个 9 以上的 SLA 服务确保系统稳定，而自建系统稳定性相去甚远。其次，部分开源软件可能存在功能 bug，造成故障隐患。最后，在数据安全方面云上数据可以轻松实现异地备份，阿里云数据存储体系下的归档存储产品具备高可靠、低成本、安全性、存储无限等特点，让企业数据更安全。

效率方面：借助与云产品深度集成，研发人员可以完成一站式研发、运维工作。从业务需求立项到拉取分支开发，再到测试环境功能回归验证，最终部署到预发验证及上线，整个持续集成流程耗时可缩短至分钟级。排查问题方面，研发人员直接选择所负责的应用，并通过集成的 SLS 日志控制台快速检索程序的异常日志进行问题定位，免去了登录机器查日志的麻烦。

赋能业务：阿里云提供超过 300 余种的云上组件，组件涵盖计算、AI、大数据、IOT 等等诸多领域。研发人员开箱即用，有效节省业务创新带来的技术成本。

# 案例二： 完美日记电商业务案例 #

**背景和挑战**

作为美妆届的璀璨新星，完美日记（Perfect Diary）上线不到两年即成为天猫彩妆销冠，截至 2020 年 4 月，品牌 SKU 超过 700 个，全网用户粉丝数量超过 2500 万，月曝光量 10 亿 +。

伴随着公司业务高速发展，技术运维对于面临着非常严峻的挑战。伴随着“双 11”电商大促、“双 12”购物节、小程序、网红直播带货呈现爆发式增长趋势，如何确保微商城系统稳定顺畅地运行成为完美日记面对的首要难题。其中，比较突出几个挑战包含以下几点：

系统开发迭代快，线上问题较多，定位问题耗时较长；

频繁大促，系统稳定性保障压力很大，第三方接口和一些慢 SQL 存在导致严重线上故障的风险；

压测与系统容量评估工作相对频繁，缺乏常态化机制支撑；

系统大促所需资源与日常资源相差较大，需要频繁扩缩容。

**云原生解决方案**

完美日记与阿里云一起针对所面临问题以及未来业务规划进行了深度沟通与研讨。通过阿里云原生应用稳定性解决方案以解决业务问题。引入阿里云容器服务 ACK、Spring Cloud Alibaba、PTS、AHAS、链路追踪等配套产品，对应用进行容器化改造部署，优化配套的测试、容量评估、扩所容等研发环节，提升产研效率。

![请添加图片描述][9f56e3b3b2384b42a42e2388d2b8b37c.png]

方案的关键点是：

*  通过容器化部署，利用阿里云容器服务的快速弹性应对大促时的资源快速扩容。
 *  提前接入链路追踪产品，用于对分布式环境下复杂的服务调用进行跟踪，对异常服务进行定位，帮助客户在测试和生产中快速定位问题并修复，降低对业务的影响。
 *  使用阿里云性能测试服务（PTS）进行压测，利用秒级流量拉起、真实地理位置流量等功能，以最真实的互联网流量进行压测，确保业务上线后的稳定运营。
 *  采集压测数据，解析系统强弱依赖关系、关键瓶颈点，对关键业务接口、关键第三方调用、数据库慢调用、系统整体负载等进行限流保护。
 *  配合阿里云服务团队，在大促前进行 ECS/RDS/ 安全等产品扩容、链路梳理、缓存 / 连接池预热、监控大屏制作、后端资源保障演练等，帮助大促平稳进行。

**应用收益**

高可用：利用应用高可用服务产品（AHAS）的限流降级和系统防护功能，对系统关键资源进行防护，并对整体系统水位进行兜底，确保大促平稳进行，确保顺畅的用户体验。

容量评估：利用性能测试服务（PTS）和业务实时监控（ARMS）对系统单机能力及整体容量进行评估，对单机及整体所能承载的业务极限量进行提前研判，以确保未来对业务大促需求可以做出合理的资源规划和成本预测。

大促保障机制：通过与阿里云服务团队的进行多次配合演练，建立大促保障标准流程及应急机制，达到大促保障常态化。

**客户声音**

“使用 ACK 容器服务可以帮助我们快速拉起测试环境，利用 PTS 即时高并发流量压测确认系统水位，结合  
ARMS 监控，诊断压测过程中的性能瓶颈，最后通过 AHAS 对突发流量和意外场景进行实时限流降级，加上阿里云团队保驾护航，保证了我们每一次大促活动的系统稳定性和可用性，同时利用 ACK 容器快速弹性扩缩容，节约服务器成本 50% 以上。”——完美日记技术中台负责人

# 案例三： 特步业务中台案例 （零售、公共云） #

**背景和挑战**

成立于 2001 年的特步，作为中国领先的体育用品企业之一，门店数 6230 家。2016 年，特步启动集团第三次战略升级，打造以消费者体验为核心的“3+”( 互联网 +、体育 + 和产品 +) 的战略目标，积极拥抱云计算、大数据等新技术，实现业务引领和技术创新，支撑企业战略变革的稳步推进。在集团战略的促使下，阿里云中间件团队受邀对特步 IT 信息化进行了深度调研，挖掘阻碍特步战略落地的些许挑战：

*  商业套件导致无法满足特步业务多元化发展要求，例如多品牌拆分重组所涉及的相关业务流程以及组织调整。对特步而言，传统应用系统都是紧耦合，业务的拆分重组意味着必须重新实施部署相关系统。
 *  IT 历史包袱严重，内部烟囱系统林立。通过调研，阿里云发现特步烟囱系统多达六十三套，仅 IT 供应商就有三十余家。面对线上线下业务整合涉及到的销售、物流、生产、采购、订货会、设计等不同环节及场景，想要实现全渠道整合，需要将几十套系统全部打通。
 *  高库存、高缺货问题一直是服装行业的死结，特步同样被这些问题困扰着。系统割裂导致数据无法实时在线，并受限于传统单体 SQLServer 数据库并发限制，6000 多家门店数据只能采用 T+1 方式回传给总部，直接影响库存高效协同周转。
 *  IT 建设成本浪费比较严重，传统商业套件带来了“烟囱式”系统的弊端，导致很多功能重复建设、重复数据模型以及不必要的重复维护工作。

**云原生解决方案**

阿里云根据特步业务转型战略需求，为之量身打造了基于云原生架构的全渠道业务中台解决方案，将不同渠道通用功能在云端合并、标准化、共享，衍生出全局共享的商品中心、渠道中心、库存中心、订单中心、营销中心、用户中心、结算中心。无论哪个业务线、哪个渠道、哪个新产品诞生或调整，IT 组织都能根据业务需求，基于共享服务中心现有模块快速响应，打破低效的“烟囱式”应用建设方式。全渠道业务中台遵循互联网架构原则，规划线上线下松耦合云平台架构，不仅彻底摆脱传统 IT 拖业务后腿的顽疾并实现灵活支撑业务快速创新，将全渠道数据融通整合在共享服务中心平台上，为数据化决策、精准营销、统一用户体验奠定了良好的产品与数据基础，让特步真正走上了“互联网 +”的快车道。

2017 年 1 月特步与阿里云启动全渠道中台建设，耗时 6 个月完成包括需求调研、中台设计、研发实施、测试验证等在内的交付部署，历经 4 个月实现全国 42 家分公司、6000+ 门店全部上线成功。以下是特步全渠道业务中台总体规划示意图，

![请添加图片描述][49df67b7467e4b72ac43e51534010022.png]

下面是基于云原生中间件的技术架构示意图

![请添加图片描述][5fbd51d91eb1417b838b176f4973776c.png]

架构的关键点：

*  应用侧：新技术架构全面承载面向不同业务部门的相关应用，包括门店 POS、电商 OMS、分销商管理供销存 DRP、会员客户管理 CRM。此外，在全渠道管理方面也会有一些智能分析应用，比如库存平衡，同时可以通过全渠道运营平台来简化全渠道的一些配置管理。所有涉及企业通用业务能力比如商品、订单等，可以直接调用共享中心的能力，让应用“更轻薄”。
 *  共享中心：全渠道管理涉及到参与商品品类、订单寻源、共享库存、结算规则等业务场景，也涉及与全渠道相关的会员信息与营销活动等。这些通用业务能力全部沉淀到共享中心，向不同业务部门输出实时 / 在线 / 统一 / 复用的能力。直接将特步所有订单 / 商品 / 会员等信息融合、沉淀到一起，从根本上消除数据孤岛。
 *  技术层：为了满足弹性、高可用、高性能等需求，通过 Kubernetes/EDAS/MQ/ARMS/PTS 等云原生中间
 *  件产品，目前特步核心交易链路并发可支撑 10w/tps 且支持无线扩容提升并发能力。采用阿里历经多年双 11考验的技术平台，稳定性 / 效率都得到了高规格保障，让开发人员能够更加专注在业务逻辑实现，再无后顾之忧。
 *  基础设施：底层的计算、存储、网络等 IaaS 层资源。
 *  后台系统：客户内部的后台系统，比如 SAP、生产系统、HR/OA 等。

**应用收益**

全渠道业务中台为特步核心战略升级带来了明显的变化，逐步实现了 IT 驱动业务创新。

经过中台改造后，POS 系统从离线升级为在线化。包括收银、库存、会员、营销在内的 POS 系统核心业务全部由业务中台统一提供服务，从弱管控转变为集团强管控，集团与消费者之间真正建立起连接，为消费者精细化管理奠定了坚实的基础。

中台的出现，实现了前端渠道的全局库存共享，库存业务由库存中心实时处理。借助全局库存可视化，交易订单状态信息在全渠道实时流转，总部可直接根据实时经营数据对线下店铺进行销售指导，实现快速跨店商品挑拨。中台上线后，售罄率提升 8%，缺货率降低 12%，周转率提升 20%，做到赋能一线业务。

IT 信息化驱动业务创新，通过共享服务中心将不同渠道类似功能在云端合并共享，打破低效的“烟囱式”应用  
建设方式，吸收互联网 DDD 领域驱动设计原则，设计线上线下松耦合云平台架构，不仅彻底摆脱了传统 IT 拖业务后腿的顽疾并灵活支撑业务快速创新。全渠道数据融通整合在共享服务中心平台上，沉淀和打造出特步的核心数据资产，培养出企业中最稀缺的“精通业务，懂技术”创新人才，使之在企业业务创新、市场竞争中发挥核心作用。截止2019 年初，业务部门对 IT 部门认可度持续上升，目前全渠道业务支撑系统几乎全部自主搭建，80% 前台应用已经全部运行在中台之上，真正实现技术驱动企业业务创新。

本文分享就到这里了，在此如果有对云原生架构感兴趣的朋友，小编也整理了一些云原生资料，可关注微信公众号“老周扯IT”  
![请添加图片描述][a97c880a09864b7586e8215d4c618d8f.png]

[9fd1dbd701564888b1b52caaa75848ec.png]: https://img-blog.csdnimg.cn/9fd1dbd701564888b1b52caaa75848ec.png
[9f56e3b3b2384b42a42e2388d2b8b37c.png]: https://img-blog.csdnimg.cn/9f56e3b3b2384b42a42e2388d2b8b37c.png
[49df67b7467e4b72ac43e51534010022.png]: https://img-blog.csdnimg.cn/49df67b7467e4b72ac43e51534010022.png
[5fbd51d91eb1417b838b176f4973776c.png]: https://img-blog.csdnimg.cn/5fbd51d91eb1417b838b176f4973776c.png
[a97c880a09864b7586e8215d4c618d8f.png]: https://img-blog.csdnimg.cn/a97c880a09864b7586e8215d4c618d8f.png