對于DevOps來說，2017年是重要的一年，因?yàn)樯鷳B(tài)系統(tǒng)參與者數(shù)量大幅增長，CNCF項(xiàng)目增加了兩倍。展望未來一年，我們預(yù)計創(chuàng)新和市場變化將進(jìn)一步加速。以下是我們對2018年微服務(wù)趨勢的總結(jié):服務(wù)網(wǎng)格、事件驅(qū)動架構(gòu)、容器原生安全性、GraphQL和chaos engineering。
我們將關(guān)注這些趨勢，以及在未來一年圍繞這些趨勢開展業(yè)務(wù)的公司。你看到了什么趨勢?在下面的評論讓我們知道我們遺漏了什么，或者如果你同意/不同意我們在這里概述的觀點(diǎn)。
1.服務(wù)網(wǎng)格很流行！
服務(wù)網(wǎng)格是一個專用的基礎(chǔ)設(shè)施層，用于改善服務(wù)到服務(wù)的通信，是目前最熱門的關(guān)于云的本地類別。隨著容器變得越來越流行，服務(wù)拓?fù)渥兊迷絹碓絼討B(tài)，需要改進(jìn)的網(wǎng)絡(luò)功能。服務(wù)網(wǎng)格可以通過服務(wù)發(fā)現(xiàn)，路由，負(fù)載平衡，運(yùn)行狀況檢查和可觀察性來幫助管理流量。服務(wù)網(wǎng)格試圖馴服不守規(guī)矩的容器復(fù)雜性。
很明顯，服務(wù)網(wǎng)絡(luò)越來越受歡迎，因?yàn)橄馠AProxy，traefik和NGINX這樣的負(fù)載均衡器已經(jīng)開始將自己重新定位為數(shù)據(jù)平面。我們還沒有看到廣泛的部署，但我們知道在生產(chǎn)中運(yùn)行服務(wù)網(wǎng)格的企業(yè)。此外，服務(wù)網(wǎng)格不是微服務(wù)或Kubernetes環(huán)境專有的，也可以應(yīng)用于VM和無服務(wù)器環(huán)境。例如，國家生物技術(shù)信息中心沒有運(yùn)行容器，但它正在使用Linkerd。
服務(wù)網(wǎng)格也可以用于混沌工程，“在分布式系統(tǒng)上進(jìn)行實(shí)驗(yàn)的學(xué)科，以建立對系統(tǒng)承受湍流條件的能力的信心。”而不是安裝在每個主機(jī)上運(yùn)行的守護(hù)進(jìn)程，服務(wù)網(wǎng)格可以注入延遲和進(jìn)入環(huán)境的失敗。Istio和Buoyant 的 Linkerd 是該領(lǐng)域最引人注目的產(chǎn)品。請注意，Buoyant去年12月發(fā)布了針對Kubernetes的開源服務(wù)網(wǎng)絡(luò)Conduit v0.1。
.png)
2.事件驅(qū)動架構(gòu)的崛起。
隨著對業(yè)務(wù)敏捷性的需求的增加，我們開始看到向“推送”或基于事件的架構(gòu)的轉(zhuǎn)變，其中一個服務(wù)發(fā)送一個事件，一個或多個觀察該事件的觀察器容器通過異步運(yùn)行邏輯來響應(yīng)而沒有事件生產(chǎn)者意識到。與請求 - 響應(yīng)體系結(jié)構(gòu)不同，在事件驅(qū)動系統(tǒng)中，啟動容器中的功能流程和事務(wù)負(fù)載不依賴于下游容器中遠(yuǎn)程進(jìn)程的可用性和完成。這樣做的另一個優(yōu)點(diǎn)是開發(fā)人員在設(shè)計各自的服務(wù)時可以更加獨(dú)立。
雖然開發(fā)人員可以將容器環(huán)境設(shè)計為事件驅(qū)動，但函數(shù)即服務(wù)（FaaS）本質(zhì)上體現(xiàn)了這種質(zhì)量。在FaaS體系結(jié)構(gòu)中，函數(shù)作為文本存儲在數(shù)據(jù)庫中，并由事件觸發(fā)。調(diào)用該函數(shù)后，API控制器接收消息并通過負(fù)載均衡器將其發(fā)送到消息總線，消息總線將其排隊(duì)等待調(diào)度并配置到調(diào)用程序容器。執(zhí)行后，結(jié)果存儲在數(shù)據(jù)庫中，用戶將被發(fā)送結(jié)果，并且該函數(shù)將被解除，直到再次觸發(fā)為止。
FaaS的好處包括：1）縮短從編寫代碼到運(yùn)行服務(wù)的時間，因?yàn)闆]有工件可以創(chuàng)建或超越源代碼，2）由于函數(shù)由AWS Lambda等FaaS平臺管理和擴(kuò)展，所以開銷減少。然而，F(xiàn)aaS并非沒有挑戰(zhàn)。由于FaaS需要將每個服務(wù)分離，因此可能存在大量函數(shù)，這些函數(shù)很難發(fā)現(xiàn)，管理，協(xié)調(diào)和監(jiān)控。最后，如果沒有包括依賴關(guān)系在內(nèi)的全面可見性，很難調(diào)試FaaS系統(tǒng)，并且可能會出現(xiàn)無限循環(huán)。
目前，F(xiàn)aaS不適合需要更長調(diào)用，大量數(shù)據(jù)加載到內(nèi)存以及一致性能的進(jìn)程。雖然開發(fā)人員將FaaS用于后臺作業(yè)和時間事件，但我們相信隨著存儲層的加速和平臺性能的提高，用例將隨著時間的推移而擴(kuò)展。
2017年秋季，云原生計算基金會（CNCF）調(diào)查了550人，其中31％使用無服務(wù)器技術(shù)，28％計劃在未來18個月內(nèi)使用無服務(wù)器。調(diào)查隨后詢問正在使用哪個特定的無服務(wù)器平臺。在使用無服務(wù)器技術(shù)的169個中，77％表示他們使用AWS Lambda。雖然Lambda可能是領(lǐng)先的無服務(wù)器平臺，但我們相信可能會有一些有趣的機(jī)會。Edgecompute對于物聯(lián)網(wǎng)和AR / VR使用場景尤為強(qiáng)大。
3.安全需求正在發(fā)生變化。
由于內(nèi)核訪問，默認(rèn)情況下，打包在容器中的應(yīng)用程序基本上更安全。在VM環(huán)境中，唯一的可見性點(diǎn)是虛擬設(shè)備驅(qū)動程序?，F(xiàn)在轉(zhuǎn)移到容器環(huán)境，操作系統(tǒng)具有系統(tǒng)調(diào)用和語義含義。這是一個更豐富的信號。以前，運(yùn)營商可以通過將代理放入虛擬機(jī)來實(shí)現(xiàn)這一信號，但這很復(fù)雜且需要管理很多。容器提供更清晰的可見性，與VM環(huán)境相比，容器環(huán)境中的集成是微不足道的。
考慮到這一點(diǎn)，451 Research調(diào)查顯示，安全性是容器采用的最大障礙 - 挑戰(zhàn)仍然存在！最初，漏洞是容器環(huán)境中的主要安全問題。隨著公共注冊表中即用型容器圖像的數(shù)量成倍增加，確保它們也沒有漏洞變得非常重要。超時，圖像掃描和身份驗(yàn)證已經(jīng)成為一種商品。
與虛擬機(jī)管理程序作為訪問和控制點(diǎn)的虛擬化環(huán)境不同，任何可訪問內(nèi)核根目錄的容器最終都可以訪問內(nèi)核上的所有容器。反過來，組織必須保護(hù)容器與主機(jī)的交互方式，以及哪些容器可以執(zhí)行某些操作或系統(tǒng)調(diào)用。強(qiáng)化主機(jī)以確保正確配置組和命名空間對于維護(hù)安全性也很重要。
最后，傳統(tǒng)防火墻依靠IP地址規(guī)則來允許網(wǎng)絡(luò)流量。此技術(shù)無法擴(kuò)展到容器環(huán)境，因?yàn)閯討B(tài)協(xié)調(diào)器會重用IP。運(yùn)行時威脅檢測和響應(yīng)對于生產(chǎn)環(huán)境至關(guān)重要，并通過對容器環(huán)境進(jìn)行指紋識別并為行為基線構(gòu)建詳細(xì)圖片來實(shí)現(xiàn)，因此很容易檢測到異常行為并對攻擊者進(jìn)行沙箱處理。451研究報告指出，52％接受調(diào)查的公司正在生產(chǎn)集裝箱，這表明企業(yè)采用容器本地運(yùn)行時威脅檢測解決方案的速度加快。
4.從REST遷移到GraphQL。
GraphQL于2012年由Facebook創(chuàng)建，于2015年開源，是一種API規(guī)范，它是一種查詢語言和用于完成查詢的運(yùn)行時。GraphQL類型系統(tǒng)允許開發(fā)人員定義數(shù)據(jù)模式。可以添加新字段，并且可以在不影響現(xiàn)有查詢或重構(gòu)客戶端應(yīng)用程序的情況下老化字段。GraphQL功能強(qiáng)大，因?yàn)樗灰蕾囉谔囟ǖ臄?shù)據(jù)庫或存儲引擎。
GraphQL服務(wù)器作為單個HTTP端點(diǎn)運(yùn)行，表示服務(wù)的全部功能。通過在類型和字段（而不是像REST這樣的端點(diǎn)）方面定義資源之間的關(guān)系，GraphQL可以遵循屬性之間的引用，因此服務(wù)可以使用單個查詢從多個資源接收數(shù)據(jù)?；蛘?，REST API需要為單個請求加載多個URL，從而增加網(wǎng)絡(luò)躍點(diǎn)，從而減慢查詢速度。通過減少往返次數(shù)，GraphQL減少了每個數(shù)據(jù)請求所需的資源數(shù)量。返回的數(shù)據(jù)通常格式為JSON。
使用GraphQL而不是REST還有其他好處。首先，客戶端和服務(wù)器是分離的，因此可以單獨(dú)維護(hù)它們。與REST不同，GraphQL使用類似的語言在客戶端和服務(wù)器之間進(jìn)行通信，因此調(diào)試更容易。查詢的形狀完全匹配從服務(wù)器獲取的數(shù)據(jù)的形狀，與其他語言（如SQL或Gremlin）相比，使GraphQL高效且有效。查詢反映其響應(yīng)的形狀，因此可以檢測到偏差，并且可以識別未正確解析的字段。由于查詢更簡單，因此整個過程更加穩(wěn)定。眾所周知，該規(guī)范支持外部API，但我們發(fā)現(xiàn)它也被用于內(nèi)部API。
GraphQL用戶包括Amplitude，Credit Karma，KLM，NY Times，Twitch，Yelp等。11月，亞馬遜通過推出包含GraphQL支持的AWS AppSync驗(yàn)證了GraphQL的流行程度?？纯碐raphQL如何在諸如Twitch的Twirp RPC框架之類的gRPC和替代方案中發(fā)展，將會很有趣。
5.Chaos工程變得越來越出名。
最初由Netflix推廣，后來由亞馬遜(Amazon)、谷歌、微軟(Microsoft)和Facebook進(jìn)行實(shí)踐，Chaos工程在一個系統(tǒng)上進(jìn)行實(shí)驗(yàn)，以提高其抵御生產(chǎn)問題的能力。Chaos工程在過去十年中不斷發(fā)展。它從關(guān)閉生產(chǎn)環(huán)境中的服務(wù)的Chaos monkey開始，并通過故障注入測試(FIT)和用于更大環(huán)境的Chaos Kong擴(kuò)展了其規(guī)模。
從表面上看，Chaos工程只不過是注入混亂。雖然破壞系統(tǒng)可能很有趣，但它可能并不總是富有成效或提供有用的信息。Chaos engineering包含更廣泛的范圍，不僅包括注入失敗，還包括其他一些癥狀，如交通阻塞、不尋常的請求組合等，以發(fā)現(xiàn)存在的問題。除了驗(yàn)證假設(shè)，它還應(yīng)該揭示系統(tǒng)的新特性。通過挖掘系統(tǒng)弱點(diǎn)，團(tuán)隊(duì)可以幫助提高彈性，防止客戶體驗(yàn)差。
像神經(jīng)網(wǎng)絡(luò)和深度學(xué)習(xí)這樣的新技術(shù)是如此的復(fù)雜，以至于決定某物如何工作可能變得不如證明它是否正常運(yùn)作那么重要。Chaos工程通過對系統(tǒng)進(jìn)行整體測試來識別不穩(wěn)定性，從而幫助解決這一難題。隨著工程師們努力使他們?nèi)找鎻?fù)雜的系統(tǒng)更加健壯，這可能會成為一種更為普遍接受的做法。
隨著chaos工程變得更加主流，它可以采用現(xiàn)有的開源項(xiàng)目、商業(yè)產(chǎn)品，或者如上所述，通過服務(wù)網(wǎng)格實(shí)現(xiàn)。
英文原文：5 Microservices Trends to Watch in 2018
原文：開源中國：https://www.oschina.net/translate/5-microservices-trends-to-watch-in-2018?lang=chs&p=1
翻譯：硅谷課堂、liyue李月
