一、前言
我們在學習和討論微服務架構時經常會提及這樣一個架構:SOA(service-oriented architecture)架構。不少人包括閒宇在內在初次接觸SOA架構時經常會混淆SOA架構和微服務架構。究其原因,微服務架構是從SOA架構中演變過來的。甚至早先wiki對微服務進行定義的時候都是將其定義為SOA架構的一種變體。
Microservices is a software development technique — a variant of the service-oriented architecture (SOA) structural style.
當然,站在今天來看這樣一個定義顯然是非常不合適的。爲了更好地區分微服務架構和SOA架構,讓我們透過研究微服務架構取代SOA架構的原因來去釐清兩者的區別。
二、微服務取代SOA架構的原因
下面我們從這樣幾個方面具體分析一下微服務取代SOA的原因:
1. 輕量化與技術簡化
SOA:SOA 強調透過企業服務匯流排(ESB)來連線和管理不同的服務。這導致了架構的重量級,因為 ESB 通常引入了額外的複雜性、較大的學習成本和更高的運維成本。SOA 還需要大量中介軟體,增加了系統的複雜度。
微服務:微服務架構避免了使用複雜的 ESB,通常透過更輕量的通訊方式(如 REST API、gRPC)來進行服務間互動,減少了複雜的中介軟體和通訊管理層,使架構更加輕量化。每個服務都是獨立的,可以自行決定如何通訊,而不是依賴於複雜的中間層系統。
2. 去中心化管理與治理
SOA:SOA 通常採用集中式治理,例如透過統一的企業服務匯流排來管理所有的服務。治理策略、資料模型、訊息協議等都需要在統一的系統中進行管理和控制。這種集中式的控制在跨團隊協作、擴充套件性和靈活性上存在侷限性。
微服務:微服務強調去中心化治理,允許各個服務獨立開發、獨立選擇技術棧和工具,給開發團隊更多自由度。每個團隊可以根據其需求自由選擇開發語言、資料庫或其他技術,實現高效的團隊協作和獨立部署。這種靈活的管理方式使微服務架構在大規模分散式系統中的應用更具優勢。
3. 更強的獨立性與靈活性
SOA:在 SOA 架構中,服務可能共享底層的資料庫或資源,使得某個服務的變更可能影響到其他服務,甚至需要重新部署整個系統。此外,服務的升級或擴充套件通常受到中心化控制系統的約束,靈活性不足。
微服務:微服務架構中,每個服務是完全獨立的實體,擁有自己的資料庫、業務邏輯和生命週期。這種獨立性使得服務之間的耦合度大大降低,服務可以獨立開發、獨立部署和獨立擴充套件,極大提高了靈活性。一個服務的升級不會影響其他服務,且服務可以根據實際需求水平擴充套件。
4. 更好的擴充套件性
SOA:SOA 的擴充套件性在一定程度上受制於企業服務匯流排和中心化的管理系統。如果某個服務需要擴充套件,可能要考慮到整個系統的架構設計,擴充套件不夠靈活。此外,SOA 的擴充套件能力受限於傳統架構和硬體資源的限制,難以與現代雲原生架構無縫對接。
微服務:微服務天然適應水平擴充套件,可以根據業務需求對特定服務進行按需擴充套件,且通常基於容器化(如 Docker)和容器編排工具(如 Kubernetes)來實現彈性擴充套件,具有極高的擴充套件性。此外,微服務可以靈活遷移到雲端,實現雲原生的自動化部署、負載均衡和彈性擴充套件。
5. 與雲原生、DevOps 的契合
SOA:SOA 是爲了解決大型企業系統整合問題而設計的,它更適合傳統的資料中心和企業內部網路,難以與現代雲原生架構、持續整合(CI)和持續交付(CD)模型很好地結合。SOA 中的服務可能會因為使用不同的中介軟體和整合工具而導致部署和運維的複雜度增加,難以實現 DevOps 的自動化運維流程。
微服務:微服務架構與雲原生(cloud-native)理念高度契合,特別適合基於雲的應用。微服務可以透過容器(如 Docker)進行部署,透過 Kubernetes 實現自動化編排和管理。這與 DevOps 理念中的自動化運維、快速迭代、持續交付密切相關,使得微服務架構能夠快速響應市場需求,實現敏捷開發。
6. 部署靈活性
SOA:在 SOA 中,服務通常依賴於 ESB 這樣的中心化元件,這使得服務的部署變得複雜,更新或變更某個服務時可能會影響到其他服務,甚至整個系統。ESB 的存在使得部分服務的獨立部署變得困難。
微服務:微服務的獨立部署特性是其核心優勢。每個微服務可以根據自身的生命週期進行獨立部署,避免了傳統單體應用或 SOA 中部署時的相互影響。服務的升級、修復、擴充套件都可以獨立進行,不需要對整個系統進行停機或大規模變動。
7. 資料管理的靈活性
SOA:在 SOA 架構中,多個服務可能共享同一個資料庫或者資料儲存,這會帶來效能瓶頸和資料一致性問題,且難以根據各個服務的不同需求來調整資料庫。
微服務:微服務允許每個服務擁有獨立的資料庫或儲存,形成資料庫自治。這種設計使得每個微服務可以根據自身業務需求來選擇最適合的資料庫型別(如關係型資料庫、NoSQL 資料庫等),並最佳化資料管理的效能和可擴充套件性。
三、總結
從上面的分析我們可以看出,微服務架構逐漸取代 SOA 的原因主要在於其更輕量、靈活、去中心化的設計,更適應現代企業級系統的需求。特別是在雲原生、DevOps、容器化等技術的推動下,微服務架構提供了更高的擴充套件性和靈活性,能夠更好地滿足複雜分散式系統和快速迭代的開發需求。
同時,與傳統 SOA 相比,微服務避免了複雜的中介軟體和中心化管理,降低了系統的耦合度和複雜度,使得開發、部署和運維都更加敏捷、高效。這使得微服務在現代軟件開發中成為主流架構。
簡而言之,時代選擇了微服務。