| 编辑推荐: |
| 本文来自于博客园，本篇主要基于一个最小化的集群搭建了一个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的agent，所有运行Consul
Agent节点的集合构成Consul Cluster。Consul Agent有两种运行模式：Server和Client。这里的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.设置环境变量
分别在三台节点中设置环境变量：
在profile中增加一行CONSUL_HOME并更改PATH：
| #
Consul
export CONSUL_HOME=/usr/local/consul
export PATH=$PATH:$JAVA_HOME/bin:$CONSUL_HOME; |
使得配置生效
测试是否生效，在三个节点测试输入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类定义如下：
|
public class ServiceEntity
{
public string IP { get; set; }
public int Port { get; set; }
public string ServiceName { get; set; }
public string ConsulIP { get; set; }
public int ConsulPort { get; set; }
} |
其中用到了appSettings.json配置文件，其定义如下：
| {
"Service": {
"Name": "CAS.NB.ClientService",
"Port": "8810"
},
"Consul": {
"IP": "192.168.80.101",
"Port": "8500"
},
"Logging": {
"IncludeScopes": false,
"Debug": {
"LogLevel": {
"Default": "Warning"
}
},
"Console": {
"LogLevel": {
"Default": "Warning"
}
}
}
} |
*.这段代码不再解释，一眼就能看懂。另外，除了调用Consul API之外，还可以通过配置文件的方式，例如以下配置文件格式，这里不再演示。
| {
"service": {
"name": "hwapp_web",
"tags": ["master"],
"address": "10.9.10.173",
"port": 5000,
"checks": [
{
"http": "http://10.9.10.173:5000/health",
"interval": "10s"
}
]
}
} |
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是一个天生适合微服务的技术，也希望能在我们的学习和推动下，让公司把.NET Core应用起来，将来能够跑在Linux和Docker上，这是我目前的目标，与大家共勉。
后续我会继续尝试基于Ocelot构建API网关，到时会结合Consul进行进一步的集成。另外，还会尝试Polly进行熔断降级、Identity
Server进行验证，Exceptionless作分布式日志，基本上会遵循.NET Core大队长张善友的微服务示例项目NanoFabric用到的（或者说是给我们安利的技术框架）那些开源技术来搭建一个初步的微服务架构，以便于以后在公司内部推广和应用。此外，考虑到公司目前的微服务架构是基于Java的（Spring
Cloud），那么也会考虑通过 Steeltoe 来和Spring Cloud进行兼容，让Java和.Net
Core微服务能够共存。
|
