用戶案例 | 騰訊醫(yī)療資訊平臺云原生容器化之路

摘要

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

業(yè)務背景

stage1:騰訊醫(yī)療資訊平臺主要包括了醫(yī)典、醫(yī)生、醫(yī)藥等核心業(yè)務，其中醫(yī)典主要提供醫(yī)療相關內容獲取、醫(yī)療知識科普傳遞；醫(yī)生滿足醫(yī)生和患者的互聯(lián)；醫(yī)藥服務了廣大藥企。在業(yè)務發(fā)展過程中我們原來基于taf平臺構建了大量后臺服務，完成了初期業(yè)務的快速搭建。

由于業(yè)務數(shù)量較多，大量業(yè)務有多地域的述求，最終我們在taf平臺部署多個業(yè)務集群。這個時候發(fā)布、運維、問題排查純靠人工階段，效率較低。

業(yè)務上云

stage2:隨著業(yè)務規(guī)模的急速擴張，傳統(tǒng)的開發(fā)、運維方式在敏捷、資源、效率方面對業(yè)務迭代形成較大的制約。隨著公司自研上云項目推進，擁抱云原生化，基于K8s來滿足業(yè)務對不同資源多樣化需求和彈性調度，基于現(xiàn)有成熟devops平臺來進行敏捷迭代，越來越成為業(yè)務正確的選擇。醫(yī)療后臺團隊開始了整體服務上云的遷移。

上云之前，還有幾個問題需要考慮

1.服務眾多，代碼如何管理

2.上云后怎么快速進行問題定位、排查

3.監(jiān)控告警平臺如何選擇

4.基礎鏡像怎么選擇

關于服務代碼管理

使用git做代碼版本控制，按業(yè)務建立項目組，每個服務使用單獨的代碼倉庫，倉庫名使用同一命名規(guī)范。

關于問題排查

調研云上有成熟的elk服務，業(yè)務只需要把日志放到同一目錄，通過filebeat采集后，通過ETL邏輯可以把日志方便導入Elasticsearch。這樣的做法還有個優(yōu)點就是可以同時支持前后端服務日志的采集，技術較為成熟，復用了組件能力，通過在請求中埋點加入traceid，方便在全鏈路定位問題。

關于監(jiān)控告警平臺

CSIG提供了基于日志監(jiān)控的CMS平臺，將業(yè)務日志導入到CMS后，可以基于上報的日志配置監(jiān)控和告警，監(jiān)控維度、指標業(yè)務可以自己定義。我們采用了主調、被調、接口名等維度，調用量、耗時、失敗率等指標，滿足業(yè)務監(jiān)控告警訴求?；谌罩镜谋O(jiān)控可以復用同一條數(shù)據(jù)采集鏈路，系統(tǒng)架構統(tǒng)一簡潔。

關于基礎鏡像

為了方便業(yè)務初期快速上云，以及統(tǒng)一服務啟動、數(shù)據(jù)采集上報，有必要對業(yè)務的基礎鏡像進行處理，預先建立對應目錄，提供腳本和工具，方便業(yè)務快速接入。這里我們提供了不同語言、版本的基礎鏡像，封裝了supervisord和filebeat，通過supervisord來拉起filebeat和業(yè)務服務。

Devops

stage3:在上云過程中，也通過和質量同學逐步完善，將開發(fā)過程中原有人工操作的步驟pipeline化，來提高迭代效率，規(guī)范開發(fā)流程；通過單測和自動化撥測，提升服務穩(wěn)定性。采用統(tǒng)一的流水線后，開發(fā)、部署效率從原來的小時級別降低到分鐘級別。

這里主要使用了coding平臺，為了區(qū)分不同環(huán)境，建立了開發(fā)、測試、預發(fā)布、測試四套不同流水線模板，還引入了合流機制來加入人工code review階段。

在合流階段：通過MR HOOK，自動輪詢code review結果，確保代碼在review通過后才能進行下一步（不同團隊可能要求不一樣）。

在CI階段：通過代碼質量分析，來提升代碼規(guī)范性，通過單元測試，來保證服務質量。

在CD階段：通過引入人工審批和自動化撥測，提高服務穩(wěn)定性。

資源利用率提升

stage4：在業(yè)務整體上云后，由于不少業(yè)務有多地域部署（廣州、南京、天津、香港）的述求，加上每個服務需要四套（開發(fā)、測試、預發(fā)布、正式）不同的環(huán)境，上云后我們初步整理，一共有3000+不同workload。由于不同業(yè)務訪問量具有很大不確定性，初期基本上按照理想狀態(tài)來配置資源，存在不少的浪費。

為了提高資源整體利用率，我們進行了一系列優(yōu)化，大致遵循如下規(guī)范：

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

1.優(yōu)雅停止，進程停止前等北極星、cl5路由緩存過期；入口：tke->工作負載->具體業(yè)務->更新工作負載如果使用的服務發(fā)現(xiàn)是CL5，推薦preStop70s，北極星配置10s足夠了。

2.就緒、存活檢測，進程啟動完成后再調配流量；入口：tke->工作負載->具體業(yè)務->更新工作負載，根據(jù)不同業(yè)務配置不同探測方式和時間間隔。

通過上面一系列調整優(yōu)化，我們的資源利用率大幅提升，通過TKE上彈性升縮，在保證業(yè)務正常訪問同時，局部高峰訪問資源不足的問題基本解決，避免了資源浪費，也提升了服務穩(wěn)定性；但多環(huán)境問題還是會導致存在一定損耗。

可觀測性技術

stage4：初期使用基于日志的方式來做（log/metric/tracing），滿足了業(yè)務快速上云、問題排查效率提升的初步述求，但隨著業(yè)務規(guī)模增長，愈加龐大的日志流占用了越來越多的資源，日志堆積在高峰期成為常態(tài)，CMS告警可能和實際發(fā)生時已經(jīng)間隔了半個小時，ELK的維護成本也急劇上升。

云原生的可觀測技術已經(jīng)成為必要，這里我們引入了Coding應用管理所推薦的可觀測技術方案，通過統(tǒng)一的coding-sidecar對業(yè)務數(shù)據(jù)進行采集：

·監(jiān)控：云監(jiān)控中臺

·日志：CLS

·Tracing：APM

通過接入這些平臺的能力，我們的問題發(fā)現(xiàn)、定位、排查效率有了極大的提高，業(yè)務的運營維護成本較大降低。通過監(jiān)控、和tracing，也發(fā)現(xiàn)了不少系統(tǒng)潛在的問題，提高了服務質量。

結尾

最后，要感謝上云過程中全體開發(fā)同學的辛勤付出，以及各位研發(fā)leader的大力支持。