華為云云原生 發表於 2020-12-17 17:59:11
近日，國內較權威的Go大會——Gopher China召開，眾多一線網際網路公司的大神們匯聚一堂，深入探討了Go語言並產生了諸多乾貨。其中，華為雲微服務首席架構師田曉亮老師也受邀參與本次大會，以《華為雲的Go語言云原生實戰經驗》為題進行了分享，今天小編整理匯總了田曉亮老師分享中的技術乾貨。
有理論、有實操、有深度、需細品！
2016年華為成立Cloud BU以來，就引入了Go語言編寫的Kubernetes，Prometheus等CNCF項目，華為雲研發團隊也開始用Go語言來構建雲服務。不過，當時Go的生態並不完善，所以要自己從頭到尾編寫基礎能力模塊。那麼，如何用Go構建雲服務並將基礎能力慢慢建立起來，有哪些經驗和方法？且聽我們慢慢道來……
從一個簡單雲應用看如何構築一個雲服務
和Eureka一樣，一個簡單的註冊發現服務Service Center可以通過多種手段來增強。
1.靜態與動態信息定義
減少數據信息量，抽出公共部分統一管理，通過靜態信息來劃分實例組。這樣微服務與微服務實例為1對n的映射，將微服務名、版本、數據中心等信息都抽到了公共部分，通過降低冗餘度，來減少網絡的開銷，同時也規範化了微服務模型。
2.契約化微服務
上一張圖我們看到微服務靜態信息裡面包含了多個Schemas，裡面關聯了微服務所關聯的契約文檔，同樣是1對n的映射關係。通過手動上傳或者代碼自動生成文檔上傳，可以在註冊中心中查看微服務文檔，且文檔與微服務版本綁定，不允許更改。
對比客戶端開發團隊等待後端的服務編寫完成後，才開始進行集成開發的方式。高效方式是以文檔為基準，客戶端與服務端同時開發，客戶端通過Mock去除對服務端的依賴。
為何要保證文檔先行？如果文檔不及時審視，那麼將會出現非常糟糕的情況。比如不一致的命名規範，定義相似的API，擴展能力差，任何一點都會大大增加研發成本。及早審視並規避十分重要，這就是為何註冊中心加入文檔上傳與查詢能力。
3.服務間依賴管理
調用層級過高將引起定位困難、性能下降的問題，合理的層級是3個服務：a->b->c的調用就可以完成一次調用。彼此互相依賴的兩個服務在功能升級或者變更時要花費更多時間來分析影響，比如ab互相依賴，一個新功能涉及2個都要更改，那怎麼一起上線？
簡單的依賴有助於系統測試和分析，這給架構師一個很好的審視方式，可以及時看到微服務間的依賴關係，以及時對架構調整。
4.緩存機制
由於Service Center內部本身是不存數據的，一旦etcd出現網絡故障的時候，就會導致Service Center不可用。所以Service Center引入了異步緩存機制，啟動之初，Service Center會與etcd建立一個長連接，也就是watch。為了防止建立watch時間窗發生變化，又做了一層保護，在watch之前做全量的查詢。運行過程中查詢所得到的資源變化會緩存到Service Center本地，然後進行異步的循環。
總的來說，我們通過了多種手段來提升微服務研發效率，減少網絡開銷，並通過異步緩存提升性能。這是華為雲積累的能力，但交付一個雲服務遠遠不止交付業務功能這麼簡單，還要考慮微服務的安全、韌性、隱私、可運維等能力。
我們剛才看到的只是水面之上的冰山，水面之下還隱藏著大量的基礎能力需要編寫。真的要達成微服務架構模式的願景，需要繁重的工作量。就像冰山那樣，我們要將通用能力沉澱下去，能夠復用。如果讓各個業務團隊同時照顧冰山上下，各自開發各自的，那結果將是災難性的，企業用人成本極高，下面讓我們展開Service Center的架構看看。
立足Service Center架構，
「冰山下」的基礎能力庫編寫很重要
下面這個組件主要負責微服務的註冊發現，提供Restful API。
它有四個主要的模塊：
服務註冊發現：通過註冊發現完成服務拓撲的感知；
契約發現：每個服務具備一個契約記錄，支持多種格式如Open API，gRPC proto；
RBAC：基於角色的訪問控制，管理員可以管理帳號，將帳號分發給微服務或者不同人員；
服務治理：針對微服務下發治理規則，比如重試，限流，熔斷，路由策略等。
交付一個雲服務遠遠不止交付業務功能，而是要去全方面的考慮安全，韌性，隱私，可運維等能力，當然我們將部分的能力可以交給一些中間件來完成，比如網關。然而仍有大量功能需要自己編寫，且可以復用在每個微服務中，這就是基礎能力庫編寫的初衷。
配額管理：雲資源按照租戶進行配額管理，租戶所能使用的資源受到嚴格限制
告警：當微服務發生關鍵問題時要直接上報告警系統，而非通過雲服務設置閾值等告警策略
安全：加解密證書，密碼
ID生成：ID的生成算法，用於生成微服務ID，實例ID等
多種中間件：調用過程需要被審計，調用鏈追蹤，生成指標監控等
該項目已經開源並捐獻給Apache，項目地址：
https://github.com/apache/servicecomb-service-center
對於這些能力，抽取普通的庫函數也是完全不夠用的，所以要做到如下能力：
可插拔：也就是按需在編譯期引入（受限於Go語言能力），例如配額系統的具體實現在社區是不需要的。
異構系統：也就是一個功能要有多種具體實現，比如審計，公有雲存在一套審計系統需要對接，而社區則是本地日誌列印。
不同的算法：解密工具、ID生成器……面對不同的交付場景或安全要求，都要通過不同實現來替換算法。比如ID生成可以是snowflake、UUID；加解密算法使用AES或者其他公開算法。
如何通過Go Chassis加速雲服務開發？
為了滿足上面提到的需求多樣性，並且讓所有新規劃的組件受益、快速進行開發，我們需要統一的框架和標準來加速開發，這就是華為雲用Go語言編寫的開發框架Go Chassis誕生的原因。所以大家看可以看到go chassis的源碼和設計有著service center代碼的影子。
責任編輯：xj
原文標題：掀開華為雲的Go語言編程底座！有深度、有點難、需細品
文章出處：【微信公眾號：華為開發者社區】歡迎添加關注！文章轉載請註明出處。
打開APP閱讀更多精彩內容
聲明：本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人，不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用，如有內容圖片侵權或者其他問題，請聯繫本站作侵刪。 侵權投訴