
在去年的.NET Core微服务系列文章中,初步学习了一下Consul服务发现,总结了两篇文章。本次基于Docker部署的方式,以一个Demo示例来搭建一个Consul的示例集群,最后给出一个HA的架构示范,也会更加贴近于实际应用环境。
一、示例整体架构

此示例会由一个API Gateway, 一个Consul Client以及三个Consul Server组成,有关Consul的Client和Server这两种模式的Agent的背景知识,请移步我之前的文章加以了解:《.NET Core微服务之基于Consul实现服务治理》。其中,Consul的Client和Server节点共同构成一个Data Center,而API Gateway则从Consul中获取到服务的IP和端口号,并返回给服务消费者。这里的API Gateway是基于Ocelot来实现的,它不是这里的重点,也就不过多说明了,不了解的朋友请移步我的另一篇:《.NET Core微服务之基于Ocelot实现API网关服务》。
二、Consul集群搭建
2.1 Consul镜像拉取
docker pull consul:1.4.4  验证:docker images
  
2.2 Consul Server实例创建
以下我的实践是在一台机器上(CentOS 7)操作的,因此将三个实例分别使用了不同的端口号(区别于默认端口号8500)。实际环境中,建议多台机器部署。
(1)Consul实例1
docker run -d -p 8510:8500 --restart=always 	
-v /XiLife/consul/data/server1:/consul/data 	
-v /XiLife/consul/conf/server1:/consul/config 	
-e CONSUL_BIND_INTERFACE='eth0' --privileged=true 	
--name=consul_server_1 consul:1.4.4 agent -server 	
-bootstrap-expect=3 -ui -node=consul_server_1 	
-client='0.0.0.0' 	
-data-dir /consul/data -config-dir /consul/config 	
-datacenter=xdp_dc;

(2)Consul实例2
为了让Consul实例2加入集群,首先获取一下Consul实例1的IP地址:
JOIN_IP="$(docker inspect -f '{{.NetworkSettings.IPAddress}}' consul_server_1)";
docker run -d -p 8520:8500 --restart=always 	
-v /XiLife/consul/data/server2:/consul/data 	
-v /XiLife/consul/conf/server2:/consul/config 	
-e CONSUL_BIND_INTERFACE='eth0' 	
--privileged=true 	
--name=consul_server_2 consul:1.4.4 agent -server -ui 	
-node=consul_server_2 -client='0.0.0.0' 	
-datacenter=xdp_dc 	
-data-dir /consul/data 	
-config-dir /consul/config 	
-join=$JOIN_IP;  (3)Consul实例3
docker run -d -p 8530:8500 --restart=always 	
-v /XiLife/consul/data/server3:/consul/data 	
-v /XiLife/consul/conf/server3:/consul/config 	
-e CONSUL_BIND_INTERFACE='eth0' --privileged=true 	
--name=consul_server_3 consul:1.4.4 agent -server -ui 	
-node=consul_server_3 -client='0.0.0.0' 	
-datacenter=xdp_dc 	
-data-dir /consul/data 	
-config-dir /consul/config 	
-join=$JOIN_IP;  验证1:docker exec consul_server_1 consul operator raft list-peers
  
验证2:http://192.168.16.170:8500/
  
2.3 Consul Client实例创建
(1)准备services.json配置文件,向Consul注册两个同样的Product API服务
    {	"services": [	{	"id": "core.product-/192.168.16.170:8000",	"name": "core.product",	"tags": [ "xdp-/core.product" ],	"address": "192.168.16.170",	"port": 8000,	"checks": [	{	"name": "core.product.check",	"http": "http://192.168.16.170:8000/api/health",	"interval": "10s",	"timeout": "5s"	}	]	},	{	"id": "core.product-/192.168.16.170:8001",	"name": "core.product",	"tags": [ "xdp-/core.product" ],	"address": "192.168.16.170",	"port": 8001,	"checks": [	{	"name": "core.product.check",	"http": "http://192.168.16.170:8001/api/health",	"interval": "10s",	"timeout": "5s"	}	]	}	]	}有关配置文件的细节,请移步另一篇文章:《.NET Core微服务之基于Consul实现服务治理(续)》
(2)Consul Client实例
docker run -d -p 8550:8500 --restart=always 	
-v /XiLife/consul/conf/client1:/consul/config 	
-e CONSUL_BIND_INTERFACE='eth0' 	
--name=consul_client_1 consul:1.4.4 agent -node=consul_client_1 	
-join=$JOIN_IP 	
-client='0.0.0.0' -datacenter=xdp_dc 	
-config-dir /consul/config  (3)验证
  
  
  
2.4 服务检查监控邮件提箱
(1)为Client添加watches.json
       {	"watches": [	{	"type": "checks",	"handler_type": "http",	"state": "critical",	"http_handler_config": {	"path": "http://192.168.16.170:6030/api/Notifications/consul",	"method": "POST",	"timeout": "10s",	"header": { "Authorization": [ "token" ] }	}	}	]	}*.这里的api接口 http://192.168.16.170:6030/api/Notifications/consul是我的一个通知服务发送Email的接口。
(2)验证
  
三、Ocelot网关配置
3.1 为Ocelot增加Consul支持
(1)增加Nuget包:Ocelot.Provider.Consul
Nuget>> Install-Package Ocelot.Provider.Consul
(2)修改StartUp.cs,增加Consul支持
s.AddOcelot()
.AddConsul();
更多内容,请移步:Ocelot官方文档-服务发现
3.2 修改Ocelot配置文件增加Consul配置
"GlobalConfiguration": {	"BaseUrl": "http://api.xique.com",	"ServiceDiscoveryProvider": {	"Host": "192.168.16.170",	"Port": 8550,	"Type": "Consul"	}	}*.这里指向的是Consul Client实例的地址
此外,Ocelot默认策略是每次请求都去Consul中获取服务地址列表,如果想要提高性能,也可以使用PollConsul的策略,即Ocelot自己维护一份列表,然后定期从Consul中获取刷新,就不再是每次请求都去Consul中拿一趟了。例如下面的配置,它告诉Ocelot每2秒钟去Consul中拿一次。
    "Type": "PollConsul",	"PollingInterval": 20003.3 Service配置
    // -- Service	{	"UseServiceDiscovery": true,	"DownstreamPathTemplate": "/api/{url}",	"DownstreamScheme": "http",	"ServiceName": "core.product",	"LoadBalancerOptions": {	"Type": "RoundRobin"	},	"UpstreamPathTemplate": "/product/{url}",	"UpstreamHttpMethod": [ "Get", "Post", "Put", "Delete" ]	}这里配置了在Consul中配置的服务名(ServiceName),以及告诉Ocelot我们使用轮询策略(RoundRobin)做负载均衡。
3.4 验证
第一次访问:
  
第二次访问:
  
四、HA示例整体架构
对于实际应用中,我们往往会考虑单点问题,因此会借助一些负载均衡技术来做高可用的架构,这里给出一个建议的HA示例的整体架构:

对于一个API请求,首先会经历一个Load Balancer才会到达API Gateway,这个Load Balancer可以是基于硬件的F5,也可以是基于软件的Nginx或LVS再搭配Keepalived,一般来说大部分团队都会选择Nginx。然后API Gateway通过部署多个,来解决单点问题,也达到负载均衡的效果。而对于API Gateway和Consul Client之间的连接,我们往往也会增加一个Load Balancer来实现服务发现的高可用,这个Load Balancer也一般会基于Nginx/LVS搭配Keepalived,API Gateway只需要访问一个Virtual IP即可。而在Consul Data Center中,Consul Server会选择3或5个,Consul Client也会部署多个,刚刚提到的Virtual IP则会指向多个Consul Client,从而防止了Consul Client的单点问题。
.NET社区新闻,深度好文,欢迎访问公众号文章汇总 http://www.csharpkit.com 