08 js發布訂閱模式簡單實現(vuejs源碼用了什么設計模式，具體點的)

通過方法調用，或者跨語言通信。SOA降低了這種語言直接的耦合度，采用基于SOAP協議的web服務。這種web服務的功能和消息體定義都十分復雜，微服務需要更輕量的機制。

同步消息 REST

同步消息就是客戶端需要保持等待，直到服務器返回應答。REST是微服務中默認的同步消息方式，它提供了基于HTTP協議和資源API風格的簡單消息格式，多數微服務都采用這種方式（每個功能代表了一個資源和對應的操作）

異步消息 – AMQP, STOMP, MQTT

異步消息就是客戶端不需要一直等待服務應答，有應到后會得到通知。某些微服務需要用到異步消息，一般采用AMQP, STOMP, MQTT 這三種通訊協議

消息格式 – JSON, XML, Thrift, ProtoBuf, Avro

消息格式是微服務中另外一個很重要的因素。SOA的web服務一般采用文本消息，基于復雜的消息格式（SOAP）和消息定義（xsd）。微服務采用簡單的文本協議JSON和XML，基于HTTP的資源API風格。如果需要二進制，通過用到Thrift, ProtoBuf, Avro。

服務約定 – 定義接口 – Swagger, RAML, Thrift IDL

如果把功能實現為服務，并發布，需要定義一套約定。單體架構中，SOA采用WSDL，WSDL過于復雜并且和SOAP緊耦合，不適合微服務。

REST設計的微服務，通常采用Swagger和RAML定義約定。

對于不是基于REST設計的微服務，比如Thrift，通常采用IDL（Interface Definition Languages），比如Thrift IDL。

微服務集成 (服務間通信)

大部分微服務基于RPC、HTTP、JSON這樣的標準協議，集成不同標準和格式變的不再重要。另外一個選擇是采用輕量級的消息總線或者網關，有路由功能，沒有復雜的業務邏輯。下面就介紹幾種常見的架構方式。

點對點方式

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

上圖：通過點對點方式通信

很明顯，在比較簡單的微服務應用場景下，這種方式還可行，隨著應用復雜度的提升，會變得越來越不可維護。這點有些類似SOA的ESB，盡量不采用點對點的集成方式。

API-網關方式

API網關方式的核心要點是，所有的客戶端和消費端都通過統一的網關接入微服務，在網關層處理所有的非業務功能個。通常，網關也是提供REST/HTTP的訪問API。服務端通過API-GW注冊和管理服務。

上圖：通過API-網關暴露微服務

所有的業務接口通過API網關暴露，是所有客戶端接口的唯一入口。微服務之間的通信也通過API網關。\

采用網關方式有如下優勢：

目前，API網關方式應該是微服務架構中應用最廣泛的設計模式。

消息代理方式

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

上圖：異步通信方式

通常異步的生產者/消費者模式，通過AMQP, STOMP, MQTT 等異步消息通訊協議規范。

數據的去中心化

單體架構中，不同功能的服務模塊都把數據存儲在某個中心數據庫中。

每個微服務有自己私有的數據庫，其它微服務不能直接訪問。單體架構，用一個數據庫存儲所有數據

微服務方式，多個服務之間的設計相互獨立，數據也應該相互獨立（比如，某個微服務的數據庫結構定義方式改變，可能會中斷其它服務）。因此，每個微服務都應該有自己的數據庫。

每個微服務有自己私有的數據庫，其它微服務不能直接訪問。每個微服務有自己私有的數據庫，其它微服務不能直接訪問。

數據去中心話的核心要點：

數據的去中心化，進一步降低了微服務之間的耦合度，不同服務可以采用不同的數據庫技術（SQL、NoSQL等）。在復雜的業務場景下，如果包含多個微服務，通常在客戶端或者中間層（網關）處理。

微服務架構的優點：

微服務架構的缺點：

微服務的一些想法在實踐上是好的，但當整體實現時也會呈現出其復雜性。

關于微服務架構的取舍

很赞哦!（2827）