在2017年，DevOps領域中增加了大量的生態(tài)系統(tǒng)玩家，那么2018年會有哪些變化呢？本文展望了微服務在2018年可能的5個發(fā)展趨勢，并對各個趨勢進行了詳細的介紹。

對于DevOps來說，2017年是重要的一年，不僅生態(tài)系統(tǒng)玩家的數(shù)量大幅增加，而且CNCF項目增加了兩倍。展望未來一年，我們期待創(chuàng)新和市場變化進一步加速。以下是我們對2018年微服務趨勢的看法:服務網(wǎng)格、事件驅(qū)動架構、容器本地安全、GraphQL和混沌工程。

我們將關注這些趨勢，以及未來一年將圍繞它們建立業(yè)務的公司。你看到了什么趨勢?在下面留言讓我們知道哪些被遺漏了，或者如果你同意/不同意我們概述的內(nèi)容。

1. 服務網(wǎng)格非常熱門

服務網(wǎng)格是一個用于改進服務與服務之間的通信的基礎架構層，也是目前最流行的原生云類別。隨著容器變得越來越普遍，服務拓撲變得越來越動態(tài)，需要更先進的網(wǎng)絡功能。服務網(wǎng)格可以通過服務發(fā)現(xiàn)、路由、負載均衡、健康檢查和可觀察性來幫助管理流量。服務網(wǎng)格試圖馴服難以控制的容器復雜性。

隨著像HAProxy、traefik和NGINX這樣的負載均衡器開始重新定位為數(shù)據(jù)平面，它的服務網(wǎng)格變得越來越受歡迎。我們還沒有看到廣泛的部署，但確實知道在生產(chǎn)環(huán)境中運行服務網(wǎng)格的業(yè)務。此外，服務網(wǎng)格并不僅限于微服務或Kubernetes環(huán)境，還可以應用于VM和serverless環(huán)境。例如，國家生物技術信息中心不是運行容器，而是使用Linkerd。

服務網(wǎng)格也可用于混沌工程，“在分布式系統(tǒng)上進行實驗的規(guī)程，以建立對系統(tǒng)抵御混亂狀況能力的信心�！狈�務網(wǎng)格不需要在每個主機上安裝一個守護進程，而是將延遲和失敗注入到環(huán)境中。

Istio和Buoyant Linkerd是該領域最引人注目的產(chǎn)品。請注意，Buoyant在去年12月為Kubernetes提供的一個開源服務網(wǎng)格 Conduit v0.1。

2. 事件驅(qū)動架構的崛起

隨著業(yè)務敏捷性需求的增加，我們開始看到一個向“推送”架構或者基于事件體系結構的發(fā)展趨勢，即：一個服務發(fā)送一個事件，一個或多個觀察者容器異步地運行邏輯來響應該事件，而不需要通知事件生產(chǎn)者。與請求-響應架構不同，在事件驅(qū)動的系統(tǒng)中，啟動容器中的功能流程和事務負載并不依賴于下游容器中遠程進程的可用性和完成情況。另一個好處是，在設計各自的服務時，開發(fā)人員可以更加獨立。

雖然開發(fā)人員可以將容器環(huán)境構建為事件驅(qū)動架構，但功能即服務(FaaS)本身就體現(xiàn)了這種能力。在FaaS架構中，函數(shù)作為文本存儲在數(shù)據(jù)庫中，并通過事件觸發(fā)。一旦調(diào)用了該函數(shù)，API控制器就會接收消息并通過負載均衡器將其發(fā)送到消息總線，消息總線將其排入計劃并提供給一個調(diào)用容器。執(zhí)行完后，結果存儲在數(shù)據(jù)庫中，并發(fā)送給用戶，然后函數(shù)被分解，直到再次觸發(fā)。

FaaS的好處包括: 1）從編寫代碼到運行服務的時間縮短了，因為創(chuàng)建或push源碼之后不需要做額外操作。2）當函數(shù)由FaaS平臺(如AWS)管理和縮放時，開銷會減少。然而，F(xiàn)aaS并非沒有自身的挑戰(zhàn)。由于FaaS要求將服務的每個部分解耦，因此可能會出現(xiàn)難以發(fā)現(xiàn)、管理、編排和監(jiān)視的函數(shù)的擴散。最后，如果沒有依賴項的全面可視化工作，就很難調(diào)試FaaS系統(tǒng)，可能會出現(xiàn)無限循環(huán)。

目前，F(xiàn)aaS不適合需要長調(diào)用、加載大量數(shù)據(jù)到內(nèi)存和強一致性能要求的進程。雖然開發(fā)人員使用FaaS進行后臺工作和臨時事件，但我們認為隨著存儲層加速和平臺性能的提高，用例將隨著時間的推移而擴展。

在2017年秋季，云計算基金會(CNCF)對550人進行了調(diào)查，其中31%使用serverless技術，28%計劃在未來18個月內(nèi)使用serverless。接下來的調(diào)查是詢問哪個特定的服務器平臺正在被使用。在使用serverless技術的169項中，有77%表示他們使用了AWS。雖然Lambda可能是領先的serverless平臺，但我們相信在邊緣需求中可能會有其他的機會。邊緣計算對于物聯(lián)網(wǎng)和AR/VR用例尤其有效。

3. 安全需要改變

由于內(nèi)核訪問控制，打包在容器中的應用程序從根本上更安全。在VM環(huán)境中，唯一可見的點是虛擬設備驅(qū)動程序�，F(xiàn)在應用程序移動到容器環(huán)境，操作系統(tǒng)具有syscalls和semantic含義。這是一個更加豐富的信號。以前的操作符通過將代理放入VM來實現(xiàn)某些信號，但它比較復雜并且需要很多管理工作。容器環(huán)境下要提供清晰的可視化和集成功能，而這些工作量與VM環(huán)境工作量相比是微不足道的。

考慮到這一點，在451研究調(diào)查報告說，安全是容器應用的最大障礙——挑戰(zhàn)依然存在！ 最初，漏洞是容器環(huán)境中的主要安全問題。隨著公共注冊中心中隨時可用的容器映像的數(shù)量成倍增加，確保它們沒有漏洞變得非常重要。人工處理、鏡像掃描和授權認證已經(jīng)成為一種常態(tài)處理方式。

與虛擬機管理程序作為訪問和控制點的虛擬化環(huán)境不同，任何具有訪問內(nèi)核根的容器最終都可以訪問內(nèi)核上的所有容器。反過來，組織必須確保容器如何與宿主機交互，哪些容器可以執(zhí)行某些操作或系統(tǒng)命令。增強主機控制以確保正確配置cgroups和namespace對于維護安全性也很重要。

最后，傳統(tǒng)防火墻依靠IP地址規(guī)則來把關網(wǎng)絡流。這種技術無法擴展到容器環(huán)境，因為動態(tài)編排器會復用IP地址。

運行時威脅檢測和響應對生產(chǎn)環(huán)境至關重要，通過對容器環(huán)境進行指紋識別，并構建詳細的行為基線圖像，可以容易地檢測到異常行為和攻擊者的沙箱。一份451的研究報告指出，52%的被調(diào)查公司在生產(chǎn)環(huán)境中運行容器，這表明容器的運行時威脅檢測解決方案正在加速發(fā)展。

4. 從REST轉(zhuǎn)變到GraphQL

GraphQL是一種API規(guī)范，它是一種查詢語言和一個運行時的查詢執(zhí)行操作。它由Facebook在2012年創(chuàng)建，并于2015年開源。GraphQL類型系統(tǒng)允許開發(fā)人員自定義數(shù)據(jù)模式�？梢噪S時添加新的字段，并可以在不影響現(xiàn)有查詢或重構客戶端應用程序的情況下對字段進行更新。GraphQL是功能強大的，因為它沒有綁定到特定的數(shù)據(jù)庫或存儲引擎。

GraphQL服務器作為一個單獨的HTTP端點運行，它表示服務的全部功能。通過在類型和字段之間定義資源之間的關系(而不是像REST一樣的端點)，GraphQL可以遵循屬性之間的引用，因此服務可以使用單個查詢從多個資源中接收數(shù)據(jù)。此外，REST api需要為單個請求加載多個url，這導致網(wǎng)絡跳數(shù)增多，降低了查詢速度。通過較少的通信次數(shù)，GraphQL減少了每個數(shù)據(jù)請求所需的資源數(shù)量，并且返回的數(shù)據(jù)通常格式化為JSON。

使用GraphQL可以獲得比REST額外的好處。首先，客戶端和服務器是解耦的，于是可以單獨維護它們。與REST不同，GraphQL在客戶機和服務器之間使用的語言非常類似，使得調(diào)試更容易。查詢語句的數(shù)據(jù)形狀與從服務器獲取的數(shù)據(jù)的形狀完全匹配，使得GraphQL比SQL或Gremlin等其他語言更加高效和有效。查詢語句反映了它們的響應的形狀，因此可以檢測到偏差，并且不能正確解析的字段可以被識別。由于查詢更簡單，使得整個過程的穩(wěn)定性更強。該規(guī)范最廣為人知的是支持外部api，而我們發(fā)現(xiàn)它也被用于內(nèi)部api。

GraphQL的用戶包括 Amplitude, Credit Karma, KLM, NY Times, Twitch, Yelp等。在11月，Amazon通過推出AWS AppSync(包括GraphQL支持)證明了GraphQL的流行程度。觀察GraphQL將如何在gRPC和諸如Twitch的Twirp RPC框架這樣的替代環(huán)境中發(fā)展，將會非常有趣。

5. 混沌工程變得更加廣為人知

最初由Netflix推廣，后來被亞馬遜(Amazon)、谷歌、微軟(Microsoft)和Facebook應用，在系統(tǒng)上進行混沌工程實驗，以提高其在生產(chǎn)問題上的確定性�；煦绻こ淘谶^去的十年里不斷發(fā)展。它從Chaos Monkeys開始，它們在生產(chǎn)環(huán)境中關閉了服務，并且擴展到更大的環(huán)境中使用失敗注入測試(FIT)和Chaos Kong。

表面上看來，混亂工程僅僅是為了注入混亂。雖然破壞系統(tǒng)可能很有趣，但它并不總是有效或提供有用的信息�；煦绻こ贪�含了更廣泛的范圍，不僅僅是注入故障，還包括其他場景，如流量峰值、異常請求組合等，以發(fā)現(xiàn)現(xiàn)存的問題。除了驗證假設之外，它還應該顯示系統(tǒng)的新屬性。通過發(fā)掘系統(tǒng)的弱點，團隊可以幫助提高彈性，預防糟糕的客戶體驗。

像神經(jīng)網(wǎng)絡和深度學習這樣的復雜的新技術，相比證明它們的有效性，理清它們的工作原理可能會變得不那么重要�；煦绻こ掏ㄟ^對系統(tǒng)進行整體測試來識別不穩(wěn)定性，從而幫助應對這一挑戰(zhàn)。隨著工程師們努力使他們?nèi)找鎻碗s的系統(tǒng)變得更加健壯，這可能會成為一種更為普遍的做法。

隨著混沌工程變得越來越主流，它可以采用現(xiàn)有的開源項目、商業(yè)產(chǎn)品的形式，或者用上文提到的服務網(wǎng)格形式實現(xiàn)。

原文鏈接： 5 Microservices Trends to Watch in 2018

===========

譯者介紹

陳杰，阿里巴巴數(shù)據(jù)庫團隊算法專家，工作重心為利用深度學習技術優(yōu)化數(shù)據(jù)庫場景中的性能問題，平時也樂于去實現(xiàn)一些突發(fā)的想法。在疲于配置系統(tǒng)環(huán)境時發(fā)現(xiàn)了Docker，跟大家一起學習、使用和研究Docker。

 

來自：http://dockone.io/article/3070

 

標簽： 安全 代碼 防火墻 服務器 谷歌 漏洞 數(shù)據(jù)庫 通信 推廣 網(wǎng)絡 云計算

版權申明：本站文章部分自網(wǎng)絡，如有侵權，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯(lián)系。