ASP.NET Core OceLot 微服务实践

1、OceLot中间件介绍

  在传统的BS应用中,随着业务需求的快速发展变化,需求不断增长,迫切需要一种更加快速高效的软件交付方式。微服务可以弥补单体应用不足,是一种更加快速高效软件架构风格。单体应用被分解成多个更小的服务,每个服务有自己的独立模块,单独部署,然后共同组成一个应用程序。把范围限定到单个独立业务模块功能。分布式部署在各台服务器上。

  而Ocelot开发的目标就是使用.NET运行面向微服务/服务的架构,要达到这个目标需要一个统的系统入口点(我们统称为API网关),同时需要与IdentityServer或相关的验证服务进行集成。

  Ocelot同时是一系列按特定顺序排列的中间件。

  包括(IdentityServer,Consul,Butterfly)等等。

  Ocelot将HttpRequest对象操作到其配置指定的状态,直到它到达请求构建器中间件,在该中间件中它创建HttpRequestMessage对象,该对象用于向下游服务发出请求。发出请求的中间件是Ocelot管道中的最后一件事。它不会调用下一个中间件。下游服务的响应存储在每个请求范围的存储库中,并在请求返回Ocelot管道时进行检索。有一个中间件将HttpResponseMessage映射到HttpResponse对象并返回给客户端。

  以下是部署Ocelot时使用的结构图:

  与IdentityServer4的集成:

  与Consul的集成:

  从上面基本的介绍可以得出一个结论,OceLot微服务网关类似于经典设计模式的Fa?ade模式,它将底层的复杂细节进行屏蔽,对外提供简单而统一的调用方式,通常使用HTTP的RESTful API服务。此时,对于客户端而言,可以是PC端网页,也可以是移动设备,客户端通过HTTP方式调用OceLot网关。

2、整体设计

看了前面的基于OceLot微服务的基础介绍,发现OceLot已提供了足够强大的功能及扩展能力,而我们只需要进行集成,对就是集成(我们不生产水,我们只是大自然的搬运工),如下图:

如图,我们采用了Nginx作为入口的高可用及负载均衡,通过API网关作为具体二次转发接入的统一入口,先向IdentityService进行Login以进行验证并获取Token,在IdentityService的验证过程中会访问数据库以验证。接着再通过Consul服务器获取服务的所在服务器,最后再带上Token通过API网关去访问具体的服务A、B、C。这里我们的IdentityService基于IdentityServer4开发,它具有统一登录验证和授权的功能。

  而API网关的模块组件图大致如下图:

3、Nginx负载均衡

点击进入:https://www.cnblogs.com/littlewrong/p/9491901.html

4、OceLot网关服务

4.1、路由

  Ocelot的主要功能是接管进入的http请求并把它们转发给下游服务。目前是以另一个http请求的形式(将来可能是任何传输机制)。

捕获所有

  Ocelot的路由还支持捕获所有样式的路由,用户可以指定他们想要匹配所有流量。如果你像下面那样设置你的配置,请求将被直接代理(它不一定叫url,任何占位符名称都可以)。

{

"DownstreamPathTemplate": "/{url}",

"DownstreamScheme": "https",

"DownstreamHostAndPorts": [

{

"Host": "localhost",

"Port": 80,

}

],

"UpstreamPathTemplate": "/{url}",

"UpstreamHttpMethod": [ "Get" ]

}

该捕获所有的优先级低于其他任何ReRoute。 如果你的配置中还有下面的ReRoute,那么Ocelot会在捕获所有配置之前先匹配它。

{
    "DownstreamPathTemplate": "/",
    "DownstreamScheme": "https",
    "DownstreamHostAndPorts": [
            {
                "Host": "10.0.10.1",
                "Port": 80,
            }
        ],
    "UpstreamPathTemplate": "/",
    "UpstreamHttpMethod": [ "Get" ]
}

上游主机

此功能允许您基于上游主机进行ReRoutes。 这是通过查看客户端使用的主机头来工作,然后将其用作识别ReRoute的信息的一部分。

为了使用这个功能,在你的配置中加上如下配置。

{
    "DownstreamPathTemplate": "/",
    "DownstreamScheme": "https",
    "DownstreamHostAndPorts": [
            {
                "Host": "10.0.10.1",
                "Port": 80,
            }
        ],
    "UpstreamPathTemplate": "/",
    "UpstreamHttpMethod": [ "Get" ],
    "UpstreamHost": "somedomain.com"
}

上面的ReRoute只会匹配主机头是somedomain.com的请求。

如果您没有在ReRoue上设置UpstreamHost,则任何主机头都可以匹配它。 这基本上是一个捕获所有功能并保留构建功能时的现有功能。这意味着如果您有两个相同的ReRoute,其中一个与UpstreamHost是null,另一个有值。 Ocelot会倾向于设定值的那个。

这个功能在问题 216提出要求。

优先级

{
    "Priority": 0
}

0是最低优先级,Ocelot将始终使用0作为/{catchAll}路由条目,并且可以硬编码。之后,你可以自由设置你想要的任何优先级。

例如你可以这样:

{
    "UpstreamPathTemplate": "/goods/{catchAll}",
    "Priority": 0
}

还可以:

{
    "UpstreamPathTemplate": "/goods/delete",
    "Priority": 1
}

在上面的例子中,如果您向Ocelot请求/goods/delete,Ocelot将匹配/goods/delete这个ReRoute。不过在不设置优先级以前它会匹配/goods/{catchAll}(因为这是列表中的第一个ReRoute!)。

以上摘自官方的介绍,地址为:https://ocelot.readthedocs.io/en/latest/features/routing.html

最终实现代码如下:

调试时,确认启动多个项目。

启动多个项目:

  进行路由测试:

通过PostMan测试发现,BookingAPI,及PassengerAPI已通过网关API成功访问。

配置文件解析

{
  "ReRoutes": [ //路由是API网关最基本也是最核心的功能、ReRoutes下就是由多个路由节点组成。
    {
      "DownstreamPathTemplate": "", //下游服务模板
      "UpstreamPathTemplate": "", //上游服务模板
      "UpstreamHttpMethod": [ "Get" ],//上游方法类型Get,Post,Put
      "AddHeadersToRequest": {},//需要在转发过程中添加到Header的内容
      "FileCacheOptions": { //可以对下游请求结果进行缓存,主要依赖于CacheManager实现
        "TtlSeconds": 10,
        "Region": ""
      },
      "ReRouteIsCaseSensitive": false,//重写路由是否区分大小写
      "ServiceName": "",//服务名称
      "DownstreamScheme": "http",//下游服务schema:http, https
      "DownstreamHostAndPorts": [ //下游服务端口号和地址
        {
          "Host": "localhost",
          "Port": 8001
        }
      ],
      "RateLimitOptions": { //限流设置
        "ClientWhitelist": [], //客户端白名单
        "EnableRateLimiting": true,//是否启用限流设置
        "Period": "1s", //每次请求时间间隔
        "PeriodTimespan": 15,//恢复的时间间隔
        "Limit": 1 //请求数量
      },
      "QoSOptions": { //服务质量与熔断,熔断的意思是停止将请求转发到下游服务。当下游服务已经出现故障的时候再请求也是无功而返,
      并且增加下游服务器和API网关的负担,这个功能是用的Polly来实现的,我们只需要为路由做一些简单配置即可
        "ExceptionsAllowedBeforeBreaking": 0, //允许多少个异常请求
        "DurationOfBreak": 0, //熔断的时间,单位为秒
        "TimeoutValue": 0 //如果下游请求的处理时间超过多少则自如将请求设置为超时
      }
    }
  ],
  "UseServiceDiscovery": false,//是否启用服务发现
  "Aggregates": [ //请求聚合
    {
      "ReRouteKeys": [ //设置需要聚合的路由key
        "booking",
        "passenger"
      ],
      "UpstreamPathTemplate": "/api/getbookingpassengerinfo" //暴露给外部的聚合请求路径
    },
  "GlobalConfiguration": { //全局配置节点
    "BaseUrl": "https://localhost:5000" //网关基地址
  }
}
{
    "DownstreamPathTemplate": "/api/posts/{postId}",
    "DownstreamScheme": "https",
    "DownstreamHostAndPorts": [
            {
                "Host": "10.0.1.10",
                "Port": 5000,
            },
            {
                "Host": "10.0.1.11",
                "Port": 5000,
            }
        ],
    "UpstreamPathTemplate": "/posts/{postId}",
    "LoadBalancer": "LeastConnection",
    "UpstreamHttpMethod": [ "Put", "Delete" ]
}

万能模板

如果不希望对请求做任何的处理,则可以使用下面的万能模板:(万能模板的优先级最低,只要有其它的路由模板,其它的路由模板则会优先生效)

{
    "DownstreamPathTemplate": "/{url}",
    "DownstreamScheme": "https",
    "DownstreamHostAndPorts": [
            {
                "Host": "localhost",
                "Port": 80,
            }
        ],
    "UpstreamPathTemplate": "/{url}",
    "UpstreamHttpMethod": [ "Get" ]
}

Prioirty优先级

对多个产生冲突的路由设置优化级

{
    "UpstreamPathTemplate": "/goods/{catchAll}"
    "Priority": 0
}
{
    "UpstreamPathTemplate": "/goods/delete"
    "Priority": 1
}

请求聚合

可以通过gateway将客户端的多个请求聚合然后将结果一次返回到客户端去,此时我们需要给每个模板指定一个key

{
  "ReRoutes": [
    {
      "DownstreamPathTemplate": "/api/booking",
      "UpstreamPathTemplate": "/api/getbooking",
      "UpstreamHttpMethod": [ "Get" ],
      "DownstreamScheme": "http",
      "DownstreamHostAndPorts": [
        {
          "Host": "localhost",
          "Port": 8001
        }
      ],
      "Key": "booking"
    },
    {
      "DownstreamPathTemplate": "/api/passenger",
      "UpstreamPathTemplate": "/api/getpassenger",
      "UpstreamHttpMethod": [ "Get" ],
      "ReRouteIsCaseSensitive": false,
      "DownstreamScheme": "http",
      "DownstreamHostAndPorts": [
        {
          "Host": "localhost",
          "Port": 8002
        }
      ],
      "Key": "passenger"
    }
  ],
  "GlobalConfiguration": {
    "BaseUrl": "https://localhost:5000"
  },
  "Aggregates": [
    {
      "ReRouteKeys": [
        "booking",
        "passenger"
      ],
      "UpstreamPathTemplate": "/api/getbookingpassengerinfo"
    }
  ]
}

需要注意的是:

  1. 聚合服务目前只支持返回json
  2. 目前只支持Get方式请求下游服务
  3. 任何下游的response header并会被丢弃
  4. 如果下游服务返回404,聚合服务只是这个key的value为空,它不会返回404

  有没有觉得这里的聚合很类似于GraphQL的功能,但实际上在Ocelot中并不打算实现GraphQL的功能,因为毕竟Ocelot的主要职责是实现网关的功能,聚合只是其中的一个feature,GraphQL提供了一个库 graphql-dotnet ,我们可以用它来完成需要的功能,而在Ocelot中实现类似认证,授权等这样它擅长的事情:

{
    "ReRoutes": [
        {
            "DownstreamPathTemplate": "/graphql",
            "DownstreamScheme": "http",
            "DownstreamHostAndPorts": [
              {
                "Host": "yourgraphqlhost.com",
                "Port": 80
              }
            ],
            "UpstreamPathTemplate": "/graphql",
            "DelegatingHandlers": [
                "GraphQlDelegatingHandler"
            ]
        }
    ]
  }

  在此感谢KenWang007 https://github.com/KenWang007/OcelotDemo 示例,查了很久的资料,最终通过上面的示例调试成功。

  最后,github 有个 https://github.com/dbarkwell/Ocelot.ConfigEditor,这个项目实现了asp.net core mvc 的在线编辑路由。

4.2、API安全认证(OceLot+IdentityServer4)

IdentityServer4的介绍博客园上已经有非常多了,

点击打开:https://www.cnblogs.com/jaycewu/p/7791102.html 可以看一下。

这里主要介强OceLot集成需要进行改动的地方。

  新增加IdentityService服务API

参照https://www.cnblogs.com/jaycewu/p/7791102.html

实现后IdentityService代码如下:

Startup.cs调整

configuration.json网关配置文件增加Token的获取地址

{

"DownstreamPathTemplate": "/connect/token",

"UpstreamPathTemplate": "/api/connect/token",

"UpstreamHttpMethod": [ "Post" ],

"ReRouteIsCaseSensitive": false,

"DownstreamScheme": "http",

"DownstreamHostAndPorts": [

{

"Host": "localhost",

"Port": 5001

}

],

"Key": "IdentityService",

"RateLimitOptions": {

"ClientWhitelist": [],

"EnableRateLimiting": true,

"Period": "1s",

"PeriodTimespan": 15,

"Limit": 1

}

},

{

"DownstreamPathTemplate": "/api/passenger",

"UpstreamPathTemplate": "/api/passenger",

"UpstreamHttpMethod": [ "Get" ],

"ReRouteIsCaseSensitive": false,

"DownstreamScheme": "http",

"ServiceName": "API002",

"LoadBalancer": "NoLoadBalancer",

"UseServiceDiscovery": true,

      "Key": "passenger",

      "AuthenticationOptions": {

        "AuthenticationProviderKey": "Bearer",

        "AllowScopes": [ "TWAPI" ]

      }

},

测试

启动程序

未获取Token的情况下:

  获取Token:

  带上Token进行访问:

  通过调用发现,返回的结果和预期一样,调用成功。

4.3、服务注册及发现(OceLot+Consul)

安装Consul就不介绍,可以参考:https://www.cnblogs.com/axzxs2001/p/8487521.html 自行调试,按照上面的写法需要非常注意的一点是OceLot9.X版本以下是OK的,最新版本的需要进行调整几个地方:

  安装OceLot.Provider.Consul包

    Install-Package Ocelot.Provider.Consul

  Startup.cs修改

  configuration.json调整

  官方参考:https://ocelot.readthedocs.io/en/latest/features/servicediscovery.html,按照官方的调整后,调试通过

  测试

  启动程序及Consul

  调用:

  我们发现,OceLot已通过Consul调用成功。

4.4、服务质量与熔断

  熔断的意思是停止将请求转发到下游服务。当下游服务已经出现故障的时候再请求也是功而返,并且增加下游服务器和API网关的负担。这个功能是用的Pollly来实现的,我们只需要为路由做一些简单配置即可

  "QoSOptions": {

  "ExceptionsAllowedBeforeBreaking":3,

  "DurationOfBreak":5,

  "TimeoutValue":5000

  }

  ExceptionsAllowedBeforeBreaking 允许多少个异常请求

  DurationOfBreak 熔断的时间,单位为秒

  TimeoutValue 如果下游请求的处理时间超过多少则自如将请求设置为超时。

4.5、分流控制

对请求进行限流可以防止下游服务器因为访问过载而崩溃,这个功能就是我们的张善友添加进去的。非常优雅的实现,我们只需要在路由下加一些简单的配置即可以完成。

"RateLimitOptions": {

"ClientWhitelist": [],

"EnableRateLimiting": true,

"Period": "1s",

"PeriodTimespan": 1,

"Limit": 1

}

ClientWihteList 白名单

EnableRateLimiting 是否启用限流

Period 统计时间段:1s, 5m, 1h, 1d

PeroidTimeSpan 多少秒之后客户端可以重试

Limit 在统计时间段内允许的最大请求数量

在 GlobalConfiguration下我们还可以进行以下配置

"RateLimitOptions": {

"DisableRateLimitHeaders": false,

"QuotaExceededMessage": "Customize Tips!",

"HttpStatusCode": 999,

"ClientIdHeader" : "Test"

}

Http头  X-Rate-Limit 和 Retry-After 是否禁用

QuotaExceedMessage 当请求过载被截断时返回的消息

HttpStatusCode 当请求过载被截断时返回的http status

ClientIdHeader 用来识别客户端的请求头,默认是 ClientId

如图:

  连续点击几下后,返回:429 Too Many Requests.

4.6、负载均衡

当下游服务有多个结点的时候,我们可以在DownstreamHostAndPorts中进行配置。

{

"DownstreamPathTemplate": "/api/posts/{postId}",

"DownstreamScheme": "https",

"DownstreamHostAndPorts": [

{

"Host": "10.0.1.10",

"Port": 5000,

},

{

"Host": "10.0.1.11",

"Port": 5000,

}

],

"UpstreamPathTemplate": "/posts/{postId}",

"LoadBalancer": "LeastConnection",

"UpstreamHttpMethod": [ "Put", "Delete" ]

}

LoadBalancer将决定负载均衡的算法

  • LeastConnection – 将请求发往最空闲的那个服务器
  • RoundRobin – 轮流发送
  • NoLoadBalance – 总是发往第一个请求或者是服务发现

在负载均衡这里,我们还可以和Consul结合来使用服务发现,同一个服务和Name配置成相同,则在请求时,会根据LoadBalancer请求的算法进行访问,如下:

{

"service": {

"id": "count1",

"name": "Count",

"tags": ["dev"],

"address": "localhost",

"port": 5001

}

}

{

"service": {

"id": "count2",

"name": "Count",

"tags": ["dev"],

"address": "localhost",

"port": 5002

}

}

4.7、Swagger文档生成

Swagger 是一个规范和完整的框架,用于生成、描述、调用和可视化 RESTful 风格的 Web 服务。总体目标是使客户端和文件系统作为服务器以同样的速度来更新。文件的方法,参数和模型紧密集成到服务器端的代码,允许API来始终保持同步你可以通过一个文本编辑器来编辑 Swagger 文件,或者你也可以从你的代码注释中自动生成。各种工具都可以使用 Swagger 文件来生成互动的 API 文档。

在集成Swagger的时候,我们同时需要考虑到与IdentityServer的集成,在调试的时候让Swagger充许进行验证。

BookingApi  Startup.cs修改

public void ConfigureServices(IServiceCollection services)

{

services.AddSwaggerGen(c =>

{

c.SwaggerDoc("v1", new Info { Title = "BookingApi", Version = "v1" });

c.AddSecurityDefinition("Bearer", new ApiKeyScheme

{

Description = "请输入带有Bearer的Token",

Name = "Authorization",

In = "header",

Type = "apiKey"

});

//Json Token认证方式,此方式为全局添加

c.AddSecurityRequirement(new Dictionary<string, IEnumerable<string>>

{

{ "Bearer", Enumerable.Empty<string>() }

});

});

services.AddMvc();

}

// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.

public void Configure(IApplicationBuilder app, IHostingEnvironment env)

{

app.UseSwagger();

// Enable middleware to serve swagger-ui (HTML, JS, CSS, etc.),

// specifying the Swagger JSON endpoint.

app.UseSwaggerUI(c =>

{

c.SwaggerEndpoint("/swagger/v1/swagger.json", "BookingApi");

});

app.UseMvc();

}

PassengerApi Startup.cs修改

public void ConfigureServices(IServiceCollection services)

{

services.AddMvc();

services.AddSwaggerGen(c =>

{

c.SwaggerDoc("v1", new Info { Title = "PassengerApi", Version = "v1" });

c.AddSecurityDefinition("Bearer", new ApiKeyScheme

{

Description = "请输入带有Bearer的Token",

Name = "Authorization",

In = "header",

Type = "apiKey"

});

//Json Token认证方式,此方式为全局添加

c.AddSecurityRequirement(new Dictionary<string, IEnumerable<string>>

{

{ "Bearer", Enumerable.Empty<string>() }

});

});

}

// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.

public void Configure(IApplicationBuilder app, IHostingEnvironment env)

{

app.UseSwagger();

// Enable middleware to serve swagger-ui (HTML, JS, CSS, etc.),

// specifying the Swagger JSON endpoint.

app.UseSwaggerUI(c =>

{

c.SwaggerEndpoint("/swagger/v1/swagger.json", "PassengerApi");

});

app.UseMvc();

}

Tw.ApiGateway Startup.cs修改

public void ConfigureServices(IServiceCollection services)

{

services.AddOcelot().AddConsul();

services.AddMvcCore(option =>

{

}).AddAuthorization().AddJsonFormatters();

services.AddAuthentication("Bearer")

.AddIdentityServerAuthentication(options =>

{

options.Authority = "http://localhost:5001";

options.RequireHttpsMetadata = false;

options.ApiName = "TWAPI";

});

services.AddMvc();

services.AddSwaggerGen(options =>

{

options.SwaggerDoc("ApiGateway", new Info { Title = "网关服务", Version = "v1" });

});

}

// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.

public void Configure(IApplicationBuilder app, IHostingEnvironment env)

{

var apis = new List<string> { "BookingApi", "PassengerApi" };

app.UseMvc()

.UseSwagger()

.UseSwaggerUI(options =>

{

apis.ForEach(m =>

{

options.SwaggerEndpoint($"/{m}/swagger.json", m);

});

});

app.UseAuthentication();

app.UseOcelot().Wait();

}

测试

启动程序:

查看生成的API:

调用:

失败,加上验证:

最后调用成功。

4.8、数据监控Butterfly

Butterfly被设计为分布式追踪和APM的Server端,它将包含Collector,Storage,独立的Web UI,并使用Open Tracing规范来设计追踪数据。目前仅根据规范实现了Open Tracing API,后续还会兼容google的opencensus。这里顺便提下为什么我们不用zipkin 或是Jaeger,他们只做了tracing,Butterfly比他们多一点就是同时要做metrics和预警,就是要做立体化监控系统。目前Butterfly也是在起步阶段,还有非常多的功能需要开发,目前有两个事情的优先级比较高一个应用程序进程级别的metrics,一个是后端collector和es的性能优化,欢迎各位同学加入一起开发,我们相信通过不断的建设,我们.NET社区一样可以达到Java的高度。回想Ocelot 的发展历程,2016年才是到现在已经开发了2年时间,完成了3.0版本的开发,现在已经是一个日趋成熟的API网关,通过API网关连接后面的服务,像今天和大家分享的最近我业余时间在开发的分布式跟踪的支持,这项任务在一年前提出来,https://github.com/TomPallister/Ocelot/issues/19 这里有我们的讨论,现在集成Butterfly 来实现这个功能,让我们的微服务能够可运维。

要使用跟踪,请阅读Butterfly文档。

在ocelot中,如果要跟踪ReRoute,则需要执行以下操作。

Install-Package Ocelot.Tracing.Butterfly

在您的ConfigureServices方法中

services

.AddOcelot()

// this comes from Ocelot.Tracing.Butterfly package

.AddButterfly(option =>

{

//this is the url that the butterfly collector server is running on...

option.CollectorUrl = "http://localhost:9618";

option.Service = "Ocelot";

});

最后在您的ocelot.json中将以下内容添加到您要跟踪的ReRoute中。

"HttpHandlerOptions": {

"UseTracing": true

},

现在,当调用此ReRoute时,Ocelot将向Butterfly发送跟踪信息。

参考地址:

https://www.cnblogs.com/shanyou/p/8413506.html

https://ocelot.readthedocs.io/en/latest/features/tracing.html

5、源码介绍

5.1、源码结构

API

Booking Api 测试用API

PassengerApi 测试用API

ApiGateWay

Tw.ApiGateway OceLot网关

Tw.IdentityService IdentityServer4服务

Libraies

Tw.Core 功能类库

Tw.Redis 功能类库

Tw.Repository 类库

Tw.Service 类库

MiddleWare

Tw.IdentityServer IdentityServer4中间件源码

Tw.IdentityServer4.AccessTokenValidation 中间件源码

Tw.Ocelot OceLot源码

Tw.Ocelot.Provider.Consul 源码

5.2、下载地址

下载地址:https://github.com/littlewrong/ApiGateway

6、相关资料

1、https://ocelot.readthedocs.io/en/latest/introduction/bigpicture.html 官网介绍

2、http://www.sohu.com/a/132033560_468635 微服务网关Ocelot

3、https://blog.csdn.net/ai52011/article/details/77645009 Surgin API网关

4、https://github.com/KenWang007/OcelotDemo KenWang007/OcelotDemo

5、https://www.cnblogs.com/jaycewu/p/7791102.html IdentityServer4实现Token认证登录以及权限控制

6、http://www.cnblogs.com/edisonchou/archive/2018/07/08/9278775.html .NET Core微服务之基于Ocelot+IdentityServer实现统一验证与授权

7、https://www.cnblogs.com/axzxs2001/p/8487521.html Ocelot + Consul实践

8、https://www.jianshu.com/p/05a1bf2545a0 .Netcore 2.0 Ocelot Api网关教程

9、https://www.cnblogs.com/jesse2013/p/net-core-apigateway-ocelot-docs.html .NET Core开源API网关 – Ocelot中文文档

10、https://www.cnblogs.com/shanyou/p/8413506.html Ocelot 集成Butterfly 实现分布式跟踪

整个框架基本完成,真真想起一句广告词,我们不生产水,我们只是大自然的搬运工!

原文地址:https://www.cnblogs.com/littlewrong/p/9535743.html

时间: 2024-10-10 05:46:21

ASP.NET Core OceLot 微服务实践的相关文章

.Net微服务实践(三):Ocelot配置路由和请求聚合

目录 配置 路由 基本配置 占位符 万能模板 优先级 查询参数 请求聚合 默认聚合 自定义聚合 最后 在上篇.Net微服务实践(二):Ocelot介绍和快速开始中我们介绍了Ocelot,创建了一个Ocelot Hello World程序,接下来,我们会介绍Oclot的主要特性路由和另外一个特性请求聚合.这些特性都是通过配置来实现的. 配置 { "ReRoutes": [], "GlobalConfiguration": {} } Ocelot的配置文件包含两个节点:

.Net微服务实践(四)[网关]:Ocelot限流熔断、缓存以及负载均衡

目录 限流 熔断 缓存 Header转化 HTTP方法转换 负载均衡 注入/重写中间件 后台管理 最后 在上篇.Net微服务实践(三)[网关]:Ocelot配置路由和请求聚合中我们介绍了Ocelot的配置,主要特性路由以及服务聚合.接下来,我们会介绍Ocelot的限流.熔断.缓存以及负载均衡. 限流 我们先来看限流的配置 Reroute节点中的配置如下: { "DownstreamPathTemplate": "/api/orders", "Downstr

.Net微服务实践(五)[服务发现]:Consul介绍和环境搭建

目录 介绍 服务发现 健康检查.键值存储和数据中心 架构 Consul模式 环境安装 HTTP API 和Command CLI 示例API介绍 最后 在上篇.Net微服务实践(四)[网关]:Ocelot限流熔断.缓存以及负载均衡中介绍Ocelot的限流.熔断.缓存.负载均衡以及其他一些特性,Ocelot的基本配置和功能都已经介绍完了.本篇我们会介绍服务发现Consul. 介绍 Consul是一款简单.易用.可伸缩性强的服务治理系统.主要核心功能有:服务发现.健康检查.键值存储和多数据中心. 服

京东、宅急送的微服务实践分享(下)| 架构师小组交流会

架构师小组交流会是由国内知名公司技术专家参与的技术交流会,每期选择一个时下最热门的技术话题进行实践经验分享. 第一期:来自沪江.滴滴.蘑菇街.扇贝架构师的 Docker 实践分享 第二期:来自滴滴.微博.唯品会.魅族.点评关于高可用架构的实践分享 第三期:京东.宅急送的微服务实践分享(上)第三期小组交流会邀请到了国内电商领头羊京东.宅急送技术负责人,在上篇京东.宅急送的微服务实践分享(上)中他们介绍了各自产品的微服务实践,本次他们就 API 网关的设计.服务的 Docker 化.服务测试.持续集

微服务实践之路--RPC

微服务实践之路--RPC 重点来了,本文全面阐述一下我们的RPC是怎么实现并如何使用的,跟Kubernetes和Openstack怎么结合. 在选型一文中说到我们选定的RPC框架是Apache Thrift,它的用法是在Main方法中重启服务,在Client端连接服务去调用, 而我的想法是要跟Dubblo.HSF的用法一样,因为很多人都熟习这两个框架的用法,特别是我们好几个项目都是基于EDAS开发的,而且世面上用Dubbo的公司也很多. 顺便再说一下我们对于RPC的几点要求: 1,兼容Dubbo

微服务实践(总)-原文

本系列文章为 dockone.io 首发,转载请标明出处,以示尊重!! http://dockone.io/people/hokingyang   希望读者通过本系列文章对微服务优缺点有一个比较好的理解,以及何时使用这种架构.也许微服务架构比较适合你的应用.也许你正在开发一个大型.复杂单体式应用,日常开发和部署经验非常缓慢和痛苦,而微服务看起来是远方一个极乐世界.幸运的是,有可以参考的脱离苦海的策略,本篇文章中,我将描述如何逐步将单体式应用迁移到微服务架构. 本系列七篇文章列表如下: 微服务实战

Java微服务实践—Spring Boot系列

Java微服务实践-Spring Boot系列网盘地址:https://pan.baidu.com/s/1aMqPO4pXLeXDHvRuze-JWw 密码: j62z备用地址(腾讯微云):https://share.weiyun.com/c74335d7e383158ee3c4aaf193d471ed 密码:r5gqsk 原文地址:http://blog.51cto.com/12218470/2088359

免费领取 | 微服务实践沙龙-上海站 大咖演讲资料分享

本文来自网易云社区. 9月1日,网易云联合谐云在上海InnoSpace举办了"微服务实践沙龙",邀请到了携程和蚂蚁金服等微服务的先行者,共同分享了落地实践过程中总结的干货经验.感谢讲师和上海小伙伴们的支持,这里将演讲资料分享给大家.网易云还会继续举办易经布道系列的活动,欢迎大家的关注和参与~ 议题1:配置中心,让微服务更『智能』 讲师:携程框架架构研发部技术专家 宋顺 宋老师的PPT暂时不能公开,这里分享他写的文章给大家学习:配置中心,让微服务更"智能" 议题2:微

【视频】使用ASP.NET Core开发GraphQL服务

GraphQL 既是一种用于 API 的查询语言也是一个满足你数据查询的运行时. GraphQL来自Facebook,它于2012年开始开发,2015年开源. GraphQL与编程语言无关,可以使用很多种语言/框架来构建Graph 服务器,包括.NET Core. 像Github,Pinterest,Coursera等公司都在使用GraphQL.Github的API到目前有4个版本,第三个版本用的是REST,而第四个版本使用的是GraphQL. 下面是GraphQL的典型应用场景: 视频教程:使