服務調用框架DataStrom

根據之前的命名服務，重新構建了下服務框架；

結構模式；c-center-s;

1.服務端：

  服務端啓動，講本身的IP,端口註冊到註冊中心節點(master),而後註冊本身的處理類（須要繼承對應接口）;

  同時須要設置服務類型（是不是主從服務，若是是主從服務還須要設置本身是不是master）;

  若是不是主從服務則中心採用hash負載均衡進行服務調度；

 同時有心跳給註冊中心；

2.註冊中心

啓動註冊中心，註冊中心是主從方式存在，啓動時選舉本身爲master;而後接收其他註冊中心迴應，2秒沒有收到則認爲本身是master進行發佈，收到master的回覆則更新信息；

master節點實時有心跳；

主要工做：

1.判斷服務狀態是否能夠用，調度服務；

主從服務時判斷master服務，進行數據處理；

多服務認爲是須要選擇調度，則使用均衡方式；

2.負載均衡服務，調度服務；

3.判斷註冊中心master節點，隨時準備選舉新master

3.客戶端

 客戶端直接向註冊中心請求：1.請求服務地址，直接與服務通信 2.請求數據傳輸，直接由中心傳遞數據 ；同時須要設置是否須要回執數據；

 

4.通信

整個框架考慮到數據實時傳輸，大數據量處理，直接採用udp通信；提供了高層封裝；

封裝的通信層使用了數據分包，按照udp適合的傳輸包大小設置，你也能夠本身調用接口設置分包大小；每包分配了一個ID,同時一次傳輸認爲是一個session,分配seesion的id;

接收端按照數據接收，同時有包丟失時會再次向發送端請求再次發送；

接收端設計了接收發送；

發送端進行了數據緩存，內存中緩存必定時間，接收到接收端完成的ack就清除，不然保持1分鐘；直到內存耗盡；

若是是註冊中心，數據內存緩存到期還會緩存到本地數據庫中（持久化），在本地保持最近10分鐘數據；都是timer清除；

採用udp一樣也是基於框架功能，不須要鏈接，能夠在使用時能夠直接反向發送數據；也能夠不發送；

整個通信已經測完成；

5.使用包

本框架使用了goolge工具包guava-22.0，界面庫JTattoo-1.6.11，公共序列化包fastjson-1.2.9;持久化數據庫BerkeleyDB