微服務在2018年帶來的驚喜和2019年預測

譯注：

本文整理了19家IT公司的22條觀點，覆蓋了2018-2019年度對微服務領域的一些關切，事實上，在普遍看好微服務的大背景下，仍舊有一些警醒的聲音指出了一些風險，因此對微服務的態(tài)度自然分成了不成比例的3派，占主流的看多派，有10票；而并未就此發(fā)表評論（主要重點在于對容器技術的關切）的，我們列為中性，有6票；看空的有3票半，Red Hat是堅定的看空派，認為在2019年將出現微服務失敗的鐵證，而O’Reilly在看好微服務的同時，也表示了對失敗案例的擔心，據此，我們做了一個圖表。

圍繞Envoy, LinkerD以及Istio的熱情比我預期的早了一兩年。使用Kubernetes的團隊真正感興趣的是如何更有效地管理微服務。

Kubernetes在微服務、容器化和云原生領域以驚人的速度站穩(wěn)了腳跟。前瞻的運營者正逐漸認識到基于Kubernetes的云原生環(huán)境所帶來的差異化和敏捷性。

目前還沒有明確的微服務市場領導者出現。提到API，人們會想到APIgee或者MuleSoft，但還沒有供應商可以與微服務形成這種強關聯(lián)。

在2019年，微服務體系結構將迎來演進中的最大挑戰(zhàn)：如何規(guī)模化的運行有狀態(tài)容器。目前大多數存儲解決方案只適用于虛擬化平臺（如VMware等）。但不太適合容器技術。在2019年需要解決的問題是，找到一個存儲解決方案來支持這些完全獨立的虛擬化機制，以便它們能夠高效、無縫地共存。

容器需要能夠訪問持久化存儲及其內部的數據。容器必須支持橫向擴展的存儲機制，以提供可操作性和輕量級分析的能力。

在2019年，微服務以及基于事件的體系結構將繼續(xù)演進。特定的服務將越來越需要與諸如MASA（Mesh App and Services Architectures ）這樣的單體應用相兼容，利用數據服務來偵聽事件并實時地作出反應。

我們相信，由于在速度和可伸縮性方面所具有的優(yōu)勢，微服務將在2019年繼續(xù)蓬勃發(fā)展。大型的關鍵任務代碼庫需要的是迭代而不是從頭來過，應用微服務方法可以降低這一過程中的風險，微服務允許對某個特定的關切保持關注，而不會對整個體系結構產生負面影響。服務網格（特別是Istio）作為管理微服務所帶來的部署復雜性的有效手段，將獲得極大的關注。Kubernetes將在企業(yè)里大行其道。支持微服務各個方面的工具生態(tài)系統(tǒng)將出現爆炸式增長。可觀察性仍然很重要，因為架構師們需要不斷適應對多個實體對象保持關注。最后，從技術的視角來看，很可能在采用微服務方面會出現一些顯著的失敗，這也是很自然的。面對潛在的失敗，微服務采用者要么保持堅定的態(tài)度，要么接受倒退到單體應用的現實。

微服務在2018年可以說“炙手可熱”，我認為其在2019年將繼續(xù)是一個備受討論和關注的話題。微服務促成了舊的互聯(lián)網領域的一次重大范式變革。

2019年，IT主管們將如夢初醒的意識到這樣一個事實：微服務體系結構已經不再是虛無飄渺的理念，而成為近在咫尺的現實。IDC預測，到2022年，90%的企業(yè)新建應用程序將以微服務為基礎，而在2019年，許多IT部門將絞盡腦汁地想辦法使他們的虛擬機基礎設施支持微服務架構。

管理容器化應用程序需要采用廣泛的工具集，我認為，在2019年將可能會看到一些新的開源項目旨在對這些工具集形成整合。

雖然看起來“馬上就實現”，但通過Kubeadm進行生產級安裝仍然任重道遠。如果供應商僅著眼于安裝K8s，而不提供進一步的價值，將有可能遭遇某些業(yè)務風險。

微服務走回頭路。許多已經嘗試過微服務的公司將向更傳統(tǒng)的中間件方法靠攏。我們將看到良好管理和治理的API平臺的復興，因為許多公司會發(fā)現，微服務所帶來的復雜性和開銷對于企業(yè)的許多用例來說都是不合理的，企業(yè)的組織架構也無法支撐。

2019年將有越來越多地將企業(yè)遺留的工作負載遷移到容器架構。其好處在于，容器在設計上與以前的遺留環(huán)境相匹配，極大地減少了技術挑戰(zhàn)，并盡可能避免了應用程序的重寫。許多人認為，2018年末IBM收購RedHat的交易是IBM搶占容器市場的重大戰(zhàn)略舉措的一部分。

隨著Kubernetes被越來越多的企業(yè)所采用，人們將開始意識到僅僅采用Kubernetes是不夠的，需要在企業(yè)的流程、工具和體系結構等方面發(fā)生改變。Kubernetes將有力的推動整個公司范圍內的深刻變革。2019年將被銘記為不安于現狀的一年。我們將開始邁向由Kubernetes所推動的一些原則（如微服務化、連續(xù)交付、不可變基礎設施、云原生等等)。

微服務架構已成為業(yè)界的普遍實踐。如果需要敏捷，快速、智能地交付，微服務就成為必由之路。然而，微服務所帶來的多服務環(huán)境需要服務間通信或API的支撐。而API所暴露的攻擊表面正被惡意行為者所乘，也帶來了更多對API漏洞的濫用，安全行業(yè)將致力于定義API所需的安全措施。

在2019年，一些決定因素將使人們開始急于采用微服務體系結構。而轉向微服務的危險之一是人們不完全理解服務的顆粒度究竟應該有多大。有一些團隊號稱創(chuàng)建了微服務架構，卻不過是用10個更小的單體應用替換了原來的1個單體應用。服務的顆粒太大，將無法解決單體應用的問題。而服務太小，則意味著所有復雜性都會從團隊層面上升到系統(tǒng)層面，這將使普通開發(fā)者束手無策。

微服務已經成為一個熱門話題，雖然在理念上為應用程序開發(fā)者提供了一些收益，但在實操層面，分布式系統(tǒng)所帶來的復雜性和潛在的性能問題卻不容忽視 。最令人驚訝的是，一方面，微服務已經開始被采納為一種廣泛應用的標準的體系結構風格；另一方面，集成應用程序（又稱單體應用，在技術語境下常帶有貶義）是如此之快的被棄如敝履。而業(yè)界本該對這一切保持謹慎。

由此產生的后果是，我們將看到更好的服務編排工具和越來越大的微服務顆粒度。

在2019年，我們將看到更多的康威定律的實踐，企業(yè)將對技術團隊的組織架構實現重構，以推進他們所追求的系統(tǒng)設計理念。此外，伴隨著企業(yè)從單體應用向微服務架構遷移的趨勢的持續(xù)，降低復雜性成本的需求將進一步增加，由此，我認為我們將看到圍繞微服務部署的工具鏈產生更多的玩家。

在2019年，我們將看到一種面向“聚焦DevOps”、云原生、網絡操作系統(tǒng)(NOS)的轉變，所有協(xié)議和管理功能都將被構建為基于不可變容器設施的微服務。從而，網絡運營商可以原生的利用持續(xù)集成和持續(xù)部署(CI/CD)的能力。使用由容器化的微服務構建的NOS，運營商可以僅部署他們所需的功能，降低復雜性和安全攻擊向量，在生產過程中升級組件，而不必擔心會破壞其他服務，并且可以使用Kubernetes等云原生工具來自然而然地管理這些網絡服務。此外，我們需要開始利用圍繞微服務的龐大的開源社區(qū)，來創(chuàng)建創(chuàng)新的網絡組件。

微服務正從趨勢走向最佳實踐。微服務與單體應用的共生戰(zhàn)略將變得更加重要和突出。

微型服務可能正進入幻滅期的低谷。我預計在明年，我們將開始看到在采用微服務時失敗的團隊和組織的鐵證。我們將認識到，雖然在某些特定情況下非常有用，但微服務并不是靈丹妙藥，也從來就沒有什么靈丹妙藥。期望業(yè)界可以對微服務的最佳實踐進行一些整合

關于EAWorld

微服務，DevOps，數據治理，移動架構原創(chuàng)技術分享