使用者案例 | 騰訊醫療資訊平臺雲原生容器化之路

騰訊雲原生發表於2021-11-03

作者

yuhuliu,騰訊研發工程師,關注儲存、大資料、雲原生領域。

摘要

醫療資訊業務在高速發展過程中,形成了覆蓋不同場景、不同使用者、不同渠道的幾十個業務,以及上千個服務。為了高效滿足使用者多樣化的需求,醫療技術團隊通過 TKE 上雲,使用 Coding DevOps 平臺,以及雲上可觀測技術,來提升研發效率、降低運營運維成本。本文介紹我們在上雲過程中一些實踐和經驗,以及一些思考和選擇。

業務背景

  • stage1: 醫療資訊主要包括了醫典、醫生、醫藥等核心業務,其中醫典主要提供醫療相關內容獲取、醫療知識科普傳遞;醫生滿足醫生和患者的互聯;醫藥服務了廣大藥企。在業務發展過程中我們原來基於 taf 平臺構建了大量後臺服務,完成了初期業務的快速搭建。由於業務數量較多,大量業務有多地域的述求,最終我們在 taf 平臺部署多個業務叢集。這個時候釋出、運維、問題排查純靠人工階段,效率較低。

業務上雲

  • stage2: 隨著業務規模的急速擴張,傳統的開發、運維方式在敏捷、資源、效率方面對業務迭代形成較大的制約。隨著公司自研上雲專案推進,擁抱雲原生化,基於 K8s 來滿足業務對不同資源多樣化需求和彈性排程,基於現有成熟 devops 平臺來進行敏捷迭代,越來越成為業務正確的選擇。醫療後臺團隊開始了整體服務上雲的遷移。

  • 上雲之前,還有幾個問題需要考慮

​ 1:服務眾多,程式碼如何管理

​ 2:上雲後怎麼快速進行問題定位、排查

​ 3:監控告警平臺如何選擇

​ 4:基礎映象怎麼選擇

關於服務程式碼管理

使用 git 做程式碼版本控制,按業務建立專案組,每個服務使用單獨的程式碼倉庫,倉庫名使用同一命名規範。

關於問題排查

調研雲上有成熟的 elk 服務,業務只需要把日誌放到同一目錄,通過 filebeat 採集後,通過 ETL 邏輯可以把日誌方便匯入 Elasticsearch。這樣的做法還有個優點就是可以同時支援前後端服務日誌的採集,技術較為成熟,複用了元件能力,通過在請求中埋點加入 traceid,方便在全鏈路定位問題。

關於監控告警平臺

CSIG 提供了基於日誌監控的 CMS 平臺,將業務日誌匯入到 CMS 後,可以基於上報的日誌配置監控和告警,監控維度、指標業務可以自己定義。我們採用了主調、被調、介面名等維度,呼叫量、耗時、失敗率等指標,滿足業務監控告警訴求。基於日誌的監控可以複用同一條資料採集鏈路,系統架構統一簡潔。

關於基礎映象

為了方便業務初期快速上雲,以及統一服務啟動、資料採集上報,有必要對業務的基礎映象進行處理,預先建立對應目錄,提供指令碼和工具,方便業務快速接入。這裡我們提供了不同語言、版本的基礎映象,封裝了 supervisord 和 filebeat,通過 supervisord 來拉起 filebeat 和業務服務。

Devops

  • stage2: 在上雲過程中,也通過和質量同學逐步完善,將開發過程中原有人工操作的步驟 pipeline 化,來提高迭代效率,規範開發流程;通過單測和自動化撥測,提升服務穩定性。採用統一的流水線後,開發、部署效率從原來的小時級別降低到分鐘級別。

這裡主要使用了 coding 平臺,為了區分不同環境,建立了開發、測試、預釋出、測試四套不同流水線模板,還引入了合流機制來加入人工 code review 階段。

在合流階段:通過 MR HOOK,自動輪詢 code review 結果,確保程式碼在 review 通過後才能進行下一步(不同團隊可能要求不一樣)。

在 CI 階段:通過程式碼質量分析,來提升程式碼規範性,通過單元測試,來保證服務質量。

在 CD 階段:通過引入人工審批和自動化撥測,提高服務穩定性。

資源利用率提升

  • stage3:在業務整體上雲後,由於不少業務有多地域部署(廣州、南京、天津、香港)的述求,加上每個服務需要四套(開發、測試、預釋出、正式)不同的環境,上雲後我們初步整理,一共有3000+不同 workload。由於不同業務訪問量具有很大不確定性,初期基本上按照理想狀態來配置資源,存在不少的浪費。

為了提高資源整體利用率,我們進行了一系列優化,大致遵循如下規範:

這裡由於 HPA 會導致業務容器動態擴縮,在停止過程中如果原有流量還在訪問,或者啟動還未完成就匯入流量,會導致業務的失敗,因此需要需要預先開啟 TKE 上 preStop 以及就緒檢測等配置。

1:優雅停止,程式停止前等北極星、cl5 路由快取過期;
入口:tke->工作負載->具體業務->更新工作負載
如果使用的服務發現是 CL5,推薦 preStop70s,北極星配置 10s 足夠了

2:就緒、存活檢測,程式啟動完成後再調配流量;
入口:tke->工作負載->具體業務->更新工作負載,根據不同業務配置不同探測方式和時間間隔。

通過上面一系列調整優化,我們的資源利用率大幅提升,通過 TKE 上彈性升縮,在保證業務正常訪問同時,區域性高峰訪問資源不足的問題基本解決,避免了資源浪費,也提升了服務穩定性;但多環境問題還是會導致存在一定損耗。

可觀測性技術

  • stage4:初期使用基於日誌的方式來做(log/metric/tracing),滿足了業務快速上雲、問題排查效率提升的初步述求,但隨著業務規模增長,愈加龐大的日誌流佔用了越來越多的資源,日誌堆積在高峰期成為常態, CMS 告警可能和實際發生時已經間隔了半個小時,ELK的維護成本也急劇上升。雲原生的可觀測技術已經成為必要,這裡我們引入了 Coding 應用管理所推薦的可觀測技術方案,通過統一的 coding-sidecar 對業務資料進行採集:

監控:雲監控中臺

日誌:CLS

Tracing:APM

通過接入這些平臺的能力,我們的問題發現、定位、排查效率有了極大的提高,業務的運營維護成本較大降低,通過監控、和 tracing,也發現了不少系統潛在的問題,提高了服務質量。

結尾

最後,要感謝上雲過程中全體開發同學的辛勤付出,以及各位研發 leader 的大力支援。

關於我們

更多關於雲原生的案例和知識,可關注同名【騰訊雲原生】公眾號~

福利:

①公眾號後臺回覆【手冊】,可獲得《騰訊雲原生路線圖手冊》&《騰訊雲原生最佳實踐》~

②公眾號後臺回覆【系列】,可獲得《15個系列100+篇超實用雲原生原創乾貨合集》,包含Kubernetes 降本增效、K8s 效能優化實踐、最佳實踐等系列。

【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊,掃碼關注同名公眾號,及時獲取更多幹貨!!

相關文章