架構設計思惟

架構設計思惟

架構思惟中的分解和集成是隨着系統的演化進行演化，從單體架構到ESB爲表明的SOA架構再到如今流行的微服務，集成方式也從直接依賴到ESB爲樞紐再到多種形式存在的微服務集成，接下來咱們就來解決微服務中集成的方式有哪些。

單體架構

Web應用程序發展的早期，在開發服務端企業應用時，應用須要支持各類不一樣類型的客戶端，好比桌面瀏覽器、移動瀏覽器以及原生移動應用。應用還須要向第三方提供可訪問的API，並經過Web Service或者消息代理與其它應用實現集成。大部分web工程是將全部的功能模塊(service side)打包到一塊兒並放在一個web容器中運行，不少企業的Java應用程序打包爲war包。應用經過執行業務邏輯、訪問數據庫、與其它系統交換信息、並返回一條HTML/JSON/XML響應，來處理請求（HTTP請求與消息）。

應用採用多層架構或者六角架構，主要由如下幾類不一樣組件構成：

• 展示組件——負責處理HTTP請求並響應HTML或者JSON/XML（對於web Services APIs）
• 業務邏輯——應用的業務邏輯
• 數據庫訪問邏輯——用於訪問數據庫的數據訪問對象

不一樣邏輯組件分別響應應用中的不一樣功能模塊。

SOA架構

SOA架構，是一種粗粒度、開放式、鬆耦合的服務結構，要求軟件產品在開發過程當中，按照相關的標準或協議，進行分層開發。經過這種分層設計或架構體系可使軟件產品變得更加彈性和靈活，且儘量的與第三方軟件產品互補兼容，以達到快速擴展，知足或響應市場或客戶需求的多樣化、多變性。

微服務架構

微服務是一種用於構建應用的架構方案。微服務架構有別於更爲傳統的單體式方案，可將應用拆分紅多個核心功能。每一個功能都被稱爲一項服務，能夠單獨構建和部署，這意味着各項服務在工做（和出現故障）時不會相互影響。是應用的各項核心功能，並且這些服務都可獨立運行。可是，微服務架構不僅是應用核心功能間的這種鬆散耦合，它還涉及重組開發團隊、涉及如何進行服務間通訊以應對不可避免的故障、知足將來的可擴展性並實現新的功能集成。

集成方式

微服務架構傾向於下降中心消息總線（相似於ESB）的依賴，將業務邏輯分佈在每一個具體的服務終端。大部分微服務基於HTTP、JSON這樣的標準協議，集成不一樣標準和格式變的再也不重要。另一個選擇是採用輕量級的消息總線或者網關，有路由功能，沒有複雜的業務邏輯。下面就介紹幾種常見的架構方式。

點對點方式

點對點方式中，服務之間直接用。每一個微服務都開放REST API，而且調用其它微服務的接口。

 

 

網關方式

 

 

消息代理方式

微服務也能夠集成在異步的場景下，經過隊列和訂閱主題，實現消息的發佈和訂閱。一個微服務能夠是消息的發佈者，把消息經過異步的方式發送到隊列或者訂閱主題下。做爲消費者的微服務能夠從隊列或者主題共獲取消息。經過消息中間件把服務之間的直接調用解耦。

 

 

參考：https://mp.weixin.qq.com/s/f1ZlEpvbnox_re14ceCgFQ