在信通院 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（止損）的穩定性保障目标，進而在使用者滿意度上不斷提升。