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

作者:禾連健康

“健康體檢是一個低容錯的場景,用戶到醫院體檢,由於 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

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

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

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

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

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

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

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

微服務未來規劃

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

4.png

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

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

5.png

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

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

參考鏈接:

[1] https://www.aliyun.com/product/aliware/mse*

[2] https://www.aliyun.com/product/kubernetes

[3] https://help.aliyun.com/document_detail/214749.html

點擊此處 ,立即前往微服務引擎官網查看更多~

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章