前言

大家好，這里是浩道linux，主要給大家分享linux、python、網(wǎng)絡(luò)通信相關(guān)的IT知識(shí)平臺(tái)。

今天浩道跟大家分享一篇硬核干貨，關(guān)于微服務(wù)、容器、K8S之間的關(guān)系！

什么是微服務(wù)？

什么是微服務(wù)？你應(yīng)該使用微服務(wù)嗎？

從根本上講，微服務(wù)只是一個(gè)運(yùn)行在服務(wù)器或虛擬計(jì)算實(shí)例上并響應(yīng)網(wǎng)絡(luò)請(qǐng)求的計(jì)算機(jī)程序。

這與典型的 Rails/Django/Node.js 應(yīng)用程序有何不同？它根本上沒(méi)有什么不同。事實(shí)上，您可能會(huì)發(fā)現(xiàn)您的組織中已經(jīng)部署了十幾個(gè)微服務(wù)。沒(méi)有任何新的神奇技術(shù)使您的應(yīng)用程序有資格稱(chēng)為微服務(wù)。微服務(wù)不是由它的構(gòu)建方式來(lái)定義的，而是由它如何變成更通用的系統(tǒng)或解決方案來(lái)定義的。

那么是如何使服務(wù)成為微服務(wù)呢？一般來(lái)說(shuō)，微服務(wù)的范圍更窄，專(zhuān)注于做好較小的任務(wù)。讓我們通過(guò)看一個(gè)例子來(lái)進(jìn)一步探索。

微服務(wù)示例：亞馬遜產(chǎn)品列表

讓我們檢查在 Amazon 上為您提供此產(chǎn)品頁(yè)面的系統(tǒng)。它包含幾個(gè)信息塊，可能是從不同的數(shù)據(jù)庫(kù)中檢索到的：

產(chǎn)品描述，包括價(jià)格、標(biāo)題、照片等。

推薦項(xiàng)目，即其他人購(gòu)買(mǎi)的類(lèi)似書(shū)籍。

與此項(xiàng)目相關(guān)的贊助商列表。

關(guān)于本書(shū)作者的信息。

顧客評(píng)論。

您自己在亞馬遜商店中瀏覽其他商品的歷史記錄。

如果您要快速編寫(xiě)用于此列表的代碼，那么簡(jiǎn)單的方法將如下所示：

當(dāng)用戶(hù)的請(qǐng)求來(lái)自瀏覽器時(shí)，它將由 Web 應(yīng)用程序（Linux 或 Windows 進(jìn)程）提供服務(wù)。通常，被調(diào)用的應(yīng)用程序代碼片段稱(chēng)為請(qǐng)求處理程序。處理程序內(nèi)部的邏輯將依次多次調(diào)用數(shù)據(jù)庫(kù)，獲取呈現(xiàn)頁(yè)面所需的信息并將其拼接在一起，然后呈現(xiàn)返回給用戶(hù)的網(wǎng)頁(yè)。很簡(jiǎn)單吧？事實(shí)上，許多 Ruby on Rails 書(shū)籍都有類(lèi)似這樣的教程和示例。那么，你可能會(huì)問(wèn)，為什么要把事情復(fù)雜化？

想象一下隨著應(yīng)用程序的增長(zhǎng)和越來(lái)越多的工程師參與其中會(huì)發(fā)生什么。上面例子中的推薦引擎是由一小群程序員和數(shù)據(jù)科學(xué)家維護(hù)的。有幾十個(gè)不同的團(tuán)隊(duì)負(fù)責(zé)渲染該頁(yè)面的某些組件。這些團(tuán)隊(duì)中的每一個(gè)通常都希望獲得以下自由：

更改他們的數(shù)據(jù)庫(kù)架構(gòu)。

快速且頻繁地將他們的代碼發(fā)布到生產(chǎn)環(huán)境中。

使用他們選擇的編程語(yǔ)言或數(shù)據(jù)存儲(chǔ)等開(kāi)發(fā)工具。

在計(jì)算資源和開(kāi)發(fā)人員生產(chǎn)力之間做出自己的權(quán)衡。

偏好維護(hù)/監(jiān)控其功能。

可以想象，隨著時(shí)間的推移，讓團(tuán)隊(duì)就發(fā)布 Web 商店應(yīng)用程序的新版本的所有內(nèi)容達(dá)成一致將變得更加困難。

解決方案是將組件拆分為更小的、獨(dú)立的服務(wù)（也就是微服務(wù)）。

升級(jí)流程變得更小、更笨。它基本上是一個(gè)代理，它簡(jiǎn)單地將傳入的頁(yè)面請(qǐng)求分解為幾個(gè)專(zhuān)門(mén)的請(qǐng)求，并將它們轉(zhuǎn)發(fā)給相應(yīng)的微服務(wù)，這些微服務(wù)現(xiàn)在是他們自己的進(jìn)程并在其他地方運(yùn)行?！皯?yīng)用微服務(wù)”基本上是專(zhuān)門(mén)服務(wù)返回的數(shù)據(jù)的聚合器。您甚至可以完全擺脫它并將該工作卸載到用戶(hù)的設(shè)備上，讓此代碼在瀏覽器中作為單頁(yè) JavaScript 應(yīng)用程序運(yùn)行。

其他微服務(wù)現(xiàn)在被分離出來(lái)，每個(gè)開(kāi)發(fā)微服務(wù)的開(kāi)發(fā)團(tuán)隊(duì)都可以：

隨心所欲地部署他們的服務(wù)，而不會(huì)干擾其他團(tuán)隊(duì)。

以他們認(rèn)為合適的方式擴(kuò)展他們的服務(wù)。例如，使用他們選擇的 AWS 實(shí)例類(lèi)型，或者可能在專(zhuān)用硬件上運(yùn)行。

擁有自己特定于其服務(wù)的監(jiān)控、備份和災(zāi)難恢復(fù)。

什么是容器？

從技術(shù)上講，容器只是一個(gè)從可執(zhí)行文件產(chǎn)生的進(jìn)程，運(yùn)行在 Linux 機(jī)器上，它有一些限制，例如：

容器不允許“看到”所有文件系統(tǒng)，它只能訪問(wèn)其中的指定部分。

一個(gè)容器不允許使用所有的 CPU 或 RAM。

容器在如何使用網(wǎng)絡(luò)方面受到限制。

從歷史上看，現(xiàn)代操作系統(tǒng)總是對(duì)進(jìn)程施加限制，例如每個(gè) Linux 進(jìn)程都以系統(tǒng)用戶(hù)的權(quán)限運(yùn)行，但是容器化技術(shù)引入了更多可能的限制并使其更加靈活。

基本上，任何 Linux 可執(zhí)行文件都可以受到限制，即可以“容器化”。

大多數(shù)情況下，當(dāng)人們說(shuō)“容器”時(shí)，他們不僅僅指的是 Linux 進(jìn)程，還指的是可執(zhí)行文件的打包和存儲(chǔ)方式。

類(lèi)似的工具Docker允許開(kāi)發(fā)人員獲取他們的可執(zhí)行文件及其依賴(lài)項(xiàng)，以及他們想要的任何其他文件，并將它們?nèi)看虬梢粋€(gè)文件。這項(xiàng)技術(shù)與 tarball 之類(lèi)的存檔沒(méi)有太大區(qū)別。Docker 還允許包含一些額外的指令和配置來(lái)運(yùn)行這個(gè)打包的可執(zhí)行文件。通常這些文件，通常稱(chēng)為“容器鏡像”，也稱(chēng)為容器。

但為了簡(jiǎn)單起見(jiàn)，請(qǐng)記?。?/p>

一個(gè)容器就是一個(gè)運(yùn)行受限制的linux進(jìn)程

容器鏡像是可執(zhí)行進(jìn)程的依賴(lài)和配置打包

容器鏡像是自給自足的。它們將在任何 Linux 機(jī)器上運(yùn)行，因此容器化使得將代碼從開(kāi)發(fā)人員的機(jī)器復(fù)制（部署）到任何環(huán)境變得更加容易。

微服務(wù)和容器有什么區(qū)別？

我們剛剛了解到，容器只是一種打包、部署和運(yùn)行 Linux 程序/進(jìn)程的方法。您可以將一個(gè)巨大的單體應(yīng)用程序作為容器，也可以擁有一群完全不使用容器的微服務(wù)。

容器是一種有用的資源分配和共享技術(shù)。這是 DevOps 人們感到興奮的事情。微服務(wù)是一種軟件設(shè)計(jì)架構(gòu)。這是開(kāi)發(fā)人員感到興奮的事情。

它們是相關(guān)的，但不需要彼此。您可以將單體應(yīng)用部署為容器，也可以擁有不受限制的、非容器化的微服務(wù)。

什么時(shí)候使用微服務(wù)？

微服務(wù)背后的想法并不新鮮。幾十年來(lái)，軟件架構(gòu)師一直致力于將單體應(yīng)用程序分解為可重用的組件。

微服務(wù)的好處

微服務(wù)的好處很多，包括：

更簡(jiǎn)單的自動(dòng)化測(cè)試；

快速靈活的部署模式；

更強(qiáng)彈性擴(kuò)縮容。

采用微服務(wù)的另一個(gè)好處是能夠?yàn)楣ぷ鬟x擇最佳工具。應(yīng)用程序的某些部分可以從 C++ 的速度中受益，而其他部分可以從更高級(jí)別語(yǔ)言（例如 Python 或 JavaScript）的生產(chǎn)力提高中受益。

微服務(wù)的缺點(diǎn)

微服務(wù)的缺點(diǎn)包括：

需要更仔細(xì)的規(guī)劃；

更高的研發(fā)投入；

過(guò)度設(shè)計(jì)的誘惑。

如果應(yīng)用程序和開(kāi)發(fā)團(tuán)隊(duì)足夠小并且工作量不具有挑戰(zhàn)性，則通常無(wú)需投入額外的工程資源來(lái)解決您尚未解決的問(wèn)題并使用微服務(wù)。但是，如果您開(kāi)始看到微服務(wù)的利大于弊，這里有一些具體的設(shè)計(jì)注意事項(xiàng)：

計(jì)算和存儲(chǔ)分離。隨著您對(duì) CPU 能力和存儲(chǔ)需求的增長(zhǎng)，這些資源具有非常不同的擴(kuò)展成本和特性。從一開(kāi)始就不必依賴(lài)本地存儲(chǔ)，這將使您能夠相對(duì)輕松地適應(yīng)未來(lái)的工作負(fù)載。這既適用于文件系統(tǒng)等簡(jiǎn)單的存儲(chǔ)形式，也適用于數(shù)據(jù)庫(kù)等更復(fù)雜的解決方案。

異步處理。通過(guò)添加越來(lái)越多的相互調(diào)用的子進(jìn)程或?qū)ο髞?lái)逐步構(gòu)建應(yīng)用程序的傳統(tǒng)方法隨著工作負(fù)載的增長(zhǎng)而停止工作，并且應(yīng)用程序本身必須跨多臺(tái)機(jī)器甚至數(shù)據(jù)中心擴(kuò)展。將需要圍繞事件驅(qū)動(dòng)模型重新構(gòu)建應(yīng)用程序。這意味著發(fā)送事件（而不是等待結(jié)果）而不是調(diào)用函數(shù)并同步等待結(jié)果。

擁抱消息總線。這是必須實(shí)現(xiàn)異步處理模型的直接后果。隨著您的單體應(yīng)用程序被分解為事件處理程序和事件發(fā)射器，就需要一個(gè)健壯、高性能和靈活的消息總線。有多種選擇，選擇取決于應(yīng)用程序規(guī)模和復(fù)雜性。對(duì)于一個(gè)簡(jiǎn)單的用例，像 Redis 這樣的東西就可以做到。如果您需要您的應(yīng)用程序真正是云原生的并自行擴(kuò)展和縮減，您可能需要能夠處理來(lái)自多個(gè)事件源的事件：從 Kafka 等流管道到基礎(chǔ)設(shè)施，甚至監(jiān)控事件。

API 版本控制。由于您的微服務(wù)將使用彼此的 API 通過(guò)總線相互通信，因此設(shè)計(jì)用于保持向后兼容性的架構(gòu)將是至關(guān)重要的。只需部署一個(gè)微服務(wù)的最新版本，開(kāi)發(fā)人員就不應(yīng)該要求其他人升級(jí)他們的代碼。這將是向整體方法向后兼容的一步，開(kāi)發(fā)團(tuán)隊(duì)必須在永遠(yuǎn)支持舊 API 和保持更高的開(kāi)發(fā)速度之間達(dá)成合理的妥協(xié)。這也意味著 API 設(shè)計(jì)成為一項(xiàng)重要的技能。頻繁的破壞性 API 更改是團(tuán)隊(duì)無(wú)法高效開(kāi)發(fā)復(fù)雜微服務(wù)的原因之一。

重新考慮您的安全性。許多開(kāi)發(fā)人員沒(méi)有意識(shí)到這一點(diǎn)，但遷移到微服務(wù)為更好的安全模型創(chuàng)造了機(jī)會(huì)。由于每個(gè)微服務(wù)都是一個(gè)專(zhuān)門(mén)的進(jìn)程，因此最好只允許它訪問(wèn)所需的資源。這樣，僅一個(gè)微服務(wù)中的漏洞就不會(huì)將系統(tǒng)的其余部分暴露給攻擊者。這與大型單體形成對(duì)比，后者傾向于以更高的特權(quán)（每個(gè)人都需要的超集）運(yùn)行，并且可能導(dǎo)致更多的違規(guī)行為。

Kubernetes 與微服務(wù)有什么關(guān)系？

Kubernetes太復(fù)雜了，無(wú)法在此詳細(xì)描述，但值得對(duì)其進(jìn)行概述，因?yàn)楹芏嗳嗽谟嘘P(guān)微服務(wù)的對(duì)話中都會(huì)提到它。

嚴(yán)格來(lái)說(shuō)，Kubernetes（又名 K8s）的主要好處是通過(guò)跨多個(gè)進(jìn)程高效共享計(jì)算資源來(lái)提高基礎(chǔ)設(shè)施利用率。Kubernetes 是動(dòng)態(tài)分配計(jì)算資源以滿(mǎn)足需求的大師。這允許組織避免為他們不使用的計(jì)算資源付費(fèi)。但是，K8s 的一些附帶好處使向微服務(wù)的過(guò)渡變得更加容易。

當(dāng)您將單體應(yīng)用程序分解為單獨(dú)的、松散耦合的微服務(wù)時(shí)，您的團(tuán)隊(duì)將獲得更多的自主權(quán)和自由度。但是，在與微服務(wù)必須運(yùn)行的基礎(chǔ)設(shè)施進(jìn)行交互時(shí)，它們?nèi)匀槐仨毭芮泻献鳌?/p>

您必須解決以下問(wèn)題：

預(yù)測(cè)每個(gè)服務(wù)需要多少計(jì)算資源；

這些要求在負(fù)載下如何變化；

如何劃分基礎(chǔ)設(shè)施分區(qū)并將它們劃分到微服務(wù)之間；

實(shí)施資源限制。

Kubernetes 非常優(yōu)雅地解決了這些問(wèn)題，并提供了一個(gè)通用框架來(lái)描述、檢查和推理基礎(chǔ)設(shè)施資源的共享和利用。這就是為什么采用 Kubernetes 作為微服務(wù)重新架構(gòu)的一部分是一個(gè)好主意。

然而，Kubernetes 是一項(xiàng)需要學(xué)習(xí)的復(fù)雜技術(shù)，而且更難管理。如果可以，您應(yīng)該利用云提供商提供的托管 Kubernetes 服務(wù)。但是，對(duì)于需要跨多個(gè)云提供商和企業(yè)數(shù)據(jù)中心運(yùn)行自己的 Kubernetes 集群的公司來(lái)說(shuō)，這并不總是可行的。

結(jié)論

容器只是具有應(yīng)用受限制的 Linux 進(jìn)程。限制的示例包括允許進(jìn)程使用多少 CPU 或內(nèi)存。Docker 之類(lèi)的工具允許開(kāi)發(fā)人員將他們的可執(zhí)行文件與依賴(lài)項(xiàng)和附加配置打包在一起。這些包被稱(chēng)為 鏡像，并且經(jīng)常且容易混淆地也被稱(chēng)為容器。

微服務(wù)并不新鮮。這是一種舊的軟件設(shè)計(jì)模式，由于互聯(lián)網(wǎng)公司的規(guī)模不斷擴(kuò)大，它越來(lái)越受歡迎。微服務(wù)不一定要容器化。同樣，單體應(yīng)用程序可以是微服務(wù)。

小項(xiàng)目不應(yīng)該回避整體設(shè)計(jì)。它為較小的團(tuán)隊(duì)提供更高的生產(chǎn)力。

Kubernetes 是由多個(gè)微服務(wù)組成的復(fù)雜應(yīng)用程序的絕佳平臺(tái)。

Kubernetes 也是一個(gè)復(fù)雜的系統(tǒng)，學(xué)習(xí)曲線陡峭，管理成本非常高。