十萬個爲何之SOA服務,服務治理,微服務

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知識內容博大精深,以上若是有什麼不對的,或者有特殊看法的,請留言一塊兒探討;