正文

微服務(wù)和soa（微服務(wù)和soa架構(gòu)的區(qū)別）

發(fā)布時(shí)間：2023-04-13 22:08:00 稿源：創(chuàng)意嶺閱讀： 53

大家好！今天讓創(chuàng)意嶺的小編來大家介紹下關(guān)于微服務(wù)和soa的問題，以下是小編對此問題的歸納整理，讓我們一起來看看吧。

開始之前先推薦一個(gè)非常厲害的Ai人工智能工具，一鍵生成原創(chuàng)文章、方案、文案、工作計(jì)劃、工作報(bào)告、論文、代碼、作文、做題和對話答疑等等

只需要輸入關(guān)鍵詞，就能返回你想要的內(nèi)容，越精準(zhǔn)，寫出的就越詳細(xì)，有微信小程序端、在線網(wǎng)頁版、PC客戶端

官網(wǎng)：https://ai.de1919.com。

創(chuàng)意嶺作為行業(yè)內(nèi)優(yōu)秀的企業(yè)，服務(wù)客戶遍布全球各地，如需了解SEO相關(guān)業(yè)務(wù)請撥打電話175-8598-2043，或添加微信：1454722008

本文目錄:

1、soa架構(gòu)的優(yōu)點(diǎn)有哪些？
2、SOA和WebService
3、軟件架構(gòu)入門-分層架構(gòu)、事件驅(qū)動(dòng)、微服務(wù)架構(gòu)和云原生架構(gòu)
4、如何快速搭建一個(gè)微服務(wù)架構(gòu)

微服務(wù)和soa（微服務(wù)和soa架構(gòu)的區(qū)別）

一、soa架構(gòu)的優(yōu)點(diǎn)有哪些？

利用SOA架構(gòu)開發(fā)的優(yōu)點(diǎn)：

第一、更易維護(hù)

業(yè)務(wù)服務(wù)提供者和業(yè)務(wù)服務(wù)使用者的松散耦合關(guān)系及對開放標(biāo)準(zhǔn)的采用確保了該特性的實(shí)現(xiàn)。建立在以 SOA基礎(chǔ)上的信息系統(tǒng)，當(dāng)需求發(fā)生變化的時(shí)候，不需要修改提供業(yè)務(wù)服務(wù)的接口，只需要調(diào)整業(yè)務(wù)服務(wù)流程或者修改操作即可，整個(gè)應(yīng)用系統(tǒng)也更容易被維護(hù)。

第二、更高的可用性

該特點(diǎn)是在于服務(wù)提供者和服務(wù)使用者的松散耦合關(guān)系上得以發(fā)揮與體現(xiàn)。使用者無須了解提供者的具休實(shí)現(xiàn)細(xì)節(jié)。

第三、更好的伸縮性

依靠業(yè)務(wù)服務(wù)設(shè)計(jì)、開發(fā)和部署等所采用的架構(gòu)模型實(shí)現(xiàn)伸縮性。使得服務(wù)提供者可以互相彼此獨(dú)立地進(jìn)行調(diào)整，以滿足新的服務(wù)需求。

二、SOA和WebService

傳統(tǒng)服務(wù)架構(gòu)模型中，服務(wù)請求者和服務(wù)調(diào)用者之間是緊密耦合的關(guān)系。

SOA 模型最大程度解耦合服務(wù)請求者和服務(wù)提供者。

SOA 是概念層級(jí)的架構(gòu)模型，需要使用其他技術(shù)來具體實(shí)現(xiàn) SOA 模型，比如 Web Service（主流方式）、組件服務(wù)、REST 服務(wù)等。

Web Service 不是一個(gè)協(xié)議標(biāo)準(zhǔn)，它是一系列協(xié)議標(biāo)準(zhǔn)的集合。它主要包括：XML、XML Schema、NameSpace、SOAP、WDSL、WS-BPEL/WS-CDLUDDI、WSIL、WS-*

Web Service 協(xié)議與具體的平臺(tái)、語言、技術(shù)無關(guān)，在各開發(fā)平臺(tái)、語言、環(huán)境中均有相關(guān)支撐。

三、軟件架構(gòu)入門-分層架構(gòu)、事件驅(qū)動(dòng)、微服務(wù)架構(gòu)和云原生架構(gòu)

軟件架構(gòu)（software architecture）就是軟件的基本結(jié)構(gòu)。

合適的架構(gòu)是軟件成功的最重要因素之一。大型軟件公司通常有專門的架構(gòu)師職位（architect），只有資深程序員才可以擔(dān)任。

O'Reilly 出版過一本免費(fèi)的小冊子《Software Architecture Patterns》（PDF），介紹了五種最常見的軟件架構(gòu)，是非常好的入門讀物。

軟件架構(gòu)就是軟件的基本結(jié)構(gòu)。架構(gòu)的本質(zhì)是管理復(fù)雜性。 如果你覺得架構(gòu)不重要，可能是你做的事情不夠復(fù)雜，或者是你沒有管理好復(fù)雜性。架構(gòu)模式雖多，經(jīng)過抽象沉淀之后，也就那么幾種：

1. 分層架構(gòu)（比較傳統(tǒng)的單體架構(gòu)）

2. 事件驅(qū)動(dòng)架構(gòu) （一般適用于應(yīng)用局部場景，用來實(shí)現(xiàn)異步解耦）

3. 微核架構(gòu)（又稱插件架構(gòu)，開發(fā)難度較高，一般用來做工具軟件開發(fā)，如Eclipse，不太適合分布式業(yè)務(wù)場景）

4. 微服務(wù)架構(gòu)（當(dāng)前比較流行的服務(wù)化架構(gòu)，解決單體架構(gòu)面臨的問題，適合敏捷開發(fā)，快速迭代）

5. 云架構(gòu)（現(xiàn)在的說法是云原生架構(gòu)-Cloud Native，基于Docker、Kubernetes、Service Mesh 云原生架構(gòu)）

在原文的基礎(chǔ)上，我按照自己的想法，進(jìn)行了小幅調(diào)整。

分層架構(gòu)（ layered architecture ）是最常見的軟件架構(gòu)，也是事實(shí)上的標(biāo)準(zhǔn)架構(gòu)。如果你不知道要用什么架構(gòu)，那就用它。

這種架構(gòu)將軟件分成若干個(gè)水平層，每一層都有清晰的角色和分工，不需要知道其他層的細(xì)節(jié)。層與層之間通過接口通信。

雖然沒有明確約定，軟件一定要分成多少層，但是四層的結(jié)構(gòu)最常見。

有的軟件在邏輯層（business）和持久層（persistence）之間，加了一個(gè)服務(wù)層（service），提供不同業(yè)務(wù)邏輯需要的一些通用接口。

用戶的請求將依次通過這四層的處理，不能跳過其中任何一層。

優(yōu)點(diǎn)

缺點(diǎn)

事件（event）是狀態(tài)發(fā)生變化時(shí)，軟件發(fā)出的通知。

事件驅(qū)動(dòng)架構(gòu)（event-driven architecture）就是通過事件進(jìn)行通信的軟件架構(gòu)。它分成四個(gè)部分。

事件驅(qū)動(dòng)架構(gòu)（event-driven architecture）核心組件：

對于簡單的項(xiàng)目，事件隊(duì)列、分發(fā)器和事件通道，可以合為一體，整個(gè)軟件就分成事件代理和事件處理器兩部分。

優(yōu)點(diǎn)

缺點(diǎn)

事件驅(qū)動(dòng)架構(gòu)在通信產(chǎn)品中應(yīng)用得也非常廣泛，典型的如狀態(tài)機(jī)處理。 事件驅(qū)動(dòng)架構(gòu)不適于做頂層架構(gòu)，但適合做局部實(shí)現(xiàn)，幾乎遍布在通信軟件的各個(gè)角落。

微核架構(gòu)（microkernel architecture）又稱為"插件架構(gòu)"（plug-in architecture），指的是軟件的內(nèi)核相對較小，主要功能和業(yè)務(wù)邏輯都通過插件實(shí)現(xiàn)。

內(nèi)核（core）通常只包含系統(tǒng)運(yùn)行的最小功能。插件則是互相獨(dú)立的，插件之間的通信，應(yīng)該減少到最低，避免出現(xiàn)互相依賴的問題。

優(yōu)點(diǎn)

缺點(diǎn)

微核架構(gòu)的設(shè)計(jì)和開發(fā)難度較高，這就注定它在企業(yè)產(chǎn)品中用得不多，雖然它的優(yōu)點(diǎn)還不少。

微服務(wù)架構(gòu)（microservices architecture）是服務(wù)導(dǎo)向架構(gòu)（service-oriented architecture，縮寫 SOA）的升級(jí)。

每一個(gè)服務(wù)就是一個(gè)獨(dú)立的部署單元（separately deployed unit）。這些單元都是分布式的，互相解耦，通過遠(yuǎn)程通信協(xié)議（比如REST、SOAP）聯(lián)系。

微服務(wù)架構(gòu)分成三種實(shí)現(xiàn)模式。

現(xiàn)在開源的微服務(wù)框架比較多，如常用的有Spring Cloud、Dubbo、ServiceComb等等。

優(yōu)點(diǎn)

缺點(diǎn)

云架構(gòu)（cloud architecture，現(xiàn)在的說法是云原生-Cloud Native）主要解決擴(kuò)展性和并發(fā)的問題，是最容易擴(kuò)展的架構(gòu)。

它的高擴(kuò)展性，主要原因是可以基于云上計(jì)算資源彈性伸縮。然后，業(yè)務(wù)處理能力封裝成一個(gè)個(gè)處理單元（prcessing unit）。訪問量增加，就新建處理單元（Docker容器）；訪問量減少，就關(guān)閉處理單元（Docker容器）。由于沒有中央數(shù)據(jù)庫，所以擴(kuò)展性的最大瓶頸消失了。由于每個(gè)處理單元的數(shù)據(jù)都獨(dú)立分庫。

這個(gè)模式主要分成兩部分：處理單元（processing unit）和虛擬中間件（virtualized middleware）。

虛擬中間件又包含四個(gè)組件：

隨著Docker、Kubernetes等容器化技術(shù)的快速發(fā)展，上述關(guān)于云架構(gòu)描述有點(diǎn)陳舊了。當(dāng)前最新的云原生架構(gòu)，以Docker+Kubernetes為核心，尤其是容器編排Kubernetes 已經(jīng)成為事實(shí)上的行業(yè)標(biāo)準(zhǔn)。

云原生架構(gòu)圖的主要特征：

主要目標(biāo)：

1. 讓開發(fā)人員聚焦業(yè)務(wù)邏輯的實(shí)現(xiàn)，其他交給容器云平臺(tái)來完成；

2. 支持業(yè)務(wù)系統(tǒng)的快速迭代，支撐業(yè)務(wù)的快速變化和發(fā)展；

3. 構(gòu)建以共享服務(wù)體系為核心的業(yè)務(wù)中臺(tái)；

下面是我針對某新零售企業(yè)設(shè)計(jì)的云原生架構(gòu)圖，以云和微服務(wù)架構(gòu)為基礎(chǔ)構(gòu)建云原生應(yīng)用，這里云可以是公有云、私有云、混合云等等。

以上是從不同的視角，對架構(gòu)進(jìn)行了分類。實(shí)際應(yīng)用中，各種架構(gòu)并不是孤立的，可以根據(jù)業(yè)務(wù)環(huán)境和業(yè)務(wù)訴求，對各種架構(gòu)進(jìn)行綜合和嫁接。每種架構(gòu)都有其優(yōu)點(diǎn)和缺點(diǎn)。優(yōu)點(diǎn)不必多說，缺點(diǎn)則幾乎都是通過工具工程（比如自動(dòng)化發(fā)布工具、自動(dòng)化測試等等）能力的方法來規(guī)避，工具工程對軟件架構(gòu)非常重要。

四、如何快速搭建一個(gè)微服務(wù)架構(gòu)

什么是微服務(wù)？

微服務(wù)(Microservices Architecture)是一種架構(gòu)風(fēng)格，一個(gè)大型復(fù)雜軟件應(yīng)用由一個(gè)或多個(gè)微服務(wù)組成。系統(tǒng)中的各個(gè)微服務(wù)可被獨(dú)立部署，各個(gè)微服務(wù)之間是松耦合的。每個(gè)微服務(wù)僅關(guān)注于完成一件任務(wù)并很好地完成該任務(wù)。在所有情況下，每個(gè)任務(wù)代表著一個(gè)小的業(yè)務(wù)能力。

微服務(wù)的概念源于2014年3月Martin Fowler所寫的文章“Microservices” martinfowler.com/articles/mi…

單體架構(gòu)(Monolithic Architecture )

企業(yè)級(jí)的應(yīng)用一般都會(huì)面臨各種各樣的業(yè)務(wù)需求，而常見的方式是把大量功能堆積到同一個(gè)單體架構(gòu)中去。比如：常見的ERP、CRM等系統(tǒng)都以單體架構(gòu)的方式運(yùn)行，同時(shí)由于提供了大量的業(yè)務(wù)功能，隨著功能的升級(jí)，整個(gè)研發(fā)、發(fā)布、定位問題，擴(kuò)展，升級(jí)這樣一個(gè)“怪物”系統(tǒng)會(huì)變得越來越困難。

這種架構(gòu)模式就是把應(yīng)用整體打包部署，具體的樣式依賴本身應(yīng)用采用的語言，如果采用java語言，自然你會(huì)打包成war包，部署在Tomcat或者Jetty這樣的應(yīng)用服務(wù)器上，如果你使用spring boot還可以打包成jar包部署。其他還有Rails和Node.js應(yīng)用以目錄層次的形式打包

上圖：單體架構(gòu)

大部分企業(yè)通過SOA來解決上述問題，SOA的思路是把應(yīng)用中相近的功能聚合到一起，以服務(wù)的形式提供出去。因此基于SOA架構(gòu)的應(yīng)用可以理解為一批服務(wù)的組合。SOA帶來的問題是，引入了大量的服務(wù)、消息格式定義和規(guī)范。

多數(shù)情況下，SOA的服務(wù)直接相互獨(dú)立，但是部署在同一個(gè)運(yùn)行環(huán)境中（類似于一個(gè)Tomcat實(shí)例下，運(yùn)行了很多web應(yīng)用）。和單體架構(gòu)類似，隨著業(yè)務(wù)功能的增多SOA的服務(wù)會(huì)變得越來越復(fù)雜，本質(zhì)上看沒有因?yàn)槭褂肧OA而變的更好。圖1，是一個(gè)包含多種服務(wù)的在線零售網(wǎng)站，所有的服務(wù)部署在一個(gè)運(yùn)行環(huán)境中，是一個(gè)典型的單體架構(gòu)。

單體架構(gòu)的應(yīng)用一般有以下特點(diǎn)：

微服務(wù)架構(gòu)（Microservices Architecture）

微服務(wù)架構(gòu)的核心思想是，一個(gè)應(yīng)用是由多個(gè)小的、相互獨(dú)立的、微服務(wù)組成，這些服務(wù)運(yùn)行在自己的進(jìn)程中，開發(fā)和發(fā)布都沒有依賴。不同服務(wù)通過一些輕量級(jí)交互機(jī)制來通信，例如 RPC、HTTP 等，服務(wù)可獨(dú)立擴(kuò)展伸縮，每個(gè)服務(wù)定義了明確的邊界，不同的服務(wù)甚至可以采用不同的編程語言來實(shí)現(xiàn)，由獨(dú)立的團(tuán)隊(duì)來維護(hù)。簡單的來說，一個(gè)系統(tǒng)的不同模塊轉(zhuǎn)變成不同的服務(wù)！而且服務(wù)可以使用不同的技術(shù)加以實(shí)現(xiàn)！

上圖：微服務(wù)架構(gòu)

微服務(wù)設(shè)計(jì)

那我們在微服務(wù)中應(yīng)該怎樣設(shè)計(jì)呢。以下是微服務(wù)的設(shè)計(jì)指南：

微服務(wù)消息

在單體架構(gòu)中，不同功能之間通信通過方法調(diào)用，或者跨語言通信。SOA降低了這種語言直接的耦合度，采用基于SOAP協(xié)議的web服務(wù)。這種web服務(wù)的功能和消息體定義都十分復(fù)雜，微服務(wù)需要更輕量的機(jī)制。

同步消息 REST

同步消息就是客戶端需要保持等待，直到服務(wù)器返回應(yīng)答。REST是微服務(wù)中默認(rèn)的同步消息方式，它提供了基于HTTP協(xié)議和資源API風(fēng)格的簡單消息格式，多數(shù)微服務(wù)都采用這種方式（每個(gè)功能代表了一個(gè)資源和對應(yīng)的操作）

異步消息 – AMQP, STOMP, MQTT

異步消息就是客戶端不需要一直等待服務(wù)應(yīng)答，有應(yīng)到后會(huì)得到通知。某些微服務(wù)需要用到異步消息，一般采用AMQP, STOMP, MQTT 這三種通訊協(xié)議

消息格式 – JSON, XML, Thrift, ProtoBuf, Avro

消息格式是微服務(wù)中另外一個(gè)很重要的因素。SOA的web服務(wù)一般采用文本消息，基于復(fù)雜的消息格式（SOAP）和消息定義（xsd）。微服務(wù)采用簡單的文本協(xié)議JSON和XML，基于HTTP的資源API風(fēng)格。如果需要二進(jìn)制，通過用到Thrift, ProtoBuf, Avro。

服務(wù)約定 – 定義接口 – Swagger, RAML, Thrift IDL

如果把功能實(shí)現(xiàn)為服務(wù)，并發(fā)布，需要定義一套約定。單體架構(gòu)中，SOA采用WSDL，WSDL過于復(fù)雜并且和SOAP緊耦合，不適合微服務(wù)。

REST設(shè)計(jì)的微服務(wù)，通常采用Swagger和RAML定義約定。

對于不是基于REST設(shè)計(jì)的微服務(wù)，比如Thrift，通常采用IDL（Interface Definition Languages），比如Thrift IDL。

微服務(wù)集成 (服務(wù)間通信)

大部分微服務(wù)基于RPC、HTTP、JSON這樣的標(biāo)準(zhǔn)協(xié)議，集成不同標(biāo)準(zhǔn)和格式變的不再重要。另外一個(gè)選擇是采用輕量級(jí)的消息總線或者網(wǎng)關(guān)，有路由功能，沒有復(fù)雜的業(yè)務(wù)邏輯。下面就介紹幾種常見的架構(gòu)方式。

點(diǎn)對點(diǎn)方式

點(diǎn)對點(diǎn)方式中，服務(wù)之間直接用。每個(gè)微服務(wù)都開放REST API，并且調(diào)用其它微服務(wù)的接口。

上圖：通過點(diǎn)對點(diǎn)方式通信

很明顯，在比較簡單的微服務(wù)應(yīng)用場景下，這種方式還可行，隨著應(yīng)用復(fù)雜度的提升，會(huì)變得越來越不可維護(hù)。這點(diǎn)有些類似SOA的ESB，盡量不采用點(diǎn)對點(diǎn)的集成方式。

API-網(wǎng)關(guān)方式

API網(wǎng)關(guān)方式的核心要點(diǎn)是，所有的客戶端和消費(fèi)端都通過統(tǒng)一的網(wǎng)關(guān)接入微服務(wù)，在網(wǎng)關(guān)層處理所有的非業(yè)務(wù)功能個(gè)。通常，網(wǎng)關(guān)也是提供REST/HTTP的訪問API。服務(wù)端通過API-GW注冊和管理服務(wù)。

上圖：通過API-網(wǎng)關(guān)暴露微服務(wù)

所有的業(yè)務(wù)接口通過API網(wǎng)關(guān)暴露，是所有客戶端接口的唯一入口。微服務(wù)之間的通信也通過API網(wǎng)關(guān)。

采用網(wǎng)關(guān)方式有如下優(yōu)勢：

目前，API網(wǎng)關(guān)方式應(yīng)該是微服務(wù)架構(gòu)中應(yīng)用最廣泛的設(shè)計(jì)模式。

消息代理方式

微服務(wù)也可以集成在異步的場景下，通過隊(duì)列和訂閱主題，實(shí)現(xiàn)消息的發(fā)布和訂閱。一個(gè)微服務(wù)可以是消息的發(fā)布者，把消息通過異步的方式發(fā)送到隊(duì)列或者訂閱主題下。作為消費(fèi)者的微服務(wù)可以從隊(duì)列或者主題共獲取消息。通過消息中間件把服務(wù)之間的直接調(diào)用解耦。

上圖：異步通信方式

通常異步的生產(chǎn)者/消費(fèi)者模式，通過AMQP, STOMP, MQTT 等異步消息通訊協(xié)議規(guī)范。

數(shù)據(jù)的去中心化

單體架構(gòu)中，不同功能的服務(wù)模塊都把數(shù)據(jù)存儲(chǔ)在某個(gè)中心數(shù)據(jù)庫中。

每個(gè)微服務(wù)有自己私有的數(shù)據(jù)庫，其它微服務(wù)不能直接訪問。單體架構(gòu)，用一個(gè)數(shù)據(jù)庫存儲(chǔ)所有數(shù)據(jù)

微服務(wù)方式，多個(gè)服務(wù)之間的設(shè)計(jì)相互獨(dú)立，數(shù)據(jù)也應(yīng)該相互獨(dú)立（比如，某個(gè)微服務(wù)的數(shù)據(jù)庫結(jié)構(gòu)定義方式改變，可能會(huì)中斷其它服務(wù)）。因此，每個(gè)微服務(wù)都應(yīng)該有自己的數(shù)據(jù)庫。

每個(gè)微服務(wù)有自己私有的數(shù)據(jù)庫，其它微服務(wù)不能直接訪問。每個(gè)微服務(wù)有自己私有的數(shù)據(jù)庫，其它微服務(wù)不能直接訪問。

數(shù)據(jù)去中心話的核心要點(diǎn)：

數(shù)據(jù)的去中心化，進(jìn)一步降低了微服務(wù)之間的耦合度，不同服務(wù)可以采用不同的數(shù)據(jù)庫技術(shù)（SQL、NoSQL等）。在復(fù)雜的業(yè)務(wù)場景下，如果包含多個(gè)微服務(wù)，通常在客戶端或者中間層（網(wǎng)關(guān)）處理。

微服務(wù)架構(gòu)的優(yōu)點(diǎn)：

微服務(wù)架構(gòu)的缺點(diǎn)：

微服務(wù)的一些想法在實(shí)踐上是好的，但當(dāng)整體實(shí)現(xiàn)時(shí)也會(huì)呈現(xiàn)出其復(fù)雜性。

關(guān)于微服務(wù)架構(gòu)的取舍

以上就是關(guān)于微服務(wù)和soa相關(guān)問題的回答。希望能幫到你，如有更多相關(guān)問題，您也可以聯(lián)系我們的客服進(jìn)行咨詢，客服也會(huì)為您講解更多精彩的知識(shí)和內(nèi)容。