《Google SRE主管：使用開源軟件打造類似Google的開發(fā)和生產(chǎn)環(huán)境》要點(diǎn)：
本文介紹了Google SRE主管：使用開源軟件打造類似Google的開發(fā)和生產(chǎn)環(huán)境，希望對(duì)您有用。如果有疑問，可以聯(lián)系我們。

作者簡(jiǎn)介：

Minghua Ye(Google ?SRE 主管)

2007加入 Google 公司,2009年開始,主要負(fù)責(zé) Google 的云計(jì)算平臺(tái),特別是 Google App Engine.

前言

如果大家對(duì) App Engine 還不熟悉的話,簡(jiǎn)單來說 App Engine 就是 Google 提供的 paas,一個(gè)開發(fā)、托管網(wǎng)絡(luò)應(yīng)用程序的平臺(tái),使用戶的程序能在 Google 的數(shù)據(jù)中心運(yùn)行.

作者在本文中分析他在 Google 的一些經(jīng)驗(yàn),鑒于作者的 App Engine 背景.本文很多話題里都涉及跟 App Engine 相關(guān)的應(yīng)用.

1、云平臺(tái)至關(guān)重要的可擴(kuò)展性

當(dāng)7年前,我剛剛開始在 App Engine 的 SRE 生涯的時(shí)候,App Engine 還是在 Google 內(nèi)部一個(gè)很渺小的服務(wù),活躍用戶,流量都遠(yuǎn)遠(yuǎn)不能和 Google Search 這樣的巨無霸相提并論.

而在短短的7年時(shí)間 App Engine 實(shí)現(xiàn)的指數(shù)型的增長(zhǎng),現(xiàn)如今已經(jīng)成為了 Google 云平臺(tái)的重要組成部分.

應(yīng)用程序開發(fā)者在 App Engine 上部署了上千萬的應(yīng)用.在其中不乏一些很重要的客戶和很有趣的用例.

上圖里我提及到的這些應(yīng)用開發(fā)者們都在它們的網(wǎng)站公開描述了它們?cè)?AE 上的實(shí)現(xiàn).大家如果有興趣做深入的案例研究可以直接搜索相關(guān)的關(guān)鍵字.

值得一提的是威廉王子和凱瑟琳王妃在2011的大婚,皇室選擇了 Google 的云計(jì)算平臺(tái)作為婚禮網(wǎng)站和婚禮實(shí)時(shí)直播平臺(tái)的提供者.而作為運(yùn)維小組的 SRE 也得到了皇室的感謝.

在短短的幾天之內(nèi),網(wǎng)站接受了 15m 的訪問和超過 42000QPS 的峰值流量.他們之所以選擇 AE,最重要的原因是看中了 AE 系統(tǒng)的自動(dòng)可擴(kuò)展性.

網(wǎng)站開發(fā)者僅僅部署了網(wǎng)站的源代碼,而后臺(tái)容量的自動(dòng)擴(kuò)展和流量的自動(dòng)均衡都由 AE 系統(tǒng)自動(dòng)完成,而不需要開發(fā)者或者 SRE 的任何干預(yù).

另外一個(gè)很重要的客戶是 Workivia,Workivia 向全球500強(qiáng)公司提供財(cái)務(wù)報(bào)表的提交服務(wù).眾所周知,財(cái)務(wù)報(bào)表的提交時(shí)限性很強(qiáng),而且不容許有失敗和錯(cuò)誤出現(xiàn).

這對(duì)云平臺(tái)的穩(wěn)定性和容錯(cuò)性就有更高的要求,它們選擇AE原因也恰恰在于由 Google 提供的高可靠 SLA.

同時(shí) AE 的自動(dòng)擴(kuò)展功能使他們能夠在繁忙的稅季有足夠的后端冗余去處理用戶請(qǐng)求,而在淡季又能夠通過自動(dòng)減少后端容量已到達(dá)節(jié)約開支的目的.

最后要提到的是 Spotiy,作為互聯(lián)網(wǎng)音樂流媒體的主要提供者,它們主要看中的是 Google 云平臺(tái)的一致性和寬容度,不論你是處理每秒7個(gè)事件還是70萬個(gè),服務(wù)都能保證一至的用戶體驗(yàn).

所以說可擴(kuò)展性對(duì)于一個(gè)云平臺(tái)來說是至關(guān)重要的.

2、可擴(kuò)展系統(tǒng)的基石

Google App Engine 采用了和大多數(shù)其他 Google 內(nèi)部服務(wù)一樣的微服務(wù)架構(gòu).而不得不提到的是這些微服務(wù)的共同點(diǎn)和它們所依賴的通用內(nèi)部平臺(tái).

• 分布式鎖和存儲(chǔ)服務(wù)

首先不得提到的則是 Google 內(nèi)部自己實(shí)現(xiàn)的分布式鎖和存儲(chǔ)服務(wù) chubby.

在 Google 內(nèi)部基本上所有的服務(wù)都依賴于 chubby 所提供的一系列功能.chubby 本身并沒有開源,但是 Google 將 chubby 的實(shí)現(xiàn)細(xì)節(jié)和 API 通過一篇研究論文發(fā)表了.

這篇研究論文也恰恰催生了一批開源的實(shí)現(xiàn),而其中最有名的就是大家都知道的 Apache zookeeper.

而大家也能看到 chubby 所提供的功能在單機(jī)環(huán)境就類似于大家熟知的鎖和寄存器,而 chubby 或者 zookeeper 恰恰是把這種基礎(chǔ)的服務(wù)拓展到了分布式的環(huán)境,是的軟件開發(fā)者能在分布式的環(huán)境中輕松的應(yīng)用單機(jī)開發(fā)中常用的方法和理論.

• 服務(wù)的自動(dòng)發(fā)現(xiàn)

當(dāng)你有很多松耦合的微服務(wù)組建在運(yùn)行的時(shí)候,如何能夠自動(dòng)發(fā)現(xiàn)并尋址到這些服務(wù),就變的非常重要.服務(wù)的自動(dòng)發(fā)現(xiàn)在 Google 也是通過 chubby 來實(shí)現(xiàn)的.

BNS 是在chubby上實(shí)現(xiàn)的地址協(xié)議,chubby 提供小文件讀寫的一致性,這樣就能通過寫入 BNS 地址和真實(shí) IP：port 綁定,來實(shí)現(xiàn)服務(wù)發(fā)現(xiàn).

當(dāng)服務(wù)需要解析一個(gè) BNS 地址的時(shí)候,他只要通過一致性的讀取相應(yīng)文件即可.etcd 和基于 etcd 的 skydns 則是服務(wù)發(fā)現(xiàn)在開源環(huán)境中的實(shí)現(xiàn).

• 流量負(fù)載均衡

當(dāng)你有很多松耦合的微服務(wù)組建在運(yùn)行的時(shí)候,你同樣面臨的問題是如何能夠?qū)崿F(xiàn)流量負(fù)載均衡.

在 Google 內(nèi)部負(fù)載均衡是通過 Google generic service loadbalancer 服務(wù)來實(shí)現(xiàn)的.你如果使用 Google 的云平臺(tái)的話,Google 可以提供給你網(wǎng)絡(luò)即3層,或者 HTTPS 即七層的自動(dòng)負(fù)載均衡.

在 AWS 也有類似的 Elastic loadbalancer 實(shí)現(xiàn).在很多情況下,用戶還可以通過 HApxoy 或者 engineX 來實(shí)現(xiàn)一些簡(jiǎn)單的負(fù)載均衡.

• Protobuf

最后值得一提的是 Google 的 RPC 子系統(tǒng)和 Protobuf.Google 在近期開源了 gRPC 也就是 Google 內(nèi)部使用的 RPC 子系統(tǒng)的開源實(shí)現(xiàn).

gRPC 使用 http2 作為傳輸層,同時(shí)使用 Protobuf 作為接口描述語言和消息格式.

2.1 分布式鎖和存儲(chǔ)

讓我們來看一下 chubby 會(huì)提供哪些在分布式環(huán)境下至關(guān)重要的服務(wù)：

• 第一、不同微服務(wù)間的同步,通過獨(dú)占鎖的實(shí)現(xiàn),只有一個(gè)服務(wù)是能獲得獨(dú)占鎖并更新共享的信息.
• 第二、有一些服務(wù)需要實(shí)現(xiàn)主從分配,多個(gè)服務(wù)用例能通過masterelection庫,競(jìng)選出真正的主實(shí)例.而且從實(shí)例能自動(dòng)轉(zhuǎn)換成主實(shí)例,如果主實(shí)例不可用.
• 第三、是序列號(hào)這個(gè)在存儲(chǔ)和網(wǎng)絡(luò)中都會(huì)經(jīng)常要用到.
• 第四、則是我前面提到的 BNS 服務(wù).
• 第五、chubby 本身是一個(gè)文件系統(tǒng),所以可以用于分布式的文件存儲(chǔ).事實(shí)上,在 Google 很多服務(wù)用 chubby 存儲(chǔ)一些不大的配置文件,這樣能實(shí)現(xiàn)在線的和同步的,不需要重啟服務(wù)的配置更新.

2.2 自動(dòng)注冊(cè)的服務(wù)發(fā)現(xiàn)

自動(dòng)服務(wù)發(fā)現(xiàn)使服務(wù)能夠?qū)崿F(xiàn)自動(dòng)擴(kuò)展,你可以隨時(shí)增加服務(wù)的容量,增加或更改服務(wù)運(yùn)行的數(shù)據(jù)中心,而作為 devops 則不需要上游系統(tǒng)做任何更改.

當(dāng)一個(gè)服務(wù)用例失敗的時(shí)候,RPC 傳輸和負(fù)載均衡中間件能自動(dòng)發(fā)現(xiàn)并將不健康的用例自動(dòng)從負(fù)載均衡的備選用例中剔除,從而實(shí)現(xiàn)真正的無人值守.

2.3 谷歌云平臺(tái)上的負(fù)載均衡

剛才提到了在 Google 的云平臺(tái)上有現(xiàn)成的負(fù)載均衡可供用戶使用.而且用戶也能通過使用第三方的軟硬件來自行實(shí)現(xiàn)負(fù)載均衡.

2.4 Protobuf

不得不提到的是 Google 開源的 Protobuf 庫提供給不同的語言開發(fā)者一個(gè)統(tǒng)一的通訊協(xié)議,服務(wù)定義和存儲(chǔ)格式.

Protobuf 重要特性是向后兼容性,比如說應(yīng)用在08書寫的 Protobuf 格式的日志,在2017年能夠繼續(xù)被使用和分析,即使是 Protocol buffers 已經(jīng)被更新很多次.

在接口描述語言和消息格式里面,你可以任意添加新的閾值而不影響服務(wù)的向后兼容性.這一點(diǎn)在大規(guī)模微服務(wù)實(shí)現(xiàn)中非常重要.

當(dāng)你的服務(wù)用例數(shù)足夠大,你則不可能在不影響服務(wù)質(zhì)量的前提下,同時(shí)更新所有的服務(wù)用例.所以前端和后端必須保證向后兼容的特性,否則在升級(jí)過程中會(huì)造成數(shù)據(jù)的丟失或損壞.

在大型的開發(fā)團(tuán)隊(duì)里,更要求前端和后端能獨(dú)立開發(fā),獨(dú)立部署,獨(dú)立測(cè)試,而 Protobuf 的向后兼容的特性,恰恰是這樣的開發(fā)部署模式成為了可能.

Protobuf 還提供跨平臺(tái)和語言的兼容性,所以 node.js 的前端能很自然的使用 Protobuf 與 C++ 的后端通信.

更值得一提的是,恰恰是 Protobuf 的這種特性像 Google 這樣使用一個(gè)單一代碼庫的公司能在內(nèi)部部署成千上萬的相互依賴的松耦合的微服務(wù).

3、使用Google service(C++)的核心類庫

接下來我想談?wù)勎以谧鳛橐粋€(gè)軟件開發(fā)者的一些體會(huì),SRE 是 Dev＋Ops 的合體,所以參與開發(fā)也是 SRE 日常工作的一個(gè)重要組成部分.

眾所周知 Google 廣泛的使用各種開源軟件打造它的平臺(tái),而作為開發(fā)者 Google 也向開源社區(qū)回饋了很多內(nèi)部使用的工具的類庫.

我將舉例幾個(gè)跟 SRE 相關(guān)比較緊密的庫逐一講解,我選擇了 C++ 的版本因?yàn)槲抑饕獜氖?C++ 的開發(fā)所以比較熟悉.

這些類庫大多也都有其他語言的實(shí)現(xiàn),值得一提的這些庫基本上被所有的 Google 內(nèi)部服務(wù)調(diào)用.

3.1 命令行庫—gflags

首先提到的是 Google 的命令行庫叫 gflags.在 Google 幾乎所有的服務(wù)參數(shù)和特性都可以通過命令行參數(shù)來調(diào)教和更改.在很多時(shí)候新的服務(wù)特性往往是通過命令行參數(shù)來啟用或者禁用.

舉個(gè)例子,如果在某次的部署當(dāng)中新的服務(wù)實(shí)現(xiàn)了 A,B,C 三種新功能,但是通過部署測(cè)試發(fā)現(xiàn) B 功能不能正常工作,這是SRE往往采用命令行參數(shù)來禁用b功能,從而使 A,C 功能能及時(shí)的發(fā)布.

在第二個(gè)例子當(dāng)中,SRE 經(jīng)常會(huì)通過命令行參數(shù)來更改服務(wù)的特性而不需要重新編譯和打包.很多時(shí)候程序的配置被寫在命令行里,這樣只要更改命令行就能服務(wù)實(shí)現(xiàn)不同的功能.例如你能配置一個(gè)服務(wù)使用英文而另一個(gè)服務(wù)使用中文而不需要重新打包.

gflag 定義 flag 為全局變量,你可以用 DEFINE flag 去在任何文件里定義命令行標(biāo)志,在其他文件中通過 DELCLARE_flag 來實(shí)現(xiàn)調(diào)用.使用 gflag 你將擺脫手動(dòng)分析 args,能使程序更加簡(jiǎn)潔易讀.

3.2 日志服務(wù)—glog庫

第二個(gè)提到的是 Google 的 glog 庫,實(shí)現(xiàn)了程序中標(biāo)準(zhǔn)的日志服務(wù).

glog 定義了不同的日志類型,而開發(fā)者可以通過 LOG 類型來簡(jiǎn)單的實(shí)現(xiàn)將不同的日志存儲(chǔ)在不同文件中的目的.

glog 提供了 CHECK 宏,能幫助程序檢測(cè)一些不可恢復(fù)的錯(cuò)誤并終止程序.在這個(gè)例子中如果寫失敗將終止程序并將 stacktrace 輸出到日志中方便 SRE 和 DEV 來 debug.

glog還提供詳細(xì)日志服務(wù),詳細(xì)日志通過命令行參數(shù)來控制.通過 vmodule 和 v 兩個(gè)參數(shù)可以控制不同的模塊產(chǎn)生不同的日志.

glog 還提供系統(tǒng)信號(hào)處理,在程序被系統(tǒng)信號(hào)終止的時(shí)候,他能自動(dòng)生成出錯(cuò)點(diǎn)的 stacktrace 方便 SRE 和 dev 來 debug.

glog可以和其他的日志管理程序一起實(shí)現(xiàn)日志的重定向等服務(wù).

3.3 單元測(cè)試庫—Google test

最后要提到的是 Google 開源的單元測(cè)試庫 Googletest,提供兩個(gè)方面的功能：

一個(gè)是單元測(cè)試；
一個(gè)是虛擬測(cè)試；

單元測(cè)試被廣泛應(yīng)用于 Google 的代碼庫,基本上每個(gè)實(shí)現(xiàn)都有單元測(cè)試,而且測(cè)試的覆蓋率會(huì)自動(dòng)報(bào)告.

虛擬測(cè)試則廣泛應(yīng)用在復(fù)雜服務(wù)的測(cè)試中,在寫單元測(cè)試的過程中,被測(cè)部分的復(fù)雜依賴則通過 mock 來實(shí)現(xiàn),是開發(fā)者能專注于單元測(cè)試中.

轉(zhuǎn)載請(qǐng)注明本頁網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4295.html