摘要：華為云的Go語(yǔ)言編程底座是如何煉成的？
Gopher China作為國(guó)內(nèi)最權(quán)威和最實(shí)力干貨的Go大會(huì)，致力于為廣大的Gopher提供一線分享交流機(jī)會(huì)，也為眾多一線互聯(lián)網(wǎng)公司大咖深入探討Go語(yǔ)言的應(yīng)用發(fā)展提供契機(jī)。
在近日于上海召開的第六屆Gopher China大會(huì)上，華為云微服務(wù)首席架構(gòu)師田曉亮就受邀分享了《華為云的Go語(yǔ)言云原生實(shí)戰(zhàn)經(jīng)驗(yàn)》，講述如何構(gòu)建韌性、高可靠、安全的云原生應(yīng)用系統(tǒng)，并孵化云原生應(yīng)用開發(fā)框架Go chassis，以提升團(tuán)隊(duì)開發(fā)效能。
自華為在2016年成立Cloud BU以來(lái)，就引入了Go語(yǔ)言編寫的Kubernetes，Prometheus等CNCF項(xiàng)目，華為云的研發(fā)團(tuán)隊(duì)也開始用Go語(yǔ)言來(lái)構(gòu)建云服務(wù)。不過(guò)，當(dāng)時(shí)Go的生態(tài)并不完善，所以要自己從頭到尾編寫基礎(chǔ)能力模塊。
那么，如何用Go構(gòu)建云服務(wù)并將基礎(chǔ)能力慢慢建立起來(lái)，且聽我們慢慢道來(lái)。
從一個(gè)簡(jiǎn)單云應(yīng)用看我們?nèi)绾螛?gòu)筑一個(gè)云服務(wù)
和Eureka一樣，一個(gè)簡(jiǎn)單的注冊(cè)發(fā)現(xiàn)服務(wù)Service Center可以通過(guò)多種手段來(lái)增強(qiáng)。
1、靜態(tài)與動(dòng)態(tài)信息定義
減少數(shù)據(jù)信息量，抽出公共部分統(tǒng)一管理，通過(guò)靜態(tài)信息來(lái)劃分實(shí)例組。這樣微服務(wù)與微服務(wù)實(shí)例為1對(duì)n的映射，將微服務(wù)名、版本、數(shù)據(jù)中心等信息都抽到了公共部分，通過(guò)降低冗余度，來(lái)減少網(wǎng)絡(luò)的開銷，同時(shí)也規(guī)范化了微服務(wù)模型。
2、契約化微服務(wù)
上一張圖我們看到微服務(wù)靜態(tài)信息里面包含了多個(gè)Schemas，里面關(guān)聯(lián)了微服務(wù)所關(guān)聯(lián)的契約文檔，同樣是1對(duì)n的映射關(guān)系。通過(guò)手動(dòng)上傳或者代碼自動(dòng)生成文檔上傳，可以在注冊(cè)中心中查看微服務(wù)文檔，且文檔與微服務(wù)版本綁定，不允許更改。
對(duì)比客戶端開發(fā)團(tuán)隊(duì)等待后端的服務(wù)編寫完成后，才開始進(jìn)行集成開發(fā)的方式。高效方式是以文檔為基準(zhǔn)，客戶端與服務(wù)端同時(shí)開發(fā)，客戶端通過(guò)Mock去除對(duì)服務(wù)端的依賴。
為何要保證文檔先行？如果文檔不及時(shí)審視，那么將會(huì)出現(xiàn)非常糟糕的情況。比如不一致的命名規(guī)范，定義相似的API，擴(kuò)展能力差，任何一點(diǎn)都會(huì)大大增加研發(fā)成本。及早審視并規(guī)避十分重要，這就是為何注冊(cè)中心加入文檔上傳與查詢能力。
3、服務(wù)間依賴管理
調(diào)用層級(jí)過(guò)高將引起定位困難、性能下降的問(wèn)題，合理的層級(jí)是3個(gè)服務(wù)：a->b->c的調(diào)用就可以完成一次調(diào)用。彼此互相依賴的兩個(gè)服務(wù)在功能升級(jí)或者變更時(shí)要花費(fèi)更多時(shí)間來(lái)分析影響，比如ab互相依賴，一個(gè)新功能涉及2個(gè)都要更改，那怎么一起上線？
簡(jiǎn)單的依賴有助于系統(tǒng)測(cè)試和分析，這給架構(gòu)師一個(gè)很好的審視方式，可以及時(shí)看到微服務(wù)間的依賴關(guān)系，以及時(shí)對(duì)架構(gòu)調(diào)整。
4、緩存機(jī)制
由于Service Center內(nèi)部本身是不存數(shù)據(jù)的，一旦etcd出現(xiàn)網(wǎng)絡(luò)故障的時(shí)候，就會(huì)導(dǎo)致Service Center不可用。所以Service Center引入了異步緩存機(jī)制，啟動(dòng)之初，Service Center會(huì)與etcd建立一個(gè)長(zhǎng)連接，也就是watch。為了防止建立watch時(shí)間窗發(fā)生變化，又做了一層保護(hù)，在watch之前做全量的查詢。運(yùn)行過(guò)程中查詢所得到的資源變化會(huì)緩存到Service Center本地，然后進(jìn)行異步的循環(huán)。
總的來(lái)說(shuō)，我們通過(guò)了多種手段來(lái)提升微服務(wù)研發(fā)效率，減少網(wǎng)絡(luò)開銷，并通過(guò)異步緩存提升性能。這是華為云積累的能力，但交付一個(gè)云服務(wù)遠(yuǎn)遠(yuǎn)不止交付業(yè)務(wù)功能這么簡(jiǎn)單，還要考慮微服務(wù)的安全、韌性、隱私、可運(yùn)維等能力。
我們剛才看到的只是水面之上的冰山，水面之下還隱藏著大量的基礎(chǔ)能力需要編寫。真的要達(dá)成微服務(wù)架構(gòu)模式的愿景，需要繁重的工作量。就像冰山那樣，我們要將通用能力沉淀下去，能夠復(fù)用。如果讓各個(gè)業(yè)務(wù)團(tuán)隊(duì)同時(shí)照顧冰山上下，各自開發(fā)各自的，那結(jié)果將是災(zāi)難性的，企業(yè)用人成本極高，下面讓我們展開Service Center的架構(gòu)看看。
立足Service Center架構(gòu)，"冰山下"的基礎(chǔ)能力庫(kù)編寫很重要
下面這個(gè)組件主要負(fù)責(zé)微服務(wù)的注冊(cè)發(fā)現(xiàn)，提供Restful API。
它有四個(gè)主要的模塊：
· 服務(wù)注冊(cè)發(fā)現(xiàn)：通過(guò)注冊(cè)發(fā)現(xiàn)完成服務(wù)拓?fù)涞母兄?/P>
· 契約發(fā)現(xiàn)：每個(gè)服務(wù)具備一個(gè)契約記錄，支持多種格式如Open API，gRPC proto；
· RBAC：基于角色的訪問(wèn)控制，管理員可以管理賬號(hào)，將賬號(hào)分發(fā)給微服務(wù)或者不同人員；
· 服務(wù)治理：針對(duì)微服務(wù)下發(fā)治理規(guī)則，比如重試，限流，熔斷，路由策略等。
交付一個(gè)云服務(wù)遠(yuǎn)遠(yuǎn)不止交付業(yè)務(wù)功能，而是要去全方面的考慮安全，韌性，隱私，可運(yùn)維等能力，當(dāng)然我們將部分的能力可以交給一些中間件來(lái)完成，比如網(wǎng)關(guān)。然而仍有大量功能需要自己編寫，且可以復(fù)用在每個(gè)微服務(wù)中，這就是基礎(chǔ)能力庫(kù)編寫的初衷。
· 配額管理：云資源按照租戶進(jìn)行配額管理，租戶所能使用的資源受到嚴(yán)格限制
· 告警：當(dāng)微服務(wù)發(fā)生關(guān)鍵問(wèn)題時(shí)要直接上報(bào)告警系統(tǒng)，而非通過(guò)云服務(wù)設(shè)置閾值等告警策略
· 安全：加解密證書，密碼
· ID生成：ID的生成算法，用于生成微服務(wù)ID，實(shí)例ID等
· 多種中間件：調(diào)用過(guò)程需要被審計(jì)，調(diào)用鏈追蹤，生成指標(biāo)監(jiān)控等
該項(xiàng)目已經(jīng)開源并捐獻(xiàn)給Apache，項(xiàng)目地址https://github.com/apache/servicecomb-service-center
對(duì)于這些能力，抽取普通的庫(kù)函數(shù)也是完全不夠用的，所以要做到如下能力：
可插拔：也就是按需在編譯期引入（受限于Go語(yǔ)言能力），例如配額系統(tǒng)的具體實(shí)現(xiàn)在社區(qū)是不需要的。
異構(gòu)系統(tǒng)：也就是一個(gè)功能要有多種具體實(shí)現(xiàn)，比如審計(jì)，公有云存在一套審計(jì)系統(tǒng)需要對(duì)接，而社區(qū)則是本地日志打印。
不同的算法：解密工具、ID生成器……面對(duì)不同的交付場(chǎng)景或安全要求，都要通過(guò)不同實(shí)現(xiàn)來(lái)替換算法。比如ID生成可以是snowflake、UUID；加解密算法使用AES或者其他公開算法。
如何通過(guò)Go Chassis加速云服務(wù)開發(fā)？
為了滿足上面提到的需求多樣性，并且讓所有新規(guī)劃的組件受益、快速進(jìn)行開發(fā)，我們需要統(tǒng)一的框架和標(biāo)準(zhǔn)來(lái)加速開發(fā)，這就是華為云用Go語(yǔ)言編寫的開發(fā)框架Go Chassis誕生的原因。所以大家看可以看到go chassis的源碼和設(shè)計(jì)有著service center代碼的影子，感興趣的同學(xué)可以去深入閱讀下。
從Go Chassis的開發(fā)框架可以看到，業(yè)務(wù)邏輯是用戶自己編寫的業(yè)務(wù)代碼，框架分為協(xié)議層、中間層和插件套件三部分，管理部分是云服務(wù)，框架開發(fā)出來(lái)的應(yīng)用可以快速對(duì)接使用這些云能力。比如：
· 注冊(cè)發(fā)現(xiàn)插件可以對(duì)接Service Center與kubenetes
· 配額管理插件可以對(duì)接云服務(wù)的配額管理服務(wù)
· 中間件如指標(biāo)監(jiān)控對(duì)接到prometheus
那么如何通過(guò)這個(gè)框架來(lái)加速我們的開發(fā)呢？
手段1：將后端服務(wù)作為插件使用
后端服務(wù)指的是不由自己組織開發(fā)并運(yùn)維，從應(yīng)用運(yùn)行到基礎(chǔ)設(shè)施不可見(jiàn)的黑盒子服務(wù)。常見(jiàn)的后端包括配額管理、認(rèn)證鑒權(quán)服務(wù)和對(duì)象存儲(chǔ)服務(wù)，云原生的其中一個(gè)要素是把后端服務(wù)當(dāng)作附加資源。
當(dāng)我們調(diào)用這些后端服務(wù)時(shí)，其實(shí)它們并不在微服務(wù)的治理體系內(nèi)，考慮到可測(cè)試性（比如mock測(cè)試）以及可替換性（業(yè)務(wù)能夠連續(xù)，且隨時(shí)更換更好的服務(wù)，應(yīng)對(duì)變換的需求等），我們需要將它們插件化，以靈活的進(jìn)行選擇替換或者去除。
手段2：沉淀需求基線
在我們提供任何一種服務(wù)前，我們都需要滿足基本的要求，比如：
· 請(qǐng)求體必須做大小限制
· API必須限流
· 密碼不能明文存儲(chǔ)
· 訪問(wèn)進(jìn)行認(rèn)證鑒權(quán)
· 無(wú)單點(diǎn)故障
· 訪問(wèn)審計(jì)
· 運(yùn)維能力
考慮到這些需求，首先要將運(yùn)行時(shí)的調(diào)用模型標(biāo)準(zhǔn)化。由于不同部門會(huì)有私有協(xié)議訴求，那么服務(wù)治理就交給核心框架完成，協(xié)議由業(yè)務(wù)部門決定自主研發(fā)或是集成現(xiàn)有協(xié)議。
當(dāng)公司內(nèi)部不同部門都在開發(fā)自己的協(xié)議做自己的服務(wù)治理時(shí)，再將業(yè)務(wù)統(tǒng)一在一個(gè)架構(gòu)、工具鏈上，就非常困難。
所以，我們使用Invocation概念來(lái)統(tǒng)一協(xié)議描述，這樣就可以在統(tǒng)一的處理鏈中進(jìn)行處理。
處理鏈的設(shè)計(jì)滿足AOP，也就是在業(yè)務(wù)處理的前后加入代碼邏輯進(jìn)行特殊處理，比如審計(jì)用戶操作。
ResponseCallBack 用于接受后置handler返回的結(jié)果，所以每一個(gè)handler處理時(shí)都可以按需定義自己的ResponseCallBack來(lái)獲取后面handler，甚至是業(yè)務(wù)邏輯代碼的執(zhí)行結(jié)果，讓通用邏輯（即中間件）和業(yè)務(wù)邏輯徹底解耦。
目前Go Chassis已經(jīng)支持的中間件包括限流、熔斷、負(fù)載均衡、認(rèn)證鑒權(quán)和審計(jì)，都用此機(jī)制來(lái)實(shí)現(xiàn)：將公司全部的工具鏈，服務(wù)治理手段，安全合規(guī)等都落入到處理鏈中，來(lái)快速加快研發(fā)速度，并統(tǒng)一規(guī)范，減少管理負(fù)擔(dān)。
框架內(nèi)部提供給了命令式調(diào)用能力，比如指標(biāo)收集。
也提供了聲明式使用方式，比如流量管理，其具備基于流量特征的限流能力。
從插件能力全景圖可以看到，Go Chassis目前已經(jīng)支持多種生態(tài)，并對(duì)多種后端系統(tǒng)提供了抽象接口，從而幫助應(yīng)用快速開發(fā)。
通過(guò)這樣的框架，我們可以讓業(yè)務(wù)團(tuán)隊(duì)專注于業(yè)務(wù)代碼開發(fā)，而無(wú)需理解后端的復(fù)雜性和其他非功能需求。帶來(lái)的收益如下：
· 對(duì)于龐大的系統(tǒng)可以進(jìn)行mock測(cè)試，提升交付質(zhì)量
· 應(yīng)對(duì)不同的交付場(chǎng)景
· 保證后端可替換性
· 研發(fā)職責(zé)界面分離
從架構(gòu)或者業(yè)務(wù)演進(jìn)的角度來(lái)思考，后端使用的技術(shù)是在快速演進(jìn)的，我們需要通過(guò)后端服務(wù)的快速替換來(lái)確保系統(tǒng)和產(chǎn)品的及時(shí)演進(jìn)，所以接口設(shè)計(jì)的可替換性大于可重用性。這也滿足程序設(shè)計(jì)原則的依賴倒置，當(dāng)我們?cè)匍_發(fā)一個(gè)新的微服務(wù)時(shí)，僅僅需要實(shí)現(xiàn)他的業(yè)務(wù)邏輯即可。
手段3：通過(guò)配置簡(jiǎn)化開發(fā)流程
這也是一種命令式調(diào)用方式，其結(jié)構(gòu)如下：
Source層: 配置源是一種標(biāo)準(zhǔn)接口，可以通過(guò)實(shí)現(xiàn)一個(gè)source來(lái)接入不同配置源，它定義配置來(lái)自哪個(gè)資源：可以來(lái)自遠(yuǎn)端系統(tǒng)，來(lái)自本地文件，來(lái)自環(huán)境變量或是啟動(dòng)命令行。source負(fù)責(zé)將配置項(xiàng)緩存到本地內(nèi)存，用戶可以選擇加載任意的source實(shí)現(xiàn)。
remote source：對(duì)接分布式配置管理系統(tǒng)，目前對(duì)接了攜程開源的配置中心Apollo。
Config manager：負(fù)責(zé)整合管理所有source的配置，每個(gè)source可以定義優(yōu)先級(jí)，當(dāng)通過(guò)manager獲取配置時(shí)，如果2個(gè)不同的source有相同的配置，那么就會(huì)取最大優(yōu)先級(jí)的配置。
Event Dispatcher：用戶可以通過(guò)Archaius API進(jìn)行配置變化監(jiān)聽，當(dāng)source內(nèi)部的配置項(xiàng)新增、更新、刪除、時(shí)，都會(huì)通知監(jiān)聽器。
Source優(yōu)先級(jí)：優(yōu)先級(jí)由大到小依次為Config center、CLI、ENV、file，當(dāng)有相同配置項(xiàng)的時(shí)候僅優(yōu)先級(jí)大的配置生效。在一個(gè)分布式系統(tǒng)中，遠(yuǎn)程的配置中心理應(yīng)擁有最大優(yōu)先級(jí)。而在本地運(yùn)行一個(gè)獨(dú)立的進(jìn)程時(shí)，通常的思維是命令行參數(shù)優(yōu)先級(jí)高于環(huán)境變量，高于本地文件內(nèi)容。擁有了這樣一套機(jī)制后，用戶就無(wú)需再寫代碼處理配置項(xiàng)生效邏輯。
Archaius API： 封裝底層實(shí)現(xiàn)，提供友好的API供開發(fā)者使用。
其中，內(nèi)存source非常重要，它使得UT測(cè)試更加簡(jiǎn)單。File source使得本地進(jìn)程的測(cè)試可行。遠(yuǎn)程的配置中心比如攜程的Apollo，則幫助系統(tǒng)進(jìn)行聯(lián)調(diào)測(cè)試并支撐生產(chǎn)環(huán)境。
手段4：易處理
意思是它們可以瞬間開啟或停止。 這里我們不會(huì)談到快速的開始，因?yàn)镚o語(yǔ)言和Docker運(yùn)行時(shí)，容器平臺(tái)就能處理這樣的一個(gè)場(chǎng)景，所以我們談?wù)劽嫦蛞馔獾奶幚怼?/P>
這個(gè)Protocol server通常代表一個(gè)協(xié)議，也可以是某種編程模型，比如http。
還有個(gè)框架的配置樣例，意思是在一個(gè)微服務(wù)進(jìn)程中拉起了2個(gè)http端口和grpc端口服務(wù)。
在收到系統(tǒng)信號(hào)后，就會(huì)遍歷的停止每個(gè)server。
另外由社區(qū)開發(fā)者貢獻(xiàn)的自定義優(yōu)雅停機(jī)功能，可以允許用戶劫持信號(hào)和停機(jī)處理過(guò)程，也可以在前后自定義處理過(guò)程。
手段5：輕量級(jí)內(nèi)核
目前，Go Chassis只依賴必要的prometheus、opentracing、jwt、k8s client、Go-restful相關(guān)的依賴庫(kù)。
注冊(cè)發(fā)現(xiàn)也是可插拔的。
另外，包括grpc協(xié)議、kubernetes注冊(cè)中心等多種能力都在另一個(gè)倉(cāng)庫(kù)中提供，可以按需引入
擁有自己重新制造的輪子
擁有自己重新制造的輪子是Go Chassis開發(fā)框架logo想要傳達(dá)的理念。
我認(rèn)為真正有能力的團(tuán)隊(duì)不會(huì)自己重新制造輪子，因?yàn)樗麄兌裁词禽喿�，什么樣的輪子適合自己，并將這種抽象的輪子引入并進(jìn)行增強(qiáng)，打造成更加適合自己的輪子，你是"越野輪子"還是"雪地輪子"，品類皆由你定。我們將自己研發(fā)團(tuán)隊(duì)積累的能力抽象成多種接口及插件，為的就是不要重復(fù)制造輪子，而是基于現(xiàn)有輪子重新打造，讓項(xiàng)目產(chǎn)品跑的更快。
兩個(gè)Go Chassis的案例分享
首先是基于Go Chassis和Service Center進(jìn)行服務(wù)治理的視頻通話后臺(tái)，其一直應(yīng)用于華為榮耀手機(jī)和智慧屏等終端上，且上線了公有云，有效支撐終端公司暢聯(lián)通話上億注冊(cè)用戶。
第二個(gè)案例是基于Go Chassis開發(fā)服務(wù)治理底座的邊緣處理能力，它管理全國(guó)29個(gè)省、自治區(qū)的將近10萬(wàn)邊緣節(jié)點(diǎn)，超過(guò)50萬(wàn)邊緣應(yīng)用的部署。支撐了1萬(wàn)多個(gè)收費(fèi)站的門架信息采集業(yè)務(wù)的不斷調(diào)整、更新，滿足了每日3億條以上的信息采集。為日后車路協(xié)同、自動(dòng)駕駛等創(chuàng)新業(yè)務(wù)的發(fā)展提供了良好的平臺(tái)支撐。
https://github.com/kubeedge/kubeedge
除此之外，華為云ServiceStage就是無(wú)縫托管基于GoChassis開發(fā)的微服務(wù)，并在此之上提供免運(yùn)維的微服務(wù)引擎功能（ https://www.huaweicloud.com/product/servicestage.html）
總結(jié)
1、定義你的應(yīng)用開發(fā)通信協(xié)議
一家公司非常重要的兩樣?xùn)|西是企業(yè)文化與行為規(guī)范，這是每個(gè)公司的領(lǐng)導(dǎo)者必須優(yōu)先定義的事情，它就像是一種通信協(xié)議，保證團(tuán)隊(duì)之間能夠良好的協(xié)作。這樣領(lǐng)導(dǎo)者就無(wú)需事必躬親，甚至可以做到無(wú)為而治。這套機(jī)制就是所謂的"通信協(xié)議"
所以定義一套通信協(xié)議是非常重要的。Go chassis就是Go研發(fā)團(tuán)隊(duì)的通信協(xié)議
每個(gè)微服務(wù)都是個(gè)小團(tuán)隊(duì)開發(fā)的，有可能是同一個(gè)團(tuán)隊(duì)，也可能是不同團(tuán)隊(duì)，我們所做的框架是為了定義一套最簡(jiǎn)化的范式（接口與模型），以此來(lái)減輕研發(fā)的成本，同時(shí)兼顧擴(kuò)展性，不要對(duì)開發(fā)有過(guò)度的限制。我們規(guī)范化了API first來(lái)審視API設(shè)計(jì)，依賴管理來(lái)審視合理的服務(wù)關(guān)系，并規(guī)定所有的能力要沉淀為插件與中間件，而這些都是為了定義研發(fā)團(tuán)隊(duì)開發(fā)與治理云服務(wù)的"通信協(xié)議"。
2、Go在新基建中的作用
互聯(lián)網(wǎng)演進(jìn)第一代是PC，第二代是手機(jī)，第三代便是萬(wàn)物互聯(lián)，5G時(shí)代允許更多的設(shè)備接入，而較小的設(shè)備勢(shì)必會(huì)催生新的半導(dǎo)體，新的操作系統(tǒng)（比如說(shuō)華為鴻蒙），這樣一層層下去，勢(shì)必會(huì)需要一種新的語(yǔ)言及對(duì)應(yīng)的框架，Go語(yǔ)言的特性就很契合這樣一個(gè)位置，而分布式的設(shè)備也需要一種框架來(lái)進(jìn)行治理，Go Chassis也將在這里扮演比較重要的角色。
綜上，我認(rèn)為Go語(yǔ)言很可能成為基礎(chǔ)設(shè)施領(lǐng)域的一個(gè)開發(fā)底座，從kubeedge、視頻云等項(xiàng)目使用Go Chassis就可以看出端倪。
歡迎大家參與社區(qū)，Go Chassis開源項(xiàng)目地址：https://github.com/go-chassis/go-chassis
