[[412146]]

什么是微服務(wù)?

微服務(wù)背后的中心思想是，當(dāng)某些類型的應(yīng)用程序被分解成更小的、可組合的部分并協(xié)同工作時(shí)，它們會(huì)變得更容易構(gòu)建和維護(hù)。

每個(gè)組件都是不斷開(kāi)發(fā)和單獨(dú)維護(hù)的，應(yīng)用程序只是其組成組件的總和。這與傳統(tǒng)的“整體式”應(yīng)用程序形成對(duì)比，后者全部是一體式開(kāi)發(fā)的。

作為一組模塊化組件構(gòu)建的應(yīng)用程序更易于理解、更易于測(cè)試，最重要的是，在應(yīng)用程序的整個(gè)生命周期內(nèi)更易于維護(hù)。它使組織能夠?qū)崿F(xiàn)更高的敏捷性，并能夠大大縮短將研發(fā)部署到生產(chǎn)所需的時(shí)間。這種方法已被證明是優(yōu)越的，特別是對(duì)于由不同地域和文化的開(kāi)發(fā)人員團(tuán)隊(duì)開(kāi)發(fā)的大型企業(yè)應(yīng)用程序。

還有其他好處：

• 開(kāi)發(fā)人員獨(dú)立性：

小團(tuán)隊(duì)并行工作，迭代速度比大團(tuán)隊(duì)快。

• 隔離和彈性：

如果一個(gè)組件死了，你在啟動(dòng)的一段時(shí)間里，應(yīng)用程序的其余部分繼續(xù)運(yùn)行。

• 可擴(kuò)展性：

較小的組件占用較少的資源，并且可以擴(kuò)展以滿足該組件不斷增長(zhǎng)的需求。

• 生命周期自動(dòng)化：

單個(gè)組件更容易適應(yīng)持續(xù)交付管道和單體應(yīng)用無(wú)法實(shí)現(xiàn)的復(fù)雜部署場(chǎng)景。

• 與業(yè)務(wù)的關(guān)系：

微服務(wù)架構(gòu)沿業(yè)務(wù)領(lǐng)域邊界劃分，增加了整個(gè)組織的獨(dú)立性和對(duì)業(yè)務(wù)的理解。

微服務(wù)的通用定義通常依賴于每個(gè)微服務(wù)提供一個(gè) API 接口，通常但不總是一個(gè)無(wú)狀態(tài)的 REST API，可以像標(biāo)準(zhǔn)網(wǎng)頁(yè)一樣通過(guò) HTTP(S) 訪問(wèn)。這種訪問(wèn)微服務(wù)的方法使開(kāi)發(fā)人員可以輕松使用它們，因?yàn)樗鼈冎恍枰_(kāi)發(fā)人員使用已經(jīng)熟悉的工具和方法。

這是一個(gè)新概念嗎?

不是什么新鮮事。還有其他編程范式可以解決這個(gè)相同的概念，例如面向服務(wù)的體系結(jié)構(gòu) (SOA)。然而，最近的技術(shù)進(jìn)步加上對(duì)集成“數(shù)字體驗(yàn)”的期望越來(lái)越高，催生了用于滿足現(xiàn)代業(yè)務(wù)應(yīng)用程序需求的新型開(kāi)發(fā)工具和技術(shù)。

微服務(wù)不僅依賴于為支持這一概念而建立的技術(shù)，還依賴于一個(gè)擁有文化、知識(shí)和結(jié)構(gòu)的組織，以便開(kāi)發(fā)團(tuán)隊(duì)能夠采用這種模型。微服務(wù)是 IT 部門向 DevOps 文化轉(zhuǎn)變的一部分，在這種文化中，開(kāi)發(fā)和運(yùn)營(yíng)團(tuán)隊(duì)密切合作以支持應(yīng)用程序的整個(gè)生命周期，并經(jīng)歷快速甚至持續(xù)的發(fā)布周期，而不是更傳統(tǒng)的長(zhǎng)周期.

為什么開(kāi)源對(duì)微服務(wù)很重要?

當(dāng)您從頭開(kāi)始將應(yīng)用程序設(shè)計(jì)為模塊化和可組合的時(shí)候，它允許您在許多地方使用插入式組件，而過(guò)去您可能需要特定的解決方案，因?yàn)榻M件的許可或特殊要求，但是現(xiàn)在，許多應(yīng)用程序組件可以是現(xiàn)成的開(kāi)源工具，并且有無(wú)數(shù)的開(kāi)源項(xiàng)目實(shí)現(xiàn)了微服務(wù)架構(gòu)的跨領(lǐng)域需求，例如身份驗(yàn)證、服務(wù)發(fā)現(xiàn)、日志記錄和監(jiān)控、負(fù)載平衡、擴(kuò)展等等。

關(guān)注微服務(wù)還可能使應(yīng)用程序開(kāi)發(fā)人員更容易為應(yīng)用程序提供可選接口。當(dāng)一切都是API時(shí)，應(yīng)用程序組件之間的通信就標(biāo)準(zhǔn)化了。組件要使用您的應(yīng)用程序和數(shù)據(jù)，所要做的就是能夠通過(guò)這些標(biāo)準(zhǔn)api進(jìn)行身份驗(yàn)證和通信。這允許組織內(nèi)部和組織外部的人員(在適當(dāng)?shù)臅r(shí)候)輕松地開(kāi)發(fā)利用應(yīng)用程序數(shù)據(jù)和服務(wù)的新方法。

容器技術(shù)從何而來(lái)?

輕量級(jí)操作系統(tǒng)容器的現(xiàn)代概念是在21世紀(jì)初作為FreeBSD項(xiàng)目的一部分引入的。Docker為創(chuàng)建和共享容器映像提供了更好的用戶體驗(yàn)，因此從2013年開(kāi)始就得到了廣泛采用。

容器非常適合微服務(wù)，滿足了輕量且靈活的組件的需求，這些組件可以輕松地管理和動(dòng)態(tài)替換。與虛擬機(jī)不同的是，容器被設(shè)計(jì)成能夠運(yùn)行容器設(shè)計(jì)要做的任何事情的最小可行部分，而不是將多個(gè)功能打包到同一個(gè)虛擬機(jī)或物理機(jī)中。Docker和類似工具提供的開(kāi)發(fā)便捷性有助于快速開(kāi)發(fā)和測(cè)試服務(wù)。

當(dāng)然，容器只是一個(gè)工具，微服務(wù)體系結(jié)構(gòu)只是一個(gè)概念。完全有可能在不使用容器的情況下按照微服務(wù)方法構(gòu)建一個(gè)應(yīng)用程序，就像在容器中構(gòu)建一個(gè)更傳統(tǒng)的應(yīng)用程序一樣，當(dāng)您想要利用容器編排功能而不需要重寫大型、整體的應(yīng)用程序時(shí)，這可能是有意義的。

你如何編排微服務(wù)?

為了實(shí)際運(yùn)行基于微服務(wù)的應(yīng)用程序，您需要能夠監(jiān)視、管理和擴(kuò)展不同的組成部分。有許多不同的工具可以幫助您完成這一任務(wù)。對(duì)于容器，像Kubernetes這樣的開(kāi)源工具可能是解決方案的一部分?；蛘?，對(duì)于應(yīng)用程序的非容器組件，可以使用其他工具來(lái)編排組件:例如，在OpenStack云中，您可以使用Heat來(lái)管理應(yīng)用程序組件。

另一個(gè)選擇是使用一個(gè)平臺(tái)即服務(wù)(PaaS)工具,它可以讓開(kāi)發(fā)者專注于編寫代碼通過(guò)抽象一些潛在的編排技術(shù)和允許他們?nèi)菀走x擇現(xiàn)成的開(kāi)源組件應(yīng)用程序的某些部分,就像一個(gè)數(shù)據(jù)庫(kù)存儲(chǔ)引擎,日志服務(wù),持續(xù)集成服務(wù)器、web服務(wù)器或其他部分。一些PaaS系統(tǒng)，如OpenShift，直接使用Docker和Kubernetes等上游項(xiàng)目來(lái)管理應(yīng)用程序組件，而另一些系統(tǒng)則試圖自己重新實(shí)現(xiàn)管理工具。

現(xiàn)有的應(yīng)用程序呢?

雖然利用微服務(wù)可能是一個(gè)組織未來(lái)IT戰(zhàn)略的重要組成部分，但肯定有許多應(yīng)用程序不滿足此模型，也不太可能在一夜之間對(duì)這些應(yīng)用程序進(jìn)行重新架構(gòu)以滿足此新范式。遷移到微服務(wù)體系結(jié)構(gòu)有文化和技術(shù)成本，但幸運(yùn)的是，如果組織具有可靠的雙模式IT戰(zhàn)略，微服務(wù)和傳統(tǒng)應(yīng)用程序可以在相同的環(huán)境中一起工作。

根據(jù)Gartner的說(shuō)法，雙模式IT是一種能力，既可以交付注重穩(wěn)定性和正常運(yùn)行時(shí)間的傳統(tǒng)IT應(yīng)用程序，也可以通過(guò)更新的方法交付更新的、更敏捷的、但可能較少測(cè)試的應(yīng)用程序，這些方法包括開(kāi)發(fā)人員自我供應(yīng)機(jī)器的能力和較短的開(kāi)發(fā)周期。

許多(如果不是大多數(shù))組織將需要適應(yīng)在未來(lái)許多年使用這兩種方法。 

原文：https://opensource.com/resources/what-are-microservices