*作者：禾連健康*

*  
“健康體檢是一個低容錯的場景，使用者到醫院體檢，由於 IT 原因導致無法完成預約的專案，會對使用者體驗造成極大的影響。”*

*——禾連健康 CTO 鄧志豪*

禾連健康成立於 2014 年，是一家從體檢場景切入的健康管理服務公司。對於醫院，禾連提供的是圍繞體檢檢前、檢中、檢後的一套 SaaS 服務；對於企業，提供的是團體體檢、健康管理，李錦記、普華永道都是禾連的客戶；對於家庭，提供的則是健康管理 APP。目前，禾連已經覆蓋全國 200 多個城市，2000 多家醫院。

## 禾連健康經歷了哪些技術發展階段？

第一個階段：宏應用。從 0 到 1，迭代速度很快，同時故障也很多，業務需要禾連快速迭代並驗證，怎麼快怎麼來，當時還用過阿里雲聚石塔提供的一個容器管理服務，也算是容器化的雛形。**總結來看，關注速度，但是會出現技術債務、故障多、達不到業務的預期。**

第二個階段：微服務化。當禾連對接的醫院越來越多後，故障也更多了，客戶抱怨很大，那時候開發整天在“救火”。隨後，禾連開始做模組化的解耦和服務拆分，引入了 Dubbo 和 Nacos，但當時對業務的理解還是不夠深刻，服務拆的有問題，導致服務交叉呼叫非常多，出現幾乎所有介面都會呼叫到的超級服務，對穩定性有害。**總結來看，對業務理解不深刻的微服務拆分，治標不治本。**

第三個階段：微服務重構。以橫向的訂單、落單、資料同步為主，重新梳理了模組和服務，同時部署架構換成了 K8s，並把用於服務治理的一些中介軟體替換成阿里雲微服務引擎 MSE 這類雲服務 **[** **1]** ，這個時候，整個系統總體就比較穩定了。**總結來看，圍繞業務來構建微服務，結合雲的優勢，提升了開發運維效率和線上穩定性。**

## 低容錯的體檢業務有哪些不一樣的技術挑戰？

低容錯是禾連的業務特點。例如，使用者到醫院體檢，由於 IT 原因導致無法完成預約的專案，會對使用者體驗造成極大的影響，不僅是體檢，**其實整個醫療行業都有著低容錯的特點**。另外，對於大多數人而言，體檢的頻率一年也就1-2次，是非常低頻的場景，因此流量也非常低。而低流量帶來的問題是，灰度釋出幾乎是無效的，甚至全量釋出都可能無法發現 bug，有些 bug 會在程式碼釋出一年以後才會被發現。

因此，禾連首先要解決複雜邏輯的問題，必須做模組化、做解耦。

但如果只做業務解耦，那麼實現模組化就足夠了。例如，如果使用的是 Java 語言，將 Java 模組分為 JAR 包，用 Maven 管理不同依賴即可。但是，早期很多技術架構是透過單一的包支撐不同業務，業務模組多、業務不隔離。沒有做微服務拆分時，可能會出現企業業務程式碼有問題，導致醫院容錯較低的業務崩潰，這對業務來說，是難以接受的。

因此，禾連直接實現了服務化，將服務拆分開，有公共的基礎服務可以呼叫，不同業務之間不會互相影響。服務化不僅實現了業務解耦，也實現了服務分層，保障履約的核心服務。例如，**針對容錯率非常低的業務，可以構建專門針對問題場景的保障服務。同時，可以對服務做獨立質檢，而如果打包在一起則無法做獨立的質檢。**

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/66887265fa9241a1aa6e0ecf04ec59ab~tplv-k3u1fbpfcp-zoom-1.image "1.png")

服務拆分主要有兩種模式，一種為按照業務拆分，一種為按照能力拆分，不同業務可以互相呼叫。最終，禾連的架構如上圖所示。以按照能力拆分為主，按照業務拆分為輔。比如最前端是 web 服務，藍色塊是業務核心迭代的業務服務，底層按照能力拆分訂單、支付、訊息三種服務。往下一層與業務較遠的，比如醫院資料同步服務、人工履約服務，是自建的獨立服務。

業務迭代最頻繁的服務與相對穩定的服務各自區分獨立，兩邊透過 HTTP 打通，業務叢集內使用 Dubbo 做 RPC，Nacos 做註冊和配置中心，RocketMQ 做非同步訊息。

## 微服務演進過程中的實踐經驗

微服務上，禾連使用的是 Dubbo + Nacos 這套技術棧。

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2a23070eec9349a48d1df5280fd24f17~tplv-k3u1fbpfcp-zoom-1.image "2.png")

Dubbo 是一個 基於 Java Interface 的 RPC 框架，對於 Java 程式設計師而言，只需加簡單的註解即可成為微服務，於是在團隊中推行。同時，呼叫幾乎不侵入程式碼，將 @Autowire 改為 @DubboReference 即可注入服務。Nacos 在 Dubbo 的整合非常完善，只需幾行配置即可使用，控制皮膚簡單易用，與 Dubbo 一樣均為中文社群，對於程式設計師的門檻更低。

早期，禾連自行搭建社群版 Nacos 曾遇到較大效能瓶頸，當時的 Dubbo2 服務模型基於介面，一個介面、一個函式就會帶來一個服務，流量非常大。阿里雲的微服務引擎 MSE 幫助禾連扛住了 Dubbo 的壓力，它具有良好的相容性，後續禾連跟隨社群升級至 Dubbo 3，解決了 Dubbo 2 服務模型的問題。另外，從記憶體視角看，MSE 具有出色的調優能力，使業務效能提升 4 倍，降低了資源成本。

禾連服務大量的醫院，每個醫院的需求不確定、也不盡相同，會存在大量的特性開關。此類開關的操作非常危險，一般由開發人員進行配置，而 MSE 很好地解決了痛點。MSE 的特性開關可以做動態配置，無需重啟應用。同時可以一鍵與 KMS 阿里雲金鑰管理服務相結合，對資料進行加密儲存，但是使用者無感知。

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/679a5a62b09b4ab9a2b313a65891a896~tplv-k3u1fbpfcp-zoom-1.image "3.png")

HTTP 閘道器主要解決協議轉換的問題。禾連的 App 前端業務邏輯重，無需做任何結果封裝，只要暴露服務能力即可。因此，基於開源的 Apache ShenYu 做了改造，將 HTTP 協議轉為 Dubbo ，同時支援 POST/GET，將鑑權和授權邏輯都放至閘道器。

**DevOps 方面，K8s +映象釋出回滾使用了** **ACK[2]，持續整合** **使用了雲效 CI ，為禾連帶來了極高的釋出效率，一週最多時會發布 20-30 次，單次釋出時間從原先的 2-3 小時降低至 8 分鐘內。** 另外，禾連基於 Dubbo 做了服務隔離，例如，同一個服務可以部署兩個版本，程式碼和使用方式均一致，例項不同。兩個服務均有獨立記憶體，一個服務故障時，不會影響到另外一個相同的服務。但該能力目前依然較弱，控制面能力的增強是未來的發展方向。

## 微服務未來規劃

未來，禾連希望能夠實現 Service Mesh 的控制面。

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8aa02775c8664a3194002ce98892dc87~tplv-k3u1fbpfcp-zoom-1.image "4.png")

如上圖所示，比如服務請求到達時，如果是 req*，則希望它路由至特殊版本 ServiceA* 。請求經過 MQ 之後發出的訊息不能被 Service 訊息接收，而是應被 Service* 接收，實現全鏈路的路由能力。目前阿里雲的 ASM 提供的 Istio 託管具備以上能力，也提供了基本的 Dubbo 治理能力 **[3** **]** ， 後續也將探索在 ASM 中如何進行融合演進。

實現 Service Mesh 的目的是降低測試環境成本。當前，禾連的大叢集裡有 7-8 套測試環境供各個業務小組使用，每個小組各用一套，互不干擾，但成本過高。如果能實現全鏈路的路由，每個開發小組只要做服務的測試環境釋出，使用打標流量即可實現釋出。

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/557da2576e8c48229c7b7a677546704b~tplv-k3u1fbpfcp-zoom-1.image "5.png")

參考目前業界的實踐，全鏈路的灰度路由，可以透過在閘道器層面識別流量並打標、每個測試環境都有單獨的標籤；每一跳服務呼叫傳遞流量標籤，並在每一跳呼叫時，根據流量標籤和對端機器標籤做不同策略的匹配路由。最終，禾連可以做到每個環境，只需要部署當前環境修改後的服務，最大限度地重用基線環境的服務，降低了總體成本。

另外，禾連將實現全量 HTTP 閘道器。從未來趨勢看，前端越來越重，無需後端做 web 層，將後端服務直接暴露給前端即可。因此，禾連考慮將所有 web 層替換成 BFF 閘道器，期待緊密跟進社群的步伐，聯合雲原生社群一起向前發展。

## *參考連結：*

*[1]* *<https:>*

*[2]* *<https:>*

*[3]* *<https:>*

**點選**[**此處**](https://www.aliyun.com/product/aliware/mse) **，立即前往微服務引擎官網檢視更多～**</https:></https:></https:>

在低容錯業務場景下落地微服務的實踐經驗

相關文章