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

作者

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 效能最佳化實踐、最佳實踐等系列。