微服务说起来高大尚，实际撸一遍来试试看，用现在比较常用的微服务框架，Consul和Ocelote做一个Demo，一起来试试吧！
说在前面的话
准备好环境，拉取源代码，按照每个章节中的【实践操作】进行操作，即可搭建起来，已经测试通过。
不想把篇幅拉太长，且此文实践为主，如果对微服务没有理论基础，建议先阅读其他博主的微服务理论，再食用本文，效果更佳~
如有解释不当或错误的地方，欢迎各位大佬加以斧正！
之后要是有空，后续会容器化部署上云服务器，把部署过程剪一个视频出来。
环境准备（Windows版）
- Windows 系统
- 源代码：https://gitee.com/yi_zihao/micservice 或 Github https://github.com/OrzCoCo-Y/MicService.Net
- Consul安装包：https://www.consul.io/downloads
- Nginx： https://nginx.org/en/download.html
- Apipost 或者 PostMan
- Visual Studio 2019：Demo用的.Net Core 3.1，能跑起来就行
- （建议安装）控制台终端：https://docs.microsoft.com/zh-cn/windows/terminal/install
- 修改Hosts文件，单机跑Consul集群，解决Ocelot在请求下发时，出现识别不到主机错误，此错误的原因是服务实例和Consul在同一台电脑上时，Ocelot会将请求下发至对应的HostName , 在不同电脑上则返回服务所在电脑的 ipAddress.具体参考这位博主的分享：
https://www.cnblogs.com/citycomputing/p/12070909.html
Windows单体部署架构图
- 用户发送请求至网关地址，网关对此次请求做请求转发，转发的策略及配置规则在Ocelot项目中，指定一个configuration.json的配置文件，在宿主机创建IConfiguration时，将配置json文件作为键值对给Ocelot做配置使用
- 一开始，用户在授权中心获取Token
- 从ocelot源代码可以看到FileRoute定义了Ocelot的基本配置
- 上游的请求（upstream），在网关中，根据路由匹配规则（Routes），转发到下游地址（downstream）
- 下游地址便是服务地址，那网关如何知道将请求转发到哪个服务呢，这里便用上了Consul的服务注册与发现，当然不仅仅只集成Consul，Consul只是选择之一。
- 请求在经过网关时，使用了Polly的弹性故障处理框架，加了一层自定义缓存。
- 身份认证下放至服务实例，未在网关层加验证
以上便是简易的微服务Demo框架介绍，下边开始拉取项目实践吧！
服务注册与发现
启动并创建Consul集群
简单来说，各个业务服务实例注册在Consul这个平台的节点中，各个节点分享注册信息，一起组合成为一个集群。
每个节点分为客户端模式与服务端模式，其区别就是，服务端会存储各个节点的数据，客户端则所有注册到该节点的服务信息，都会转发至其他服务端节点，本身不存储这些信息。
也是由此原因，客户端模式的节点数量是不限制的，服务端模式节点则会控制数据
raft是一种选举的算法，用来实现微服务CAP中的分布式一致性，上图的Server模式带星的则为选举出来的Lead，可以自行了解一下
模拟动画，辅助理解raft：http://thesecretlivesofdata.com/raft/
Consul配置详解： https://www.cnblogs.com/sunsky303/p/9209024.html
实践操作
准备Consul配置文件，源代码根目录下已经上传
- 启动Consul有两种方式，比如纯命令行启动、按照配置文件启动
- 因为是单机部署，所以此处为：配置文件指定了每个Consul实例的端口，按照配置文件结合命令进行启动
// Windows 终端
-- 进入Consul解压目录
cd D:\Consul
-- 服务端模式
.\consul.exe agent -server -bootstrap-expect=3 -data-dir=d:\consultmp\data-dir1 -config-file=D:\Consul\config\8500.json -node=server1 -bind='127.0.0.1' -client='0.0.0.0' -ui
.\consul.exe agent -server -data-dir=d:\consultmp\data-dir2 -config-file=D:\Consul\config\9500.json -node=server2 -bind='127.0.0.1' -client='0.0.0.0' -join='127.0.0.1:8301' -ui
.\consul.exe agent -server -data-dir=d:\consultmp\data-dir3 -config-file=D:\Consul\config\10500.json -node=server3 -bind='127.0.0.1' -client='0.0.0.0' -join='127.0.0.1:8301' -ui
-- 客户端模式
.\consul.exe agent -data-dir=d:\consultmp\data-dir4 -config-file=D:\Consul\config\11500.json -node=client1 -bind='127.0.0.1' -join='127.0.0.1:8301' -client='0.0.0.0' -ui
下载Consul应用程序之后，存放在指定文件夹，分别启动服务端模式和客户端模式的节点，组成Consul集群
启动集群之后可以分别打开
127.0.0.1:8500 127.0.0.1:9500 127.0.0.1:10500 127.0.0.1:11500
可以看到Consul的自带的ui界面，启动命令中的 -ui开启此界面
至此，Consul集群搭建完成，接下来用Nginx为集群做请求负载均衡。
Nginx使用如下配置
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
upstream ConsulNginx {
server localhost:8500;
server localhost:9500;
server localhost:10500;
server localhost:11500;
}
server {
listen 8080;
server_name localhost;
location / {
proxy_pass http://ConsulNginx;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
}
进入Nginx安装目录，使用start nginx命令
Nginx启动成功，则进入http://localhost:8080/即可看到Consul的UI界面
业务服务启动与注册到Consul
准备一个业务服务程序，实际开发中可以为商品服务，订单服务，支付服务等等，服务中在调用Consul提供的方法注册在其节点中之后，业务服务需要抛出一个简易的可以返回当前状态的接口，用作健康检查。
此Demo使用一个简易的用户服务做演示，其中包含了受保护的资源、可匿名访问的资源，健康检查则是一个打印当前日期的接口。
实践操作
服务实例注册到Consul节点中，Appsettings.json文件中的ConsulAddress对应注册到某个Consul节点
// 启动webapi
-- Windows 终端
-- 进入指定文件夹,自行修改文件路径，生成路径
cd D:\Study\micservice-master\MicServiceDemo\MicServiceWebApi\bin\Debug\netcoreapp3.1
-- 微服务Api，可以是用户服务，产品服务等待
dotnet MicServiceWebApi.dll --urls="http://*:44380" --ip="127.0.0.1" --port=44380
dotnet MicServiceWebApi.dll --urls="http://*:44381" --ip="127.0.0.1" --port=44381
dotnet MicServiceWebApi.dll --urls="http://*:44382" --ip="127.0.0.1" --port=44382
dotnet MicServiceWebApi.dll --urls="http://*:44383" --ip="127.0.0.1" --port=44383
注册至服务Conul节点，当然可以直接用ConsulNginx 8080端口进行注册，此处是为了注册至每个节点而这样处理
在此，启动了四个服务实例：
127.0.0.1:44380 127.0.0.1:44381 127.0.0.2:44382 127.0.0.2:44383
分别注册在4个consul节点之中
http://127.0.0.1:8500 http://127.0.0.1:9500 http://127.0.0.1:10500 http://127.0.0.1:11500
试着请求 127.0.0.1:44380/api/user/getall 请求保护资源，因为未授权则会是401无权限错误，这里需要授权中心拿到accesstoken才可以获取到结果，Token的获取在下一节便能知道。
接着尝试请求127.0.0.1:44381/api/user/getallwithnoverify 请求匿名接口，则可以拿到mock的数据。
授权中心
目前为止，此时还只是注册了服务，获取数据还是请求的业务服务暴露出来的地址与端口，这显然还不算微服务，也不安全，现在先把授权中心启动，待万事具备，再网关启动则可以跑通整个链路。
当然为了安全，服务实例部署到云服务器，会将44380这些端口用防火墙给墙柱，不让外部直接访问，只留下网关端口地址即可
Ids4授权中心
Identity Server 4 中有多种授权模式，常见的密码模式、客户端模式用的比较多，这里使用简单的客户端模式，他们都是基于Oauth2.0协议，可自行了解，这里不展开，使用起来还是很容易理解。
AuthenticationCenter项目，Startup中启用的授权中心services.AddIdentityServer，就是核心的一些配置和参数，他们决定了授权服务保护了哪些API作用域，决定了哪些客户端可以使用这个授权服务。
这里指定了一个客户端的Id与密码，以及授权访问的域
StartUp.cs授权下方的【测试访问受保护资源】，则是在授权中心这个项目中做了一个测试，用于测试授权访问是否成功，例如：
Home/Index 设为[Authorize] 需要授权才能访问
Home/Allow 设为[AllowAnonymous] 匿名访问
实践操作
// 启动授权中心
-- 进入生成目录
cd G:\Study\Git\micservice\MicServiceDemo\AuthenticationCenter\bin\Debug\netcoreapp3.1\
-- 启动授权中心
dotnet AuthenticationCenter.dll --urls="http://*:7000" --ip="127.0.0.1" --port=7000
验证授权中心是否生效，此时预留测试接口派上用场
1.从授权中心获取token,http://localhost:7000/connect/token
- 直接访问受保护的资源，必定401无权访问，将获取的token放置请求头中，即可通过授权
授权中心，便启动测试成功了，以上的测试是一个极简的OAuth2.0流程，授权中心拿Token去访问受保护资源
网关启动
现在服务注册准备好了，多个业务服务也注册在Consul的各个节点之中，授权中心也是启动可授权状态，现在便开始Ocelot网关的启动
Ocelot
在上文中一起看过源码，了解到ocelot集成了包括路由、请求聚合、服务发现、认证鉴权、限流、负载均衡等功能。而这些功能都可以直接通过修改json配置文件即可使用
//*****************************超时+限流+熔断+降级+Consul+Polly********************************
{
"Routes": [
{
//转发到下游服务地址--url变量
"DownstreamPathTemplate": "/api/{url}", // 服务地址--url变量
//下游http协议
"DownstreamScheme": "http",
//负载方式，
"LoadBalancerOptions": {
"Type": "RoundRobin" // RoundRobin 轮询 LeastConnection-最少连接数的服务器 NoLoadBalance不负载均衡
},
//上游地址
"UpstreamPathTemplate": "/gateway/{url}", // 网关地址--url变量 // 冲突的还可以加权重Priority
"UpstreamHttpMethod": [ "Get", "Post", "DELETE", "PUT" ],
// 使用服务发现
"UseServiceDiscovery": true,
"ServiceName": "MicServiceDemo", //consul服务名称
// 限流设置， polly
"RateLimitOptions": {
"ClientWhitelist": [ "admin" ], //白名单 请求头ClientId 区分大小写
"EnableRateLimiting": true,
"Period": "5m", //1s, 5m, 1h, 1d
"PeriodTimespan": 30, //多少秒之后客户端可以重试
"Limit": 5 //统计时间段内允许的最大请求数量
},
// 熔断设置,熔断器使用Polly
//"QoSOptions": {
// "ExceptionsAllowedBeforeBreaking": 3, //允许多少个异常请求
// "DurationOfBreak": 10000, // 熔断的时间，单位为ms
// "TimeoutValue": 2000 //单位ms 如果下游请求的处理时间超过多少则自如将请求设置为超时 默认90秒
//}
// 鉴权
//"AuthenticationOptions": {
// "AuthenticationProviderKey": "UserGatewayKey", // 指定一个key,startUp中使用
// "AllowedScopes": [ "gatewayScope" ]
//},
// 文件缓存
"FileCacheOptions": {
"TtlSeconds": 15,
"Region": "UserCache" //可以调用Api清理
}
}
],
"GlobalConfiguration": {
"ServiceDiscoveryProvider": {
"Host": "localhost", // Consul 集群地址
"Port": 8080, // Consul Nginx负载均衡 端口
// "Port": 8500. // Consul 节点端口
// 由Consul提供服务发现
"Type": "Consul"
},
// 限流选项
"RateLimitOptions": {
"QuotaExceededMessage": "请求太频繁，触发限流 ", // 当请求过载被截断时返回的消息
"HttpStatusCode": 666 // 当请求过载被截断时返回的http status
//"ClientIdHeader": "client_id" // 用来识别客户端的请求头，默认是 ClientId
}
}
}
在此配置下，可以大致了解，请求经过网关时，Ocelot所做的一些处理
- 上游当请求至网关，符合
UpstreamPathTemplate节点所设置的模板“/gateway/{url}”，则将请求下发至下游的DownstreamPathTemplate："/api/{url}" - 服务的提供者则为
GlobalConfiguration.ServiceDiscoveryProvider，包含Consul的地址与端口,服务名称为"ServiceName": "MicServiceDemo" - 判断该请求是否触发polly的限流策略，在此配置中
RateLimitOptions和GlobalConfiguration.RateLimitOptions的策略为：5分钟之内，至多请求5次，第6次开始HTTP状态码为666，返回的信息为“请求太频繁，触发限流”，30秒冷却期，请求头中加入 ClientId=admin，则为白名单可不受限流策略影响 - 授权策略在这里注释了，认证授权在服务层做，而不再网关层，如果想要在网关进行授权认证，取消注释即可
实践操作
-- 进入生成目录
cd D:\Study\Git\micservice\MicServiceDemo\OcelotGateway\bin\Debug\netcoreapp3.1\
-- Windows 终端
dotnet OcelotGateway.dll --urls="http://*:6297" --ip="127.0.0.1" --port=6297
dotnet OcelotGateway.dll --urls="http://*:6298" --ip="127.0.0.1" --port=6298
dotnet OcelotGateway.dll --urls="http://*:6299" --ip="127.0.0.1" --port=6299
为了容错及高可用， 启动三个 网关实例。
此时可以用 http://localhost:6297/gateway/user/getallwithnoverify测试链路是否通了
http://localhost:6297/gateway/user/getallwithnoverify符合网关下发请求的规则，则在服务注册中心(NginxForConsul:localhost:8080)取一个节点（此处随机到节点client1）- 将请求下发至
http://client1:44380/api/user/getallwithnoverify - 因为修改了Host文件,client1映射为127.0.0.1，故请求转发的真实地址为
http://127.0.0.1:44380/api/user/getallwithnoverify
至此网关的集群搭建已完成，与Consul集群一样，这里再用Nginx做一层针对于Ocelot网关的负载均衡
NginxForOcelot 使用如下配置
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
upstream OcelotNginx {
server localhost:6297;
server localhost:6298;
server localhost:6299;
}
server {
listen 9090;
server_name localhost;
location / {
proxy_pass http://OcelotNginx;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
}
进入Nginx安装目录，使用start nginx命令
启动Nginx之后，则可在上文的基础上再做一次负载均衡。
尝试请求 http://127.0.0.1:9090/gateway/user/getallwithnoverify，则会自动选择Ocelot集群中的某一个网关进行请求下发
OK，至此整个微服务架构就搭建完了，下面进行测试
测试负载均衡
多次请求网关获取数据，返回的apiDomain不尽相同，则负载均衡完成
当然可以查看Ocelot网关的控制台，是将请求转发至哪个网关，及其网关下的Consul节点
测试授权访问
直接访问http://localhost:9090/gateway/User/GetAll是为401未授权错误。
在授权中心获取Token之后，ApiPost中填入认证Token，即可获取到受保护接口提供的数据
测试限流
快速请求多次，触发限流
总结
这次的微服务搭建，只在单机环境下，做的负载均衡都是伪负载均衡，没有整虚拟机和多个服务器上去部署，确实是一个遗憾，但是涉及的方面比较多还是有很多的学习价值，Consul和Ocelot这一套算是很常见的.net 微服务框架了，之后也可以试试其他框架。
往后，准备给目前这一套架构舔砖加瓦，比如分布式配置中心Apollo，分布式系统的应用程序性能监视工具 skywalking等等.....
最后再贴一下架构图
总结一下部署的流程
- 启动Consul集群
- 为Consul集群添加Nginx 负载均衡
- 启动服务实例，并且注册至Consul
- 启动Ids4授权中心
- 启动Ocelot网关集群
- 为网关集群添加Nginx 负载均衡
源代码
【Gitee】源代码 https://gitee.com/yi_zihao/micservice
【GitHub】源代码 https://github.com/OrzCoCo-Y/MicService.Net.git
参考资料
【博客园-可均可可】微服务简介与技术栈 https://www.cnblogs.com/PatrickLiu/p/13925259.html
【博客园-sunsky303】consul配置参数大全、详解、总结 https://www.cnblogs.com/sunsky303/p/9209024.html
【博客园-神游虚空】Ocelot 发现服务总是失败的解决办法 https://www.cnblogs.com/citycomputing/p/12070909.html
【raft】 http://thesecretlivesofdata.com/raft/