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

譯註：

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

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

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

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

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

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

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

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

微服務在2018年可以說“炙手可熱”，我認為其在2019年將繼續是一個備受討論和關注的話題。微服務促成了舊的網際網路領域的一次重大正規化變革。

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

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

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

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

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

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

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

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

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

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

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

在2019年，我們將看到一種面向“聚焦DevOps”、雲原生、網路作業系統(NOS)的轉變，所有協議和管理功能都將被構建為基於不可變容器設施的微服務。從而，網路運營商可以原生的利用持續整合和持續部署(CI/CD)的能力。使用由容器化的微服務構建的NOS，運營商可以僅部署他們所需的功能，降低複雜性和安全攻擊向量，在生產過程中升級元件，而不必擔心會破壞其他服務，並且可以使用Kubernetes等雲原生工具來自然而然地管理這些網路服務。此外，我們需要開始利用圍繞微服務的龐大的開源社群，來建立創新的網路元件。

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

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

關於EAWorld

微服務，DevOps，資料治理，移動架構原創技術分享