Ocelot实现API网关服务

NET Core微服务之基于Ocelot实现API网关服务

https://www.cnblogs.com/edisonchou/p/api_gateway_ocelot_foundation_01.html

一、啥是API网关?

  API 网关一般放到微服务的最前端,并且要让API 网关变成由应用所发起的每个请求的入口。这样就可以明显的简化客户端实现和微服务应用程序之间的沟通方式。以前的话,客户端不得不去请求微服务A(假设为Customers),然后再到微服务B(假设为Orders),然后是微服务C(假设为Invoices)。客户端需要去知道怎么去一起来消费这三个不同的service。使用API网关,我们可以抽象所有这些复杂性,并创建客户端们可以使用的优化后的端点,并向那些模块们发出请求。API网关的核心要点是:所有的客户端和消费端都通过统一的网关接入微服务,在网关层处理所有的非业务功能(比如验证、鉴权、监控等等)。

  关于API网关,个人觉得园友杨晓东的这篇文章《谈谈微服务中的API网关》值得一读。微服务架构中的任何一个环节,都是可以说很久的,而我没有太多经验,也就不多谈了。

二、开源项目:Ocelot

  Ocelot是一个使用.NET Core平台上的一个API Gateway,这个项目的目标是在.NET上面运行微服务架构。Ocelot框架内部集成了IdentityServer(身份验证)和Consul(服务注册发现),还引入了Polly(上一篇博文中提到过)来处理进行故障处理。目前,腾讯和微软是Ocelot在官网贴出来的客户,我想也是因为这两家公司都是巨头,所以要标榜一下,哈哈。

  Ocelot github : https://github.com/TomPallister/Ocelot

三、快速开始第一个API网关
3.1 安装Ocelot
NuGet>Install-Package Ocelot  

3.2 快速准备两个API服务
  (1)准备一个ClientService

  

  创建一个ASP.NET Core WebAPI程序,保留默认ValuesController,做一下修改:

复制代码
[Route("api/[controller]")]
public class ValuesController : Controller
{
// GET api/values
[HttpGet]
public IEnumerable Get()
{
return new string[] { "ClinetService-value1", "ClinetService-value2" };
}

    ......
}

复制代码
  (2)准备一个ProductService

  

  创建一个ASP.NET Core WebAPI程序,保留默认ValuesController,做一下修改:

复制代码
[Route("api/[controller]")]
public class ValuesController : Controller
{
// GET api/values
[HttpGet]
public IEnumerable Get()
{
return new string[] { "ProductService-value1", "ProductService-value2" };
}

    ......
}

复制代码
3.3 静态配置两个API服务
  创建一个ASP.NET Core WebAPI程序,这里命名为APIGateway.

  (1)新建一个json文件:eg.configuration.json

  首先,一个最基本的配置文件如下:

{
"ReRoutes": [],
"GlobalConfiguration": {
"BaseUrl": "https://api.mybusiness.com"
}
}
  这里特别注意一下BaseUrl是我们外部暴露的Url,比如我们的Ocelot运行在http://123.111.11.1的一个地址上,但是前面有一个Nginx绑定了域名http://api.edisonchou.cn,那这里我们的BaseUrl就是 http://api.edisonchou.cn。现在我们的实验环境不存在这个条件,所以我们暂时不需要配置这个option。下面我们根据模板将刚刚创建并启动的两个Service的信息进行了配置

复制代码
{
"ReRoutes": [
// API:CAS.ClientService
{
"DownstreamPathTemplate": "/api/{url}",
"DownstreamScheme": "http",
"DownstreamHostAndPorts": [
{
"Host": "192.168.2.231",
"Port": "8810"
}
],
"UpstreamPathTemplate": "/ClientService/{url}",
"UpstreamHttpMethod": [ "Get", "Post" ]
},
// API:CAS.ProductService
{
"DownstreamPathTemplate": "/api/{url}",
"DownstreamScheme": "http",
"DownstreamHostAndPorts": [
{
"Host": "192.168.2.231",
"Port": "8820"
}
],
"UpstreamPathTemplate": "/ProductService/{url}",
"UpstreamHttpMethod": [ "Get", "Post" ]
}
]
}
复制代码
  其中,我们得了解一下微服务架构中的上游服务器和下游服务器,一般下游服务器指的是提供API服务的REST Service Server(比如WebAPI、WCF App等),而上游服务器则指的是提供Web网页服务的Web Server(比如MVC Application,可能需要访问REST Service)。那么,这里我们可以了解到:

Downstream 是下游服务配置 => 即我们刚刚创建的提供API服务的配置,我们会指定PathTemplate,Host和Port等信息(具体调哪一台服务器是由我说了算)
UpStream 是上游服务配置 => 即服务消费方(eg.MVC Server, SPA App)的调用配置(你要怎么按照什么URL格式和什么HTTP类型调用我才能理解)
  通过配置文件,我们可以猜测Ocelot的实现原理大致应该就是把客户端对网关的请求(Request),按照configuration.json的映射配置,转发给对应的后端http service,然后从后端http service获取响应(Response)后,再返回给客户端。当然,具体细节应该十分复杂,等后面有时间深入看看实现机制。

  其他不再解释,可以看明白,另外,需要对这个配置文件进行以下设置:为了确保直接运行时能够找到这个configuration.json文件

  

  *.通过配置文件可以完成对Ocelot的功能配置:路由、服务聚合、服务发现、认证、鉴权、限流、熔断、缓存、Header头传递等。在配置文件中包含两个根节点:ReRoutes和GlobalConfiguration。ReRoutes是一个数组,其中的每一个元素代表了一个路由,我们可以针对每一个路由进行以上功能配置。

  (2)改写Program和StartUp类,才能正常使用Ocelot

  ①在Program类的BuildWebHost中让程序读取configuration.json文件

复制代码
public class Program
{
public static void Main(string[] args)
{
BuildWebHost(args).Run();
}

    public static IWebHost BuildWebHost(string[] args)
    {
        return WebHost.CreateDefaultBuilder(args)
                        .UseStartup<Startup>()
                        .UseUrls($"http://{IP}:{Port}")
                        .ConfigureAppConfiguration((hostingContext, builder) =>
                        {
                            builder.AddJsonFile("configuration.json", false, true);
                        })
                        .Build();
    }
}

复制代码
  ②在StartUp类中为Ocelot注入配置,并启动Ocelot

复制代码
public class Startup
{
public Startup(IConfiguration configuration)
{
Configuration = configuration;
}

    public IConfiguration Configuration { get; }

    // This method gets called by the runtime. Use this method to add services to the container.
    public void ConfigureServices(IServiceCollection services)
    {
        //services.AddMvc(); -- no need MVC
        // Ocelot
        services.AddOcelot(Configuration);
    }

    // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
    public void Configure(IApplicationBuilder app, IHostingEnvironment env)
    {
        if (env.IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
        }

        //app.UseMvc(); -- no need MVC
        // Ocelot
        app.UseOcelot().Wait();
    }
}

复制代码
3.3 测试一下
  (1)先启动ClientService和ProductService => 也可以通过在VS中更改启动顺序来指定

  

  (2)再启动APIGateway,在浏览器中直接访问API网关所在的地址和端口(这里是192.168.2.231:8800)进行测试:先请求ClientService,再请求ProductService,可以看到API网关对请求进行了转发,服务消费方不需要记住每个service所在的IP和端口,而是只需要告诉网关我需要消费哪个service即可。

  

  

  *.tip:这里配置的PathTemplate大小写不敏感,可以选择通过设置ReRouteIsCaseSensitive:true来实现大小写敏感

  到这里,第一个API网关的实现就结束了,但是对于众多的微服务,如果我们都一一硬编码地配置其IP和Port在配置文件中,不适合微服务架构的风格,因为众多的服务地址变化会让静态配置的工作变得越来越大。因此,我们学习了服务发现,那么是否可以结合服务发现呢?Ocelot + Consul的方式为我们给出了答案。

四、Ocelot+Consul的结合
4.1 实验节点部署结构

  这里仍然采用之前的Consul实验集群,三个Consul Server节点(1个leader,2个follwer),一个Consul Client节点(部署了两个服务ClientService和ProductService),以及一个API网关节点(基于Ocelot)。

4.2 启动Consul

  启动方式以及步骤这里不再赘述,如不了解请浏览我的前两篇博文《.NET Core微服务之基于Consul实现服务治理》以及《.NET Core微服务之基于Consul实现服务治理(续)》。这里可以看到,我们已经成功地注册了ClientService和ProductService。

4.3 启动API Gateway
  (1)为了适配Consul服务发现,减少服务IP和Port的hard-code,我们需要改一下配置文件:

复制代码
{
"ReRoutes": [
// API01:CAS.ClientService
{
"UseServiceDiscovery": true, // use Consul service discovery
"DownstreamPathTemplate": "/api/{url}",
"DownstreamScheme": "http",
"ServiceName": "CAS.ClientService",
"LoadBalancerOptions": {
"Type": "RoundRobin"
},
"UpstreamPathTemplate": "/api/clientservice/{url}",
"UpstreamHttpMethod": [ "Get", "Post" ],
"ReRoutesCaseSensitive": false // non case sensitive
},
// API02:CAS.ProductService
{
"UseServiceDiscovery": true, // use Consul service discovery
"DownstreamPathTemplate": "/api/{url}",
"DownstreamScheme": "http",
"ServiceName": "CAS.ProductService",
"LoadBalancerOptions": {
"Type": "RoundRobin"
},
"UpstreamPathTemplate": "/api/productservice/{url}",
"UpstreamHttpMethod": [ "Get", "Post" ],
"ReRoutesCaseSensitive": false // non case sensitive
}
],
"GlobalConfiguration": {
//"BaseUrl": "https://api.mybusiness.com"
"ServiceDiscoveryProvider": {
"Host": "192.168.80.100", // Consul Service IP
"Port": 8500 // Consul Service Port
}
}
}
复制代码
  Ocelot提供了基本的负载均衡选项(LoadBalanceOptions):轮询和最小连接数,如果我们部署了多个一样的服务,那么我们设置一个选项。

  (2)其他代码无须更改,对于基本用法,我们要做的基本只是对配置文件的修改。配置完成后,即可启动API网关项目。

4.4 测试
  (1)请求ClientService

  

  (2)请求ProductService

  

五、小结
  本篇介绍了API网关的基础概念以及一个基于适合于.NET Core的开源项目Ocelot,并通过两个小案例(一个静态配置服务,一个结合Consul服务发现)来了解了API网关的作用和Ocelot的最基础的用法。下一篇会继续Ocelot的一些比较有用的功能(比如:限流、熔断、缓存,以及结合Swagger),继续做一些实践,也希望到时可以总结下来与各位园友分享。

参考资料
杨晓东,《谈谈微服务中的API网关》

桂素伟,《Ocelot + Consul实践》

杨中科,《.NET微服务直播课课件pdf》

李朝强,《ASP.NET Core API网关Ocelot》

jesse 腾飞,《.NET Core开源API网关 – Ocelot中文文档》

Ocelot官网:https://github.com/ThreeMammals/Ocelot => tip: 张善友大队长为主要贡献者之一

Ocelot官方文档:http://ocelot.readthedocs.io/en/latest/index.html

作者:周旭龙

出处:http://edisonchou.cnblogs.com

原文地址:https://www.cnblogs.com/Leo_wl/p/9196577.html

时间: 2024-11-05 22:07:45

Ocelot实现API网关服务的相关文章

.NET Core微服务之基于Ocelot实现API网关服务(续)

一.负载均衡与请求缓存 1.1 负载均衡 为了验证负载均衡,这里我们配置了两个Consul Client节点,其中ClientService分别部署于这两个节点内(192.168.80.70与192.168.80.71). 为了更好的展示API Repsonse来自哪个节点,我们更改一下返回值: [Route("api/[controller]")] public class ValuesController : Controller { // GET api/values [Http

Spring Cloud学习系列第五篇【API网关服务】

这篇随笔接着学习微服务中一个比较重要的组件API网关服务.当我们微服务架构完成后最终是要提供给外部访问的,于是我们需要一个统一的访问入口,能隐藏我们内部服务URL细节,这就有点像局域网里那个网关的概念了,这是API网关服务就应运而生了.API网关作用有能为实现请求路由.负载均衡.校验过滤等基础功能,还能实现请求转发的熔断机制.服务集合等高级功能.补充下通常我们对外服务统一入口可以采用F5.Nginx等方式也能实现前面的请求路由与负载均衡,但是要实现后面功能了F5.Nginx就无能为力了吧,这就是

springCloud学习05之api网关服务zuul过滤器filter

前面学习了zuul的反向代理.负载均衡.fallback回退.这张学习写过滤器filter,做java web开发的对filter都不陌生,那就是客户端(如浏览器)发起请求的时候,都先经过过滤器filter做一些相关的校验或业务判断(如登录.权限等),zuul也同样提供了过滤器功能.只要继承ZuulFilter类即可. 通过前文的介绍,我们对于Zuul的第一印象通常是这样的:它包含了对请求的路由和过滤两个功能,其中路由功能负责将外部请求转发到具体的微服务实例上,是实现外部访问统一入口的基础:而过

Spring Cloud(五):API网关服务——Spring Cloud Zuul

通过前面的介绍,我们可以使用Spring Boot进行微服务开发,使用Spring Cloud Eureka实现注册中心以及微服务的注册和发现,使用Spring Cloud Ribbon实现服务间的负载均衡,使用Spring Cloud Hystrix实现线程隔离以及断路器功能.但是实际应用中这样的架构无疑增加了开发成本以及运维难度,而且后期重构难度也很大.为了解决以上各种问题,需要使用API 网关的方式.API 网关是一个服务器,它是进入一个系统的唯一节点,封装了内部系统的架构,并且提供了AP

.net core 3.1 基于ocelot实现API网关

Ocelot是一个用.NET Core实现的开源API网关,它功能强大,包括了:路由.请求聚合.服务发现.认证.鉴权.限流熔断,缓存等. 接下来,会使用ocelot 结合consul ,polly ,cachemanager 实现负载均衡,服务发现,限流熔断和缓存功能.(本文只做记录,就直接贴完整代码,不分别测试了) 新建ApiGateWay项目,nuget安装Ocelot,Ocelot.Provider.Consul,Ocelot.Provider.Polly,Ocelot.Cache.Cac

基于.NET CORE微服务框架 -Api网关服务管理

1.前言 经过10多天的努力,surging 网关已经有了大致的雏形,后面还会持续更新完善,请大家持续关注研发的动态 最近也更新了surging新的版本 更新内容: 1. 扩展Zookeeper封装2. 增加服务元数据3. 增加API网关 开源地址:https://github.com/dotnetcore/surging 2.软件环境 IDE:Visual Studio 2017 15.3 Preview ,vscode 框架:.NET core 2.0 依赖程序:Zookeepe.Rabbi

干货分享微服务spring-cloud(6.Api网关服务zuul)

Spring cloud zuul对Netflix zuul进行了封装实现 新建spring boot项目demo-springcloud-api-gateway,创建启动类ZuulApplication,@EnableZuulProxy启动网关代理的配置,它也是组合注解,启用了服务注册发现和熔断器 项目关键依赖spring-cloud-starter-zuul对网关支持 配置文件application.properties,路由配置主要有传统路由和服务路由,传统路由就是ip和端口这种,服务路由

API网关模式

什么是网关 网关一词来源于计算机网络中的定义,网关(Gateway)又称网间连接器.协议转换器.网关的准确定义是: 两个计算机程序或系统之间的连接,网关作为两个程序之间的门户,允许它们通过不同计算机之间的协议通信来共享信息.顾名思义API网关就是API之间相互调用的关卡和屏障. API之间为什么需要网关 试想一下我们在实现一个非常庞大的业务系统,分为不同的业务domain和子系统,各个domain和子系统提供处理业务的API,不同系统之间以API的方式进行数据交互.通常情况下我们可能会将所有实现

【3分钟就会系列】使用Ocelot+Consul搭建微服务吧!

原文:[3分钟就会系列]使用Ocelot+Consul搭建微服务吧! 一.什么Ocelot? API网关是一个服务器,是系统的唯一入口.API 网关一般放到微服务的最前端,并且要让API 网关变成由应用所发起的每个请求的入口.这样就可以明显的简化客户端实现和微服务应用程序之间的沟通方式.从面向对象设计的角度看,它与外观模式类似.API网关封装了系统内部架构,为每个客户端提供一个定制的API.它可能还具有其它职责,如身份验证.监控.负载均衡.缓存.请求分片与管理.静态响应处理. Ocelot 是一