這篇文章主要還是想談如果僅僅是內部多個微服務模組間的介面服務整合，是否能夠實現一種去中心化的微服務閘道器，或者也可以理解為實現一種去中心化的輕量服務匯流排能力。要知道，在微服務模組間的介面服務呼叫中，涉及到安全，日誌，路由，**，監控，限流等能力，我們還是希望有乙個統一的微服務閘道器來處理。
在前面的文章裡面我們曾經談到過，去中心化的乙個核心思路就是在微服務架構實施過程中，結合容器化自動化部署過去，在微服務模組部署的時候，自動在容器裡面同時部署相應的sdk**包。這個sdk**包將傳統的服務閘道器能力下沉到微服務模組本地化容器中去實現和執行。
即使這樣，我們仍然需要保留中心化的服務中心，本地的sdk服務**包具備相應的快取能力，即在服務註冊中心宕機的時候仍然可以讀取本地快取資訊進行服務位址獲取和訪問。
本地的sdk包是乙個本地化的jar包，我們可以在jar包裡面對http rest介面的訪問和消費進一步封裝，將其封裝為本地api方法，同時在本地api方法中進行類似安全，日誌等方面內容的攔截處理。在這種實現方法下，我們可以看下整個服務呼叫過程。
舉例來說當前有考勤管理a和使用者管理b兩個微服務模組，考勤管理需要呼叫使用者管理模組的查詢使用者rest服務介面。在這種場景下，具體的實現過程如下：
1. 考勤管理模組a在自身專案中匯入服務**sdk包的內容。
2. a呼叫sdk包裡面的queryuserinfo介面方法
3. sdk包獲取到呼叫請求後，呼叫服務註冊中心，獲取queryuserinfo方法的rest介面位址
4. sdk包發起對遠端rest介面方法的呼叫並返回結果
5. a模組對返回的結果進行處理。
在整個過程中還可以在sdk包中新增安全，日誌，流控等各種***外掛程式實現進一步的控制和處理。基於這個基礎流程，我們來看實際的服務閘道器的關鍵能力實現。
服務**能力
考勤管理模組只能看到本地sdk包的查詢使用者方法，而看不到具體的遠端呼叫位址，而遠端呼叫位址是sdk包通過動態查詢服務註冊庫獲取到後，再發起的呼叫。也就是說在去中心化架構下，傳統服務閘道器的服務**層前置到了本地微服務模組容器中的sdk**包。
負載均衡和路由**能力
sdk包中本身也不儲存具體的遠端服務訪問位址，而是告訴服務中心我們需要訪問哪個服務，服務中心根據服務編碼或名稱返回具體服務的訪問位址，如果乙個服務在服務中心註冊有多個可訪問位址，那麼服務中心就可以實現最簡單的負載均衡能力。即實際的負載均衡在服務註冊中心實現。
第二種方法是sdk包呼叫服務註冊中心後，服務註冊中心把所有可訪問的服務位址全部返回給sdk包，由sdk包在進行負載均衡演算法選擇和路由。
可以看到第一種方法往往更好，因為乙個介面服務往往有多個微服務模組都在消費和呼叫，第二種方法是無法真正做到完全的負載均衡的。但是第一種方法仍然存在問題就是會增加服務註冊中心的計算負荷。
日誌和監控能力
在這種架構下，本地的sdk包是完全可以攔截到具體的服務輸入和服務輸出資訊的，而且在這種去中心化的架構下還可以做到對於a模組和b模組各自本地的sdk包分別攔截到服務的輸入和輸出，以方面後續的日誌審計。在sdk包攔截到服務日誌後，在這裡需要通過另外乙個jms api介面，將日誌資訊通過非同步訊息的模式寫入到jms訊息中介軟體中，然後再通過訊息中介軟體對日誌進行相關的持久化處理。
如果寫jms訊息中介軟體報錯，我們可以對異常資訊直接寫入到本地的磁碟檔案中，在jms訊息中介軟體恢復後再重新寫回到訊息中介軟體中。
限流和流量控制
首先還是需要在服務註冊中心設定相應的限流策略，然後將限流策略分發到本地的sdk包中，本地的sdk包對服務呼叫次數，時間等資訊進行計算統計，並將計算統計資訊僅快取，同時對快取的資料進行實時計算，當滿足流量控制策略的時候，則對服務進行限流。
由於在服務提供的a模組和服務消費的b模組我們都部署了服務**sdk包，因此也很容易實現類似服務匯流排的輸入端限流和提供端限流的雙向限流能力。
服務訪問安全控制
如果乙個服務沒有進行授權，首先可以做到sdk包在獲取服務位址資訊的時候就返回安全校驗不通過。
那我們再來看額外的服務訪問控制場景，基礎的需要做到的就是基於ip位址的服務訪問控制，只有授權的ip位址才能夠訪問服務。在這裡也是同樣的道理，需要將ip訪問控制策略資訊下發到服務**sdk包中。
同時在去中心化的架構下我們也很容易實現類似動態token的訪問安全控制，比如在a模組，我們完全可以在a模組發起呼叫的時候通過傳遞業務系統id，日期，再傳遞乙個計算出來的md5碼值到服務提供端。提供端根據通用的演算法也計算md5碼值，只有當兩個值匹配的時候才認為校驗通過。
在去中心化的架構下，可以看到仍然保留了中心化的服務註冊中心，同時對於一些管控需要的基礎配置元資料也需要在服務註冊中心完成。對於各種配置元資料，我們需要實時下發到各個微服務模組。因此最好的做法技術在各個微服務模組都實現乙個jms訊息訂閱介面，通過訊息發布訂閱的模式實時下發訊息
微服務 閘道器
3 很難重構 二 定義 三 閘道器的用途 四 優缺點 缺點 五 實現 採用反應性程式設計模型 服務呼叫 服務發現 處理部分失敗 netflix hysrix 對於實現遠端服務呼叫 來說是乙個非常好用的庫。hystrix記錄那些超過預設定的極限值的呼叫。它實現了circuit break模式，使得可以...
微服務閘道器
1.什麼是微服務閘道器 api閘道器是乙個伺服器，是系統對外的唯一入口。api閘道器封裝了系統內部架構，為每個客戶端提供乙個定製的api。api閘道器方式的核心要點是 所有的客戶端和消費端都通過統一的閘道器接入微服務，在閘道器層處理所有的非業務功能。2.為什麼需要微服務閘道器 首先是需要路由器功能，...
微服務閘道器
nacos配置中心 限流 工程名稱api gateway org.springframework.cloudgroupid spring cloud starter gatewayartifactid dependency server port 9000 spring name api gatew...