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知識內容博大精深,以上如果有什麼不對的,或者有特殊見解的,請留言一起探討;