快速搭建微服务架构

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 快速搭建微服务架构


说在前面的话

准备好环境,拉取源代码,按照每个章节中的【实践操作】进行操作,即可搭建起来,已经测试通过。

不想把篇幅拉太长,且此文实践为主,如果对微服务没有理论基础,建议先阅读其他博主的微服务理论,再食用本文,效果更佳~

如有解释不当或错误的地方,欢迎各位大佬加以斧正!

之后要是有空,后续会容器化部署上云服务器,把部署过程剪一个视频出来。

环境准备(Windows版)

网络异常,图片无法展示
|

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:9500http://127.0.0.1:10500http://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

网络异常,图片无法展示
|

  1. 直接访问受保护的资源,必定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的限流策略,在此配置中RateLimitOptionsGlobalConfiguration.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等等.....

最后再贴一下架构图

相关实践学习
部署高可用架构
本场景主要介绍如何使用云服务器ECS、负载均衡SLB、云数据库RDS和数据传输服务产品来部署多可用区高可用架构。
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
相关文章
|
23小时前
|
存储 NoSQL MongoDB
【MongoDB 专栏】MongoDB 与微服务架构的结合
【5月更文挑战第11天】微服务架构流行趋势下,选择合适的数据库至关重要。MongoDB作为非关系型数据库,与微服务有天然契合度。其灵活的文档模型、水平扩展性、高性能及局部事务支持,满足微服务对数据模型多样性、高可用性、快速读写的需求。实践中,需注意数据划分、索引优化、监控调优和版本控制。未来,MongoDB在微服务中的应用将更广泛,新技术将提升其在微服务架构中的价值。
【MongoDB 专栏】MongoDB 与微服务架构的结合
|
1天前
|
监控 数据库 开发者
构建高效可靠的微服务架构:策略与实践
【5月更文挑战第11天】在当今软件开发的世界中,微服务架构已经成为构建可扩展、灵活且容错的系统的首选方法。本文深入探讨了设计、部署和维护微服务系统时面临的挑战,并提出了一系列实用的策略和最佳实践。我们将从服务的划分原则出发,讨论如何确保每个微服务的自治性,以及如何通过容器化和编排技术实现服务的高效运行。文章还将涉及监控、日志记录和故障恢复的策略,旨在帮助开发人员构建一个既高效又可靠的微服务环境。
|
1天前
|
Kubernetes API 开发者
构建高效微服务架构:后端开发的新范式
【5月更文挑战第11天】 在现代软件开发的快速演变中,微服务架构已成为企业追求敏捷性、可扩展性和技术多样性的关键解决方案。本文旨在探讨如何构建高效的微服务架构,并分析其对后端开发的影响。我们将通过一系列最佳实践和策略,展示如何优化服务的独立性、弹性和性能,同时确保系统的整体稳定性和安全性。文章还将介绍容器化、API网关、服务发现和分布式追踪等关键技术的应用,为后端开发者提供一份全面的微服务实施指南。
|
1天前
|
设计模式 监控 API
构建高效的微服务架构:后端开发的新范式
【5月更文挑战第11天】 在当今的软件开发领域,微服务架构已经成为一种流行的设计模式。它通过将应用程序分解为一组小型、松散耦合的服务来提供高度可扩展和灵活的解决方案。本文将探讨如何构建一个高效的微服务架构,包括选择合适的技术栈、设计原则以及应对常见挑战的策略。我们将深入讨论如何确保系统的可维护性、可靠性和性能,同时考虑到安全性和监控的需求。
|
2天前
|
监控 持续交付 Docker
使用Docker进行微服务架构的最佳实践
【5月更文挑战第10天】本文探讨了使用Docker实施微服务架构的最佳实践。首先,理解微服务架构是拆分小型独立服务的模式,借助Docker实现快速部署、高可移植性和环境一致性。Docker的优势在于服务扩展、容器编排、自动化构建与部署。最佳实践包括:定义清晰服务边界,使用Dockerfile和Docker Compose自动化构建,利用Docker Swarm或Kubernetes编排,实施服务发现和负载均衡,监控与日志记录,以及持续集成和持续部署。Docker虽重要,但需与其他技术结合以确保系统整体稳定性。
|
2天前
|
缓存 负载均衡 API
微服务架构下的API网关性能优化实践
【5月更文挑战第10天】在微服务架构中,API网关作为前端和后端服务之间的关键枢纽,其性能直接影响到整个系统的响应速度和稳定性。本文将探讨在高并发场景下,如何通过缓存策略、负载均衡、异步处理等技术手段对API网关进行性能优化,以确保用户体验和服务的可靠性。
|
2天前
|
监控 持续交付 开发者
构建高效微服务架构:后端开发的新范式
【5月更文挑战第10天】在现代软件开发领域,微服务架构已经成为一种流行的设计模式,它通过将大型应用程序拆分为一组小型、独立和松散耦合的服务来提供更高的可伸缩性和灵活性。本文深入探讨了微服务架构的设计理念、实施步骤以及面临的挑战,并提出了一套实用的策略和最佳实践,帮助后端开发者构建和维护高效的微服务系统。
|
2天前
|
存储 监控 API
构建高效微服务架构:后端开发的现代实践
【5月更文挑战第9天】 在本文中,我们将深入探讨如何在后端开发中构建一个高效的微服务架构。通过分析不同的设计模式和最佳实践,我们将展示如何提升系统的可扩展性、弹性和维护性。我们还将讨论微服务架构在处理复杂业务逻辑和高并发场景下的优势。最后,我们将分享一些实用的工具和技术,以帮助开发者实现这一目标。
|
4天前
|
API 持续交付 开发者
构建高效微服务架构:后端开发的新视角
【5月更文挑战第8天】 随着现代软件开发的演变,微服务架构已经成为了企业追求敏捷、可扩展和灵活部署的重要解决方案。本文将深入探讨如何构建一个高效的微服务架构,包括关键的设计原则、技术栈选择以及持续集成与部署的最佳实践。我们还将讨论微服务带来的挑战,如数据一致性、服务发现和网络延迟,并提出相应的解决策略。通过本文,后端开发者将获得构建和维护微服务系统所需的深度知识,并了解如何在不断变化的技术环境中保持系统的健壮性和可维护性。
37 8
|
3天前
|
负载均衡 算法 NoSQL
探索微服务架构下的服务发现与治理
【5月更文挑战第9天】 在当今的软件开发领域,微服务架构已成为构建可伸缩、灵活且容错的系统的首选模式。随着服务的增多,如何有效地进行服务发现与治理成为了关键的挑战。本文将深入探讨微服务环境中服务发现的机制和治理策略,分析不同服务发现工具的优缺点,并提出一种基于一致性哈希和健康检查相结合的服务治理方案,旨在提高系统的可用性和性能。