為什麼要使用微服務架構？

好雨雲幫發表於2018-09-03
微服務架構

微服務架構已經流行了很長時間，但是想要回答為什麼要使用微服務架構的問題，首先應該瞭解一體化架構。

什麼是一體化架構？

一體化架構顧名思義，將應用各層打成一個包來部署。為了讓程式碼正常工作，一體化應用的所有元件缺一不可。

以典型的3層傳統web應用為例，該應用由使用者介面、資料庫、伺服器端應用組成。這裡的伺服器端應用被稱為monolith（一體化），包含表現、業務層、資料層。所有程式碼都存在於同一個程式碼庫中。為了讓程式碼工作起來，它被部署成為一個單元。任何一個小的改動變化，都需要重新構建和部署整個應用。

為什麼要使用微服務架構？

什麼是微服務架構？

微服務架構是一種架構風格，整個應用被劃分並設計為以業務域為模型的鬆散耦合的獨立服務。微服務中的“微”非常具有欺騙性，事實上它沒有規定服務的規模有多小或多大。

這裡的重點是每個獨立服務都有一個業務邊界，可以獨立開發、測試、部署、監控和擴充套件，甚至可以用不同的程式語言開發它們。

為什麼要使用微服務架構？

在基於微服務的架構中，每個元件或服務都有自己的資料庫。沒有集中式資料庫，我們可以根據需要為每個單獨的微服務使用NoSQL、RDBMS或任何其他資料庫，這也是讓微服務真正獨立的原因之一。

一體化架構的問題

或者說是微服務架構所解決的問題。

難以擴充套件

一體化架構應用只能通過在負載均衡器後面放置整個應用程式的多個例項來進行水平擴充套件。如果應用中的特定服務需要擴充套件，則沒有簡單的選項。我們需要完整地擴充套件應用程式，這顯然會造成不必要的資源浪費。

相比之下，基於微服務的應用程式允許我們根據需要獨立擴充套件單個服務。在上圖中，如果需要縮放服務B，則可以有10個例項，同時保持其他例項，並可以根據需要隨時更改。

交付時間長

一體化架構在單個應用的任何部分/層中進行的任何更改都需要構建和部署整個應用程式。個人開發人員還需要下載整個應用程式程式碼來修復和測試，而不僅僅是受影響的模組，這就影響到了持續部署的效率。

而在微服務架構中，如果僅在一百個微服務中的一箇中需要改變，則僅構建和部署改變的微服務，沒有必要部署一切。我們甚至可以在短時間內多次部署。

應用複雜性

過去，隨著應用規模的增長（功能、功能等），團隊也會相應擴張，應用很快就就會變得複雜和交織在一起。隨著不同的團隊不斷修改程式碼，維護模組化結構慢慢變得越來越困難，並慢慢導致像義大利麵一樣交織的程式碼。這不僅會影響程式碼質量，還會影響整個組織。

在基於微服務的應用中，每個團隊都在單獨的微服務上工作，程式碼會有序很多。

沒有明確的所有權

在一體化應用中，看起來獨立的團隊實際上並不是獨立的。它們同時在相同的程式碼庫上工作，嚴重依賴於彼此。

在基於微服務的應用中，獨立團隊處理單獨的微服務。一個團隊將擁有一個完整的微服務。工作的明確所有權明確控制服務的一切，包括開發、部署和監控。

故障級聯

如果沒有正確設計，一體化交媾應用的一部分失敗可能會級聯並導致整個系統崩潰。

在基於微服務的架構的情況下，我們可以使用斷路器來避免這種故障。

Dev和Ops之間的牆

開發團隊通常會進行開發、測試，一旦部署，就會將維護和支援的所有權交給運維團隊，應用此時與開發團隊無關了，而運維團隊需要努力在生產環境中支援一體化架構應用。

在基於微服務的應用中，團隊的組織理解為“構建它、執行它”，開發團隊繼續在生產中擁有該應用。

陷入某種技術/語言

使用一體化架構，意味著被某種已實現的技術/語言鎖定。如果需要更改技術/語言，則必須重寫整個應用程式。

使用微服務，每個服務可以根據需求和業務以不同的技術或語言實現。任何改變服務技術/語言的決定都只需要重寫該特定服務，因為所有微服務都是相互獨立的。

支援微服務的正確工具/技術的可用性

幾年前，我們還沒有適當的工具和技術來支援微服務。但自從Docker容器和雲基礎設施（特別是PaaS）向大眾提供服務以來，微服務正在大規模採用，因為它們提供了我們所需的“自由”，而無需進行傳統的配置程式。

小結

簡單來說，使用微服務架構會獲得以下好處：

  • 獨立開發部署服務
  • 速度和敏捷性
  • 更高的程式碼質量
  • 獲得圍繞業務功能建立/組織的程式碼
  • 提高生產力
  • 更容易擴充套件
  • 自由（在某種程度上）選擇實施技術/語言

關於Rainbond

當下，已經有很大一部分公司完成了單體架構向微服務架構的遷移改造，並在疲於應對大量微服務間通訊問題時，開始考慮採用Service Mesh微服務架構作為服務與服務直接通訊的透明化管理框架，以外掛式的方式實現各種業務所需的高階管理功能。

而開源PaaS Rainbond提供了開箱即用的Service Mesh微服務架構，部署在Rainbond上的應用原生即是Service Mesh微服務架構應用。

相關文章