2. 程式人生 > >ASP.NET Core 微服務初探[1]：服務發現之Consul

ASP.NET Core 微服務初探[1]：服務發現之Consul

阿新 • • 發佈：2019-01-08
原文: ASP.NET Core 微服務初探[1]：服務發現之Consul

在傳統單體架構中，由於應用動態性不強，不會頻繁的更新和釋出，也不會進行自動伸縮，我們通常將所有的服務地址都直接寫在專案的配置檔案中，發生變化時，手動改一下配置檔案，也不會覺得有什麼問題。但是在微服務模式下，服務會更細的拆分解耦，微服務會被頻繁的更新和釋出，根據負載情況進行動態伸縮，以及受資源排程影響而從一臺伺服器遷移到另一臺伺服器等等。總而言之，在微服務架構中，微服務例項的網路位置變化是一種常態，服務發現也就成了微服務中的一個至關重要的環節。

服務發現是什麼

其實，服務發現可以說自古有之，我們每天在不知不覺中就一直在使用服務發現。比如，我們在瀏覽器中輸入域名，DNS伺服器會根據我們的域名解析出一個Ip地址，然後去請求這個Ip來獲取我們想要的資料，又或是我們使用網路印表機的時候，首先要通過WS-Discovery或者Bonjour協議來發現並連線網路中存在的列印服務等。這都是服務發現，它可以讓我們只需說我想要什麼服務即可，而不必去關心服務提供者的具體網路位置（IP 地址、埠等）。

目前，服務發現主要分為兩種模式，客戶端模式與服務端模式，兩者的本質區別在於，客戶端是否儲存服務列表資訊，比如DNS就屬於服務端模式。

在客戶端模式下，如果要進行微服務呼叫，首先要到服務註冊中心獲取服務列表，然後使用本地的負載均衡策略選擇一個服務進行呼叫。

而在服務端模式下，客戶端直接向服務註冊中心傳送請求，服務註冊中心再通過自身負載均衡策略對微服務進行呼叫後返回給客戶端。

客戶端模式相對來說比較簡單，也比較容易實現，本文就先來介紹一下基於Consul的客戶端服務發現。

Consul簡介

Consul是HashiCorp公司推出的使用go語言開發的開源工具，用於實現分散式系統的服務發現與配置，內建了服務註冊與發現框架、分佈一致性協議實現、健康檢查、Key/Value儲存、多資料中心方案，使用起來較為簡單。

Consul的安裝包僅包含一個可執行檔案，部署非常方便，直接從 官網) 下載即可。

consul

如圖，可以看出Consul的叢集是由N個Server，加上M個Client組成的。而不管是Server還是Client，都是Consul的一個節點，所有的服務都可以註冊到這些節點上，正是通過這些節點實現服務註冊資訊的共享。

Consule的核心概念：

  • Server：表示Consul的server模式，它會把所有的資訊持久化的本地，這樣遇到故障，資訊是可以被保留的。

  • Client：表示consul的client模式，就是客戶端模式。在這種模式下，所有註冊到當前節點的服務會被轉發到server，本身不持久化這些資訊。

  • ServerLeader：上圖那個Server下面有LEADER標識的，表明這個Server是它們的老大，它和其它Server不一樣的是，它需要負責同步註冊的資訊給其它的Server，同時也要負責各個節點的健康監測。

關於Consul叢集搭建等文章非常之多，本文就不再囉嗦，簡單使用開發模式來演示，執行如下命令：

./consul agent -dev

# 輸出
==> Starting Consul agent...
==> Consul agent running!
           Version: 'v1.4.0'
           Node ID: '21ec5df7-f11d-3a4e-ad1b-5ca445f8149b'
         Node name: 'Cosmos'
        Datacenter: 'dc1' (Segment: '<all>')
            Server: true (Bootstrap: false)
       Client Addr: [127.0.0.1] (HTTP: 8500, HTTPS: -1, gRPC: 8502, DNS: 8600)
      Cluster Addr: 127.0.0.1 (LAN: 8301, WAN: 8302)
           Encrypt: Gossip: false, TLS-Outgoing: false, TLS-Incoming: false

如上，可以看到Consul預設的幾個埠，如8500是客戶端基於Http呼叫的，也是我們最常用的，另外再補充一下常用的幾個引數的含義：

  • -dev：建立一個開發環境下的server節點，不會有任何持久化操作，不建議在生產環境中使用。
  • -bootstrap-expect：該命令通知consul server準備加入的server節點個數，延遲日誌複製的啟動，直到指定數量的server節點成功的加入後才啟動。
  • -client: 用於客戶端通過RPC, DNS, HTTP 或 HTTPS訪問，預設127.0.0.1。
  • -bind: 用於叢集間通訊，預設0.0.0.0。
  • -advertise: 通告地址，通告給叢集中其他節點，預設使用 -bind 地址。

註冊服務

我們首先建立一個ASP.NET Core WebAPI程式，命名為ServiceA。

然後引入Cosnul的官方Nuge包：

dotnet add package Consul

Consul包中提供了一個IConsulClient類，我們可以通過它來呼叫Consul進行服務的註冊，以及發現等。

首先在Startup的ConfigureServices方法中來配置IConsulClient到ASP.NET Core的依賴注入系統中：

services.AddSingleton<IConsulClient, ConsulClient>(p => new ConsulClient(consulConfig =>
{
    consulConfig.Address = new Uri("http://localhost:8500");
}));

我們需要在服務啟動的時候，將自身的地址等資訊註冊到Consul中，並在服務關閉的時候從Consul撤銷。這種行為就非常適合使用 IHostedService 來實現。

1.啟動時註冊服務：

public async Task StartAsync(CancellationToken cancellationToken)
{
    _cts = CancellationTokenSource.CreateLinkedTokenSource(cancellationToken);

    var features = _server.Features;
    var address = features.Get<IServerAddressesFeature>().Addresses.First();
    var uri = new Uri(address);

    _serviceId = "Service-v1-" + Dns.GetHostName() + "-" + uri.Authority;

    var registration = new AgentServiceRegistration()
    {
        ID = _serviceId,
        Name = "Service",
        Address = uri.Host,
        Port = uri.Port,
        Tags = new[] { "api" }
    };

    // 首先移除服務，避免重複註冊
    await _consulClient.Agent.ServiceDeregister(registration.ID, _cts.Token);
    await _consulClient.Agent.ServiceRegister(registration, _cts.Token);
}

這裡要注意的是，我們需要保證_serviceId對於同一個例項的唯一，避免重複性的註冊。

2.關閉時撤銷服務：

public async Task StopAsync(CancellationToken cancellationToken)
{
    _cts.Cancel();
    await _consulClient.Agent.ServiceDeregister(_serviceId, cancellationToken);
}

我們可以複製一份ServiceA的程式碼，命名為ServiceB，修改一下埠，分別為5001和5002，執行後，開啟Consul的管理UI http://localhost:8500：

consul-healthy

如果我們關閉其中一個服務的，會呼叫StopAsync方法，撤銷其註冊的服務，然後重新整理瀏覽器，可以看到只剩下一個節點了。

Consul是支援健康檢查，我們可以在註冊服務的時候指定健康檢查地址，修改上面AgentServiceRegistration中的資訊如下：

var registration = new AgentServiceRegistration()
{
    ID = _serviceId,
    Name = "Service",
    Address = uri.Host,
    Port = uri.Port,
    Tags = new[] { "api" }
    Check = new AgentServiceCheck()
    {
        // 心跳地址
        HTTP = $"{uri.Scheme}://{uri.Host}:{uri.Port}/healthz",
        // 超時時間
        Timeout = TimeSpan.FromSeconds(2),
        // 檢查間隔
        Interval = TimeSpan.FromSeconds(10)
    }
};

對於上面的healthz地址，我使用了ASP.NET Core 2.2中自帶的健康檢查，它需要在Startup中新增如下配置：

public void ConfigureServices(IServiceCollection services)
{
    services.AddHealthChecks();
}

public void Configure(IApplicationBuilder app)
{
    app.UseHealthChecks("/healthz");
}

關於健康檢查更詳細的介紹可以檢視：ASP.NET Core 2.2.0-preview1: Healthchecks。

現在，我們重新運作這兩個服務，等待註冊成功後，使用工作管理員殺掉其中的一個程序（阻止StopAsync的執行），可以看到Consul會將其移動到不健康的節點，顯示如下：

consul-unhealthy

發現服務

現在來看看服務消費者如何從Consul來獲取可用的服務列表。

我們建立一個ConsoleApp，做為服務的呼叫端，新增ConsulNuget包,然後，建立一個ConsulServiceProvider類，實現如下：

public class ConsulServiceProvider : IServiceDiscoveryProvider
{
    public async Task<List<string>> GetServicesAsync()
    {
        var consuleClient = new ConsulClient(consulConfig =>
        {
            consulConfig.Address = new Uri("http://localhost:8500");
        });
        var queryResult = await consuleClient.Health.Service("Service", string.Empty, true);
        var result = new List<string>();
        foreach (var serviceEntry in queryResult.Response)
        {
            result.Add(serviceEntry.Service.Address + ":" + serviceEntry.Service.Port);
        }
        return result;
    }
}

如上，我們建立一個ConsulClient例項，直接呼叫consuleClient.Health.Service就可以獲取到可用的服務列表了，然後使用HttpClient就可以發起對服務的呼叫。

但我們需要思考一個問題，我們什麼時候從Consul獲取服務呢？

最為簡單的便是在每次呼叫服務時，都先從Consul來獲取一下服務列表，這樣做的好處是我們得到的服務列表是最新的，能及時獲取到新註冊的服務以及過濾掉掛掉的服務。但是這樣每次請求都增加了一次對Consul的呼叫，對效能有稍微的損耗，不過我們可以在每個呼叫端的機器上都部署一個Consul Agent，這樣對效能的影響就微乎其微了。

另外一種方式，可以在呼叫端做服務列表的本地快取，並定時與Consul同步，具體實現如下：

public class PollingConsulServiceProvider : IServiceDiscoveryProvider
{
    private List<string> _services = new List<string>();
    private bool _polling;

    public PollingConsulServiceProvider()
    {
        var _timer = new Timer(async _ =>
        {
            if (_polling) return;

            _polling = true;
            await Poll();
            _polling = false;

        }, null, 0, 1000);
    }

    public async Task<List<string>> GetServicesAsync()
    {
        if (_services.Count == 0) await Poll();
        return _services;
    }

    private async Task Poll()
    {
        _services = await new ConsulServiceProvider().GetServicesAsync();
    }
}

其實現也非常簡單，通過一個Timer來定時從Consul拉取最新的服務列表。

現在我們獲取到服務列表了，還需要設計一種負載均衡機制，來實現服務呼叫的最優化。

負載均衡

如何將不同的使用者的流量分發到不同的伺服器上面呢，早期的方法是使用DNS做負載，通過給客戶端解析不同的IP地址，讓客戶端的流量直接到達各個伺服器。但是這種方法有一個很大的缺點就是延時性問題，在做出排程策略改變以後，由於DNS各級節點的快取並不會及時的在客戶端生效，而且DNS負載的排程策略比較簡單，無法滿足業務需求，因此就出現了負載均衡器。

常見的負載均衡演算法有如下幾種：

  • 隨機演算法：每次從服務列表中隨機選取一個伺服器。

  • 輪詢及加權輪詢：按順序依次呼叫服務列表中的伺服器，也可以指定一個加權值，來增加某個伺服器的呼叫次數。

  • 最小連線：記錄每個伺服器的連線數，每次選取連線數最少的伺服器。

  • 雜湊演算法：分為普通雜湊與一致性雜湊等。

  • IP地址雜湊：通過呼叫端Ip地址的雜湊，將來自同一呼叫端的分組統一轉發到相同伺服器的演算法。

  • URL雜湊：通過管理呼叫端請求URL資訊的雜湊，將傳送至相同URL的請求轉發至同一伺服器的演算法。

本文中簡單模擬前兩種來介紹一下。

隨機均衡

隨機均衡是最為簡單粗暴的方式，我們只需根據伺服器數量生成一個隨機數即可：

public class RandomLoadBalancer : ILoadBalancer
{
    private readonly IServiceDiscoveryProvider _sdProvider;

    public RandomLoadBalancer(IServiceDiscoveryProvider sdProvider)
    {
        _sdProvider = sdProvider;
    }

    private Random _random = new Random();

    public async Task<string> GetServiceAsync()
    {
        var services = await _sdProvider.GetServicesAsync();
        return services[_random.Next(services.Count)];
    }
}

其中IServiceDiscoveryProvider是上文介紹的Consule服務提供者者，定義如下：

public interface IServiceDiscoveryProvider
{
    Task<List<string>> GetServicesAsync();
}

而ILoadBalancer的定義如下：

public interface ILoadBalancer
{
    Task<string> GetServiceAsync();
}

輪詢均衡

再來看一下最簡單的輪詢實現：

public class RoundRobinLoadBalancer : ILoadBalancer
{
    private readonly IServiceDiscoveryProvider _sdProvider;

    public RoundRobinLoadBalancer(IServiceDiscoveryProvider sdProvider)
    {
        _sdProvider = sdProvider;
    }

    private readonly object _lock = new object();
    private int _index = 0;

    public async Task<string> GetServiceAsync()
    {
        var services = await _sdProvider.GetServicesAsync();
        lock (_lock)
        {
            if (_index >= services.Count)
            {
                _index = 0;
            }
            return services[_index++];
        }
    }
}

如上，使用lock控制併發，每次請求，移動一下服務索引。

最後，便可以直接使用HttpClient來完成服務的呼叫了：

var client = new HttpClient();
ILoadBalancer balancer = new RoundRobinLoadBalancer(new PollingConsulServiceProvider());

// 使用輪詢演算法呼叫
for (int i = 0; i < 10; i++)
{
    var service = await balancer.GetServiceAsync();
    Console.WriteLine(DateTime.Now.ToString() + "-RoundRobin:" +
        await client.GetStringAsync("http://" + service + "/api/values") + " --> " + "Request from " + service);
}

// 使用隨機演算法呼叫
balancer = new RandomLoadBalancer(new PollingConsulServiceProvider());
for (int i = 0; i < 10; i++)
{
    var service = await balancer.GetServiceAsync();
    Console.WriteLine(DateTime.Now.ToString() + "-Random:" +
        await client.GetStringAsync("http://" + service + "/api/values") + " --> " + "Request from " + service);
}

總結

本文從服務註冊，到服務發現，再到負載均衡，演示了一個最簡單的服務間呼叫的流程。看起來還不錯，但是還有一個很嚴重的問題，就是當我們獲取到服務列表時，服務都還是健康的，但是在我們發起請求中，服務突然掛了，這會導致呼叫端的異常。那麼能不能在某一個服務呼叫失敗時，自動切換到下一個服務進行呼叫呢？下一章就來介紹一下熔斷降級，完美的解決了服務呼叫失敗以及重試的問題。

附本文原始碼地址：https://github.com/RainingNight/AspNetCoreSample/tree/master/src/Microservice/ServiceDiscovery/ConsulDemo

參考資料

相關推薦

ASP.NET Core 微服務初探[1]：服務發現之Consul

原文: ASP.NET Core 微服務初探[1]：服務發現之Consul 在傳統單體架構中，由於應用動態性不強，不會頻繁的更新和釋出，也不會進行自動伸縮，我們通常將所有的服務地址都直接寫在專案的配置檔案中，發生變化時，手動改一下配置檔案，也不會覺得有什麼問題。但是在微服務模式下，服務會更細的拆分解耦，微服

ASP.NET Core中的快取[1]：如何在一個ASP.NET Core應用中使用快取

.NET Core針對快取提供了很好的支援 ，我們不僅可以選擇將資料快取在應用程序自身的記憶體中，還可以採用分散式的形式將快取資料儲存在一個“中心資料庫”中。對於分散式快取，.NET Core提供了針對Redis和SQL Server的原生支援。除了這個獨立的快取系統之外，ASP.NET Core還藉助一箇中

ASP.NET Core 微服務初探[2]：熔斷降級之Polly

當我們從單體架構遷移到微服務模式時，其中一個比較大的變化就是模組（業務，服務等）間的呼叫方式。在以前，一個業務流程的執行在一個程序中就完成了，但是在微服務模式下可能會分散到2到10個，甚至更多的機器（微服務）上，這必然就要使用網路進行通訊。而網路本身就是不可靠的，並隨著每個服務都根據自身的情況進行的動態擴容，

ASP.NET Core微服務 on K8S（Jessetalk）（第一章：詳解基本物件及服務發現）（持續更新）

課程連結：http://video.jessetalk.cn/course/explore 良心課程，大家一起來學習哈！ 任務1：課程介紹 任務2：Labels and Selectors 所有資源物件（包括Pod, Service, Namespace, Volume）都可以打

ASP.NET Core微服務+Tabler前端框架搭建個人框架1--開始前想說的話

docker 開源框架 個人博客 前後端 app asp.net 集成 cap mysq 　　寫在前面　　 　　本人為在讀研究生，特別喜歡.NET，覺得.NET的編程方式、語法都特別友好，學習.NET Core已經差不多有一年半了，從一開始不知道如何入門到現在終於可以編寫

【新書推薦】《ASP.NET Core微服務實戰：在雲環境中開發、測試和部署跨平臺服務》 帶你走近微服務開發

《ASP.NET Core 微服務實戰》譯者序：https://blog.jijiechen.com/post/aspnetcore-microservices-preface-by-translator/ “微服務”的概念在 2014 年正式提出之後，越來越多的團隊開始用它來設計自己

（7）學習筆記 ） ASP.NET CORE微服務 Micro-Service ---- 利用Polly+AOP+依賴註入封裝的降級框架

tostring methods summary bstr 判斷 KS foreach public tde 創建簡單的熔斷降級框架 要達到的目標是： 參與降級的方法參數要一樣，當HelloAsync執行出錯的時候執行HelloFallBackAsync方法。 pu

ASP.NET Core 網站發布到Linux服務器(轉)

asp.net list oot module func iis 春天 window comment 出處;ASP.NET Core 網站發布到Linux服務器 長期以來，使用.NET開發的應用只能運行在Windows平臺上面，而目前國內蓬勃發展的互聯網公司由於成本的考慮

Asp.net Core 微信公眾號開發系列

net 配置 splay targe www -- c-s mage cnblogs 參考：http://www.cnblogs.com/zskbll/p/4074855.html 一、微信公眾平臺操作流程 1、先到微信公眾平臺註冊賬號 2、登錄成功後找到開發-->開

asp.net core 微信支付工具類（H5支付，掃碼支付，公眾號支付，app支付）之2-H5支付

IV app支付 tno 方式 quest ces sys net ota 　　上一篇說到微信掃碼支付，今天來分享下微信H5支付，適用場景為手機端非微信瀏覽器調用微信H5支付驚醒網站支付業務處理。申請開通微信H5支付工作不多做介紹，直接上代碼。 　　首先是微信支付業務類（W

asp.net core mvc視頻A：筆記4.高級數據綁定

前端 ade .net .net core 高級 指定 測試 如果 視頻 默認的綁定順序，如果需要取指定數據源裏的數據，需要通過屬性控制，比如[FromQuery] 前端 控制器方法 前端 此時並不能得到head中的數據 改造控制器方

ASP.NET Core MVC 授權的擴充套件：自定義 Authorize Attribute 和 IApplicationModelProvide

一、概述 ASP.NET Core MVC 提供了基於角色( Role )、宣告( Chaim ) 和策略 ( Policy ) 等的授權方式。在實際應用中，可能採用部門（ Department ,

[文章彙總]ASP.NET Core框架揭祕[最近更新：2018/10/31]

之前一段時間都在個人公眾號賬號“大內老A”釋出關於ASP.NET Core的系列文章，很多人留言希望能夠同步到這裡，所以在這裡 對這些文章做一個彙總，以便於PC端閱讀。如果說微軟官方文件主要關於ASP.NET Core的程式設計模式的話，我這個系列則主要關注整個ASP.NET Core的設計思想和實現原理。我

ASP.NET core webapi RouteAttribute _平臺：windows (3)

ASP.NET core webapi RouteAttribute _平臺：windows (3) 簡版(後面還有囉嗦版本 點我進入囉嗦版本)： 問題： 1、介紹RouteAttribute特性。 這個東西其實很簡單：主要用處就是設定路由罷了 什麼？不懂路由是什麼？ 那麼你就理

Asp.Net Core輕量級Aop解決方案：AspectCore

什麼是AspectCore Project ? AspectCore Project 是適用於Asp.Net Core 平臺的輕量級 Aop(Aspect-oriented programming) 解決方案，它更好的遵循Asp.Net Core的模組化開發理念，使用AspectCore可以更容易構建低耦合、

.NET Core的檔案系統[1]：讀取並監控檔案的變化

ASP.NET Core 具有很多針對檔案讀取的應用。比如我們傾向於採用JSON檔案來定義配置，所以應用就會涉及針對配置檔案讀取。如果使用者傳送一個針對物理檔案的HTTP請求，應用會根據指定的路徑讀取目標檔案的內容並對請求予以響應。在一個ASP.NET Core MVC應用中，針對View的動態編譯會涉及到根

Asp.net core 學習筆記 2.1 升級到 2.2

contex basepath nbsp odata art esp apps ack 一個 首先跟著官網 step by step https://docs.microsoft.com/en-us/aspnet/core/migration/21-to-22?view=

ASP.NET Core 執行原理解剖[1]:Hosting

原文: ASP.NET Core 執行原理解剖[1]:Hosting ASP.NET Core 是新一代的 ASP.NET，第一次出現時代號為 ASP.NET vNext，後來命名為ASP.NET 5，隨著它的完善與成熟，最終命名為 ASP.NET Core，表明它不是 ASP.NET 的升級，而是一個重新

ASP.NET Core 認證與授權[1]:初識認證

在ASP.NET 4.X 中，我們最常用的是Forms認證，它既可以用於區域網環境，也可用於網際網路環境，有著非常廣泛的使用。但是它很難進行擴充套件，更無法與第三方認證整合，因此，在 ASP.NET Core 中對認證與授權進行了全新的設計，並使用基於宣告的認證(claims-based authentica

asp.net core 系列 3 依賴註入服務

生成 configure lan adf unity 現在 而不是 日誌輸出 face 一. 依賴註入概述 在軟件設計的通用原則中，SOLID是非常流行的縮略語，它由5個設計原則的首字母構成：單一原則(S)、開放封閉原則(O)、裏氏替換原則(L)、接口分離原則(I)、依賴