网站界面设计应遵循的原则,网站建设费大概多少钱,搜外网 seo教程,wordpress js弹窗简介#xff1a; 畅捷通公司是用友集团旗下的成员企业#xff0c;专注于服务国内小微企业的财务和管理服务。一方面#xff0c;畅捷通将自己的产品、业务、技术架构互联网化#xff1b;另一方面#xff0c;畅捷通推出了畅捷通一站式云服务平台#xff0c;面向小微企业提供…简介 畅捷通公司是用友集团旗下的成员企业专注于服务国内小微企业的财务和管理服务。一方面畅捷通将自己的产品、业务、技术架构互联网化另一方面畅捷通推出了畅捷通一站式云服务平台面向小微企业提供以数智财税、数智商业为核心的平台服务、应用服务、业务服务及数据增值服务致力于建立“小微企业服务生态体系”。
在信通院 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 路径根据灰度名单中的租户信息进行路由。
云原生带来的业务价值
容器化运维管理
基于 EDASACK 模式的容器化部署和管理实现了应用发布的提升并且在弹性伸缩和容量管理也可以加快异常识别故障自愈。并且在 2异常识别-5快速定位-10自愈止损的目标上不断攀升。
可观测性
基于日志平台和数据中台的结合分析实现用户画像和用户轨迹的展示并且对数据的不断挖掘可以实现用户体验百分数量化产品质量百分数量化从而在服务团队对接上提供数字化保障。
成本方面
从 IDC 机房容器模式到云平台容器化的升级不必要投入到硬件设备的大额投入和替换设备上从而在设备成本和人力成本上大幅度节省了很多并且新的需求和想法都可以按量投入弹性伸缩。
DevOps 对接云原生环境的 devops 在研发需求支持上节省人员 50%构建及部署效率上提升了 4 倍。其中 2020 全年更新次数 12734 次成功率 91.8%。
多环境资源
通过多特性灰度方案的模式7 套开发环境合并为1套。其中每套环境 90 个微服务可以实现灵活性的动态调整和扩展。节省 450 个节点。
云原生容器化 容器化 EDASK8s 部署模式可以实现节点的弹性伸缩特别是支撑了畅捷通直播活动秒杀场景。不仅仅节省了人力的部署等环节投入也节省了秒级伸缩的成本。
多云平台
通过 DevOps 和容器化模式的建立满足了用户多云场景的需求并且节省人力50%实现多云环境的自动化运维模式。
数据库升级
好生意从 MySQL 升级到 PolarDB 后其中处理性能提升 20%~40% 并成功的将无法支持的低端手持 pda 适配工作成功复活。抽样回访客户满意度也大幅提升。
稳定性
基于云原生基础组建的对接云产品可以实现 5 个 9 的 SLA 服务这样避免了自身搭建开源组件的稳定性和安全风险。并且在组件功能上也能享受到各种业务需求功能的福利。对接云原生后可以提出 2告警-5定位-10止损的稳定性保障目标从而在用户满意度上不断提升。
原文链接 本文为阿里云原创内容未经允许不得转载。
