助力.NET，此文轉於博客園《fanly11》

surging受到大家這麼強烈的關注，我感到非常意外，比如有同僚在公司的分享會上分享surging, 還有在博客拿其它的RPC框架，微服務做對比等等，這些舉動都讓我感覺壓力很大，畢竟作為個人的開源項目，無法與成熟的開源社區的項目相比，也只有等到後面有許許多多志同道合的朋友加入一起研發完善surging，這樣才能讓surging 成為流行的微服務框架。

這篇文章介紹如何使用surging

開源地址：https://github.com/dotnetcore/surging

2、設計模式

Surging 提供了以下四種設計模式

2.1 代理模式

通過代理調用不同的微服務。並且針對於規則控制其訪問，如下圖所示：

2.2 異步消息模式

再處理等待而阻塞的問題時候， 基於微服務的架構會選擇使用消息隊列來代替請求/響應模式，如下圖所示：

2.3 鏈式模式

這種模式在接收到請求後會進行互相合並的響應，如下圖所示：

服務A接收到請求後會與服務B進行通信，服務B會同服務C進行通信。所有服務之間的通信使用基於Netty的RPC通信。

2.4 分支模式

這種模式允許調用多個服務提供者,來合併數據進行返回，如下圖所示：

3、外部如何交互

服務主要針對提交的數據進行處理，在單個服務或多個服務調用的問題上，採取使用網關統一訪問的形式進行處理，如下圖所示

網關包括以下功能：

1. 安全身份認證

2. 統一訪問

3. 流量控制

4. 分流控制

5. 數據監控

6. 緩存攔截

2.簡單示例

服務端

服務路由訪問配置

在接口上，添加以下特性（還未實現統一方法配置）

[ServiceBundle("api/{Service}")]

服務創建代理調用 （需要依賴接口創建代理）

ServiceLocator.GetService().CreateProxy(key)

服務根據RoutePath 進行調用（不需要依賴接口，耦合性低）

ServiceLocator.GetService().Invoke(model, path, serviceKey)

本地模塊和服務調用

ServiceLocator.GetService(key)

通過以上配置，可以通過網關進行訪問，如果我們要訪問接口IUserService ,方法為GetUser，路由映射的規則[ServiceBundle("api/{Service}/{Method}")],所轉化地址應該是api/User/GetUser,

用Postman測試的效果如下：

4. 總結

surging外部通過Api 網關 Rest 訪問，內部通過netty RPC訪問，surging還在不斷完善中，幫助文檔也正在趕工中，請大家耐心等待。如感興趣請多關注或者加入QQ群：542283494

閱讀更多 哥們兒是程序猿 的文章

關鍵字: 設計模式 服務 通信