共计 10866 个字符，预计需要花费 28 分钟才能阅读完成。
简介：畅捷通公司是用友团体旗下的成员企业，专一于服务国内小微企业的财务和治理服务。一方面，畅捷通将本人的产品、业务、技术架构互联网化；另一方面，畅捷通推出了畅捷通一站式云服务平台，面向小微企业提供以数智财税、数智商业为外围的平台服务、应用服务、业务服务及数据增值服务，致力于建设“小微企业服务生态体系”。
在信通院 2021 年云原生产业大会上，畅捷通取得 2021 年度云原生优良案例。
畅捷通公司是用友团体旗下的成员企业，专一于服务国内小微企业的财务和治理服务。一方面，畅捷通将本人的产品、业务、技术架构互联网化；另一方面，畅捷通推出了畅捷通一站式云服务平台，面向小微企业提供以数智财税、数智商业为外围的平台服务、应用服务、业务服务及数据增值服务，致力于建设“小微企业服务生态体系”。
依据易观国内的报告，目前畅捷通在国内小微企业云服务市场的覆盖率放弃第一。有超过 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（止损）的稳定性保障指标，从而在用户满意度上一直晋升。
原文链接
本文为阿里云原创内容，未经容许不得转载。
