微服務(wù)的下一步，離不開服務(wù)網(wǎng)格

來源：http://www.360doc.com/content/20/0918/06/46368139_936322950.shtml

軟件行業(yè)走了很長一段路，在整個(gè)過程中，軟件體系結(jié)構(gòu)也已經(jīng)發(fā)展了很多。經(jīng)歷了1層（單節(jié)點(diǎn)），2層（客戶端/服務(wù)器），3層和分布式，我們?cè)诖诉^程中看到了一些不同的軟件架構(gòu)模式。

微服務(wù)面臨的挑戰(zhàn)

大多數(shù)軟件公司，正從單體架構(gòu)(Monolithic)過渡到微服務(wù)架構(gòu)(Microservices)，而微服務(wù)架構(gòu)(Microservices)也正在逐步接管軟件行業(yè)。單體架構(gòu)雖然有很多好處，但在滿足現(xiàn)代軟件開發(fā)需求時(shí)也有很多缺點(diǎn)。

微服務(wù)架構(gòu)使我們能夠更頻繁，更獨(dú)立地部署應(yīng)用程序，并可靠地滿足現(xiàn)代軟件應(yīng)用程序開發(fā)要求。

將單體應(yīng)用分解為微服務(wù)應(yīng)用

微服務(wù)架構(gòu)幾乎解決了單體架構(gòu)的所有缺點(diǎn)。微服務(wù)提供了故障隔離，滿足應(yīng)用更小，更快的部署，具備應(yīng)用的可伸縮性，使得不同服務(wù)可以采用不同的開發(fā)技術(shù)，提高了開發(fā)效率，滿足了以業(yè)務(wù)為中心的需求。

盡管微服務(wù)架構(gòu)相對(duì)于其他架構(gòu)具有許多優(yōu)勢，但它也面臨著一系列挑戰(zhàn)。在微服務(wù)體系結(jié)構(gòu)中，它必須處理與設(shè)計(jì)分布式系統(tǒng)時(shí)遇到的問題。

微服務(wù)架構(gòu)背后的思想是，我們將擁有多個(gè)獨(dú)立的較小服務(wù)集，每個(gè)服務(wù)提供單獨(dú)的業(yè)務(wù)功能，而不是擁有一個(gè)大型的單個(gè)代碼庫。通過這種方法，現(xiàn)代軟件應(yīng)用程序?qū)⑿枰獛资畟€(gè)、甚至數(shù)百個(gè)單獨(dú)服務(wù)的協(xié)同工作。

通過微服務(wù)架構(gòu)，引入了網(wǎng)絡(luò)依賴，并引發(fā)了可靠性問題。網(wǎng)絡(luò)可靠性，延遲，帶寬和網(wǎng)絡(luò)安全性，是我們必須處理的一些與網(wǎng)絡(luò)相關(guān)的挑戰(zhàn)。

在服務(wù)之間實(shí)現(xiàn)通信也將是一項(xiàng)艱巨的任務(wù)。隨著服務(wù)數(shù)量的增加，我們必須處理它們之間的交互。除了服務(wù)之間的通信外，我們還必須處理整個(gè)系統(tǒng)運(yùn)行狀況的監(jiān)視，容錯(cuò)，日志記錄和遙測功能，處理多點(diǎn)故障等等。使用微服務(wù)架構(gòu)，由于我們必須處理許多服務(wù)間通信和基礎(chǔ)網(wǎng)絡(luò)，因此調(diào)試問題可能會(huì)更加棘手。

隨著基于第三方類庫和組件的引入，克服了與微服務(wù)體系結(jié)構(gòu)有關(guān)的上述挑戰(zhàn)，每個(gè)服務(wù)也都具備了這些通用功能（監(jiān)視，運(yùn)行狀況檢查，日志記錄，遙測等），使得服務(wù)到服務(wù)的通信順暢且可靠。但是，將這些功能整合到每一項(xiàng)服務(wù)中，這在開發(fā)和維護(hù)上都需要付出很多努力。

開發(fā)人員使用第三方類庫和組件（例如Eureka，Ribbon，Hystrix）來提供這些通用功能，例如服務(wù)發(fā)現(xiàn)，負(fù)載均衡，斷路器，日志記錄和度量，遙測等。

結(jié)合了業(yè)務(wù)功能和網(wǎng)絡(luò)相關(guān)功能的微服務(wù)

但是，使用第三方庫和組件會(huì)帶來一系列不同的挑戰(zhàn)，例如：

• 緊密耦合-這些第三方庫/組件的編碼和配置與服務(wù)中的業(yè)務(wù)功能緊密相關(guān)?，F(xiàn)在，應(yīng)用程序代碼是業(yè)務(wù)功能和這些其他庫/組件配置的混合。

• 編碼/配置的復(fù)雜性增加-使用的第三方庫/組件，可能必須使用不同的編程和配置語言集

• 可維護(hù)性差—每當(dāng)這些外部庫/組件升級(jí)時(shí)，我們都必須更新應(yīng)用程序代碼，對(duì)其進(jìn)行驗(yàn)證并部署這些更改

• 調(diào)試/故障排除復(fù)雜度增加-現(xiàn)在服務(wù)是與第三方庫/組件的混合，如果出現(xiàn)應(yīng)用故障，開發(fā)人員必須花費(fèi)大量時(shí)間來了解代碼并排查問題

沒有服務(wù)網(wǎng)格體系結(jié)構(gòu)的微服務(wù)

盡管微服務(wù)架構(gòu)提供了很多好處，但是開發(fā)人員在面對(duì)上述挑戰(zhàn)時(shí)也面臨很多困難。這些挑戰(zhàn)促使開發(fā)人員找到了更好的替代方案–Service Mesh(服務(wù)網(wǎng)格)。

微服務(wù)的解決方案

服務(wù)網(wǎng)格可以定義為處理微服務(wù)架構(gòu)中服務(wù)間通信的專用基礎(chǔ)結(jié)構(gòu)層，從而降低了上述挑戰(zhàn)帶來的復(fù)雜性。Service Mesh使我們能夠成功，高效地運(yùn)行分布式微服務(wù)架構(gòu)，并提供保護(hù)，連接和監(jiān)視微服務(wù)的統(tǒng)一方法。

服務(wù)網(wǎng)格背后的想法非常簡單。不要在服務(wù)代碼中增加其他與基礎(chǔ)架構(gòu)/網(wǎng)絡(luò)相關(guān)的細(xì)節(jié)，而讓它僅關(guān)注其必須執(zhí)行的業(yè)務(wù)功能。

通常，Service Mesh提供以下功能：

• 負(fù)載均衡

• 服務(wù)發(fā)現(xiàn)

• 健康檢查

• 認(rèn)證方式

• 流量管理和路由

• 斷路器和故障轉(zhuǎn)移

• 安全管理

• 指標(biāo)收集和監(jiān)控

• 故障注入

有了Service Mesh，我們不必使用任何第三方庫/組件，就可以在每個(gè)微服務(wù)中提供與網(wǎng)絡(luò)相關(guān)的通用功能，例如配置，路由，遙測，記錄，斷路等。Service Mesh將把那些與網(wǎng)絡(luò)相關(guān)的通用功能抽象/外部化為一個(gè)單獨(dú)的組件/層，稱為“服務(wù)代理”。

服務(wù)網(wǎng)格將應(yīng)用程序中使用第三方庫/組件的復(fù)雜性解耦。

現(xiàn)在，開發(fā)人員可以根據(jù)與應(yīng)用程序或網(wǎng)絡(luò)相關(guān)的問題輕松排查任何問題的根本原因，從而使他們的生活變得異常便捷。借助Service Mesh架構(gòu)，業(yè)務(wù)功能和與網(wǎng)絡(luò)相關(guān)的功能之間的職責(zé)分工清晰。

具有服務(wù)代理(Sidecar)的微服務(wù)

通常，Sidecar模式用于實(shí)現(xiàn)服務(wù)網(wǎng)格體系結(jié)構(gòu)。在這種模式下，我們可以在服務(wù)旁邊部署服務(wù)網(wǎng)格代理。服務(wù)代理的Sidecar將復(fù)雜性從應(yīng)用程序中抽象出來，并處理服務(wù)發(fā)現(xiàn)，流量管理，負(fù)載均衡，斷路器等功能。

具有服務(wù)網(wǎng)格架構(gòu)的基于微服務(wù)的解決方案

總而言之，采用基于服務(wù)網(wǎng)格架構(gòu)的微服務(wù)，開發(fā)人員：

• 無需擔(dān)心使用任何第三方庫/組件來提供與網(wǎng)絡(luò)相關(guān)的功能

• 所有服務(wù)到服務(wù)的通信將通過稱為“服務(wù)代理”的組件/層，因此我們不必在每個(gè)服務(wù)中都實(shí)現(xiàn)它

• 將業(yè)務(wù)功能與與網(wǎng)絡(luò)相關(guān)的功能分離

• 僅關(guān)注業(yè)務(wù)功能，而無需擔(dān)心與網(wǎng)絡(luò)相關(guān)的基礎(chǔ)功能，讓服務(wù)網(wǎng)格為你處理

• 無需擔(dān)心服務(wù)網(wǎng)格的開發(fā)，因?yàn)榉?wù)網(wǎng)格基于開放標(biāo)準(zhǔn)，例如HTTP，TCP，RPC，gRPC等。

結(jié)論

微服務(wù)架構(gòu)由于其優(yōu)于其他架構(gòu)模式的優(yōu)勢，正在積極地控制軟件工程行業(yè)。隨著越來越多的組織從單體架構(gòu)過渡到微服務(wù)架構(gòu)，作為開發(fā)人員，我們需要了解微服務(wù)架構(gòu)中的挑戰(zhàn)并找到解決方法。Service Mesh架構(gòu)解決了微服務(wù)架構(gòu)引入遇到的一些挑戰(zhàn)。

現(xiàn)在我們知道了服務(wù)網(wǎng)格在微服務(wù)架構(gòu)中的作用和重要性，下面讓我們看一下可以在下一次開發(fā)活動(dòng)中使用的服務(wù)網(wǎng)格產(chǎn)品/平臺(tái)。Linkerd， Envoy Proxy， Istio， Consul， Kuma和 Open Service Mesh（OSM）是我們可以使用的一些領(lǐng)先的開源的Service Mesh平臺(tái)。它們中的大多數(shù)經(jīng)過了大量測試，可以投入生產(chǎn)使用。

- END -

?推薦閱讀?

Kubernetes生產(chǎn)環(huán)境最佳實(shí)踐
主流日志采集器，陰暗潮濕的地底世界
使用GitLab CI和Docker自動(dòng)部署SpringBoot應(yīng)用
記一次 Linux服務(wù)器被入侵后的排查思路
Nginx為什么快到根本停不下來？
用了3年Kubernetes，我們得到的5個(gè)教訓(xùn)
Linux 運(yùn)維必備的 40 個(gè)命令總結(jié)，收好了~



點(diǎn)亮，服務(wù)器三年不宕機(jī)