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