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

摘要

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

業(yè)務(wù)背景

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

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

業(yè)務(wù)上云

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

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

1.服務(wù)眾多，代碼如何管理

2.上云后怎么快速進(jìn)行問題定位、排查

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

4.基礎(chǔ)鏡像怎么選擇

關(guān)于服務(wù)代碼管理

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

關(guān)于問題排查

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

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

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

關(guān)于基礎(chǔ)鏡像

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

Devops

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

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

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

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

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

資源利用率提升

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

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

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

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

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

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

可觀測性技術(shù)

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

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

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

·日志：CLS

·Tracing：APM

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

結(jié)尾

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