淺談SOA、微服務、分布式、叢集之間的聯系

SOA

        SOA（Service Oriented Architecture）“面向服務的架構”。SOA是一種設計方法，包含多個服務，而多個服務之間通過互相依賴最終提供一系列的功能；每一個服務通常是以獨立的形式存在于作業系統的程序中，各個服務通過網絡來調用。簡而言之：業務系統分解為多個元件，讓每個元件都獨立提供離散，自治，可複用的服務能力，通過服務的組合和編排來實作上層的業務流程 。

        SOA架構開發中的作用及優點：

        簡化維護

        業務服務提供者和業務服務使用者的松散耦合關系及對開放标準的采用確定了該特性的實作。建立在以 SOA基礎上的資訊系統，當需求發生變化的時候，不需要修改提供業務服務的接口，隻需要調整業務服務流程或者修改操作即可，整個應用系統也更容易被維護。

         系統內建：站在系統的角度，解決企業系統間的通信問 題，把原先散亂、無規劃的系統間的網狀結構，梳理成 規整、可治理的系統間星形結構，這一步往往需要引入 一些産品，比如 ESB、以及技術規範、服務管理規範； 這一步解決的核心問題是【有序】。

        高可用性

        該特點是在于服務提供者和服務使用者的松散耦合關系上得以發揮與展現。使用者無須了解提供者的具休實作細節。

        系統的服務化：站在功能的角度，把業務邏輯抽象成 可複用、可組裝的服務，通過服務的編排實作業務的 快速再生。目的：把原先固有的業務功能轉變為通用 的業務服務，實作業務邏輯的快速複用；這一步解決 的核心問題是【複用】

        靈活的伸縮性

        依靠業務服務設計、開發和部署等所采用的架構模型實作伸縮性。使得服務提供者可以互相彼此獨立地進行調整，以滿足新的服務需求。

        業務的服務化：站在企業的角度，把企業職能抽象成 可複用、可組裝的服務；把原先職能化的企業架構轉變為服務化的企業架構，進一步提升企業的對外服務能力；“前面兩步都是從技術層面來解決系統調用、系統功能複用的問題”。第三步，則是以業務驅動把一個業務單元封裝成一項服務。這一步解決的核心問題是【高效】

        ESB（企業服務總線）

         ESB 就像是一根管道，用來連接配接各個服務節點。為了集 成不同系統，不同協定的服務，ESB 做了消息的轉化解釋和路由工作，讓不同的服務互聯互通，如下圖所示：

微服務

       微服務(Microservices Architecture)是一種架構風格，一個大型複雜軟體應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注于完成一件任務并很好地完成該任務。在所有情況下，每個任務代表着一個小的業務能力。

      微服務架構:其實和 SOA 架構類似,微服務是在 SOA 上做的升華，微服務架構強調的一個重點是“業務需要徹底的元件化和服務化”，原有的單個業務系統會拆分為多個可以獨立開發、設計、運作的小應用。這些小應用之間通過服務完成互動和內建。

      架構設計概念,各服務間隔離（分布式也是隔離）,自治（分布式依賴整體組合）其它特性(單一職責,邊界,異步通信,獨立部署)是分布式概念更嚴格執行SOA到微服務架構的演進過程 。

       微服務架構的核心思想是，一個應用是由多個小的、互相獨立的、微服務組成，這些服務運作在自己的程序中，開發和釋出都沒有依賴。不同服務通過一些輕量級互動機制來通信，例如 RPC、HTTP 等，服務可獨立擴充伸縮，每個服務定義了明确的邊界，不同的服務甚至可以采用不同的程式設計語言來實作，由獨立的團隊來維護。簡單的來說，一個系統的不同子產品轉變成不同的服務！而且服務可以使用不同的技術加以實作！

      Soa的開發方法一般主要有開源的dubbo、dubbox、mule、wrs、axis、xfire、wso2、cxf，以及付費的oracle soa、ibm soa等。現在rest正在取代soa。

那我們在微服務中應該怎樣設計呢。以下是微服務的設計指南：

1. 職責單一原則（Single Responsibility Principle）：把某一個微服務的功能聚焦在特定業務或者有限的範圍内會有助于靈活開發和服務的釋出。
2. 設計階段就需要把業務範圍進行界定。
3. 需要關心微服務的業務範圍，而不是服務的數量和規模盡量小。數量和規模需要依照業務功能而定。
4. 于SOA不同，某個微服務的功能、操作和消息協定盡量簡單。
5. 項目初期把服務的範圍制定相對寬泛，随着深入，進一步重構服務，細分微服務是個很好的做法。

關于為服務的一些取舍：

1. 在合适的項目，合适的團隊，采用微服務架構收益會大于成本。
2. 微服務架構有很多吸引人的地方，但在擁抱微服務之前，也需要認清它所帶來的挑戰。
3. 需要避免為了“微服務”而“微服務”。
4. 微服務架構引入政策 – 對傳統企業而言，開始時可以考慮引入部分合适的微服務架構原則對已有系統進行改造或建立微服務應用，逐漸探索及積累微服務架構經驗，而非全盤實施微服務架構。

      微服務架構的作用及特點：

     作用：各服務可獨立應用，組合服務也可系統應用。

     1. 通過服務實作元件化

• 開發者不再需要協調其它服務部署對本服務的影響。

     2. 按業務能力來劃分服務和開發團隊

• 開發者可以自由選擇開發技術，提供 API 服務

     3. 去中心化

• 每個微服務有自己私有的資料庫持久化業務資料
• 每個微服務隻能通路自己的資料庫，而不能通路其它服務的資料庫
• 某些業務場景下，需要在一個事務中更新多個資料庫。這種情況也不能直接通路其它微服務的資料庫，而是通過對于微服務進行操作。
• 資料的去中心化，進一步降低了微服務之間的耦合度，不同服務可以采用不同的資料庫技術（SQL、NoSQL等）。在複雜的業務場景下，如果包含多個微服務，通常在用戶端或者中間層（網關）處理。

      4. 基礎設施自動化（devops、自動化部署）

• Java EE部署架構，通過展現層打包WARs，業務層劃分到JARs最後部署為EAR一個大包，而微服務則打開了這個黑盒子，把應用拆分成為一個一個的單個服務，應用Docker技術，不依賴任何伺服器和資料模型，是一個全棧應用，可以通過自動化方式獨立部署，每個服務運作在自己的程序中，通過輕量的通訊機制聯系，經常是基于HTTP資源API，這些服務基于業務能力建構，能實作集中化管理。因為服務太多，不集中管理就無法DevOps。

       微服務API網關

       API網關是一個伺服器，是系統的唯一入口。從面向對象設計的角度看，它與外觀模式類似。API網關封裝了系統内部架構，為每個用戶端提供一個定制的API。它可能還具有其它職責，如身份驗證、監控、負載均衡、緩存、請求分片與管理、靜态響應處理。API網關方式的核心要點是，所有的用戶端和消費端都通過統一的網關接入微服務，在網關層處理所有的非業務功能。通常，網關也是提供REST/HTTP的通路API。服務端通過API-GW注冊和管理服務。

       SOA與微服務之間的主要差別：

功能	SOA	微服務
元件大小	大塊業務邏輯	單獨任務或小塊業務邏輯
耦合	通常松耦合	總是松耦合
公司架構	任何類型	小型、專注于功能交叉團隊
管理	着重中央管理	着重分散管理
目标	確定應用能夠互動操作	執行新功能、快速拓展開發團隊

   Dubbo服務的最佳實踐

分包

1. 服務接口、請求服務模型、異常資訊都放在api裡面，符合重用釋出等價原則，共同重用原則
2. api裡面放入spring 的引用配置。 也可以放在子產品的包目錄下。

粒度

1. 盡可能把接口設定成粗粒度，每個服務方法代表一個獨立的功能，而不是某個功能的步驟。否則就會涉及到分布式事務
2. 服務接口建議以業務場景為機關劃分。并對相近業務做抽象，防止接口暴增
3. 不建議使用過于抽象的通用接口  T T<泛型>，接口沒有明确的語義，帶來後期的維護

版本

1. 每個接口都應該定義版本，為後續的相容性提供前瞻性的考慮 version （maven -snapshot）
2. 建議使用兩位版本号，因為第三位版本号表示的相容性更新，隻有不相容時才需要變更服務版本
3. 當接口做到不相容更新的時候，先更新一半或者一台提供者為新版本，再将消費全部更新新版本，然後再将剩下的一半提供者更新新版本

預釋出環境

推薦用法

1. 在provider端盡可能配置consumer端的屬性
2. 比如timeout、retires、線程池大小、LoadBalance

 配置管理者資訊

1. application上面配置的owner 、 owner建議配置2個人以上。因為owner都能夠在監控中心看到

配置dubbo緩存檔案

1. 注冊中心的清單
2. 服務提供者清單

分布式與叢集

         分布式：一個業務分拆多個子業務，部署在不同的伺服器上。

         叢集：同一個業務，部署在多個伺服器上

分布式和叢集都是為了解決兩個問題：

• 高吞吐量（throughput）：通過負載均衡算法（通常是借助一緻性Hash和虛拟節點），我們把Client的請求均勻配置設定到三台Memcached伺服器上，不至于隻讓一台Memcached疲于處理全部請求。
• 高可用（availability）：一旦一台Memcached節點挂了，比如說Memcached1，那借助一緻性Hash算法和它的虛拟節點機制，我們可以将原本發給Client的Memcached1的請求均勻配置設定到Memcached2和3上，緩存功能依舊可用。

以上内容大部分引用以下兩篇部落客的部落格内容：

https://blog.csdn.net/heatdeath/article/details/79038795

https://blog.csdn.net/zpoison/article/details/80729052

其他學習參考資料：

1. 架構設計漫步：從單體架構、SOA到微服務

http://www.uml.org.cn/zjjs/201708083.asp

2. SOA和微服務架構的差別

https://www.zhihu.com/question/37808426

3. 分布式與叢集的差別是什麼

https://www.zhihu.com/question/20004877

4. 分布式服務架構與微服務架構概念的差別與聯系是怎樣的

https://www.zhihu.com/question/28253777

5. Dubbo架構原理

https://zhuanlan.zhihu.com/p/39535319