| 编辑推荐: |
本文主要讲解畅捷通云原生架构转型实战的历程，云原生应用架构的驱动力、云原生应用架构设计、云原生应用技术框架、云原生应用服务特点、云原生带来的技术价值及云原生带来的业务价值。
本文来自于微信公众号阿里巴巴云原生，由Linda编辑、推荐。 |
|
畅捷通公司是用友集团旗下的成员企业，专注于服务国内小微企业的财务和管理服务。一方面，畅捷通将自己的产品、业务、技术架构互联网化；另一方面，畅捷通推出了畅捷通一站式云服务平台，面向小微企业提供以数智财税、数智商业为核心的平台服务、应用服务、业务服务及数据增值服务，致力于建立“小微企业服务生态体系”。
根据易观国际的报告，目前畅捷通在国内小微企业云服务市场的覆盖率保持第一。有超过 130 万家企业与机构通过使用畅捷通的软件及服务，实现降本提效、持续创新、数智化转型。
早期，畅捷通的业务应用都是构建在公司自主研发的 CSP 平台之上，包括客户管家、易代账、好会计和好生意等，每个企业分配一个独立的虚机，资源完全隔离，初期该平台方案极大简化了开发的复杂度，提高了开发效率，满足公司向云服务发展的最初需求。
新的需求
随着用户规模的增多，现有为每个用户分配一个独立虚机的方案产生的问题很突出。首先体现在虚机的数量日益庞大，在客户转换率不高的情况下，容易造成资源的浪费，同时运维成本也偏高；其次，不同的用户软件迭代的版本不尽相同，还需要专门设计维护多套版本的补丁更新系统；第三，产品需要停服上线，业务会出现短暂不可用的情况；最后，如果若干用户的业务出现高峰期，不能快速弹性扩容，资源的利用率不高。
在此背景下，畅捷通研发团队决定尝试当前业界比较通用的云原生架构设计方案，利用云上的基础设施，共享计算资源和存储资源，采用容器化方案，快速弹性扩容，利用微服务架构，按应用更新产品，彻底解决当前运维成本偏高、弹性不足、资源利用不均衡的问题。
小微企业的特点是数量多、单个企业业务量相对较小、企业 IT 能力有限。以畅捷通好生意产品为例，采用现有的云原生架构，能够方便畅捷通快速开发出一款应对大规模小型用户，支持弹性可扩展的
SaaS 应用。同时通过服务的编排，又能快速搭建出其他产品线，如智+。目前已经有超过 20 万的付费用户正在使用畅捷通提供的云原生架构企业云服务，每天产生的业务数据达百
G 以上。
云原生应用架构的驱动力
国内云计算产品快速发展，企业应用往云端迁移趋势明显，加上政府部门鼓励企业上云推出补贴政策，企业上云已成为大势所趋。
尤其在疫情阶段下，商业模式的变革，消费方式的转变，只有企业上云才能更有利于推动企业加快数字化、智能化的转型，更有效的帮助企业实现“客户在线、业务在线、人员在线、管理在线”。而现在的云原生技术带来的价值能更好的帮助企业进行数智转型。
1. 实时在线
采用智能接入网关，就近接入云企业网，在 VPC 间、VPC 与本地数据中心间搭建私网通信通道，通过自动路由分发及学习，提高网络的快速收敛和跨网络通信的质量和安全性，保证用户全球范围实时在线，加速实现整个客群的线上线下一体化。
2. 数智化
通过云端廉价的存储、强大的算力资源以及众多的算法模型，畅捷通用极低的成本存储海量数据并在线实时分析，为用户提供更多的商业决策。
3. 快速响应市场需求
采用 DDD 设计思想，利用微服务架构，快速开发高内聚、低耦合的应用。这些应用通过服务的编排，能快速组合更多的应用，满足不同行业和领域的客户群体，达到快速上线、迭代优化的效果。
4. 稳定高可靠
利用容器和微服务架构，可以快速构建和运行可弹性扩展的应用。系统出现故障或者性能瓶颈的时候，通过镜像可以秒级恢复受损应用，保障了系统的高可用性。利用云原生技术的红利，畅捷通可以只关注业务的开发，一方面加速构建新应用，另一方面也可以优化现有应用并在云原生架构中集成，达到奔跑中更换轮子的效果，去更方便地让历史存量的客户升级到云上。
云原生应用架构设计
云原生应用架构设计路线
原有产品是部署在物理 IDC 中，通过对 cloudfoundry 云平台的二开，实现每个租户间虚机的隔离。但由于每个租户独享容器+数据库，当用户量达到几十万级时，数据库的升级效率、容器部署成本、硬件运维复杂度都明显提升。通过应用的微服务化、上云来解决降本提效的问题迫在眉睫。
畅捷通通过基础设施上云、数据库上云、技术框架和业务框架的重构，实现了在多租户之间容器部署、应用共享、DB
共享，产品基于 EDAS 及集成在其上的阿里云容器服务 Kubernetes 版 ACK。希望通过云原生的技术红利，解决当前运维成本高、系统弹性不足、产品迭代交付周期长的问题。
应用架构的改造
1. 微服务架构
将复杂应用按照业务的视角切分为高内聚、低耦合模块，这些模块独立开发、独立发布。业务领域一共分为四层，即核心领域服务层、业务领域服务层、应用服务层和接口服务层。其中核心领域服务层包括授权、UOM、组织（Party）、产品、计价、促销和存量模型模块，主要提供核心领域知识、能力服务；业务领域服务层是提供好生意业务的业务功能，包括采购、库存管理和销售领域服务；应用服务层基于具体应用场景，调用领域服务，解决应用中具体的业务问题。每层服务都是一个单独的微服务，基于
EDAS 进行服务的全生命周期管理，通过引入 Spring Cloud 实现服务的注册发现以及治理。
此外，由于 EDAS 无缝集成了 ACK ，支持以容器的形式托管应用到阿里云 Kubernetes
集群或混合云集群（其他云域或IDC内自建集群），因此能够与畅捷通底层K8s集群打通，实现了 K8s
集群的定时弹性能力和基于 CPU/RT/Load 等某一监控指标的自动弹性能力。
2. 数据一致性
传统的单一服务架构，所有领域的功能都聚合在一个进程内运行，可以通过数据库的事务来保证业务强一致性。但是畅捷通现在按分布式微服务架构设计，不同领域模块会建成独立运行的微服务，微服务之间需要按照最终一致性方案来保证数据的一致。对于实时性要求高的场景，畅捷通采用
TCC 模型；对于实时性要求不高，可长过程处理的，畅捷通采用消息队列的方式进行服务的解耦，达到最终一致性。
技术架构的改造
1. 容器化管理
核心应用部署在容器中，通过 Kubernetes 进行统一编排和运行调度。对于秒杀场景或者耗算力的异步任务，通过函数计算来按需构建。
2. 服务治理
引入微服务架构后，服务管理尤为复杂，为此畅捷通引入 Spring Cloud 一站式解决方案，使得开发只需要专注业务的发展，不去关注技术细节。通过
Spring Cloud 完成服务发现注册、配置管理、限流降级、服务调用、数据监控等，实现降本提效，也降低了运维成本。
3. Gitops 流水线
基于 Gitlab、Jenkins、Rundeck、K8s，搭建自研的 DevOps 流水线，按照微应用独立构建、微服务自由组包、按照容器化进行发布部署，保证了研发、测试、线上各阶段的运行环境均保持不变。
4. 数据库层面的改造
所有租户共享数据库，按照应用、数据量等因素进行分库分表；引入 OLAP 数据库，分离交易库和分析库，避免大查询拖累用户的交易。
云原生应用技术框架
系统分为前端展现层、业务中台、技术平台、运维中台以及基础设施层。
前端展现层：使用基于微前端应用集成思想形成的 H5 前端开发框架，使用 qiankun 实现同构应用和异构应用的集成，支持多端开发。
业务中台：采用微服务架构的设计思想，基于 EDAS 平台搭建而成，在应用服务层可以实现弹性伸缩、限流降级、流量监控等；业务模型通过元数据驱动并支持
GraphQL 查询；利用 RocketMQ 实现了业务的解耦。
技术中台：包括容器管理、DevOps 流水线、微服务治理、链路追踪等，是企业业务快速交付、系统稳定运行，业务快速创新的基石。
基础设施层：包括数据存储层以及中间件。数据基于关系型数据库存储，如MySQL、PolarDB 等，通过
Tenant 标识在数据库表级别实现多租户共享数据库；数据库也支持读写分离，查询操作只需要访问读数据库即可。其余中间件均由技术平台进行了二次封装，对业务屏蔽了具体的技术细节。
前台采用微前端框架
前端应用由于参与的人员增多、产品的应用模块随着需求不断增加，已经从一个普通单体应用演变成一个巨石应用，好生意、智+、微商城等产品前端开发工程都在一起开发，相互影响，导致功能开发、迭代上线无法按照应用单独部署。再加上前期业务和技术分层不清晰，导致公共组件抽象不够，业务和技术强耦合，技术想单独更新换代异常艰难。
畅捷通需要设计一套框架，确保畅捷通的业务代码能平滑的迁移，且还能确保畅捷通能在不影响业务在线的情况下，进行技术的迭代更新。
畅捷通只需要在主系统构造一个足够轻量的基座，再加上公共可复用的组件（包括基础技术组件、基础业务组件、公共业务服务等），然后让各子应用按照共同的协议去实现即可。这个协议包括，主应用应该如何加载子应用，以及子应用如何被主应用感知、调度，应用之间如何通信等。同时畅捷通这个系统还应该有提供统一的
build 工程，让各子应用不再关注配置、依赖、构建、发布等操作。这样，各个微应用之间就可以独立发布部署，不同应用之间的弱耦合，也降低了开发的复杂度。
技术平台-容器管理
快速发布环节：
基于从 git 的源码管理平台和配置管理平台的联动，实现了容器镜像的快速自动生成和管理，基于环境变量的区分和配置中心的统一管控，能实现一个容器镜像多环境部署模式，并且能对每次的代码进行安全和一致性扫描，保障代码环节的安全稳定。
闭环管理环节：
发布到线上后，基于阿里云 Prometheus 监控，异常信息发送到消息中心中，并且在消息中心数据汇聚和策略编排，形成了工单流的模式，实现有效数据的闭环管理。
业务保障环节：
在容器弹性伸缩方面，畅捷通借助 K8s 的 HPA 机制，基于阿里云容器服务 ACK 最大化利用资源的能力以及业务层自定义指标，实现面对直播、秒杀、在线考试等突发流量下微服务的快速扩缩容。
技术平台-DevOps 流水线
采用管道方式，将原本独立运行于单个或者多个节点的任务连接起来，实现单个任务难以完成的复杂流程编排。自动化构建、测试和发布过程可轻松测试每次代码更改并捕获易于修复的错误。
通过构建 DevOps 工具链，实现从需求下发、到代码提交与编译，测试与验证到部署与运维的全过程支撑，打通软件交付的完整路径，提供软件研发端到端支持。
技术平台-微服务治理
随着业务的快速发展，畅捷通对原有的IT系统进行了大量的微服务化改造，以适应互联网大型应用快速迭代以及频繁发布的需求。由于
SaaS 化企业管理云服务具备用户量大、业务复杂、调用链路长、与第三方应用系统深度集成等特点，给微服务化改造工作带来了非常大的挑战。畅捷通必须提升整体的微服务治理能力与监控能力，在频繁的版本迭代中才能确保系统的稳定健壮。
最终畅捷通的微服务部署到阿里云提供的企业级分布式应用服务 EDAS 上，运行在 EDAS 上的 Spring
Cloud 应用，可以享受到应用生命周期管理、无损下线、全链路流控等一系列针对微服务治理领域的能力增强。特别在应用发布的流程中，EDAS
所提供的平滑上下线以及灰度机制极大程度的提升了系统在版本更新期间的稳定性，降低了应用发布所带来的风险。
技术平台-全链路监控
海恩法则指出：每一起严重事故背后，必然有 29 次轻微事故和 300 起未遂先兆以及 1000 起事故隐患。
尤其是畅捷通采用了微服务架构后，由于 SaaS 产品所涉及到的业务链路极为复杂，当用户反馈系统 Bug
或者性能存在问题之后，技术团队需要耗费非常长的时间在错综复杂的链路之间定位故障源以及分析性能瓶颈。畅捷通也使用了一些
APM 工具类的产品，包括应用性能监控，用户体验监控，链路追踪，问题诊断等，但是这类工具仅能定位框架级的问题，对于自定义函数以及进程中的异步处理均无法做到链路追踪，在分布式应用架构中这类
APM 发挥的作用就更少了。
由于畅捷通的应用是托管在阿里云的 EDAS 中，EDAS 集成了应用实时监控服务 ARMS，可以监控微服务的健康状态和关键指标，并针对监控指标设置告警，及时发现并处理可能存在的异常或故障，以保障应用的健康和可用性，所以畅捷通只需要将业务操作与系统日志、系统日志和
ARMS 打通，就可以实现从业务出发，贯穿整个业务的生命周期，快速定位应用的性能瓶颈以及异常故障的位置。
为此，畅捷通实现了一套机制，将业务操作按照 Timeline 进行抽象建模，并结合系统日志、阿里云
ARMS 系统形成三位一体的全链路跟踪机制。
原则上，除了读操作之外的写权限点所对应的交互都应当视作一次 BI。所以畅捷通可以简单地认为每个写操作的权限点就是一个
BI。这就反过来要求后端提供的 REST api 必须是面向场景，每个API对应一个权限点。
BI 与 REST api 的 request_id 之间需要建立关联，以便追踪业务操作与系统日志之间的关系。
WebFilter 拦截所有 RESTful API的Request 和 Response ，获取到请求和应答信息，通过交互协议中的取值公式从拦截到的数据中解析出具体的特征、角色、关系等数据。在
Request 请求中增加 Create 操作将实体的原值自动记录下来，在 Response 返回时额增加
Complete 操作，负责把新值写入，并记录前后变化。两者在接口的调用开始和调用结束时配对使用。
在后台日志里面，记录了 user_req_id 和阿里云的 arms 的 uber-trace-ID
的对照关系。
通过全链路跟踪机制，畅捷通将业务的交互操作与阿里云 ARMS 应用监控关联起来，尤其是业务中还存在一些通过消息队列进行解耦的操作，畅捷通都可以通过
BI 来进行追踪，为畅捷通的微服务体系更进一步的提供了监控能力。在接入 ARMS 之后，通过全链路信息排查以及应用实时诊断等工具，将定位系统故障源以及性能瓶颈的工作量降低到了之前的
50% 以下，极大程度的提升了 IT 团队的工作效率。
技术平台-灰度发布
灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行 A/B testing
，即让一部分用户继续用产品特性 A ，一部分用户开始用产品特性 B 。
灰度期：新特性在灰度环境发布一直到新特性部署到线上正式环境的这一段时间，称为灰度期。对于 2C 的应用，是以用户作为灰度的基本单位进行分流。而对于
2B 的应用，则是以租户为基本单位进行分流。
灰度环境包括数据库灰度和应用程序的灰度。若在数据库层面支持灰度，则需要新建一个灰度 DB ，把参与灰度的客户数据导入到灰度
DB 中，灰度结束后再把数据清洗合并到正式生产 DB 中。这个过程所需操作较多且成本较高，鉴于此，数据库层面不考虑灰度。基于这个设定，需要遵循以下几个约束：
灰度客户的量控制在较小范围，以尽可能缩小数据修复的范围；
模型设计严格遵从兼容原则，如：只增不减，字段避免复用；
对于影响业务逻辑的系统数据需要有评估。比如增加了某个系统级的枚举值，只对灰度客户可见，可以考虑针对灰度客户复制一份系统数据，灰度后删除，系统后端代码逻辑优先取租户数据，取不到再获取系统级数据。
应用程序的灰度因为后端对外提供的服务都是 REST API ，可以采用支持调用外部服务的负载均衡或反向代理获取灰度用户名单后，对用户进行分流。后端接口的兼容性需要保证，当无法保证兼容性的情况下，需要强制前端一同升级。
基础设施层-数据库读写分离
初期云服务上线的时候，用户规模小，数据量也小，所以线上环境 MySQL 没有实现读写分离方案。在平稳运行一段时间，随着用户规模导致
PV 和 UV 增加，给数据库带来了巨大压力，主要体现在如下三点：
复杂业务，多表联查效率低下，导致业务功能响应不够及时甚至查询超时;
业务高峰期传统的数据库无法快速升配，只能等待业务高峰过去或者做流控;
业务代码对主从延迟敏感，无法充分利用从库。
初期采用 Sharding-JDBC 实现读写分离，但现有产品读写操作互绕，不易将读操作分离，且读库和写库的同步延迟较大，不太满足业务需要。调研
PolarDB 后发现，其集群地址直接支持读写分离，且与 MySQL 语法 100% 的兼容，对业务无影响。通过
PolarDB 的分钟级弹升能力，能快速升配；其特有的并行查询能力也可以降低复杂查询的响应时间，同时提升系统的并发能力。
所以畅捷通将数据库从 MySQL 迁移到 PolarDB，并采用了一写多读的模式，并对耗时的报表查询业务单独指定读节点，降低了耗时操作对其他业务的影响，保障了用户的正常交易操作。
运维中台-监控体系
传统的报警机制，以消息为载体，尽量简洁，更倾向于报警即故障模式，涵盖信息少，对后期判断往往起到一个提醒开始的状态。
随着运维模式的提高，大量高效工具的结合，自愈，时序事件等相关系统不断涌现，同时近年来兴起的云原生模式，将实现智能预警的老大难问题：信息标准化问题，给出了优质的解决方案，也加速了升级监控结构的步伐，报警的单一模式已不再适应需求，运维人员更希望报警有意义，有过程、有结论。
畅捷通长期致力于以客户体验为基础的立体化监控架构，从客户性能与体验损失的纬度，对监控信息分级，分权重，通过业务链中各环节的客户画像，特征模型，精准监控用户体验。可在用户未感知的情况下预警并进入处理流程，进入流程的事件在内部消息中心扭转，关联计算，分析根因以及自愈方案。并根据事件处理模型响应事件，发送报警，报警涵盖事件的关键信息与结论。在提高了预警有效行的同时，也避免的传统故障处理模型中的各种效率损失。
云原生应用服务特点
DevOps 工具-故障检修中心
众所周知，分布式系统遵从 CAP 理论，畅捷通通常选择满足 AP 而放弃 C（一致性）。按照墨菲定律，畅捷通最终是需要通过人工干预来保证数据的最终一致性。那么检查发现不一致的数据、区别错误场景并按规程修复，就需要有一套系统来辅助进行。
不同于系统运维，业务检修面向的是业务和服务，通过租户和租户数据的监控来发现和解决业务问题。系统运行中，除数据不一致之外，还有其他一些常见故障，也需要为支持和解决一些较为普遍有共性的客户问题提供便利，以及提供部分分析视图帮助研发或运维掌握了解租户状态和趋势，这些诉求的响应也都会因为生产环境的物理隔离和安全性要求，而变得低效，只有通过固化到系统中形成工具集才能更好地解决。
所以，畅捷通提供了一套业务检修系统，负责业务数据的监控、问题诊断，故障修复、态势预警等。整体设计如下：
目前系统针对开通失败、定时任务失败、死信、数据稽核违规、导入超时、TCC 失败六类故障进行定时检查，并与运维的
Midas 消息系统集成，及时发现问题，并向具体负责人发出钉钉告警；负责人通过故障展示的看板和明细列表来查看具体原因；针对具体故障，还提供查看上下文日志、重新开通、死信重放、数量帐重算、重提交等辅助手段解决故障。
安全服务-内容安全
畅捷通的产品会涉及到协同中的聊天信息，电商类的商品评价，这些内容可能会被外人恶意使用，将一些非法广告、网络诈骗、恐怖信息等内容录入畅捷通的产品中并传播出去，所以畅捷通的运维安全部门需要增加内容安全的监控，保障公司产品的纯净、健康运行，避免网络犯罪行为发生在畅捷通公司的产品和用户之中。
畅捷通借用系统的操作日志和消息队列，将内容安全检测和业务功能进行解耦，借助函数计算的能力，按需调用云服务厂商提供的安全检测能力（文字类、图片类等），去识别可分享的业务，内容是否符合安全法，检测结果还增加了人工审核及误判赦免。
数用分离
统计分析类数据，畅捷通每天通过 DTS 将原始数据从关系型数据库增量同步到数据仓库里，在固定时间进行数据清洗、汇总统计分析后，再将这部分数据传输
Elasticsearch 。同时畅捷通也利用 MaxCompute 的多任务计算能力，进行业务数据的标签计算，计算结果也传递给
Elasticsearch ，业务系统通过 Elasticsearch 的 REST API 访问这些数据，并展现给最终用户。
全链路流量控制技术+端云联调
由于微服务间的依赖，开发人员无法在本地完成开发和测试，必须依赖一套测试开发环境。
研发效率方面：当上百人的开发人员共享一套环境，开发态的代码频繁变更，质量较低，服务之间相互影响，开发环境经常中断，调试困难，严重影响了开发效率，研发希望每个项目能提供一套环境，如图：
研发成本方面：如果为每个项目提供全量环境，计算资源成本很高，运维成本也会激增。（在开发态有近百个微服务，按
20 个项目并行开发计算，需要近 2000 个POD/ECS 的计算资源成本和运维成本）产品在成长期，并行的项目和服务数都在增加。
综合效率和成本方面的因素，畅捷通引入网关、全链路流量精确控制技术、端云联调技术，用基线环境+增量修改的应用叠加出项目开发环境：在入口处根据企业
Id 进行流量打标（根据企业 ID 在请求中注入环境标识），如：https://cloud.chanjet.com/req?orgId
=企业 ID ，环境标识随请求在整个执行流程中流转（http 请求，rpc 请求，定时任务，消息等），通过环境标识，对微服务调用/消息进行精确控制。如图：
畅捷通在基线环境部署最新上线的代码，在项目环境中只部署涉及修改的应用：
（1）为项目研发提供稳定的独立项目环境，使研发能按“小规模，多批次”（DevOps 最佳实践）的方式快速协作；
（2）节省了资源、降低了运维成本。（按每个项目修改 5% 的应用，在开发态有近百个微服务，按 20
个项目并行开发计算，将节省 2000*95%=1900 个ECS/POD）；
（3）使用端云联调技术，方便开发本地PC加入到项目环境调试。如图所示：
云原生带来的技术价值
高弹性可扩展
系统可以在应用服务层和数据库层支持横向扩展。
应用方面：通过微服务架构，容器化部署，技术平台可以感知服务器负载，弹性伸缩服务节点，实现集群扩/缩容，快速补充计算能力。
数据库方面：数据库支持快速扩容读节点，以支持更多并发请求，同时租户实现数据隔离，并可根据负载实现跨库迁移。
微服务化
在微服务架构和设计阶段：
引入 MDD 领域驱动方法论进行应用架构设计和领域模型设计；
按照微服务的设计原则进行服务的拆分和职责、关系定义，确定服务接口和领域模型；
作为一个复杂的 ToB 应用，畅捷通按照如下原则进行微服务的拆分：
可用 - 拆分的模块能够满足应用的需要；
好用 - 拆分的模块能够通过比较简单、清晰的方式组成应用，服务应用价值；
美 - 用最简单的方式表达复杂问题；业务人员容易理解。
Back-end For Front-end
服务器端采用微服务架构之后，畅捷通需要在前后端之间增加 BFF 层，简化前后端人员的协同开发复杂度。BFF
层基于 Node 实现，畅捷通选择了 Egg.js ，并基于Egg.js 做了分层封装，在 Node
自身技术升级的情况下可以不影响业务开发。为了提高效率，畅捷通还在 Node 层接入了缓存中间件 Redis
，并利用 GraphQL 做聚合查询。
端云联调方案
采用微服务架构后，每套环境部署需要 30+ 的微服务容器，如果开发阶段存在多特性并行，为每个特性分支单独部署环境，资源消耗太大。为此，畅捷通引入了网关、全链路流量打标控制技术、端云联调技术，用基线环境+增量修改的应用叠加出项目开发环境，以最小代价快速拉起一套完整的开发调试环境，降低了开发成本。同时开发人员也可以将本地电脑直接注册到微服务环境中去，在本地完成上下游业务的验证和测试，极大地提高了开发人员的工作效率以及提交代码的质量。
离线数据分析
早期，畅捷通的数据库只有 OLTP ，数据存储在 MySQL 里，随着数据量的增多，统计分析类的查询不仅自身查询时间长，还消耗了在线交易库的资源，影响在线交易的响应时间。仅仅通过云原生数据库
PolarDB ，进行读写分离，只能缓解一部分查询压力。
针对系统中一些实时性要求不高的分析，畅捷通引入了数据仓库进行离线数据的处理，通过 DataWorks
工具进行 ETL 和统一调度，在 MaxCompute 中进行大数据指标计算和标签计算。
全链路灰度方案
畅捷通的系统，实现了从前端到后端服务、消息队列、定时任务的全链路灰度。
前端静态资源：区分灰度静态资源和正式环境静态资源。登录后由登录信息里的租户，确定应该路由到哪个环境。
消息队列：区分灰度消息队列和正式消息队列。根据环境变量进行消费
定时任务：定时任务的任务执行方，通过环境变量和租户名单，来决定是否执行。
后端 Rest 接口：在 Nginx 中通过 lua 脚本，解析 url 路径，根据灰度名单中的租户信息进行路由。
云原生带来的业务价值
容器化运维管理：
基于 EDAS+ACK 模式的容器化部署和管理，实现了应用发布的提升，并且在弹性伸缩和容量管理，也可以加快异常识别，故障自愈。并且在
2（异常识别）-5（快速定位）-10（自愈止损）的目标上不断攀升。
可观测性：
基于日志平台和数据中台的结合分析，实现用户画像和用户轨迹的展示，并且对数据的不断挖掘，可以实现用户体验百分数量化，产品质量百分数量化，从而在服务团队对接上提供数字化保障。
成本方面：
从 IDC 机房容器模式到云平台容器化的升级，不必要投入到硬件设备的大额投入和替换设备上，从而在设备成本和人力成本上大幅度节省了很多，并且新的需求和想法都可以按量投入，弹性伸缩。
DevOps：
对接云原生环境的 devops ，在研发需求支持上，节省人员 50%，构建及部署效率上提升了 4 倍。其中
2020 全年更新次数 12734 次，成功率 91.8%。
多环境资源：
通过多特性灰度方案的模式，7 套开发环境合并为1套。其中每套环境 90 个微服务，可以实现灵活性的动态调整和扩展。节省
450 个节点。
云原生容器化：
容器化 EDAS+K8s 部署模式，可以实现节点的弹性伸缩，特别是支撑了畅捷通直播活动，秒杀场景。不仅仅节省了人力的部署等环节投入，也节省了秒级伸缩的成本。
多云平台：
通过 DevOps 和容器化模式的建立，满足了用户多云场景的需求，并且节省人力50%，实现多云环境的自动化运维模式。
数据库升级：
好生意从 MySQL 升级到 PolarDB 后，其中处理性能提升 20%~40% ，并成功的将无法支持的低端手持
pda 适配工作成功复活。抽样回访客户，满意度也大幅提升。
稳定性：
基于云原生基础组建的对接，云产品可以实现 5 个 9 的 SLA 服务，这样避免了自身搭建开源组件的稳定性和安全风险。并且在组件功能上也能享受到各种业务需求功能的福利。对接云原生后，可以提出
2（告警）-5（定位）-10（止损）的稳定性保障目标，从而在用户满意度上不断提升。 |
