前言
最近一直在忙公司和私下的兼职，白天十个小时，晚上四个小时，感觉每天都是打了鸡血似的，精神满满的，连自己那已经学打酱油的娃都很少关心，也有很长一段时间没有更新博客了，特别抱歉，小伙伴们都等得想取关了吧！哈哈，开个玩笑，这里十分感谢小伙伴们一直以来的关注和支持。 还有不到半个月的时间，猪年就要到来，在这里先提前祝大家猪年吉祥，愿君身体健康，福寿绵长，吉祥如意，财源滚滚，心想事成，万事顺利，新年快乐，好运平安！你看这小猪多可爱，有点像麦兜！甜品先到这儿，我们一起来看本节（也是第三部分的主要思想）重点。你可能会问，怎么突然一下画风全变了，而且还多了这么多的框框和一些看不懂的图标，不急，本来笔者想直接就中间那一部分单独拎出来讲解，但确实无法让部分朋友理解，索性直接将整个微服务架构全部展现了出来。什么是网关？
上一篇我们通过DotNetty构建的远程RPC框架，已经实现了远程客户端的调用，使用的体验是：跟在本地调用接口一样没有任何的区别。但是，这调用是没有任何限制的，任何人、任何客户端、只要知道了服务节点地址，并通过TCP实现RPC调用，便可大大方方的、肆无惮忌的调用这些服务节点，如果就这样部署在生产环境上，是非常危险的。因此，我们需要引入“网关”这样的中间服务，来限制和管理流入的请求合法性和合规性。 当然，这里我们提到的网关，并非物理机上的实体网关交换机（如下图所示）：而是将一台服务器的部分组件，通过软件技术，实现网络管理，比如网卡（笔者曾见过一台DELL服务器上装了11块网卡），通过OSI模型进行管理，实现比如流量限制，路由转发、验证、签权等等一些列功能，所以，我们一般称之为API网关。我们看看网上的统一解释：API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。 --百度通常情况下， API 网关要做很多工作，它作为一个系统的后端总入口，承载着所有服务的组合路由转换等工作，除此之外，我们一般也会把安全，限流，缓存，日志，监控，重试，熔断等放到 API 网关来做。 Kong：Kong是一个可扩展的开放源码API Layer(也称为API网关或API中间件)。Kong 在任何RESTful API的前面运行，通过插件扩展，它提供了超越核心平台的额外功能和服务。Tyk：Tyk是一个开放源码的API网关，它是快速、可扩展和现代的。Tyk提供了一个API管理平台，其中包括API网关、API分析、开发人员门户和API管理面板。Try 是一个基于Go实现的网关服务。Orange：和Kong类似也是基于OpenResty的一个API网关程序。Netflix zuul：Zuul是一种提供动态路由、监视、弹性、安全性等功能的边缘服务。Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器。apiaxle: Nodejs 实现的一个 API 网关。api-umbrella: Ruby 实现的一个 API 网关。ocelot: .Net平台下实现的一个API网关，其中我们的张队（张善友）也参与了此项目的开发。 框架分享出至于/savorboard/p/api-gateway.html#%E8%90%BD%E5%9C%B0%E6%96%B9%E6%A1%88 本系列单从NetCore入手，所以我们只讨论Ocelot网关的作用和使用。什么是Ocelot：
Ocelot是一个用.NET Core实现并且开源的API网关，它功能强大，包括了：路由、请求聚合、服务发现、认证、鉴权、限流熔断、并内置了负载均衡器与Service Fabric、Butterfly Tracing集成，并且这些功能都只需要简单的配置即可完成。简单的说，Ocelot是一堆的 middleware组成的一个管道。当有收到请求后会用一个RequestBuilder去创建一个HttpRequestMessage发送（或请求）到下游服务器，等下游服务器返回Response后再由一个Middleware将HttpRequestMessage映射到当前请求Context中的Response上，并返回给请求者。 这里从张队这边借用一张图，如想了解更多有关Ocelot的原理剖析，可在张队的 博客中了解到更多： /shanyou/p/7787183.html。当然，笔者也推荐查看官方原始API文档： https://ocelot.readthedocs.ioOcelot的使用结构图：
用一台web api来作为Ocelot的宿主，在这里有一个json配置文件，里面设置了所有对当前这个网关的配置。它会接收所有的客户端请求，并路由到对应的下游服务器进行处理，再将请求结果返回。而这个上下游请求的对应关系也被称之为路由。 一起来看看官方给出的基础结构图：在公共网络上，无论是客户端a还是客户端b，还是其他任何智能设备，通过http/https进行访问，都将经过Ocelot进行一次过滤，而这些过滤将通过Ocelot的配置文件及其简单的配置便可实现下游路由转发，然后，在通过指定的下游路由配置，请求到映射的指定服务节点上。当然，这是最只是Ocelot基础的路由转发。结合IdentityServer：
私有网络中，不做验证的畅通访问是极不可取的、非常危险的，因此，Ocelot为我们提供了私有网络身份验证解决方案，我们可以通过跟IdentityServer进行结合，实现私有网络身份验证，当网关需要认证信息的时候会与IdentityServer服务器进行交互来完成。网关的集群：
只有一个网关是很非常危险的，也就是我们通常所讲的单点，一旦只要它挂了，所有的服务全部挂掉，这显然无法达到高可用的目的，所以我们也可以部署多台网关，当然，这个时候在多台网关前，你还需要一台负载均衡器，用于平衡请求到网关的负载的平衡。Consul服务发现：
在Ocelot已经支持简单的负载功能，也就是当下游服务存在多个结点的时候，Ocelot能够承担起负载均衡的作用。但是它不提供健康检查，服务的注册也只能通过手动在配置文件里面添加完成，这不够灵活并且在一定程度下会有风险，这个时候，我们就可以用Consul来做服务发现，它能与Ocelot完美的结合。Ocelot的使用：
在 Core中集成Ocelot网关
既然Ocelot是通过中间件进行网关管理，那么我们肯定就需要一个作为宿主，为了演示DEMO，笔者建立了三个模板为Web API的 core项目，在其中一个 core里通过nuget即可完成安装和集成Ocelot，或者命令行dotnet add package Ocelot以及通过vs package manager添加Ocelot nuget引用都可以，甚至你还可以跟笔者一样喜欢全家桶系列（VS固然非常强大，甚至宇宙第一，但笔者更喜欢三大平台都一模一样的Jetbrains全家桶），用Rider的Nuget管理来安装Ocelot也可以。我们把这个网关项目取名为ApiGatway，然后在这个项目的Startup中添加依赖注入和中间件，即可完成Ocelot安装和注入1 public void ConfigureServices(IServiceCollection services)2 {3services.AddOcelot();4 }5 6 public void Configure(IApplicationBuilder app, IHostingEnvironment env)7 {8if (env.IsDevelopment())9{10 app.UseDeveloperExceptionPage();11}12 13app.UseOcelot().Wait();14 }
添加配置
我们需要添加一个.json的文件用来添加Ocelot的配置，以下是最基本的配置信息。{"ReRoutes": [],"GlobalConfiguration": {"BaseUrl": ""}}
要特别注意一下BaseUrl是我们外部暴露的Url，比如我们的Ocelot运行在http://127.0.0.1的一个地址上（或一个端口上），但是前面有一个Nginx绑定了域名 ，那这里我们的BaseUrl就应该是 。
将配置文件加入Core Configuration
我们需要通过IWebHostBuilder将我们添加的json文件添加进Core中1 public static IWebHostBuilder CreateWebHostBuilder(string[] args) => WebHost.CreateDefaultBuilder(args)2.ConfigureAppConfiguration((hostingContext, builder) =>3 {4builder.SetBasePath(hostingContext.HostingEnvironment.ContentRootPath)5 .AddJsonFile("Ocelot.json");6 })7 .UseStartup<Startup>();8 }
Ocelot的功能配置介绍
通过配置文件可以完成对Ocelot的功能配置：路由、服务聚合、服务发现、认证、鉴权、限流、熔断、缓存、Header头传递等。在配置文件中包含两个根节点：ReRoutes和GlobalConfiguration。ReRoutes是一个数组，其中的每一个元素代表了一个路由，我们可以针对每一个路由进行以上功能配置。下面是一个较完整的配置文件，根据笔者的理解，并加上了详细的注释，方便初学者理解。官方路径戳这儿： https://ocelot.readthedocs.io/en/latest/features/configuration.html{"ReRoutes": [// 路由规则配置节点，数组形式// 可配置多个路由协议和规则，实现路由、服务聚合、服务发现、认证、鉴权、限流、熔断、缓存、Header头传递等{/*下游服务配置配置，网关出口，具体指向的服务器/api/values - 使用限定规则的方式配置下游PATH规则/{url} - 使用泛型（万用）规则方式配置下游PATH规则*/"DownstreamPathTemplate": "/{url}","DownstreamScheme": "http","DownstreamHostAndPorts": [/*下游主机信息可以配置多个主机信息，已提供Ocelot路由负载均衡模式，需配合LoadBalancer节点进行路由负载均衡。*/{"Host": "127.0.0.1","Port": 5000},{"Host": "127.0.0.1","Port": 5001}],/*上游服务配置配置，请求和网关的入口。/api/values - 使用限定规则的方式配置上游PATH规则/{url} - 使用泛型（万用）规则方式配置上游PATH规则*/"UpstreamPathTemplate": "/{url}",// 上游支持的http请求方法"UpstreamHttpMethod": ["Get","Post","Delete","Update"],// 上游域名主机// "UpstreamHost": "",// 当前路由节点的优先级"Priority": 99,/*路由负载均衡:LeastConnection – 将请求发往最空闲的那个服务器RoundRobin – 轮流发送NoLoadBalance – 总是发往第一个请求或者是服务发现*/"LoadBalancer": "LeastConnection","Key": "Route1",}],// 限流配置（请求限流）// 对请求进行限流可以防止下游服务器因为访问过载而崩溃"RateLimitOptions": {// ClientWhitelist - 白名单列表"ClientWhitelist": [],// EnableRateLimiting - 是否启用限流"EnableRateLimiting": true,// Period - 统计时间段 1s, 5m, 1h, 1d"Period": "1s",// PeriodTimespan - 多少秒之后客户端可以重试"PeriodTimespan": 1,// Limit - 在统计时间段内允许的最大请求数量"Limit": 1,// Http头 X-Rate-Limit 和 Retry-After 是否禁用// X-Rate-Limit: 为防止滥用，你应该考虑对您的 API 限流。 例如，您可以限制每个用户 10 分钟内最多调用 API 100 次。// Retry-After: 响应的 HTTP 报头指示所述用户代理应该多长时间使一个后续请求之前等待"DisableRateLimitHeaders": false,// QuotaExceededMessage - 当请求过载被截断时返回的消息"QuotaExceededMessage": "Customize Tips!",// HttpStatusCode - 当请求过载被截断时返回的http status"HttpStatusCode": 999,// ClientIdHeader - 用来识别客户端的请求头，默认是 ClientId"ClientIdHeader": "Test"},// 熔断的意思是停止将请求转发到下游服务。// 当下游服务已经出现故障的时候再请求也是无功而返，并且增加下游服务器和API网关的负担。// 这个功能是用的Pollly来实现的，我们只需要为路由做一些简单配置即可"QoSOptions": {// ExceptionsAllowedBeforeBreaking - 允许多少个异常请求"ExceptionsAllowedBeforeBreaking": 3,// DurationOfBreak - 熔断的时间，单位为秒"DurationOfBreak": 5,// TimeoutValue - 如果下游请求的处理时间超过多少则自如将请求设置为超时"TimeoutValue": 5000},// 本地配置// 可配置多个路由协议和规则，实现服务聚合、服务发现、认证、鉴权、限流、熔断、缓存、Header头传递等"GlobalConfiguration": {// 全局基础路径"BaseUrl": "http://127.0.0.1:8080"}}
View Code Downstream：是下游服务配置UpStream：是上游服务配置Aggregates：服务聚合配置ServiceName, LoadBalancer, UseServiceDiscovery：配置服务发现AuthenticationOptions：配置服务认证RouteClaimsRequirement：配置Claims鉴权RateLimitOptions：为限流配置FileCacheOptions：缓存配置QosOptions：服务质量与熔断DownstreamHeaderTransform：头信息转发
路由：
ocelot的主要功能是接收传入的HTTP请求并将其转发到下游服务，不过目前只支持HTTP请求的形式（将来可能是任何传输机制，暗中窃喜，默默关注和等待吧）。ocelot将一个请求路由到另一个请求描述为路由，为了让任何请求在ocelot中工作，我们需要在配置中设置一个路由。{"ReRoutes": []}
下面这个配置信息就是将用户的请求 /post/1转发到 localhost/api/post/1
{"DownstreamPathTemplate": "/api/post/{postId}","DownstreamScheme": "https","DownstreamHostAndPorts": [{"Host": "localhost","Port": 80,}],"UpstreamPathTemplate": "/post/{postId}","UpstreamHttpMethod": [ "Get"]}
DownstreamPathTemplate：下游服务的路径模板，支持RESTful模板路径。DownstreamScheme：下游服务协议，支持http和https。DownstreamHostAndPorts：下游服务的地址和集合，用于定义要将请求转发到的任何下游服务的主机和端口，通常，这只包含一个条目，但有时您可能希望向下游服务加载负载均衡。UpstreamPathTemplate:上游也就是用户输入的请求Url模板，支持RESTful模板路径，或者设置一个空列表以允许其中任何一个方法。UpstreamHttpMethod:上游请求http方法，可使用数组。
捕获所有（通用模板）：
通用模板即所有请求全部转发，UpstreamPathTemplate与DownstreamPathTemplate设置为 “/{url}”{"DownstreamPathTemplate": "/{url}","DownstreamScheme": "https","DownstreamHostAndPorts": [{"Host": "localhost","Port": 80,}],"UpstreamPathTemplate": "/{url}","UpstreamHttpMethod": [ "Get" ]}
万能模板的优先级最低，只要有其它的路由模板，其它的路由模板则会优先生效。
上游Host：
上游Host也是路由用来判断的条件之一，由客户端访问时的Host来进行区别。比如当/users/{userid}和/users/{userid}两个请求的时候都可以进行区别对待。{"DownstreamPathTemplate": "/","DownstreamScheme": "https","DownstreamHostAndPorts": [{"Host": "10.0.10.1","Port": 80,}],"UpstreamPathTemplate": "/","UpstreamHttpMethod": [ "Get" ],"UpstreamHost": ""}
优先级：
对多个产生冲突的路由设置优化级，可通过priority属性来定义我们希望路由与上游HttpRequest的匹配顺序。{"UpstreamPathTemplate": "/goods/{catchAll}""Priority": 0}{"UpstreamPathTemplate": "/goods/delete""Priority": 1}
比如你有同样两个路由，当请求/goods/delete的时候，则下面那个会生效，也就是说Prority数值越大的会被优先匹配。
请求聚合：
ocelot允许我们指定组成多个正常路由的聚合的重路由，并将它们的响应映射到一个下游对象中，通常情况下，当你有一个客户机向一个服务器发出多个请求时，它可能只是一个服务器，这个特性允许您使用ocelot开始实现前端类型体系结构到后端，还可以减少对后端服务节点的重复处理负载。{"ReRoutes": [{"DownstreamPathTemplate": "/","UpstreamPathTemplate": "/laura","UpstreamHttpMethod": ["Get"],"DownstreamScheme": "http","DownstreamHostAndPorts": [{"Host": "localhost","Port": 51881}],"Key": "Laura"},{"DownstreamPathTemplate": "/","UpstreamPathTemplate": "/tom","UpstreamHttpMethod": ["Get"],"DownstreamScheme": "http","DownstreamHostAndPorts": [{"Host": "localhost","Port": 51882}],"Key": "Tom"}],"Aggregates": [{"ReRouteKeys": ["Tom","Laura"],"UpstreamPathTemplate": "/","Aggregator": "FakeDefinedAggregator"}]}
在Startup中添加AddSingletonDefinedAggregator<FakeDefinedAggregator>来统一处理该路由聚合服务。
services.AddOcelot().AddTransientDefinedAggregator<FakeDefinedAggregator>();
而FakeDefinedAggregator需要继承于IDefinedAggregator，这样下游服务的统一处理将经过该Aggreage后返回到Response中。
1 public class FakeDefinedAggregator : IDefinedAggregator2 {3public Task<DownstreamResponse> Aggregate(List<DownstreamResponse> responses)4{5 ...6}7 }
有了这个特性，您几乎可以做任何您想做的事情，因为下游响应包含内容、头和状态代码，请注意，如果httpclient在向聚合中的重新路由发出请求时抛出异常，那么您将不会得到它的下游响应，但会得到任何成功的响应，如果它确实引发了异常，则会记录此异常。 如果我们设置/tom 和/laura控制器下的返回值分别是 {“Age”: 19}和 {“Age”: 25}，那么我们请求端将收到如下一个Response信息
{"Tom":{"Age": 19},"Laura":{"Age": 25}}
需要注意的是： 聚合服务目前只支持返回json目前只支持Get方式请求下游服务任何下游的response header并会被丢弃如果下游服务返回404，聚合服务只是这个key的value为空，它不会返回404做一些像 GraphQL的处理对下游服务返回结果进行处理 关于GraphQL的功能支持，Ocelot并无原生自带GraphQL动态API查询语句，如果需要集成GraphQL，Ocelot官方有自带示例： /ThreeMammals/Ocelot/tree/develop/samples/OcelotGraphQL
路由负载均衡
当下游服务有多个结点的时候，我们可以在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 –总是发往第一个请求或者是服务发现
限流
对请求进行限流可以防止下游服务器因为访问过载而崩溃，这个功能就是我们的张队添加进去的，Ocelot支持上游请求的速率限制，这样您的下游服务就不会过载。"RateLimitOptions": {"ClientWhitelist": [],"EnableRateLimiting": true,"Period": "1s","PeriodTimespan": 1,"Limit": 1}
ClientWihteList白名单EnableRateLimiting是否启用限流Period统计时间段：1s, 5m, 1h, 1dPeroidTimeSpan多少秒之后客户端可以重试Limit在统计时间段内允许的最大请求数量 在 GlobalConfiguration下我们还可以进行以下配置
"RateLimitOptions": {"DisableRateLimitHeaders": false,"QuotaExceededMessage": "Customize Tips!","HttpStatusCode": 999,"ClientIdHeader" : "Test"}
Http头 X-Rate-Limit和 Retry-After是否禁用QuotaExceedMessage当请求过载被截断时返回的消息HttpStatusCode当请求过载被截断时返回的http statusClientIdHeader用来识别客户端的请求头，默认是 ClientId
服务质量和熔断
熔断的意思是停止将请求转发到下游服务。当下游服务已经出现故障的时候再请求也是功而返，并且增加下游服务器和API网关的负担。这个功能是用的Pollly来实现的，我们只需要为路由做一些简单配置即可。关于Polly的使用，我会在下一个章节中介绍。"QoSOptions": {"ExceptionsAllowedBeforeBreaking":3,"DurationOfBreak":5,"TimeoutValue":5000}
ExceptionsAllowedBeforeBreaking允许多少个异常请求DurationOfBreak熔断的时间，单位为秒TimeoutValue如果下游请求的处理时间超过多少则自如将请求设置为超时
缓存
Ocelot支持一些非常基本的缓存功能，他是基于CacheManager实现的，当然，我们在使用的过程中，也需要安装CacheManager这个lib包，然后通过Ocelot Cache manager扩展方法来添加CacheManager实现。1 service.AddOcelot()2.AddCacheManager(x =>3{4 x.WithDictionaryHandle();5})
"FileCacheOptions": { "TtlSeconds": 15, "Region": "somename" }
在这个例子中，ttl设置为15秒，那么缓存所存在的时长就只有15秒。当然，你也可以通过添加你自定义缓存接口来注入自定义缓存服务。
1 services.AddSingleton<IOcelotCache<CachedResponse>, MyCache>()
认证
如果我们需要对下游API进行认证以及鉴权服务的，则首先Ocelot网关这里需要添加认证服务。这和我们给一个单独的API或者Core Mvc添加认证服务没有什么区别。1 public void ConfigureServices(IServiceCollection services)2 {3var authenticationProviderKey = "TestKey";4 5services.AddAuthentication()6 .AddJwtBearer(authenticationProviderKey, x =>7 {8 });9 }
然后在ReRoutes的路由模板中的AuthenticationOptions进行配置，只需要我们的AuthenticationProviderKey一致即可。
"ReRoutes": [{"DownstreamHostAndPorts": [{"Host": "localhost","Port": 51876,}],"DownstreamPathTemplate": "/","UpstreamPathTemplate": "/","UpstreamHttpMethod": ["Post"],"ReRouteIsCaseSensitive": false,"DownstreamScheme": "http","AuthenticationOptions": {"AuthenticationProviderKey": "TestKey","AllowedScopes": []}}]
签权
我们通过认证中的AllowedScopes拿到 claims之后，如果要进行权限的鉴别需要添加以下配置。"RouteClaimsRequirement": {"UserType": "registered"}
当前请求上下文的token中所带的claims如果没有name=”UserType”并且 value=”registered”的话将无法访问下游服务。
一个简单的例子
上面我们简单介绍了一下Ocelot的部分功能，要需完整功能介绍，可参考官方文档进行 https://ocelot.readthedocs.io，接下来笔者做了一个简单的路由转发的示例，来演示一下Ocelot基于http/https协议的强大而又简单的功能。 基于上面介绍的三个项目，我们只介绍了作为网关能使用到的功能，另外我们还需要一个上游作为请求客户端（当然，笔者更喜欢将客户端做成一个Console控制台，方便，快捷），一个下游作为服务端，项目名称任意。 当下游服务端的默认模板被创建后，默认会创建一个ValueController，为了演示和获取当前路由转发的结果，我们只需要对其中一个接口稍作修改，设置默认启动端口为5000。1 // GET api/values2 [HttpGet]3 public ActionResult<IEnumerable<string>> Get()4 {5return new[] { "WebServer", Request.GetDisplayUrl() };6 }
而上游服务中，可以用HttpClient来模拟一个请求。
1 using (var httpClient = new HttpClient())2 {3// 此处访问的是网关的接口映射路径，而不是实际的接口URL路径4var response = httpClient.GetAsync(new Uri("http://127.0.0.1:8080/api/values")).Result;5Console.WriteLine("response: " + response);6Console.WriteLine("content: " + response.Content.ReadAsStringAsync().Result);7 }
此处8080作为ApiGateway服务端，默认使用通用路由模板（上游和下游直接路由通用匹配{url}），代码不再贴出。启动8080网关和5000服务端，通过Console控制台直接访问8080所配置（映射）出来的公开地址（实际就是5000上的api/values），可看到如下的结果。 如需查看更多的demo示例和源码，可参考笔者的源码 /steveleeCN87/doteasy.rpc/tree/master/src/doteasy.rpc.demo
总结
Ocelot能实现的功能远远不止这些，更多内容可以参考Ocelot官方API或张队的解说。补个插曲
对了，关注DotEasy.Rpc小伙伴们，该框架已经更新到1.0.3，主要增加和修改了以下内容： 1.接口注册改用Autofac，实现统一批量接口注入，而非每次手动一个一个的去注入接口。 2.通过代理生成，将原有的“兔子耳朵”取消，增加了客户端非异步远程调用方式，避免每次调用均实现Task非阻塞方式来实现接口调用。 3.通过代理生成，调用端将自动释放接口实例资源，也就是IDisposable接口的实现，而客户端不用实现。 4.通过代理生成，如服务节点中不存在网关服务（非微服务，而是直接的RPC调用），客户端对服务端的访问可使用Token进行身份验证。 现在的客户端代码是越来越简单，功能越来越丰富了：1 public static void Test()2 {3const string token =4 "eyJhbGciOiJSUzI1NiIsImtpZCI6IjRhMjZjNDZlMzY0NjY2ODgwYjk0MGE1YjZmY2FkMCIsInR5cCI6IkpXVCJ9.eyJuYmYiOjE1NDc0MzMwOTEsImV4cCI6MTU0NzQzNjY5MSwiaXNzIjoiaHR0cDovLzEyNy4wLjAuMTo4MDgwIiwiYXVkIjpbImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC9yZXNvdXJjZXMiLCJhcGkxIl0sImNsaWVudF9pZCI6InJvLmNsaWVudCIsInN1YiI6IjEiLCJhdXRoX3RpbWUiOjE1NDc0MzMwOTEsImlkcCI6ImxvY2FsIiwic2NvcGUiOlsiYXBpMSJdLCJhbXIiOlsicHdkIl19.SmzE3KR_FOfIFIzjnAqiHVt35uefpuiExtnwKO9msIYl389bLjvLWqgwyRV5XgT0oIPYcvj2Th5ABBM9baD-pHCOaGooEwHYA4ydu1yabqEKLIooEV_mo73OSQHMYIo9DGzTddg8Ut7JKyVHLZAAJfz6NMp6NZwunEMrF1NsIj6GiL1psZ-kyZSrvIdUSFHh92mCjPmiUfUdUPZIlVZLYrFEsxJQ6gHgQUpMwwQscdoLXkyw6PJ6xLhW_RJvOYWMust1TIvMqVaxsouuaV6EKACpOJndSy7JuQy-_7Gbes7jYlrS-bntsLoi4SK9SDJenlHHc-lCUIbsHIDkbZEiwg";5 6using (var proxy = ClientProxy.Generate<IProxyService>(new Uri("http://127.0.0.1:8500"), token))7{8 Console.WriteLine($@"{proxy.MultiParTest("aaaa", "bbb", "ccccc")}");9 Console.WriteLine($@"{proxy.GetDictionary().Result["key"]}");10 Console.WriteLine($@"{proxy.Async(1).Result}");11 Console.WriteLine($@"{proxy.Sync(1)}");12}13 14Console.ReadKey();15 }
下一步将研究和实现网关中http到rpc协议自动（或手动）转换，也许会走弯路，喜欢的小伙伴请继续关注，也将在下一篇介绍。
感谢阅读！最后再次祝大家新年快乐！
