大家好，我是IT修真院鄭州分院第十期的學員，一枚正直純潔善良的java程式設計師
今天給大家分享一下，修真院官網java任務九，深度思考中的知識點——什麼是SOA？什麼是SCA？什麼是微服務？

背景介紹

平臺隨著業務的發展，All in one已經不能滿足業務需求，需要把核心或共用的服務拆分出來，在這種需求推動下，產生了SOA、SCA、微服務等概念。

知識剖析

SOA

SOA全稱Service-Oriented Architecture，中文叫面向服務架構。

SOA沒有權威的定義，統一的標準，不同角度和組織的定義也不相同，這裡採用了百度百科的定義，更接近大家目前的理解。

面向服務的架構（SOA）是一個元件模型，它將應用程式的不同功能單元（稱為服務）通過這些服務之間定義良好的介面和契約聯絡起來。介面是採用中立的方式進行定義的，它應該獨立於實現服務的硬體平臺、作業系統和程式語言。這使得構建在各種各樣的系統中的服務可以以一種統一和通用的方式進行互動。

SCA

SCA全稱Service Component Architecture，中文叫服務元件化架構。

SCA是基於SOA開發的一個模型規範，由IBM領頭提出的標準。

基於元件程式設計有很多不同的模型，為了給不同的介面提供統一的呼叫方式，IBM提出了WSIF，但WSIF沒有一個基於元件的架構模型，所以IBM在此基礎上提出了SCA。

服務元件是SCA最基本的功能單元，可以把service的實現方法，pojo等包裝為SCA的服務元件。SCA服務元件的主要介面規範是基於WSDL的，另外為了給Java提供一個比較直接的介面，也提供了Java介面。

SCA服務元件的特點

1. 服務元件一般是粗粒度。
2. 服務元件的介面是標準的介面。
3. 服務元件實現與語言無關，即不繫結語言。
4. 服務元件由元件容器管理，提供服務，不由程式程式碼控制。

服務模組由一個或多個具有內在業務聯絡的服務元件構成，是SCA中的執行單位，獨立的部署單元。

一般應用是比較複雜的，實際應用需要多個模組滿足要求，這些模組互相呼叫，模組提供兩個端點，匯入和匯出，匯入使模組可以呼叫外部的服務，匯出使外部的應用可以呼叫模組內部的服務。

當我們在構建了多個模組的時候，如果有一些資源可以在不同模組之間共享，那麼我們可以選擇建立一份可以在不同模組之間進行共享的資源。共享庫就是存放這些共享資源的地方。共享庫包含的內容只有：資料定義，介面定義，資料對映和關係。與模組最大的區別是共享庫不包含服務元件，因此也就不包含業務邏輯。

微服務

微服務最早由Martin Fowler與James Lewis於2014年共同提出，微服務架構風格是一種使用一套小服務來開發單個應用的方式途徑，每個服務執行在自己的程序中，並使用輕量級機制通訊，通常是HTTP API，這些服務基於業務能力構建，並能夠通過自動化部署機制來獨立部署，這些服務使用不同的程式語言實現，以及不同資料儲存技術，並保持最低限度的集中式管理。

常見問題

SCA的應用。SCA的簡單示例。

擴充套件思考

SOA和微服務的對比

微服務架構在某種程度上是面向服務的架構SOA繼續發展的下一步。

開發方面 - 在這兩種體系結構中，可以使用不同的程式語言和工具開發服務，從而將技術多樣性帶入開發團隊。開發可以在多個團隊中組織，但是在SOA中，每個團隊都需要了解常見的通訊機制。另一方面，使用微服務，服務可以獨立於其他服務執行和部署。因此，頻繁部署新版本的微服務或獨立擴充套件服務會更容易。您可以在這裡進一步閱讀有關微服務的這些好處。

“上下文邊界” - SOA鼓勵元件的共享，而微服務嘗試通過“上下文邊界”來最小化共享。上下文邊界是指以最小的依賴關係將元件及其資料耦合為單個單元。由於SOA依靠多個服務來完成業務請求，構建在SOA上的系統可能比微服務要慢。

通訊 - 在SOA中，ESB可能成為影響整個系統的單一故障點。由於每個服務都通過ESB進行通訊，如果其中一個服務變慢，可能會阻塞ESB並請求該服務。另一方面，微服務在容錯方面要好得多。例如，如果一個微服務存在記憶體錯誤，那麼只有該微服務會受到影響。所有其他微服務將繼續定期處理請求。

互操作性 - SOA通過訊息中介軟體元件促進了多種異構協議的使用。微服務試圖通過減少整合選擇的數量來簡化架構模式。因此，如果您想要在異構環境中使用不同協議來整合多個系統，則需要考慮SOA。如果您的所有服務都可以通過相同的遠端訪問協議訪問，那麼微服務對您來說是一個更好的選擇。

大小Size - 最後一點但並非最不重要的一點，SOA和微服務的主要區別在於規模和範圍。微服務架構中的字首“微”是指內部元件的粒度，意味著它們必須比SOA架構的服務往往要小得多。微服務中的服務元件通常有一個單一的目的，他們做得很好。另一方面，在SOA服務中通​​常包含更多的業務功能，並且通常將它們實現為完整的子系統。

不能簡單地說一種架構比另一種架構更好。這主要取決於您正在構建的應用程式的目的。SOA更適合需要與許多其他應用程式整合的大型複雜企業應用程式環境。這就是說，小型應用程式不適合SOA架構，因為它們不需要訊息中介軟體元件。而微服務架構，在另一方面，是更適合於較小和良好的分割，基於Web的系統。

參考文獻

https://blog.csdn.net/chszs/article/details/78515231

更多討論

Q1:如何將一個產品拆解為微服務（元件），每個微服務應包括哪些元素？

A1:要把單體式應用拆分成微服務元件，並沒有一個具像的標準說這個元件應該包括哪些元素。而是需要從業務的角度去分析：某一些功能是否邏輯相對獨立、可複用性高、使用頻度高等等，根據這些因素判斷是否該拆分出來作為一個微服務元件。

微服務設計強調服務的獨立性：不同微服務使用不同的資料，與外部互動通過訊息或API而不是耦合的依賴關係;此外，微服務元件的設計需要把握“微”的度，所以不宜在基礎的功能上做過多的堆疊，否則每個微服務元件可能又變成了大的單體應用。

具體來說，微服務設計需要可從以下幾個方面著手：

• 實現前後端分離，可把程式碼分為前端、服務層、底層程式碼；
• 根據業務邏輯及技術層面的系統架構綜合考慮，抽取模組成服務;
• 打造服務間的輕量通訊基礎元件及協議，例如REST或訊息佇列

Q2:SCA與傳統的業務元件最大區別

A2:一是元件和傳輸協議的分離，二是介面和實現語言的分離。

Q3:主流微服務框架有哪些？

A3:Dubbo和SpringCloud