基于訂閱的服務通訊架構體系

        說到訂閱服務通訊一般都會想到基于隊列的消息生產和消費模式，這也是在實際應該中比較常用的方式。一般生產者把消息發送到隊列服務中心，然后消費者去中心訂閱；然而這種方式需要一個消息服務中心，而在這里所說的訂閱服務通訊則有點不一樣，因為需要更靈活的訂閱方式，所以需要去除中心化處理；但去除中心化那則需要考慮的事情想對復雜，最基礎的環節就是如何維護生產者和消費者的關系，接下來講解如何實現這種方式。

中心化通訊方式

        由于在應用中一般會使用隊列服務作為消息中心，所以生產者和消費并沒有直接的關系，一個把消息投遞到中心，一個從中心中獲取。

去除中心化

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

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

如何發現服務

        對于不同服務通訊需要做的事情是發現對方，一般的服務程序都有固定的地方（域名）和端口來告訴使用者，你可以通過這個地方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廣播只能有效于局域網段，不適用于廣域網，所以些通訊架構體系也只適用于應用內部的集群通訊體系應用，如果需要應用到廣播網，那則需要一個發現中心來確認服務在廣域網下是可發現的。

來自： http://my.oschina.net/ikende/blog/601218