.NET Core微服务之基于Consul实现服务治理

一、Consul基础介绍

  Consul是HashiCorp公司推出的开源工具,用于实现分布式系统的服务发现与配置。与其他分布式服务注册与发现的方案,比如 Airbnb的SmartStack等相比,Consul的方案更“一站式”,内置了服务注册与发现框 架、分布一致性协议实现、健康检查、Key/Value存储、多数据中心方案,不再需要依赖其他工具(比如ZooKeeper等),使用起来也较 为简单。

  Consul用Golang实现,因此具有天然可移植性(支持Linux、windows和Mac OS X);安装包仅包含一个可执行文件,方便部署,与Docker等轻量级容器可无缝配合

  关于Consul的更多介绍,比如优点,这里就不再赘述了,上网一搜就可以随处找到了。但是,必须贴一个和其他类似软件的对比:

  此外,关于Consul的架构以及相关的角色,如下图所示:

  要想利用Consul提供的服务实现服务的注册与发现,我们需要建立Consul Cluster。在Consul方案中,每个提供服务的节点上都要部署和运行Consul的Client Agent,所有运行Consul Agent节点的集合构成Consul Cluster。Consul Agent有两种运行模式:ServerClient。这里的Server和Client只是Consul集群层面的区分,与搭建在Cluster之上的应用服务无关。以Server模式运行的Consul Agent节点用于维护Consul集群的状态,官方建议每个Consul Cluster至少有3个或以上的运行在Server Mode的Agent,Client节点不限。

  Consul支持多数据中心,每个数据中心的Consul Cluster都会在运行于Server模式下的Agent节点中选出一个Leader节点,这个选举过程通过Consul实现的raft协议保证,多个 Server节点上的Consul数据信息是强一致的。处于Client Mode的Consul Agent节点比较简单,无状态,仅仅负责将请求转发给Server Agent节点。

二、Consul集群搭建

2.1 环境准备

  这里我准备了三台Linux(CentOS)虚拟机和一台Windows Server 2008 R2虚拟机,借助VMware Workstation搭建,如下图所示。

  其中,192.168.80.100会作为leader角色,其余两台192.168.80.101和192.168.80.102会作为follower角色。当然,实际环境中leader角色不会是一个固定的,会随着环境的变化(比如Leader宕机或失联)由算法选出新的leader。在进行下面的操作会前,请确保三台节点能够相互ping通,并能够和宿主机也ping通。另外,192.168.80.71会作为client角色,并且和其余三台虚拟机互相ping通。

2.2 下载Consul

  Consul的下载很简单,直接去:https://www.consul.io/downloads.html 选择对应的平台即可。

  这里我们的linux虚拟机选择的是Linux版本:

  

  下载之后是一个zip文件,我们通过XFtp等工具将其传送到我们的linux节点中即可。

  而Windows Server虚拟机选择的是Windows版本,不再赘述。

2.3 安装与配置Consul

  1.解压Consul.zip:

  分别在三台节点中解压,解压命令:

> unzip consul_1.1.0_linux_386.zip  

  解压之后将consul复制到我们的自定义文件目录中,比如:/usr/local/consul

> cp consul /usr/local/consul

  2.设置环境变量

  分别在三台节点中设置环境变量:

> vim /etc/profile  

  在profile中增加一行CONSUL_HOME并更改PATH:

# Consul

export CONSUL_HOME=/usr/local/consul

export PATH=$PATH:$JAVA_HOME/bin:$CONSUL_HOME;  

  使得配置生效

> source /etc/profile

  测试是否生效,在三个节点测试输入consul

> consul

  看到下图所示的命令提示,就代表OK了。

  

  3.启动Server(s)

  分别在三台节点上执行以下命令即可启动Consul

192.168.80.100>consul agent -server -ui -bootstrap-expect=3 -data-dir=/tmp/consul -node=consul-1 -client=0.0.0.0 -bind=192.168.80.100 -datacenter=dc1

192.168.80.101>consul agent -server -ui -bootstrap-expect=3 -data-dir=/tmp/consul -node=consul-2 -client=0.0.0.0 -bind=192.168.80.101 -datacenter=dc1 -join 192.168.80.100

192.168.80.102>consul agent -server -ui -bootstrap-expect=3 -data-dir=/tmp/consul -node=consul-3 -client=0.0.0.0 -bind=192.168.80.102 -datacenter=dc1 -join 192.168.80.100

  注意101和102的启动命令中,有一句 -join 192.168.80.100 => 有了这一句,就把101和102加入到了100所在的集群中。

  启动之后,集群就开始了Vote(投票选Leader)的过程,通过下面的命令可以看到集群的情况:

  

  在Windows Server虚拟机上启动:

> consul agent -bind 0.0.0.0 -client 192.168.80.71 -data-dir=C:\Counsul\tempdata -node EDC.DEV.WebServer -join 192.168.80.100

  启动后会有如下提示:

  

  4.通过UI查看集群

  Consul不仅提供了丰富的命令查看集群情况,还提供了一个WebUI,默认端口8500,我们可以通过访问这个URL(eg.http://192.168.80.100:8500)得到如下图所示的WebUI:

  可以看到三个节点都正常启动,下面我们就来试试向Consul注册一下我们基于ASP.NET Core的WebAPI服务。

  5.模拟Leader挂掉,查看Consul集群的新选举Leader

  这里我暴力一点直接将Leader节点关机:shutdown -h now,可以看到我们的80.100已经挂了。

  

  查看其余两个节点的日志可以发现,consul-3 (80.102)被选为了新的leader:

  

  当然,也可以通过80.101或102的WebUI查看:

  也可以通过以下命令查看目前的各个Server的角色状态:

> consul operator raft list-peers

  

  虽然这里80.100这个原leader节点挂掉了,但是只要超过一半的Server(这里是2/3还活着)还活着,集群是可以正常工作的,这也是为什么像Consul、ZooKeeper这样的分布式管理组件推荐我们使用3个或5个节点来部署的原因。

三、ASP.NET Core WebAPI服务注册

3.1 准备一个ASP.NET Core WebAPI程序

  Step1.创建一个ASP.NET Core WebAPI程序

  

  Step2.创建一个HealthController用于Consul的健康检查

    [Produces("application/json")]
    [Route("api/Health")]    public class HealthController : Controller
    {
        [HttpGet]        public IActionResult Get() => Ok("ok");
    }

  *.Consul会通过call这个API来确认Service的健康状态

  Step3.改写启动代码,调用Consul API注册服务

  (1)通过Nuget安装Consul的.NET客户端

PM> install-package Consul

  (2)基于IApplicationBuilder写一个扩展方法,用于调用Consul API

    public static class AppBuilderExtensions
    {        public static IApplicationBuilder RegisterConsul(this IApplicationBuilder app, IApplicationLifetime lifetime, ServiceEntity serviceEntity)
        {            var consulClient = new ConsulClient(x => x.Address = new Uri($"http://{serviceEntity.ConsulIP}:{serviceEntity.ConsulPort}"));//请求注册的 Consul 地址
            var httpCheck = new AgentServiceCheck()
            {
                DeregisterCriticalServiceAfter = TimeSpan.FromSeconds(5),//服务启动多久后注册
                Interval = TimeSpan.FromSeconds(10),//健康检查时间间隔,或者称为心跳间隔
                HTTP = $"http://{serviceEntity.IP}:{serviceEntity.Port}/api/health",//健康检查地址
                Timeout = TimeSpan.FromSeconds(5)
            };            // Register service with consul
            var registration = new AgentServiceRegistration()
            {
                Checks = new[] { httpCheck },
                ID = Guid.NewGuid().ToString(),
                Name = serviceEntity.ServiceName,
                Address = serviceEntity.IP,
                Port = serviceEntity.Port,
                Tags = new[] { $"urlprefix-/{serviceEntity.ServiceName}" }//添加 urlprefix-/servicename 格式的 tag 标签,以便 Fabio 识别            };

            consulClient.Agent.ServiceRegister(registration).Wait();//服务启动时注册,内部实现其实就是使用 Consul API 进行注册(HttpClient发起)
            lifetime.ApplicationStopping.Register(() =>
            {
                consulClient.Agent.ServiceDeregister(registration.ID).Wait();//服务停止时取消注册            });            return app;
        }

  *.这里主要是参考的田园的蟋蟀的Code,链接见参考资料部分

  (3)在Starup类的Configure方法中,调用此扩展方法

        // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
        public void Configure(IApplicationBuilder app, IHostingEnvironment env, IApplicationLifetime lifetime)
        {            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }

            app.UseMvc();            // register this service
            ServiceEntity serviceEntity = new ServiceEntity
            {
                IP = NetworkHelper.LocalIPAddress,
                Port = Convert.ToInt32(Configuration["Service:Port"]),
                ServiceName = Configuration["Service:Name"],
                ConsulIP = Configuration["Consul:IP"],
                ConsulPort = Convert.ToInt32(Configuration["Consul:Port"])
            };
            app.RegisterConsul(lifetime, serviceEntity);
        }

  其中ServiceEntity类定义如下:

 

  其中用到了appSettings.json配置文件,其定义如下:

 

  *.这段代码不再解释,一眼就能看懂。另外,除了调用Consul API之外,还可以通过配置文件的方式,例如以下配置文件格式,这里不再演示。

 

  Step4.保留默认创建的ValuesController,其余不再创建任何API,不是本次实验的重点。当然,你可以集成一下Swagger,这样有个界面文档可以看。

  这里我默认跳转到healthcontroller:

  

3.2 发布到IIS

  Step1.在.NET Core程序中进行发布很简单,既可以采用原来在VS里边创建配置文件进行发布,也可以使用命令行(例如:dotnet publish),这里我还是在VS里面发布,得到Release文件

  Step2.通过Ftp工具copy到Windows Server虚拟机中

  Step3.这里我的Windows Server虚拟机是2008 R2,需要装一个Windows Server Hosting,下载地址:点我点我。如果不安装这个,你的IIS是跑不起来.NET Core程序的。

  Step4.按照你熟悉的方式在IIS中添加一个网站(服务):

  

  Step5.更改默认应用程序池的.net framework版本为“无托管代码”。

  

  Step6.照理说,到这里就OK了,点击浏览访问,TMD,给我报了个502.5的错误

  

  于是乎网上一阵搜索,发现需要打个补丁(Windows6.1-KB2533623-x64.msu),下载地址:点我点我

  Step7.安装补丁之后,重启IIS,可以成功访问了=>确保Consul能够call到我们的服务的health API。

3.3 查看Consul集群状态

  Step1.访问Consul的WebUI查看服务是否注册成功:可以看到我们的ClientService已成功注册

  Step2.Consul不仅仅提供了服务注册,还提供了服务发现,我们可以通过调用其提供的API来发现服务的IP和Port。

Url>http://192.168.80.100:8500/v1/catalog/service/CAS.NB.ClientService  

  *.我们可以看到返回了ClientService的ServiceAddress和ServicePort,就可以通过其组成URL进行服务调用了。当然,我们可能会对一个服务部署多个实例,以组成集群来实现负载均衡。我们可以设置一些负载均衡的策略,假设通过取模运算随机选择一个服务地址返回给服务消费者

  Step3.这里我们将发布的Release文件在Windows Server虚拟机上copy一份,并改一下配置文件,让其ServiceName变为CAS.NB.ProductService,其Port变为8820,在IIS上再添加一个网站,启动起来,再通过WebUI查看Consul集群状态:

  Step4.这时我们再通过以下API进行服务发现:

Url>http://192.168.80.100:8500/v1/catalog/service/CAS.NB.ProductService

  

四、小结与后续工作

  本篇主要基于一个最小化的集群搭建了一个Consul服务治理组件,并将ASP.NET Core API程序注册到了Consul,并尝试通过Consul进行服务发现(虽然没有模拟具体的服务消费)。本篇没有仔细讲述Consul的介绍、优点、缺点,因为本人也没有啥实际的经验,因此只能是站在其他园友的肩膀上做个小实验。ASP.NET Core是一个天生适合微服务的技术,也希望能在我们的学习和推动下,让公司把.NET Core应用起来,将来能够跑在Linux和Docker上,这是我目前的目标,与大家共勉。

  后续我会继续尝试基于Ocelot构建API网关,到时会结合Consul进行进一步的集成。另外,还会尝试Polly进行熔断降级、Identity Server进行验证,Exceptionless作分布式日志,基本上会遵循.NET Core大队长张善友的微服务示例项目NanoFabric用到的(或者说是给我们安利的技术框架)那些开源技术来搭建一个初步的微服务架构,以便于以后在公司内部推广和应用。此外,考虑到公司目前的微服务架构是基于Java的(Spring Cloud),那么也会考虑通过 Steeltoe 来和Spring Cloud进行兼容,让Java和.Net Core微服务能够共存(可以参考资料里的第7个,田园里的蟋蟀出品)。这里,也安利一下正在学习微服务的.NET Coder们,可以看看张善友老师的NanoFabric,或者是杨中科老师的.NET Core微服务课程。

  

  最近很多朋友问我为什么不再写技术文了,老是写一些观后感、读后感之类的,一来因为读那些书其实也是我今年的个人OKR,二来这半年来的确不想看技术书和资料,最后因为身体原因没法过多地熬夜。现在学习.NET Core以来被其深深吸引,就像是找到了一个那些年我们追过的女孩儿,觉得它样样都美,很想跟它继续走下去,发现它更多的美,因此也会趁着微服务学习的劲跟大家分享更多的文章。

  

附件下载

  示例代码:点我下载

参考资料

(1)田园里的蟋蟀,《Docker & Consul & Fabio & ASP.NET Core 2.0 微服务跨平台实践

(2)不小下,《服务发现 - consul 的介绍、部署和使用

(3)二胡槽子,《我是服务的执政官-服务发现和注册工具consul简介

(4)大副,《consul分布式集群搭建&简单功能测试&故障恢复

(5)94cool,《win2008server R2 x64 部署.net core到IIS

(6)杨中科《.NET Core微服务课件》

(7)田园里的蟋蟀,《.NET Core 微服务架构 Steeltoe 使用(基于 Spring Cloud)

原文地址:http://blog.51cto.com/6081921/2140664

时间: 2024-11-04 09:21:16

.NET Core微服务之基于Consul实现服务治理的相关文章

.NET Core微服务之基于Consul实现服务治理(续)

上一篇发布之后,这一篇把上一篇没有弄到的东西补一下,也算是给各位前来询问的朋友的一些回复吧. 一.Consul服务注册之配置文件方式 1.1 重温Consul实验集群 这里我们有三个Consul Server节点,一个Consul Client节点,在Client节点上跑了两个ClientService实例,分别占用8810和8820端口.至于基于Ocelot的API网关服务,还没有实现,留到以后跟各位分享.这里假设我们已经启动了这几个节点,并且能够成功访问这两个ClientService实例(

基于consul的服务注册(含踩坑过程)

在本地的一个案例中进行修改 修改微服务的相关pom文件修改每个微服务的pom文件,添加SpringCloud提供的基于Consul的依赖 <!--SpringCloud提供的基于Consul的服务发现--> <dependency>       <groupId>org.springframework.cloud</groupId>       <artifactId>spring-cloud-starter-consul-discovery&l

简单RPC框架-基于Consul的服务注册与发现

*:first-child { margin-top: 0 !important; } body>*:last-child { margin-bottom: 0 !important; } /* BLOCKS =============================================================================*/ p, blockquote, ul, ol, dl, table, pre { margin: 15px 0; } /* HEAD

基于 Consul 实现 MagicOnion(GRpc) 服务注册与发现

0.简介 0.1 什么是 Consul Consul是HashiCorp公司推出的开源工具,用于实现分布式系统的服务发现与配置. 这里所谓的服务,不仅仅包括常用的 Api 这些服务,也包括软件开发过程当中所需要的诸如 Rpc.Redis.Mysql 等需要调用的资源. 简而言之 Consul 就是根据 Key/Value 存储了一套所有服务的 IP/Port 集合,当你 Grpc 客户端需要请求某种服务的时候,具体的 IP 与端口不需要你自己来进行指定,而是通过与 Consul Agent 通信

Consul实现服务治理

.NET Core微服务之基于Consul实现服务治理 https://www.cnblogs.com/edisonchou/p/9124985.html 一.Consul基础介绍 Consul是HashiCorp公司推出的开源工具,用于实现分布式系统的服务发现与配置.与其他分布式服务注册与发现的方案,比如 Airbnb的SmartStack等相比,Consul的方案更"一站式",内置了服务注册与发现框 架.分布一致性协议实现.健康检查.Key/Value存储.多数据中心方案,不再需要

Consul实现服务治理1

NET Core微服务之基于Consul实现服务治理 https://www.cnblogs.com/edisonchou/p/9148034.html 一.Consul服务注册之配置文件方式 1.1 重温Consul实验集群 这里我们有三个Consul Server节点,一个Consul Client节点,在Client节点上跑了两个ClientService实例,分别占用8810和8820端口.至于基于Ocelot的API网关服务,还没有实现,留到以后跟各位分享.这里假设我们已经启动了这几个

.NET Core微服务系列基础文章

今年从原来的Team里面被抽出来加入了新的Team,开始做Java微服务的开发工作,接触了Spring Boot, Spring Cloud等技术栈,对微服务这种架构有了一个感性的认识.虽然只做了两个月的开发工作,但是对微服务架构的兴趣却没有结束,又因为自己的.NET背景(虽然对.NET的生态有点恨铁不成钢),想要探索一下在.NET平台下的微服务架构的可行性,也准备一些材料作为分享的素材. 幸运的是,在.NET Core首届在线峰会上,看到了很多前辈的分享,也增强了自己要摸索和实践.NET Co

个推基于Consul的配置管理

作者:个推应用平台基础架构高级研发工程师 阿飞在微服务架构体系中,由于微服务众多,服务之间又有互相调用关系,因此,一个通用的分布式配置管理是必不可少的.一般来说,配置管理需要解决配置集中管理.在系统运行期间可实现动态配置.配置修改后支持自动刷新等问题.在大多数微服务体系中,都会有一个名为配置文件的功能模块来提供统一的分布式配置管理.构建配置中心,统一对应用中各个微服务进行管理,对微服务体系的意义重大. Consul为什么适合做配置管理 Consul作为轻量级的分布式K/V存储系统,搭建方便,可用

.NET Core微服务之基于Ocelot实现API网关服务(续)

一.负载均衡与请求缓存 1.1 负载均衡 为了验证负载均衡,这里我们配置了两个Consul Client节点,其中ClientService分别部署于这两个节点内(192.168.80.70与192.168.80.71). 为了更好的展示API Repsonse来自哪个节点,我们更改一下返回值: [Route("api/[controller]")] public class ValuesController : Controller { // GET api/values [Http