soa架構和微服務架構的區別與聯繫（SOA分布式架構面向服務）

2023-04-22 03:40:57 2

SOA（service-oriented architecture，也叫面向服務的體系結構或面向服務架構）是指為了解決在InterNET環境下業務集成的需要，通過連接能完成特定任務的獨立功能實體實現的一種軟體系統架構。SOA是一個組件模型，它將應用程式的不同功能單元（稱為服務）通過這些服務之間定義良好的接口和契約聯繫起來。接口是採用中立的方式進行定義的，它應該獨立於實現服務的硬體平臺、作業系統和程式語言。這使得構建在各種這樣的系統中的服務可以以一種統一和通用的方式進行交互。

傳統的Web（HTML/HTTP）技術有效的解決了人與信息系統的交互和溝通問題，極大地促進了B2C模式的發展。WEB服務(XML/SOAP/WSDL）技術則是要有效的解決信息系統之間的交互和溝通問題，促進B2B/EAI/CB2C的發展。SOA（面向服務的體系)則是採用面向服務的商業建模技術和WEB服務技術，實現系統之間的鬆耦合，實現系統之間的整合與協同。WEB服務和SOA的本質思路在於使得信息系統個體在能夠溝通的基礎上形成協同工作。

對於面向同步和異步應用的，基於請求/響應模式的分布式計算來說，SOA是一場革命。一個應用程式的業務邏輯（business logic）或某些單獨的功能被模塊化並作為服務呈現給消費者或客戶端。這些服務的關鍵是他們的鬆耦合特性。例如，服務的接口和實現相獨立。應用開發人員或者系統集成者可以通過組合一個或多個服務來構建應用，而無須理解服務的底層實現。舉例來說，一個服務可以用。NET或J2EE來實現，而使用該服務的應用程式可以在不同的平臺之上，使用的語言也可以不同。

SOA的實施具有幾個鮮明的基本特徵。實施SOA的關鍵目標是實現企業IT資產的最大化作用。要實現這一目標，就要在實施SOA的過程中牢記以下特徵：

　　不同種類的作業系統，應用軟體，系統軟體和應用基礎結構（application infrastructure）相互交織，這便是IT企業的現狀。一些現存的應用程式被用來處理當前的業務流程（business processes），因此從頭建立一個新的基礎環境是不可能的。企業應該能對業務的變化做出快速的反應，利用對現有的應用程式和應用基礎結構（application infrastructure）的投資來解決新的業務需求，為客戶，商業夥伴以及供應商提供新的互動渠道，並呈現一個可以支持有機業務（organic business）的構架。SOA憑藉其鬆耦合的特性，使得企業可以按照模塊化的方式來添加新服務或更新現有服務，以解決新的業務需要，提供選擇從而可以通過不同的渠道提供服務，並可以把企業現有的或已有的應用作為服務， 從而保護了現有的IT基礎建設投資。

　　關於SOA平臺服務的定義，目前來說一般有兩種形式，一種是定義標準接口的形式，一種是以標準的WebService的形式來下定義服務的實現。

在上圖中是以接口的形式來定義SOA平臺服務的，RDIFramework.NET的SOA實現也是採用這種方式。具體的實現是以.NET技術的WCF來實現的，服務可以以以下幾種方式寄存（發布）：Windows服務模式（常用）、WinForm界面模式、IIS服務模式等等。在後面的文章我們會分別介紹。

一、SOA要求一致性

有很多可用於創建、發布、發現和調用服務的候選技術。SOA 應提供一個參考體系結構，以指定服務提供者和使用者將使用的特定機制；我們應以在 SAO 所有參與者間實現一致性為目標。此類一致性可以減少開發、集成和維護工作。

如果需要使用參考體系結構之外的元素，我們推薦使用補充性方法。例如，假如我們為服務發布和發現選擇的機制是 UDDI，但某個特定的開發團隊已在使用一個基於其他存儲庫技術的開發流程，此時該如何處理呢？我們將選擇投入精力將該團隊的服務同時發布到兩個存儲庫。這樣，現有的服務使用者就可以使用其熟悉（但可能並不標準）的存儲庫了。而運行於公共 SOA 基礎結構上的使用者則可以為所有服務使用標準存儲庫——例如 UDDI。

二、SOA 簡化開發

我們希望任何企業級的 SOA 基礎結構都具有可伸縮性和彈性；還應包含行業級的企業服務總線（Enterprise Service Bus，ESB）和安全技術。或者，換種說法，以 SOA 為目標的服務和流程的開發人員可利用成熟的中間件，依賴 SOA 基礎結構提供問題的解決方案，如身份驗證、消息轉換和可靠消息交付。

這些中間件功能的提供應以一個重要的原則為基礎：服務和流程開發人員應遠離中間件實現的複雜細節。我們的理想目標是，在我們的 SOA 環境中工作的開發人員應只需要業務領域的相關知識和基本的編程技巧。

服務具有標準的、經過正式定義的可由計算機處理的接口

了解了工具和代碼生成在 SOA 實現中可扮演重要角色之後，我們現在要強調使用可由計算機處理的接口的重要性。當使用定義良好的可由計算機處理的語言描述了接口時，實際上就為各種工具支持功能提供了支持。我們希望改善分離狀況，因此我們強烈建議使用 WSDL 之類正式定義的開放標準語言，而不要使用專用格式。

可由計算機處理的方法的概念應該從服務接口描述（如 WSDL）擴展到所有其他形式的聲明信息或元數據。只有同時強調聲明技術和可由計算機處理的元數據，才能將其相關的複雜性從業務應用程式開發人員轉移到基於標準的中間件中。新興的 WS-Policy 之類的技術在支持此方法方面充當著重要的角色。

三、服務應設計為可重用

服務設計人員應該記住，他們所開發的任何服務都可能成為可重用資產。設計人員不應只關注服務的最初使用者的需求，而應該進行更為廣泛的業務分析，以確定更全面的需求。我們建議，設計人員應考慮服務可能的發展方向：

設計必須能適應不斷增加的吞吐量；如果服務在使用服務的數量增加的情況下仍可成功運行，那麼使用率也會成級數遞增。

如果使用服務的數量增加，則數據量和並發數據訪問模式可能會與最初投入使用時的情況大為不同。

我們必須對服務請求的未來增長進行預計；新使用者可能需要其他的功能，或者需要對現有功能進行更改

四、服務應具有精心選擇的粒度

在選擇服務粒度時，我們可能需要在多個因素間進行折衷，如可維護性、可操作性和易用性。任何給定的 SOA 都應向服務設計人員提供指南，以便確定此類折衷方案。

五、服務應是內聚而完整的

既然認識到了在確定服務粒度時需要考慮周全，那麼在確定哪些操作應組成服務時有什麼注意事項呢？我們認為有兩個對象設計概念很有用：內聚性和完整性。

六、服務應對實現細節進行封裝

我們封裝服務實現的細節——所用的算法和資源——的動機在於增加服務使用者和提供者之間的分離，從而為將來擴展提供靈活性。

七、操作設計應考慮並發性

RDIFramework.NET框架的SOA（WCF服務端）可以通過以下幾種方式進行寄存（發布）： 以Windows服務方式寄存，以WinForm形式寄存和以IIS形式寄存。

要想框架以WCF模式運行，首先必須配置RDIFramework.NET框架可運行文件所在文件夾的「Config.xml」文件，找到「軟體服務提供程序」項，其取值有兩種：RDIFramework.ServiceAdapter與RDIFramework.ServiceClient

系統默認為「RDIFramework.ServiceAdapter」，即傳統數據訪問方式（邏輯上的三層結構），要想系統以WCF模式運行，必須設置其值為：RDIFramework.ServiceClient

通過這樣的設置，再簡單部署一下，即可以SOA模式運行本程序。SOA模式運行Config.xml文件配置如下圖所示。

當然了，對於SOA模式的客戶端與服務端的正確配置以及綁定的方法，可以參考相關文章，在我們框架的配置文件中也進行了詳細的說明。

要想我們的框架以Windows服務寄存，必須部署框架的WCF服務「RDIFramework.WinService」目錄包含的內容即為我們的框架以Windows服務進行寄存所必須的文件，如圖7.3.1所示。圖中含有兩個批處理文件可以很好的幫助我們安裝與卸載框架的Windows服務，他們分別是：

Install RDIFrameworkService.bat：用於安裝框架的WCF服務以寄存到Windows服務上。

Uninstall RDIFrameworkService.bat：用於卸載已經安裝好框架WCF服務。

如下圖：RDIFramework.NET以Windows服務進行寄存所需文件所示。

雙擊Install RDIFrameworkService.bat文件進行服務的安裝，如圖7.3.2所示，輸入:y，即可對服務進行安裝。如下圖所示：

安裝成功會出現下圖所示的字樣。

到Windows服務管理器中，可以看到我們框架的服務已經安裝成功，首次安裝成功默認沒有啟動，就請手動啟動即可，如下圖所示。

對於安裝成功的服務，我們也可以對他進行卸載，卸載服務使用Uninstall RDIFrameworkService.bat文件，雙擊此文件，輸入」y」即可對已成功安裝的框架服務進行卸載，如下圖所示。

或者用InstallUtil.exe命令卸載框架服務也可以，如下圖所示：

框架以SOA模式運行的效果如下圖所示，可以看到其與傳統的方式運行效果完全一樣。

因為我們開啟了WCF的日誌功能，我們可以通過VS2010自帶的「服務跟蹤查看器」查看WCF的調用過程，當然建議在系統投入正常使用後，關閉WCF的日誌記錄功能，以免影響整個框架的效率，在此僅做測試使用，要打開VS的服務跟蹤查看器，到開始菜單VS的安裝菜單名下，找到「服務跟蹤查看器」，即可打開，如下圖所示。

通過「服務跟蹤查看器」我們可以很清楚地看到我們框架是如何調用WCF服務的，整個過程都詳細的進行了記錄，如下圖所示。對於「服務跟蹤查看器」的使用方法可以參考相關文檔，也可以查看其自帶的幫助文件。

以上就是我們框架的分布式架構部署方案（以Windows服務為寄存宿主）。 　　

我們的框架不僅可以寄存在Windows服務程序中，還可以以WinForm形式寄存，使用方式與Windows服務寄存類似。以Winform形式寄存意思是說，服務端以窗體界面形式來啟動，這種方式比較簡單易懂，用戶可以把啟動框架服務的窗體主程序放在Windows自啟動菜單，讓開機時自動啟動我們的框架服務。RDIFramework.NET服務端以WinForm形式寄存運行目錄：Bin\FrameworkService\RDIFramework.ServiceHost.exe即可，開啟後的效果如下圖所示：

　　服務端已經開啟，現在運行RDIFrmework.NET客戶端，效果與Windows服務方式一至。要測試我們啟動的服務，我們可以使用「WCF測試客戶端」來進行測試。wcftestclient.exe是一個GUI的工具用於測試WCF，只需在Visual studio command line 窗口中鍵入wcftestclient，就啟動這個程序。如下圖：

　　可以右鍵「我的服務項目」選擇「添加服務（A）…」來添加WCF服務，在上圖中，我們輸入「net.tcp://127.0.0.1:8888/RDIFramework.ServiceAdapter/UserService/mex」添加了對用戶服務的測試調用。　　

我們的框架不僅可以Windows服務、WinForm界面形式寄存，還可以使用IIS的Web服務形式來寄存。　　要以IIS方式來寄存框架的WCF服務，首先我們需要把「RDIFramework.WCFService」項目發布到IIS下，發布的方法與常規的Web發布方式一樣，可以參照相關的文章，RDIFramework.WCFService項目如下圖所示：

　　發布到IIS後的效果如下圖所示：

　　在這兒需要說明的是，框架的服務發布到IIS下後，對應的應用程式池的.NET Framework版本要選擇.NET Framework V4.0以上版本。如下圖所示：

　　至此，我們可以用瀏覽器來瀏覽我們發布的服務，測試發布的服務是否成功，如下圖所示，我們測試StaffService服務。

　　我們也可以用「WCF測試客戶端」來測試我們發布到IIS下的WCF服務，如下圖所示：

　　以上面三種方式發布SOA服務端，來進行分布式應用的部署，都可以成功運行我們框架的客戶端，用戶在使用過程中，可以根據實際情況做出自己的選擇。　

全新跨平臺版本.NET敏捷開發框架V5.0-RDIFramework.NET震撼發布

敏捷開發框架助力企業BPM業務流程系統的開發與落地

RDIFramework.NET代碼生成器全新V5.0版發布

一路走來數個年頭，感謝RDIFramework.NET框架的支持者與使用者，大家可以通過下面的地址了解詳情。

RDIFramework.NET官方網站：http://www.rdiframework.net/

RDIFramework.NET官方博客：http://blog.rdiframework.net/

特別說明，框架相關的技術文章請以官方網站為準，歡迎大家收藏！

RDIFramework.NET框架由海南國思軟體科技有限公司專業團隊長期打造、一直在更新、一直在升級，請放心使用！

歡迎關注RDIFramework.NET框架官方微信公眾號（guosisoft），及時了解最新動態。