令人激動的微服務2.0技術棧

banq發表於2017-02-27
微服務
談論微服務架構時，我們認識到：團隊的組織方式與溝通結構對技術系統的設計有著很大影響。當我們實際開始實現這些架構時，會發現已經處於分散式系統中的較深位置。我們還發現，已經有許多技術和方法大大促進這一技術演變。因此，我們可能處在一個新的進化迴圈開始，這個新的進化就是以Lambda /函式作為服務風格。當然這裡不想過多講述。

當構建微服務時，我們真的深深進入了分析分散式系統 - 一個已經研究了40年以上的技術主題，複雜的自適應系統理論已經深入人心有很長的時間。從技術的角度來看，我們需要解決的事情如下：

部署
交付
API
版本控制
合同
縮放/自動縮放
服務發現
負載均衡
路由/自適應路由
健康檢查
配置
斷路器
bulk-heads
TTL / deadlining
延遲跟蹤
服務因果跟蹤
分散式日誌
度量操作與收集

Netflix和其他網際網路公司為解決其中一些問題做了一些事情（如開源軟體或釋出相關技術論文）。但是還是反覆修改。真正令人興奮的是，我們開始看到了下一波技術，以更優雅的方式解決了這些問題。

例如，Kubernetes是Google和Red Hat構建平臺時使用的一組應用程式級原語，用於執行在容器上構建雲本地應用程式。曾經有過迭代（無論是在Google還是在開源），但Kubernetes已經大大簡化了像服務發現，擴充套件，部署等微服務環節。建立簡單的東西其實並不容易。Kubernetes應該是github上最熱的專案，現在大概1000多個提交者。那老厲害了！如果在5年前，你不會看到這麼多的“微服務”框架解決服務發現，部署，故障轉移，負載平衡等。

另一個例子是斷路器。任何人都可以寫一個斷路器。Netflix甚至釋出了他們的斷路器（Hystrix庫）作為OSS。應用程式可使用這個hystrix斷路器庫來實現斷路功能，當希望保護自己免受下游異常嘗試請求，包括控制發生故障的爆炸半徑時，由它觸發網路呼叫，。缺點（包括斷路，服務發現，跟蹤等）是開發者需要獲得這些正確的庫包，並將這些庫包鼓搗在一起能夠正常工作，卻是很難。

Envoy專案
希望有一種不同的方式來解決這些。“更優雅”的做法，是把這些東西放在一個客戶端代理，和你的應用被部署為一個“sidecar”。這是一個偉大的小專案，同時幫助我們的工具還有來自Lyft 的Envoy專案。Envoy是一個非常小的C ++客戶端代理，用於處理諸如斷路/批次堆疊/服務發現/度量收集/跟蹤等操作。這意味著單個Envoy代理將與每個應用程式一起部署，不必考慮什麼程式語言。應用程式基本上透過“localhost”與其他服務進行交談，Envoy完全代理實際服務。它知道如何找到後端服務，做自適應路由，重試，跟蹤，調節等。作為開發人員，可以讓程式碼更乾淨，又能免費獲得所有微服務的這些功能便利。


GRPC
最後，一般我們使用REST構建微服務。一個服務對外暴露一個REST端點，並使用REST實現服務之間的所有互動/整合。但它正在演變成一個更優雅的東西。REST達到一定規模以後，會存在一些問題包括跟蹤服務之間的破碎變化，理解跨服務之間的型別安全，特別是相對於使用RPC風格的服務（至少在HTTP 1.x情況下）時會有相當大的開銷。令人興奮的是非阻塞通訊框架（即RxJava，Vert.x），非同步通訊模式，甚至GRPC庫包正在讓事情變得更加優雅。

因此，令人興奮的是，在開源社群新工具正在融合，將更多的複雜的東西推下一層（同時用最好的技術實現），從而進一步提高了構建業務應用程式的良好開發體驗。

Excited about a '2.0' tech stack for microservices

相關文章