2018年5大微服務(wù)架構(gòu)發(fā)展趨勢(shì)

1. 服務(wù)網(wǎng)格白熱化

服務(wù)網(wǎng)格是一個(gè)專注于服務(wù)間通信的基礎(chǔ)設(shè)施層，也是目前最受關(guān)注的與云原生有關(guān)的話題。隨著容器的普及，服務(wù)拓?fù)渥兊迷絹?lái)越動(dòng)態(tài)化，這對(duì)網(wǎng)絡(luò)功能提出了更多的要求。服務(wù)網(wǎng)格通過(guò)服務(wù)發(fā)現(xiàn)、路由、負(fù)載均衡、健康檢測(cè)和可觀察性來(lái)管理流量，簡(jiǎn)化容器與生俱來(lái)的復(fù)雜性。

隨著 HAProxy、traefik 和 NGINX 逐步把自己定位成數(shù)據(jù)平面，服務(wù)網(wǎng)格也變得越來(lái)越流行。盡管服務(wù)網(wǎng)格還沒(méi)有得到大規(guī)模部署，但確實(shí)有些企業(yè)已經(jīng)在生產(chǎn)環(huán)境中運(yùn)行服務(wù)網(wǎng)格。另外，服務(wù)網(wǎng)格不僅可以用在微服務(wù)或 Kubernetes 環(huán)境中，也可以被用在 VM 和無(wú)服務(wù)器架構(gòu)的環(huán)境中。例如，美國(guó)國(guó)家生物技術(shù)信息中心雖然沒(méi)有使用容器，但他們使用了 Linkerd。

服務(wù)網(wǎng)格還可以用在混沌工程中。服務(wù)網(wǎng)格可以給系統(tǒng)注入延遲和故障，這樣就不需要在每臺(tái)主機(jī)上安裝后臺(tái)進(jìn)程。

Istio 和 Buoyant 的 Linkerd 是目前最為流行的服務(wù)網(wǎng)格框架。另外，Buoyant 在去年 12 月份開(kāi)源了用于 Kubernetes 的服務(wù)網(wǎng)格框架 Conduit V0.1。

2. 事件驅(qū)動(dòng)架構(gòu)的崛起

隨著業(yè)務(wù)場(chǎng)景的不斷變化，我們已經(jīng)看到了基于推送或事件的架構(gòu)正在成為一種趨勢(shì)。服務(wù)向訂閱事件的觀察者容器發(fā)送事件，容器異步做出響應(yīng)，事件發(fā)送者可能對(duì)此一無(wú)所知。與請(qǐng)求響應(yīng)式架構(gòu)不同的是，在基于事件的系統(tǒng)架構(gòu)中，發(fā)起事件的容器并不依賴下游的容器，它們的處理過(guò)程和加載的事務(wù)與下游容器的可用性或完成情況無(wú)關(guān)。這種架構(gòu)的另一個(gè)好處是，開(kāi)發(fā)者可以更加獨(dú)立地設(shè)計(jì)各自的服務(wù)。

在容器環(huán)境中使用基于事件的架構(gòu)時(shí)，功能即服務(wù)（FaaS）可以助他們一臂之力。在 FaaS 架構(gòu)中，功能以文本的形式保存在數(shù)據(jù)庫(kù)中，然后由事件來(lái)觸發(fā)它們。在調(diào)用一個(gè)功能時(shí)，API 控制器會(huì)收到一個(gè)消息，并將它通過(guò)負(fù)載均衡器發(fā)送到消息總線，調(diào)用者容器負(fù)責(zé)處理隊(duì)列中的消息。消息處理完畢后，結(jié)果被保存在數(shù)據(jù)庫(kù)中，并發(fā)送給用戶，而功能暫時(shí)退役，等待下一次觸發(fā)。

FaaS 有兩大好處。首先，縮短了服務(wù)開(kāi)發(fā)時(shí)間，因?yàn)槌嗽创a，不需要?jiǎng)?chuàng)建其他任何東西。其次，降低了開(kāi)銷，因?yàn)楣δ艿墓芾砗蜕炜s通常是由 FaaS 平臺(tái)（比如 AWS Lambda）來(lái)完成的。當(dāng)然，采用 FaaS 本身也存在一些挑戰(zhàn)。FaaS 要求解耦每一個(gè)服務(wù)，那么就會(huì)存在大量的服務(wù)需要發(fā)現(xiàn)、管理、編配和監(jiān)控。因?yàn)槿狈?duì)服務(wù)依賴鏈的全盤(pán)了解，F(xiàn)aaS 系統(tǒng)難以調(diào)試，而且可能會(huì)出現(xiàn)無(wú)限循環(huán)依賴問(wèn)題。

在目前看來(lái)，F(xiàn)aaS 并不適用于某些場(chǎng)景，比如那些需要較長(zhǎng)處理時(shí)間、需要往內(nèi)存里加載大量數(shù)據(jù)或需要穩(wěn)定性能的場(chǎng)景。開(kāi)發(fā)者主要使用 FaaS 來(lái)運(yùn)行后臺(tái)作業(yè)和處理臨時(shí)事件，不過(guò)我們相信，隨著存儲(chǔ)層速度的加快和平臺(tái)性能的提升，F(xiàn)aaS 的應(yīng)用場(chǎng)景會(huì)越來(lái)越多。

2017 年秋天，CNCF 對(duì) 550 名用戶進(jìn)行了問(wèn)卷調(diào)查，其中 31% 的人正在使用無(wú)服務(wù)器架構(gòu)技術(shù)，28% 的人打算在未來(lái) 18 個(gè)月使用無(wú)服務(wù)器架構(gòu)技術(shù)。而在使用無(wú)服務(wù)器架構(gòu)技術(shù)的 169 人當(dāng)中，有 77% 使用的是 AWS Lambda。雖說(shuō) Lambda 或許是領(lǐng)先的無(wú)服務(wù)器架構(gòu)平臺(tái)，但我們相信邊緣計(jì)算仍然有機(jī)會(huì)。邊緣計(jì)算將在物聯(lián)網(wǎng)和 AR/VR 領(lǐng)域大展拳腳。

3. 安全模型的變化

因?yàn)閷?duì)內(nèi)核訪問(wèn)方面的限制，部署在容器中的應(yīng)用程序相對(duì)安全。在 VM 環(huán)境中，虛擬設(shè)備驅(qū)動(dòng)器是唯一暴露可見(jiàn)性的地方。而在容器環(huán)境里，操作系統(tǒng)提供了系統(tǒng)調(diào)用，信號(hào)源也變得更加豐富。之前，管理員需要在 VM 中安裝代理，但那樣太復(fù)雜了，需要管理太多的東西。容器提供了更清晰的可見(jiàn)性，相比 VM，與容器的集成會(huì)更加容易。

451 Research 公司發(fā)布的一份調(diào)查報(bào)告表明，安全性是影響容器普及的最大障礙。在一開(kāi)始，安全漏洞就已成為容器環(huán)境最主要的問(wèn)題。隨著越來(lái)越多的容器鏡像的發(fā)布，確保這些鏡像不含有漏洞便成為當(dāng)務(wù)之急。隨著時(shí)間的推移，容器鏡像掃描和認(rèn)證成為了一種有利可圖的生意。

在 VM 環(huán)境中，hypervisor 扮演著訪問(wèn)控制點(diǎn)的角色，而對(duì)于一個(gè)具備內(nèi)核訪問(wèn)權(quán)限的容器來(lái)說(shuō)，它可以訪問(wèn)內(nèi)核上的其他所有容器。因此，使用容器的企業(yè)必須限制容器與宿主機(jī)之間的交互行為以及容器將會(huì)執(zhí)行的系統(tǒng)調(diào)用。確保宿主機(jī)的 cgroup 和 namespace 配置妥當(dāng)也是非常重要的一點(diǎn)。

傳統(tǒng)的防火墻通過(guò) IP 地址規(guī)則來(lái)控制網(wǎng)絡(luò)流量。不過(guò)，這種技術(shù)無(wú)法在容器環(huán)境中使用，因?yàn)閯?dòng)態(tài)編配需要重用 IP。在生產(chǎn)環(huán)境，運(yùn)行時(shí)攻擊檢測(cè)是非常關(guān)鍵的安全手段，通過(guò)構(gòu)建容器指紋和定義行為基準(zhǔn)，就可以很容易檢測(cè)出異常行為，并把攻擊者隔離在沙箱中。451 Research 公司的報(bào)告指出，受調(diào)的 52% 企業(yè)在生產(chǎn)環(huán)境中使用了容器，可見(jiàn)，在容器環(huán)境中使用運(yùn)行時(shí)攻擊檢測(cè)十分有必要。

4. 從 REST 到 GraphQL

GraphQL 是 Facebook 于 2012 年創(chuàng)建并于 2015 年開(kāi)源的一套查詢語(yǔ)言 API 規(guī)范。GraphQL 的類型系統(tǒng)允許開(kāi)發(fā)者自己定義數(shù)據(jù) schema，可以增加新字段，也可以刪除舊字段，這些都不會(huì)影響已有的查詢，也不需要修改客戶端。GraphQL 非常強(qiáng)大，因?yàn)樗鼪](méi)有與特定的數(shù)據(jù)庫(kù)或存儲(chǔ)引擎綁定在一起。

GraphQL 服務(wù)器使用一個(gè)單獨(dú)的端點(diǎn)來(lái)提供所有的功能。只要定義好資源之間類型和字段的關(guān)系（這個(gè)與 REST 端點(diǎn)不太一樣），GraphQL 就可以跟蹤屬性之間的關(guān)系，在單個(gè)查詢中從多個(gè)資源獲取數(shù)據(jù)。在使用 REST 時(shí)，可能需要為單個(gè)請(qǐng)求加載多個(gè) URL，這樣不僅增加了網(wǎng)絡(luò)跳轉(zhuǎn)，還拖慢了查詢速度。通過(guò)減少網(wǎng)絡(luò)跳轉(zhuǎn)，GraphQL 降低了單個(gè)數(shù)據(jù)請(qǐng)求所要耗費(fèi)的資源。GraphQL 返回的數(shù)據(jù)通常是 JSON 格式。

使用 GraphQL 還有其他好處。首先，客戶端和服務(wù)器端之間解耦開(kāi)了，這樣就可以分開(kāi)維護(hù)。GraphQL 使用相似的語(yǔ)言進(jìn)行客戶端與服務(wù)器端之間的通信，所以調(diào)試更加容易了。查詢結(jié)構(gòu)與服務(wù)器端返回的數(shù)據(jù)結(jié)構(gòu)完全匹配，因此，相比其他語(yǔ)言，如 SQL 或 Gremlin，GraphQL 更加高效。查詢本身就反映了響應(yīng)消息的結(jié)構(gòu)，所以可以很容易地檢測(cè)出差異，如果沒(méi)有正確處理某些字段也可以很容易識(shí)別出來(lái)。因?yàn)椴樵兏?jiǎn)單了，整個(gè)流程也變得更穩(wěn)定。雖然說(shuō) GraphQL 規(guī)范主打支持外部 API，但我們發(fā)現(xiàn)將它用在內(nèi)部 API 中也很不錯(cuò)。

GraphQL 的用戶包括 Amplitude、Credit Karma、KLM、紐約時(shí)報(bào)、Twitch、Yelp 等。去年 11 月，亞馬遜推出的 AppSync 就提供了 GraphQL 支持，可見(jiàn)它有多么流行。在存在 gRPC 和 Twitch Twirp 這些 RPC 框架的前提下，看著 GraphQL 的發(fā)展真是一件有趣的事情。

5. 混沌工程浮出水面

混沌工程最初由 Netflix 發(fā)起，后來(lái)亞馬遜、谷歌、微軟和 Facebook 也開(kāi)始實(shí)踐?；煦绻こ痰哪康脑谟诟倪M(jìn)系統(tǒng)的確定性，以便應(yīng)對(duì)生產(chǎn)環(huán)境的各種問(wèn)題?；煦绻こ探?jīng)歷了十年的發(fā)展。最初，Netflix 開(kāi)發(fā)了 Chaos Monkeys，用它在生產(chǎn)環(huán)境關(guān)閉部分服務(wù)，后來(lái)演變成故障注入測(cè)試和 Chaos Kong，用在更大規(guī)模的環(huán)境中。

從表面上看，混沌工程只是為了向系統(tǒng)注入混亂。盡管通過(guò)破壞系統(tǒng)來(lái)發(fā)現(xiàn)問(wèn)題是件有趣的事情，但這樣做并不一定會(huì)帶來(lái)生產(chǎn)力的提升或者給我們提供有用的信息。實(shí)際上，混沌工程不只是注入故障那么簡(jiǎn)單，它還可以制造流量高峰、非正常的請(qǐng)求等，用以發(fā)現(xiàn)已經(jīng)存在的問(wèn)題。除了可以用它驗(yàn)證假設(shè)，還可用它來(lái)發(fā)現(xiàn)系統(tǒng)的新屬性。通過(guò)發(fā)現(xiàn)系統(tǒng)弱點(diǎn)來(lái)改進(jìn)系統(tǒng)彈性，以免造成糟糕的用戶體驗(yàn)。

混沌工程通過(guò)對(duì)系統(tǒng)進(jìn)行全面的測(cè)試來(lái)改善穩(wěn)定性。隨著工程師們?cè)谔嵘到y(tǒng)健壯性方面所做的工作越來(lái)越多，混沌工程似乎會(huì)變得越來(lái)越為人們所接受。

隨著混沌工程成為主流，它可能會(huì)以開(kāi)源項(xiàng)目的形式、商業(yè)的形式甚至是服務(wù)網(wǎng)格的形式來(lái)實(shí)現(xiàn)。

最后給大家 推薦一個(gè) Java 架構(gòu)方面的交流學(xué)習(xí)群： 698581634 ，里面會(huì)分享一些資深架構(gòu)師錄制的視頻錄像：有 Spring ， MyBatis ， Netty 源碼分析，高并發(fā)、高性能、分布式、微服務(wù)架構(gòu)的原理， JVM 性能優(yōu)化這些成為架構(gòu)師必備的知識(shí)體系，主要針對(duì) Java 開(kāi)發(fā)人員提升自己，突破瓶頸，相信你來(lái)學(xué)習(xí)，會(huì)有提升和收獲。在這個(gè)群里會(huì)有你需要的內(nèi)容   朋友們請(qǐng)抓緊時(shí)間加入進(jìn)來(lái)吧。