SOA與服務治理

SOA:  面向服務的體系結構 (SOA) 是一項引人注目的技術，用於開發與業務模型保持最佳一致性的軟體應用程式。

服務治理:  也稱為SOA治理，指的是用來管理SOA的採用和實現的過程。

SOA（面向服務的體系結構）概念由來已久，在10多年前便開始進入到我們廣大軟體開發者的視線中。SOA是一種粗粒度、鬆耦合服務架構，服務之間通過簡單、精確定義介面進行通訊，不涉及底層程式設計介面和通訊模型。SOA可以看作是B/S模型、Web Service技術之後的自然延伸。

服務治理要點

• 服務定義(服務的範圍,介面和邊界)
• 服務部署生命週期(各個生命週期階段)
• 服務版本治理(包括相容性)
• 服務遷移(啟用和退役)
• 服務註冊中心(依賴關係)
• 服務訊息模型(規範資料模型)
• 服務監視(進行問題確定)
• 服務所有權(企業組織)
• 服務測試(重複測試)
• 服務安全(包括可接受的保護範圍)

SOA服務落地 (dubbo的實踐使用)

直到2011年10月27日，阿里巴巴開源了自己的SOA服務化治理方案的核心框架Dubbo，服務治理和SOA的設計理念開始逐漸在國內軟體行業中落地，並被廣泛應用。

Dubbo是一個高效能服務框架，致力於提供高效能和透明化的RPC遠端服務呼叫方案，以及SOA服務治理方案，使得應用可通過高效能RPC實現服務的輸出和輸入功能，和Spring框架可以無縫整合。

作為一個分散式服務框架,以及SOA治理方案,Dubbo主要包括

• 高效能NIO通訊及多協議整合
• 服務動態定址與路由
• 軟負載均衡與容錯
• 依賴分析與服務降級

Dubbo的最大特點是按照分層的方式來架構,使用這種方式可以使各個層之間解耦合(或者最大限度的鬆耦合),從服務模型的角度來看,Dubbo採用的是一種非常簡單的模型,要麼是提供方提供服務,要麼是消費方消費服務,所以基於這一點可以抽象出服務提供方(Provider)和服務消費方(Consumer)兩個角色.

Dubbo包含遠端通訊,叢集容錯和自動發現三個核心部分,提供透明化的遠端方法呼叫,實現像呼叫本地方法一樣呼叫遠端方法,只需簡單配置,沒有任何API侵入,同事具備軟負載均衡及容錯機制,可在內網代替F5等硬體負載均衡器,降低成本,減少單點,可以實現服務自動註冊與發現,不再需要寫死服務提供方地址,註冊中心基於介面名查詢服務提供者的IP地址,並且能夠平滑新增或刪除服務提供者

什麼是微服務

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

微服務是一種架構風格，一個大型複雜軟體應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是鬆耦合的。每個微服務僅關注於完成一件任務並很好地完成該任務。在所有情況下，每個任務代表著一個小的業務能力。 如使用者管理、使用者角色、電子商務車、搜尋引擎、社交媒體登入等。此外，它們是完全獨立的，也就是說它們可以寫入不同的程式語言並使用不同的資料庫。集中式服務管理幾乎不存在，微服務使用輕量級HTTP、REST或Thrift API進行通訊。 

SOA vs. MicroServices

下面進一步解釋上表所述的不同之處：

• 開發方面 - 在這兩種體系結構中，可以使用不同的程式語言和工具開發服務，從而將技術多樣性帶入開發團隊。開發可以在多個團隊中組織，但是在SOA中，每個團隊都需要了解常見的通訊機制。另一方面，使用微服務，服務可以獨立於其他服務執行和部署。因此，頻繁部署新版本的微服務或獨立擴充套件服務會更容易。您可以在這裡進一步閱讀有關微服務的這些好處。
• “上下文邊界” - SOA鼓勵元件的共享，而微服務嘗試通過“上下文邊界”來最小化共享。上下文邊界是指以最小的依賴關係將元件及其資料耦合為單個單元。由於SOA依靠多個服務來完成業務請求，構建在SOA上的系統可能比微服務要慢。
• 通訊 - 在SOA中，ESB可能成為影響整個系統的單一故障點。由於每個服務都通過ESB進行通訊，如果其中一個服務變慢，可能會阻塞ESB並請求該服務。另一方面，微服務在容錯方面要好得多。例如，如果一個微服務存在記憶體錯誤，那麼只有該微服務會受到影響。所有其他微服務將繼續定期處理請求。
• 互操作性 - SOA通過訊息中介軟體元件促進了多種異構協議的使用。微服務試圖通過減少整合選擇的數量來簡化架構模式。因此，如果您想要在異構環境中使用不同協議來整合多個系統，則需要考慮SOA。如果您的所有服務都可以通過相同的遠端訪問協議訪問，那麼微服務對您來說是一個更好的選擇。
• 大小Size - 最後一點但並非最不重要的一點，SOA和微服務的主要區別在於規模和範圍。微服務架構中的字首“微”是指內部元件的粒度，意味著它們必須比SOA架構的服務往往要小得多。微服務中的服務元件通常有一個單一的目的，他們做得很好。另一方面，在SOA服務中通​​常包含更多的業務功能，並且通常將它們實現為完整的子系統。 

簡單結論: 因為它們服務於不同的目的，微服務和SOA確實是不同型別的體系結構。SOA更適合大型複雜企業應用程式環境,微服務架構,更適合於較小和良好的分割,基於Web的系統,正在開發移動或Web應用程式，那麼微服務作為開發人員可以為您提供更大的控制權。 

以上部分摘抄至: https://blog.csdn.net/chszs/article/details/78515231

微服務落地(SpringCloud的實踐使用)

Spring Cloud 基於 Spring Boot，為微服務體系開發中的架構問題，提供了一整套的解決方案——服務註冊與發現，服務消費，服務保護與熔斷，閘道器，分散式呼叫追蹤，分散式配置管理等。

Spring Boot 是 Spring 的一套快速配置腳手架，使用預設大於配置的理念，用於快速開發單個微服務。

重點：

• 基於 Spring Boot
• 雲服務、分散式框架集合（眾多）

核心功能：

• 分散式/版本化配置
• 服務註冊和發現
• 路由
• 服務和服務之間的呼叫
• 負載均衡
• 斷路器
• 分散式訊息傳遞

Dubbo 和 Spring Cloud 比較

使用 Dubbo 構建的微服務架構就像組裝電腦，各環節我們的選擇自由度很高，但是最終結果很有可能因為一條記憶體質量不行就點不亮了，總是讓人不怎麼放心，但是如果你是一名高手，那這些都不是問題；而 Spring Cloud 就像品牌機，在 Spring Source 的整合下，做了大量的相容性測試，保證了機器擁有更高的穩定性，但是如果要在使用非原裝元件外的東西，就需要對其基礎有足夠的瞭解。

以上部分摘抄至: https://www.cnblogs.com/xishuai/archive/2018/04/13/dubbo-and-spring-cloud.html

總結

java知識內容博大精深,以上如果有什麼不對的,或者有特殊見解的,請留言一起探討;