當下市場瞬息萬變，新技術不斷涌現，而微服務持續火熱。如果說2014年是微服務的元年，那么2015年和2016年則是微服務走下神壇的時刻，越來越多的開發者、架構師們探討著如何落地，如何解決各種實際問題，而很多技術棧和工具也紛紛涌現。
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所說，微服務領域不斷的發展，這些新的技術棧和解決思路可以讓一些已知的問題得到解決，并優雅的得到解決，他為之興奮，也值得我們關注。隨著越來越多的企業、社區、個人參與其中，微服務必將在更多的領域落地生根，開花結果。
京公網安備 11010502049343號