當(dāng)下市場(chǎng)瞬息萬變，新技術(shù)不斷涌現(xiàn)，而微服務(wù)持續(xù)火熱。如果說2014年是微服務(wù)的元年，那么2015年和2016年則是微服務(wù)走下神壇的時(shí)刻，越來越多的開發(fā)者、架構(gòu)師們探討著如何落地，如何解決各種實(shí)際問題，而很多技術(shù)棧和工具也紛紛涌現(xiàn)。

Netflix和一些互聯(lián)網(wǎng)公司作為早期微服務(wù)的采用者在這些領(lǐng)域做了很多的投資、嘗試和貢獻(xiàn)（如開源工具和相關(guān)論文）。然“微服務(wù)不是免費(fèi)的午餐”。企業(yè)也并不都是Netflix，微服務(wù)的復(fù)雜性以及帶來的各種成本還是讓很多企業(yè)望而卻步，擋在了門外。

而如今，隨著越來越多的企業(yè)和社區(qū)加入到這一行列，經(jīng)過早期采用者的沉淀和后續(xù)加入者的共同創(chuàng)造，在微服務(wù)的多個(gè)已知問題領(lǐng)域出現(xiàn)了新的一波解決方案和技術(shù)棧，給其注入了新的希望。最近，Christian Posta發(fā)表了題為“令人興奮的微服務(wù)技術(shù)棧2.0”的文章闡述了這一趨勢(shì)。他指出，這些技術(shù)棧的出現(xiàn)可以幫助解決原來很多已有的或者在一些問題域中難易跨越的問題，甚至可以更優(yōu)雅的解決。

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

Google和Red Hat都是第三次在構(gòu)建一個(gè)有應(yīng)用程序級(jí)原語的平臺(tái)時(shí)使用Kubernetes，這個(gè)平臺(tái)用來運(yùn)行在容器上構(gòu)建的原生云應(yīng)用程序。過去Google或開源社區(qū)也曾有過不同的嘗試，但Kubernetes大大簡化了像服務(wù)發(fā)現(xiàn)、規(guī)?；⒉渴鸬热蝿?wù)。似乎社區(qū)里其他人也同意Kubernetes是GitHub上最熱門的項(xiàng)目，現(xiàn)在已經(jīng)有1000多個(gè)提交者，很是瘋狂。如果Kubernetes出現(xiàn)在5年前，你不會(huì)看到這么多“微服務(wù)”框架來解決這些問題。

Christian提到的另一個(gè)例子是熔斷。微服務(wù)架構(gòu)是由多個(gè)獨(dú)立的服務(wù)組成，如果任何一個(gè)服務(wù)出現(xiàn)故障，就會(huì)導(dǎo)致其它依賴的服務(wù)像多米諾骨牌一樣出現(xiàn)連帶故障，最終導(dǎo)致整個(gè)系統(tǒng)的癱瘓。這就使得在微服務(wù)這樣的架構(gòu)中，保障服務(wù)及服務(wù)之間的穩(wěn)定性是非常重要的問題之一。而熔斷器模式則是解決這個(gè)問題的一個(gè)模式。

熔斷器模式指，在某個(gè)服務(wù)發(fā)生故障時(shí)，熔斷器的故障監(jiān)控向調(diào)用放返回一個(gè)及時(shí)的錯(cuò)誤響應(yīng)，而不是長時(shí)間的等待。這樣就不會(huì)使得線程因調(diào)用故障被長時(shí)間占用，從而避免了故障在整個(gè)系統(tǒng)中的蔓延。

在熔斷器技術(shù)的發(fā)展中，Christian談到：

“現(xiàn)在任何人都可以寫一個(gè)熔斷器（和許多有）。 Netflix甚至發(fā)布了他們的熔斷器（Hystrix庫）。應(yīng)用程序可以使用hystrix庫來實(shí)現(xiàn)相關(guān)功能。然而其對(duì)于熔斷、服務(wù)發(fā)現(xiàn)、跟蹤，指標(biāo)以及其它系列問題的缺點(diǎn)時(shí)，它強(qiáng)依賴于開發(fā)人員獲取正確的類庫，并真正的將這些事情作對(duì)。這是非常困難的。我們需要一種新的方式來解決這個(gè)問題。”

Christian認(rèn)為“我們真正想要的并不是更多的類庫或框架讓我們的應(yīng)用程序變得更復(fù)雜，而是希望每個(gè)開發(fā)人員可以正確的在項(xiàng)目之間使用或應(yīng)用它們，甚至更重要的是與編程語言無關(guān)。維護(hù)類庫不同的實(shí)現(xiàn)會(huì)讓人抓狂。”他指出在該領(lǐng)域也出現(xiàn)了一些“更優(yōu)雅的”方式，如IMHO和來自Lyft的Envoy project。

IMHO將這些問題放在客戶端代理，這個(gè)代理部署為應(yīng)用程序的“跨斗”。而Envoy是一個(gè)非常小的C++客戶端代理，用于處理諸如熔斷、批量堆棧、服務(wù)發(fā)現(xiàn)、度量收集、跟蹤等問題。這意味著單個(gè)Envoy代理將與每個(gè)應(yīng)用程序（1-1）一起部署。應(yīng)用程序可以利用此功能，而無須考慮編程語言的約束。該應(yīng)用程序基本上通過“localhost”與其他服務(wù)通信，Envoy完成服務(wù)的所有代理工作。它知道如何找到后端服務(wù)，完成自適應(yīng)路由、重試、跟蹤、調(diào)節(jié)等任務(wù)。開發(fā)人員可以保持整潔的應(yīng)用程序代碼，并免費(fèi)獲得所有的這些便利。

Christian談到的最后一個(gè)例子是構(gòu)建微服務(wù)的方式。他認(rèn)為：

用REST構(gòu)建微服務(wù)是絕對(duì)的事實(shí)。搭建一個(gè)服務(wù)，使用REST端點(diǎn)提供服務(wù)，并將其用在服務(wù)之間的所有交互和集成。而REST也存在一些在規(guī)?；弦阎膯栴}，如追蹤服務(wù)的破壞性變更，理解服務(wù)之間的類型安全，以及與二進(jìn)制RPC風(fēng)格的服務(wù)（至少HTTP 1.x）相比帶來的過大開銷等。今天它正在演進(jìn)為一些更優(yōu)雅的方式，如非阻塞通信框架（即RxJava、Vert.x）、異步通信模式等，甚至像RPC（如gRPC）也變得更加的優(yōu)雅。

最后，筆者認(rèn)為技術(shù)并不依賴于特定的技術(shù)?；蚬ぞ?，然如果沒有有效的技術(shù)棧和工具，好的想法也可能夭折。就如Christian所說，微服務(wù)領(lǐng)域不斷的發(fā)展，這些新的技術(shù)棧和解決思路可以讓一些已知的問題得到解決，并優(yōu)雅的得到解決，他為之興奮，也值得我們關(guān)注。隨著越來越多的企業(yè)、社區(qū)、個(gè)人參與其中，微服務(wù)必將在更多的領(lǐng)域落地生根，開花結(jié)果。