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 和業務服務。
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 性能優化實踐、最佳實踐等系列。