Bugsnag（注：一家雲端bug監控服務商）每天處理數以億計的錯誤資訊，為了處理這些資料，考慮優先構建一個可擴充套件，效能強大的後端系統，並從中學到很多有挑戰性的技術。最近，我們推出了新版本的儀表板，這個專案要求擴充套件系統，來處理服務呼叫的顯著增加，這些呼叫是跟蹤使用者釋出和會話所需的。

儀表板的釋出在進行中，工程團隊將Bugsnag的後端功能分解成稱之為管道（pipeline）的微服務體系。將管道擴充套件到支援釋出，意味著增加新的服務，並修改現有服務，也可預見到許多新的伺服器和客戶端的互動。為了處理上述架構的變化，需要採用一致性的方式來設計，實施和整合企業的服務。Bugsnag是一家多語言的公司，服務是用Java，Ruby，Go和Node.js等多語言編寫，因此企業需要一種與平臺無關的方法。

本文將介紹為什麼我們最終選擇了gRPC作為Pipeline的預設通訊框架。

達到REST API設計的極限

現有系統傳統上使用具有JSON有效載荷的REST API進行同步通訊。這種選擇是基於佔壓倒性比例的成熟度、熟悉度和工具的可用性做出的，但是隨著跨洲際工程團隊的增長，企業需要設計一致的，基於RESTful API的工具。

不幸的是，這感覺就像試圖將簡單的方法呼叫變成一個數據驅動的RESTful介面。這滿足了RESTful介面的verb，header，URL識別符號，資源的URL和有效載荷的神奇組合，並做了一個清潔，簡單，看起來幾乎不可能實現的功能介面。RESTful有很多規則和解釋，在大多數情況下會導致REST ish介面，這需要花費額外的時間和精力來保持其純度。

最終，考慮到RESTAPI的複雜性，我們找到了替代方案。希望微服務儘可能相互隔離，減少互動和解耦服務。它可以讓企業在很短的時間內創造出一個可行的服務，並防止跳過hoops。

評估REST的替代方案

不要輕易選擇通訊框架。大型組織（如Netflix）可以擁有超過500+個微服務的後端系統。遷移這些服務以取代不充分的服務間通訊會花費大量時間，從後勤和財務角度看這很不切實際。花時間從一開始就考慮正確的框架，可以省去很多未來的浪費。

我們花了大量的時間來制定評估標準和研究、選擇。Bugsnag到底長什麼樣子呢？

技術標準

在研究可用選項時，使用了一些特定的標準來評估。要考慮的事情是基於微服務架構的最有效的方法。主要目標是自由地使用通訊，消除通訊的複雜性，瞭解每項服務的責任所在。其中的一些技術問題是：

速度 – 對於大量的請求/響應API呼叫，需要將呼叫本身的延遲作為效能和使用者響應速度的最小因素。延遲的主要組成部分是連線成本，傳輸成本和訊息編碼/解碼時間。

基礎架構相容性 – 框架在基礎架構中扮演的角色如何？主要是關於負載平衡和自動擴充套件？我們使用託管在Google雲端平臺上的Kubernetes服務，因此需要框架來相容這種環境。

開發工具 – 在實現框架時，提供儘可能小的摩擦將會使開發人員更快捷。哪些工具可以幫助編碼，本地測試端點，以及單元和整合測試的stubbing/mocking？當事情出錯時，我們需要能夠看到包括內容在內的請求資訊。訊息格式等因素也可以使除錯更容易依賴於工具，例如JSON訊息是人可讀的，但是二進位制訊息將需要額外的努力來解碼。

成熟度和採用 – 對於初創公司來說，資源是有限的，需要花費在公司的核心業務上，而不是修復，測試和增強第三方框架。諸如框架的普及，大規模使用的例子，社群的活躍程度以及框架本身的成熟度等因素都是穩定性的良好指標。需要強調的是，選擇一個解決具體問題的框架，而並非選擇最新最熱的。

多平臺支援 – 在真正的微服務思維中，使用最適合其目的的語言編寫企業的服務，目前包括Java，Ruby，Go和Node。框架是否為現有的語言選擇提供了一流的支援，同時提供了用其他語言編寫新服務的選項？

程式碼量 – 框架應該有助於降低工程成本。企業需要編寫和維護多少程式碼才能使其工作？與業務邏輯相比，這是多少樣板程式碼？

安全 – 所有的內部通訊都應該被認證和加密。我們需要能夠使用所有通訊的SSL / TLS（或等價物）。

設計上的考慮，並非都與技術有關

服務API是最重要的介面之一，因為在開發過程中對設定服務期望至關重要。解決服務API的設計是一項艱鉅的任務，當不同的團隊負責所涉及的不同服務時，該任務會被放大。最大限度地減少由於預期不匹配而浪費的時間和精力，與縮短編碼時間一樣有價值。由於Bugsnag擁有跨地區的工程團隊，因此溝通時間有限。必須通過簡化溝通，確保事情不用那麼多解釋，否則錯誤很容易產生，事情很容易被拖延。

以下是在選擇框架時的一些設計考慮因素：

強型別 – 訊息是否是強型別的？如果通過服務邊界傳送的訊息清晰可見，那麼可以消除由於型別而造成的設計和執行時錯誤。

開啟解釋 – 能夠直接從服務API規範生成客戶端庫，減少了誤解的問題。錯誤條件 – 有一套明確定義的錯誤程式碼可以更容易一致地交流問題。

文件 – 服務API應該是易讀易懂的。定義服務API的格式應該儘可能清楚，準確地描述端點。

版本控制 – 更改是不可避免的，這是一個很好的選擇，在某些時候，服務API將需要修改。所使用的訊息傳遞格式和服務定義可以影響修改API並將其部署到生產的容易程度。是否有明確的路徑來增加版本及其相應的庫，並推出更改？

微服務最佳實踐，為什麼可擴充套件性是重要的

除了上面列出的標準外，還需要選擇一個易於擴充套件的框架。隨著微服務的發展，企業需要越來越多的“開箱即用”功能，發展的同時，為系統增加了更多的複雜性。因此企業希望的功能包括：

異常處理 – 在請求級別提供一個處理異常的機制。它允許捕獲有關請求的重要上下文元資料，例如發出請求的使用者，可以用例外報告。我們使用Bugsnag輕鬆地監視這些異常。

智慧重試 – 在特定條件下重試請求，例如僅在5xx狀態碼上。這包括支援各種退避策略，如指數退避。

服務發現配置 – 將通訊框架連線到流行的服務發現應用程式（如Zookeeper，Eureka或Consul）的選項可以提供一種快速簡便的解決方案，以繞過企業的架構來請求路由。

度量、跟蹤和日誌記錄 – 可觀察性對於複雜的分散式系統是必不可少的，但是應該小心監視的內容。在服務邊界自動收集指標和跟蹤資訊可以快速回答常見問題，例如“我的服務對請求響應緩慢嗎？”以及“請求失敗的頻率如何？”。

熔斷 – 這種模式可以通過自動檢測問題和快速失敗來防止級聯服務故障。也可以由長時間緩慢的請求來觸發，以提供響應降級的服務而不是不斷地超時。

快取和批處理 – 通過使用快取或批處理請求來加速請求。

大多數框架不會提供所有功能，但至少它們應該是可擴充套件的，以便在需要時新增。

什麼是gRPC和協議緩衝區？

沒有一個框架是萬能的。我們探索的一些選項包括Facebook的Thrift，Apache Hadoop的Avro，Twitter的Finagle，甚至使用JSON模式。

我們的需求更接近於遠端程式呼叫（RPC），給予所需要的細粒度控制。使用RPC的另一個吸引力是使用介面描述語言或IDL。IDL允許以獨立於語言的格式描述服務API，將介面與任何特定的程式語言分離。他們可以提供一系列的好處，包括服務API的一個單一的事實來源，並可能被用來生成客戶端和伺服器程式碼來與這些服務進行互動。IDL的例子包括Thrift，Avro，CORBA，當然還有ProtocolBuffers。

最後，明確的獲勝者是基於協議緩衝區的gRPC。

什麼是gRPC？

我們選擇了gRPC，因為它滿足了我們的功能需求（包括未來的可擴充套件性），背後的活躍社群以及HTTP / 2框架的使用。

gRPC是由Google開發，設計用於傳統的RPC呼叫。該框架使用最新的網路傳輸協議HTTP / 2，主要用於通過使用流的單個TCP連線來實現低延遲和多路複用請求。與REST over HTTP / 1.1相比，gRPC非常快速和靈活。

gRPC的效能對於設定管道來處理儀表板釋出的大量增加至關重要。此外，HTTP / 2是下一個標準化的網路協議，可以利用為HTTP / 2開發的工具和技術（如Envoy代理），併為gRPC提供一流的支援。由於多路複用流支援，gRPC支援雙向通訊，不限於簡單的請求/響應呼叫。

什麼是Protobufs（協議緩衝區）？

Protocol Buffers或protobufs是定義和序列化結構化資料為高效的二進位制格式的一種方式，也是由Google開發的。二者的有效結合，也是我們選擇gRPC的主要原因之一。

以前有許多與想修復的版本相關的問題。微服務意味著必須不斷更新，需要適應並保持向前和向後相容的介面，protobufs對此非常有用。由於是二進位制格式，所以它們也是通過wire快速傳送的小型有效載荷。

Protobuf訊息使用關聯的IDL進行描述，它提供了一個緊湊的，強型別的，向後相容的格式來定義訊息和RPC服務。我們使用最新的proto3規範，並在此處顯示protobuf訊息的實際示例。

所有欄位proto3都是可選的。如果未設定欄位，將始終使用預設值。這與欄位編號相結合提供了一個API，可以非常抵抗打破變化。通過遵循一些簡單的規則，向前和向後相容性可以成為大多數API更改的預設值。

protobuf格式還允許定義RPC服務本身。服務端點與訊息結構共存，在單個protobuf檔案中提供RPC服務的自包含定義。對於我們的跨洲際的工程團隊來說，這非常有用，他們可以從一個檔案中瞭解服務如何工作，生成客戶端並開始使用它。以下是我們的服務之一：

該框架能夠生成程式碼來使用protobuf檔案與這些服務進行互動，這是另一個優勢，它可以自動生成需要的所有類。這個生成的程式碼負責訊息建模，並提供一個存根類，其中包含與您的服務端點相關的重複方法呼叫。

支援多種語言，包括C ++，Java，Python，Go，Ruby，C＃，Node，Android，Objective-C和PHP。但是，使用protobuf檔案維護和同步生成的程式碼是個問題。我們已經能夠通過使用Protobuf檔案自動生成客戶端庫來解決這個問題，會在即將釋出的下一篇部落格文章中分享更多的內容。

gRPC最好的特性之一是支援中介軟體模式，被稱為攔截器。它允許擴充套件所有的gRPC實現（這對企業來說很重要），能夠輕鬆訪問所有請求，從而實現自己的微服務最佳實踐。gRPC還內建了對一系列認證機制的支援，包括SSL / TLS。

gRPC社群

我們正處於gRPC採用的開始階段，期待社群提供更多的工具和技術。很高興能夠加入這個充滿活力的社群，並對未來的專案有一些想法，我們希望看到這些專案是開放原始碼或我們自己寫的。

gRPC工具的當前狀態

gRPC比較新，缺乏可用的開發工具，特別是與經驗豐富的REST over HTTP / 1.1協議相比。搜尋教程和示例時，這一點尤其明顯，因為只有少數有用的資訊。二進位制格式也使訊息不透明，需要努力解碼。雖然有一些選擇，例如JSON程式碼轉換器可以幫助，但預計需要做一些基礎工作，以便為gRPC提供順暢的開發體驗。

我們喜歡用Apiary 來記錄外部API。使用服務協議緩衝區（protobuf）檔案自動生成互動式文件的等價物，將是理想的有效的內部通訊gRPCAPI。protobuf檔案的靜態分析在執行時能捕獲更多的bug。使用Checkstyle作為Java程式碼，並且把它用作類似於protobuf的檔案。自定義攔截器可以提供跟蹤，日誌記錄和錯誤監視功能。我們希望開源我們的Bugsnag gRPC攔截器，以自動捕獲並向Bugsnag報告錯誤。

gRPC的增長和採用

在過去幾年中，gRPC的普及度大幅增長，Square，Lyft，Netflix，Docker，Cisco和CoreOS等公司大規模採用。Netflix Ribbon是基於RPC呼叫使用REST的微服務通訊框架的事實標準。今年，他們宣佈，由於其多語言支援和更好的可擴充套件性/可組合性，他們正在向gRPC過渡。該框架最近也於2017年3月加入了CNCF基金會，支援重量級的Kubernetes和Prometheus。gRPC社群非常活躍，與開源gRPC生態系統 列出了許多gRPC激動人心的專案。

另外，gRPC有我們認同的原則

Lyft在轉向gRPC方面做了大量的討論，這與我們的經驗非常相似：使用Protocol Buffers和gRPC生成統一的API。值得一試。

gRPC現在還處於初期階段，存在一些明顯的磨合問題，但未來前景光明。總的來說，我們對gRPC如何整合到後端系統非常樂觀，並且很高興見證這個框架的發展。

原文連結：