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

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

作者｜Christian

編輯｜禚嫻靜

當下市場瞬息萬變，新技術不斷湧現，而微服務持續火熱。如果說2014年是微服務的元年，那麼2015年和2016年則是微服務走下神壇的時刻，越來越多的開發人員、架構師們探討著如何落地，如何解決各種實際問題，而很多技術棧和工具也紛紛湧現。

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

• 部署

• 交付

• API

• 版本控制

• 合約

• 縮放/自動縮放

• 服務發現

• 負載平衡

• 路由/自適應路由

• 健全狀態檢查

• 配置

• 熔斷器

• bulk-heads

• TTL / deadlining

• 延遲跟蹤

• 服務因果跟蹤

• 分布式日誌

• 度量操作與收集

Netflix和一些互連網公司作為早期微服務的採用者在這些領域做了很多的投資、嘗試和貢獻（如開源工具和相關論文）。然“微服務不是免費的午餐”。企業也並不都是Netflix，微服務的複雜性以及帶來的各種成本還是讓很多企業望而卻步，擋在了門外。

而如今，隨著越來越多的企業和社區加入到這一行列，經過早期採用者的沉澱和後續加入者的共同創造，在微服務的多個已知問題領域出現了新的一波解決方案和技術棧，給其注入了新的希望。最近，Christian Posta發表了題為“令人興奮的微服務技術棧2.0”的文章闡述了這一趨勢。他指出，這些技術棧的出現可以協助解決原來很多已有的或者在一些問題域中難易跨越的問題，甚至可以更優雅的解決。

Christian提到的第一個例子是Kubernetes。他指出：

Google和Red Hat都是第三次在構建一個有應用程式級原語的平台時使用Kubernetes，這個平台用來運行在容器上構建的原生雲應用程式。過去Google或開源社區也曾有過不同的嘗試，但Kubernetes大大簡化了像服務發現、規模化、部署等任務。似乎社區裡其他人也同意Kubernetes是GitHub上最熱門的項目，現在已經有1000多個提交者，很是瘋狂。如果Kubernetes出現在5年前，你不會看到這麼多“微服務”架構來解決這些問題。

Christian提到的另一個例子是熔斷。微服務架構是由多個獨立的服務組成，如果任何一個服務出現故障，就會導致其它依賴的服務像多米諾骨牌一樣出現連帶故障，最終導致整個系統的癱瘓。這就使得在微服務這樣的架構中，保障服務及服務之間的穩定性是非常重要的問題之一。而熔斷機制則是解決這個問題的一個模式。

熔斷機制是指在某個服務發生故障時，斷路器的故障監控向調用放返回一個及時的錯誤響應，而不是長時間的等待。這樣就不會使得線程因調用故障被長時間佔用，從而避免了故障在整個系統中的蔓延。

在熔斷技術的發展中，Christian談到：

在任何人都可以寫一個熔斷器（和許多有）。 Netflix甚至發布了他們的熔斷器（Hystrix庫）。應用程式可以使用hystrix庫來實現相關功能。然而其對於熔斷、服務發現、跟蹤，指標以及其它系列問題的缺點時，它強依賴於開發人員擷取正確的類庫，並真正的將這些事情作對。這是非常困難的。我們需要一種新的方式來解決這個問題。

Christian認為“我們真正想要的並不是更多的類庫或架構讓我們的應用程式變得更複雜，而是希望每個開發人員可以正確的在項目之間使用或應用它們，甚至更重要的是與程式設計語言無關。維護類庫不同的實現會讓人抓狂。”他指出在該領域也出現了一些“更優雅的”方式，如IMHO和來自Lyft的Envoy project。

IMHO將這些問題放在用戶端代理，這個代理部署為應用程式的“跨鬥”。而Envoy是一個非常小的C++用戶端代理，用於處理諸如熔斷、批量堆棧、服務發現、度量收集、跟蹤等問題。這意味著單個Envoy代理將與每個應用程式（1-1）一起部署。應用程式可以利用此功能，而無須考慮程式設計語言的約束。該應用程式基底本上通過“localhost”與其他服務通訊，Envoy完成服務的所有代理工作。它知道如何找到後端服務，完成自適應路由、重試、跟蹤、調節等任務。開發人員可以保持整潔的應用程式代碼，並免費獲得所有的這些便利。

Christian談到的最後一個例子是構建微服務的方式。他認為：

用REST構建微服務是絕對的事實。搭建一個服務，使用REST端點提供服務，並將其用在服務之間的所有互動和整合。而REST也存在一些在規模化上已知的問題，如追蹤服務的破壞性變更，理解服務之間的型別安全，以及與二進位RPC風格的服務（至少HTTP 1.x）相比帶來的過大開銷等。今天它正在演化為一些更優雅的方式，如非阻塞通訊架構（即RxJava、Vert.x）、非同步通訊模式等，甚至像RPC（如gRPC）也變得更加的優雅。

最後，筆者認為技術並不依賴於特定的技術棧或工具，然如果沒有有效技術棧和工具，好的想法也可能夭折。就如Christian所說，微服務領域不斷的發展，這些新的技術棧和解決思路可以讓一些已知的問題得到解決，並優雅的得到解決，他為之興奮，也值得我們關注。隨著越來越多的企業、社區、個人蔘與其中，微服務必將在更多的領域落地生根，開花結果。