网络打印机怎么设置ip(网络打印机怎么设置共享)
↓推荐关注↓
前言
微服务说起来高大尚,实际撸一遍来试试看,用现在比较常用的微服务框架,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
Windows 单体部署架构
用户发送请求至网关地址,网关对此次请求做请求转发,转发的策略及配置规则在 Ocelot 项目中,指定一个 configuration.json 的配置文件,在宿主机创建 IConfiguration 时,将配置 json 文件作为键值对给 Ocelot 做配置使用
一开始,用户在授权中心获取 Token
从 ocelot 源代码可以看到 FileRoute 定义了 Ocelot 的基本配置
上游的请求(upstream),在网关中,根据路由匹配规则(Routes),转发到下游地址(downstream)
下游地址便是服务地址,那网关如何知道将请求转发到哪个服务呢,这里便用上了 Consul 的服务注册与发现,当然不仅仅只集成 Consul,Consul 只是选择之一。
请求在经过网关时,使用了 Polly 的弹性故障处理框架,加了一层自定义缓存。
身份认证下放至服务实例,未在网关层加验证 以上便是简易的微服务 Demo 框架介绍,下边开始拉取项目实践吧!
以上便是简易的微服务 Demo 框架介绍,下边开始拉取项目实践吧!
服务发现
启动并创建 Consul 集群
简单来说,各个业务服务实例注册在 Consul 这个平台的节点中,各个节点分享注册信息,一起组合成为一个集群。
每个节点分为客户端模式与服务端模式,其区别就是,服务端会存储各个节点的数据,客户端则所有注册到该节点的服务信息,都会转发至其他服务端节点,本身不存储这些信息。也是由此原因,客户端模式的节点数量是不限制的,服务端模式节点则会控制数据。
实践操作
准备 Consul 配置文件,源代码根目录下已经上传
启动 Consul 有两种方式,比如纯命令行启动、按照配置文件启动
因为是单机部署,所以此处为:配置文件指定了每个 Consul 实例的端口,按照配置文件结合命令进行启动
// Windows 终端
-- 进入Consul解压目录
cd D:Consul
-- 服务端模式
.consul.exe agent -server -bootstrap-expect= 3-data-dir=d:consultmpdata-dir1 -config-file=D:Consulconfig 8500.json -node=server1 -bind= '127.0.0.1'-client= '0.0.0.0'-ui
.consul.exe agent -server -data-dir=d:consultmpdata-dir2 -config-file=D:Consulconfig 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:consultmpdata-dir3 -config-file=D:Consulconfig 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:consultmpdata-dir4 -config-file=D:Consulconfig 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 500502503504/ 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:Studymicservice-masterMicServiceDemoMicServiceWebApibinDebugnetcoreapp3 .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:StudyGitmicserviceMicServiceDemoAuthenticationCenterbinDebugnetcoreapp3 .1
-- 启动授权中心
dotnet AuthenticationCenter.dll --urls= "http://*:7000"--ip= "127.0.0.1"--port= 7000
验证授权中心是否生效,此时预留测试接口派上用场
从授权中心获取 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:StudyGitmicserviceMicServiceDemoOcelotGatewaybinDebugnetcoreapp3 .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 500502503504/ 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
转自:OrzCoCo
- EOF -
点击标题可跳转
.NET IM 聊天通讯架构设计
.NET Core 基于 BaGet 搭建私有Nuget服务器
为什么 .NET应用推荐使用 await、async异步编程?
看完本文有收获?请转发分享给更多人
推荐关注「DotNet」,提升.Net技能
点赞和在看就是最大的支持❤️
版权声明
本文内容均来源于互联网,版权归原作者所有。
如侵犯到您的权益,请及时通知我们,我们会及时处理。