基於訂閱的服務通信架構體系

        說到訂閱服務通信通常都會想到基於隊列的消息生產和消費模式，這也是在實際應該中比較經常使用的方式。通常生產者把消息發送到隊列服務中心，而後消費者去中心訂閱；然而這種方式須要一個消息服務中心，而在這裏所說的訂閱服務通信則有點不同，由於須要更靈活的訂閱方式，因此須要去除中心化處理；但去除中心化那則須要考慮的事情想對複雜，最基礎的環節就是如何維護生產者和消費者的關係，接下來說解如何實現這種方式。

中心化通信方式

        因爲在應用中通常會使用隊列服務做爲消息中心，因此生產者和消費並無直接的關係，一個把消息投遞到中心，一個從中心中獲取。

        

去除中心化

        去除中心化其實就是生產和消費並不依賴於中心服務，每一個生產和消費自身就是一箇中心服務，簡單地說也不存在生產和消費劃分；每一個服務充當生產的同時也是消費者。

            

        去除中心後服務之間均可以構建訂閱體系，即其中一個服務故障也不會影響其餘訂閱服務，這樣在可靠性和靈活性上對於中心化服務都有着很大的優點；但有一個很明顯的問題就是沒有中心服務，服務之間是如何發現對方呢，這的確是一個麻煩的事情。

如何發現服務

        對於不一樣服務通信須要作的事情是發現對方，通常的服務程序都有固定的地方（域名）和端口來告訴使用者，你能夠經過這個地方connect進來。既然須要去除中心化那天然就不會知道如今有什麼服務，因此須要制定一套服務自我發現機制來確保服務間能夠自動發現。

            

        既然咱們不知道對方的服務地址和端口，那怎樣發現對方呢？其實每一個服務能夠把本身的服務信息經過UDP廣播出去，這樣其餘服務就能夠接收到相關的廣播，當A接收到其餘服務的UDP廣播後就會能夠知道網內有什麼服務，這樣就能夠向具體的服務發起鏈接請求，並創建服務與服務之間的通信。

消費者註冊同步

        服務和服務之間已經握手了，那消費註冊就會變得比較簡單，由於消費者隨便一臺服務上註冊均可以同步到同一集羣中的全部服務上。

            

            若是消費者在多個服務註冊，那總體的通信結構以下

            

代碼

• 消費者
  

  Route.DefaultNode.Open();
              mSwitch = new SubscribeSwitch();
              mSwitch.GetServiceSubscribe("HELLO").RegisterProcess<Hello>((o, e) =>
              {
                  e.Reply(e.Data); 
              });

  
  
• 生產者
  

  Route.DefaultNode.Open();
              mSwitch = new SubscribeSwitch();
              Hello hello = new Hello { Name = "hello,how are you?"  };
              hello = mSwitch.Send<Hello>("HELLO", hello);

  在應用代碼中不存全部服務地址的概念，只要節點服務打開就會自動向網內進行服務信息廣播，並發現網絡的其餘服務節點。

存在問題

        因爲UDP廣播只能有效於局域網段，不適用於廣域網，因此些通信架構體系也只適用於應用內部的集羣通信體系應用，若是須要應用到廣播網，那則須要一個發現中心來確認服務在廣域網下是可發現的。