《Google SRE主管：使用開源軟件打造類似Google的開發和生產環境》要點：
本文介紹了Google SRE主管：使用開源軟件打造類似Google的開發和生產環境，希望對您有用。如果有疑問，可以聯系我們。

作者簡介：

Minghua Ye(Google ?SRE 主管)

2007加入 Google 公司,2009年開始,主要負責 Google 的云計算平臺,特別是 Google App Engine.

前言

如果大家對 App Engine 還不熟悉的話,簡單來說 App Engine 就是 Google 提供的 paas,一個開發、托管網絡應用程序的平臺,使用戶的程序能在 Google 的數據中心運行.

作者在本文中分析他在 Google 的一些經驗,鑒于作者的 App Engine 背景.本文很多話題里都涉及跟 App Engine 相關的應用.

1、云平臺至關重要的可擴展性

當7年前,我剛剛開始在 App Engine 的 SRE 生涯的時候,App Engine 還是在 Google 內部一個很渺小的服務,活躍用戶,流量都遠遠不能和 Google Search 這樣的巨無霸相提并論.

而在短短的7年時間 App Engine 實現的指數型的增長,現如今已經成為了 Google 云平臺的重要組成部分.

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

上圖里我提及到的這些應用開發者們都在它們的網站公開描述了它們在 AE 上的實現.大家如果有興趣做深入的案例研究可以直接搜索相關的關鍵字.

值得一提的是威廉王子和凱瑟琳王妃在2011的大婚,皇室選擇了 Google 的云計算平臺作為婚禮網站和婚禮實時直播平臺的提供者.而作為運維小組的 SRE 也得到了皇室的感謝.

在短短的幾天之內,網站接受了 15m 的訪問和超過 42000QPS 的峰值流量.他們之所以選擇 AE,最重要的原因是看中了 AE 系統的自動可擴展性.

網站開發者僅僅部署了網站的源代碼,而后臺容量的自動擴展和流量的自動均衡都由 AE 系統自動完成,而不需要開發者或者 SRE 的任何干預.

另外一個很重要的客戶是 Workivia,Workivia 向全球500強公司提供財務報表的提交服務.眾所周知,財務報表的提交時限性很強,而且不容許有失敗和錯誤出現.

這對云平臺的穩定性和容錯性就有更高的要求,它們選擇AE原因也恰恰在于由 Google 提供的高可靠 SLA.

同時 AE 的自動擴展功能使他們能夠在繁忙的稅季有足夠的后端冗余去處理用戶請求,而在淡季又能夠通過自動減少后端容量已到達節約開支的目的.

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

所以說可擴展性對于一個云平臺來說是至關重要的.

2、可擴展系統的基石

Google App Engine 采用了和大多數其他 Google 內部服務一樣的微服務架構.而不得不提到的是這些微服務的共同點和它們所依賴的通用內部平臺.

• 分布式鎖和存儲服務

首先不得提到的則是 Google 內部自己實現的分布式鎖和存儲服務 chubby.

在 Google 內部基本上所有的服務都依賴于 chubby 所提供的一系列功能.chubby 本身并沒有開源,但是 Google 將 chubby 的實現細節和 API 通過一篇研究論文發表了.

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

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

• 服務的自動發現

當你有很多松耦合的微服務組建在運行的時候,如何能夠自動發現并尋址到這些服務,就變的非常重要.服務的自動發現在 Google 也是通過 chubby 來實現的.

BNS 是在chubby上實現的地址協議,chubby 提供小文件讀寫的一致性,這樣就能通過寫入 BNS 地址和真實 IP：port 綁定,來實現服務發現.

當服務需要解析一個 BNS 地址的時候,他只要通過一致性的讀取相應文件即可.etcd 和基于 etcd 的 skydns 則是服務發現在開源環境中的實現.

• 流量負載均衡

當你有很多松耦合的微服務組建在運行的時候,你同樣面臨的問題是如何能夠實現流量負載均衡.

在 Google 內部負載均衡是通過 Google generic service loadbalancer 服務來實現的.你如果使用 Google 的云平臺的話,Google 可以提供給你網絡即3層,或者 HTTPS 即七層的自動負載均衡.

在 AWS 也有類似的 Elastic loadbalancer 實現.在很多情況下,用戶還可以通過 HApxoy 或者 engineX 來實現一些簡單的負載均衡.

• Protobuf

最后值得一提的是 Google 的 RPC 子系統和 Protobuf.Google 在近期開源了 gRPC 也就是 Google 內部使用的 RPC 子系統的開源實現.

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

2.1 分布式鎖和存儲

讓我們來看一下 chubby 會提供哪些在分布式環境下至關重要的服務：

• 第一、不同微服務間的同步,通過獨占鎖的實現,只有一個服務是能獲得獨占鎖并更新共享的信息.
• 第二、有一些服務需要實現主從分配,多個服務用例能通過masterelection庫,競選出真正的主實例.而且從實例能自動轉換成主實例,如果主實例不可用.
• 第三、是序列號這個在存儲和網絡中都會經常要用到.
• 第四、則是我前面提到的 BNS 服務.
• 第五、chubby 本身是一個文件系統,所以可以用于分布式的文件存儲.事實上,在 Google 很多服務用 chubby 存儲一些不大的配置文件,這樣能實現在線的和同步的,不需要重啟服務的配置更新.

2.2 自動注冊的服務發現

自動服務發現使服務能夠實現自動擴展,你可以隨時增加服務的容量,增加或更改服務運行的數據中心,而作為 devops 則不需要上游系統做任何更改.

當一個服務用例失敗的時候,RPC 傳輸和負載均衡中間件能自動發現并將不健康的用例自動從負載均衡的備選用例中剔除,從而實現真正的無人值守.

2.3 谷歌云平臺上的負載均衡

剛才提到了在 Google 的云平臺上有現成的負載均衡可供用戶使用.而且用戶也能通過使用第三方的軟硬件來自行實現負載均衡.

2.4 Protobuf

不得不提到的是 Google 開源的 Protobuf 庫提供給不同的語言開發者一個統一的通訊協議,服務定義和存儲格式.

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

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

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

在大型的開發團隊里,更要求前端和后端能獨立開發,獨立部署,獨立測試,而 Protobuf 的向后兼容的特性,恰恰是這樣的開發部署模式成為了可能.

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

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

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

接下來我想談談我在作為一個軟件開發者的一些體會,SRE 是 Dev＋Ops 的合體,所以參與開發也是 SRE 日常工作的一個重要組成部分.

眾所周知 Google 廣泛的使用各種開源軟件打造它的平臺,而作為開發者 Google 也向開源社區回饋了很多內部使用的工具的類庫.

我將舉例幾個跟 SRE 相關比較緊密的庫逐一講解,我選擇了 C++ 的版本因為我主要從事 C++ 的開發所以比較熟悉.

這些類庫大多也都有其他語言的實現,值得一提的這些庫基本上被所有的 Google 內部服務調用.

3.1 命令行庫—gflags

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

舉個例子,如果在某次的部署當中新的服務實現了 A,B,C 三種新功能,但是通過部署測試發現 B 功能不能正常工作,這是SRE往往采用命令行參數來禁用b功能,從而使 A,C 功能能及時的發布.

在第二個例子當中,SRE 經常會通過命令行參數來更改服務的特性而不需要重新編譯和打包.很多時候程序的配置被寫在命令行里,這樣只要更改命令行就能服務實現不同的功能.例如你能配置一個服務使用英文而另一個服務使用中文而不需要重新打包.

gflag 定義 flag 為全局變量,你可以用 DEFINE flag 去在任何文件里定義命令行標志,在其他文件中通過 DELCLARE_flag 來實現調用.使用 gflag 你將擺脫手動分析 args,能使程序更加簡潔易讀.

3.2 日志服務—glog庫

第二個提到的是 Google 的 glog 庫,實現了程序中標準的日志服務.

glog 定義了不同的日志類型,而開發者可以通過 LOG 類型來簡單的實現將不同的日志存儲在不同文件中的目的.

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

glog還提供詳細日志服務,詳細日志通過命令行參數來控制.通過 vmodule 和 v 兩個參數可以控制不同的模塊產生不同的日志.

glog 還提供系統信號處理,在程序被系統信號終止的時候,他能自動生成出錯點的 stacktrace 方便 SRE 和 dev 來 debug.

glog可以和其他的日志管理程序一起實現日志的重定向等服務.

3.3 單元測試庫—Google test

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

一個是單元測試；
一個是虛擬測試；

單元測試被廣泛應用于 Google 的代碼庫,基本上每個實現都有單元測試,而且測試的覆蓋率會自動報告.

虛擬測試則廣泛應用在復雜服務的測試中,在寫單元測試的過程中,被測部分的復雜依賴則通過 mock 來實現,是開發者能專注于單元測試中.

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4295.html