一.背景 目前我们项目是采用的 Ocelot 作为 API 网关,并且在其基础上结合 IdentityServer4 开发了一套 API 开放平台.由于部分项目是基于 ABP 框架进行开发的,接口的平均 QPS 基本是在 2K~3K /S 左右 (E3 1231 16G).采用 Ocelot 进行请求转发之后,前端反馈接口调用速度变慢了,也没有太过在意,以为是项目接口的问题,一直在接口上面尝试进行优化. 极限优化接口后仍然没有显著改善,故针对 Ocelot 的性能进行压力测试,得到的结果也是让我

目前,Ocelot使用标准的日志记录接口ILoggerFactory/ILogger . 在IOcelotLogger / IOcelotLoggerFactory中提供了标准的asp.net core日志记录的一个实现. 因为Ocelot在日志中添加了一些额外的信息,如请求ID(如果已配置的话). 这有个全局的错误处理程序,可以捕获所有异常并作为错误记录他们. 最后,如果日志记录设置为跟踪级别,Ocelot将记录开始,结束和任何抛出异常的中间件,这些异常可能非常有用. 不是使用标准框架的日志记

[.NET Core项目实战-统一认证平台]开篇及目录索引 一.背景 首先说声抱歉,可能是因为假期综合症(其实就是因为懒哈)的原因,已经很长时间没更新博客了,现在也调整的差不多了,准备还是以每周1-2篇的进度来更新博客,并完成本项目所有功能. 言归正传,本重构项目是在我根据实际需求重构,由于还未完全写完,所以也没进行压测,在2月份时,张善友老师给我留言说经过压测发现我重构的Ocelot网关功能性能较差,其中根本原因就是缓存模块,由于重构项目的缓存强依赖Redis缓存,造成性能瓶颈,发现问题后,我

l  前言 本文记录了我的一次.net core 微服务架构实践经验,以及所用到的技术 l  优点 每个服务聚焦于一块业务,无论在开发阶段或是部署阶段都是独立的,更适合被各个小团队开发维护,团队对服务的整个生命周期负责,工作在独立的上下文之中. 如果某一项服务的性能达到瓶颈,我们只需要增加该服务负载节点,能够针对系统的瓶颈服务更有效的使用资源. 服务A可以使用.net实现 ,服务B可以使用java实现,技术选型灵活,系统不会长期限制在某个技术栈上. 松耦合.高内聚,代码容易理解,开发效率高,更好

在<技术中台与业务中台都是啥玩意>一文中留下一个问题:BFF是啥?为啥在API网关和业务中台之间加入了一层BFF?考虑到在实际工作中,我的大部分同事都问过这个问题,这里我也总结一下进行答复. 一.从一个MyShop开始说起 为了讲清BFF是个啥,这里引用我在波波老师的课程<Spring Boot与K8s云原生应用开发>中学到的一个案例,来跟大家分享一下,并尽力说清楚BFF是啥,又是如何演化出来的. 假设我们在一个开发团队中,开发了一个叫做MyShop的电商项目,它采用的是微服务的架

在微软Tech Summit 2017 大会上和大家分享了一门课程<.NET Core 在腾讯财付通的企业级应用开发实践>,其中重点是基于ASP.NET Core打造可扩展的高性能企业级API网关,以开源的API网关Ocelot为基础结合自己的业务特性,当天课程只有40分钟,有很多内容都没有展开,接下来就用一篇小文章来聊下Ocelot 的实现原理,大家在使用的过程中也可以一起来贡献. 总体来说这是一个ASP.NET Core 高级编程的内容,之前在公众号里已经发过不少各位朋友写的文章,今天都会

微服务,通常都是用复杂的.大规模分布式集群来实现的.微服务构建在不同的软件模块上,这些软件模块,有可能是由不同的团队开发.可能使用不同的编程语言来实现.有可能布在了几千台服务器,横跨多个不同的数据中心.因此,就需要一些可以帮助理解系统行为.用于分析性能问题的工具. API网关Ocelot 作为微服务的一个重要组件,出现在系统边界上的一个面向API的.串行集中式的强管控服务,这里的边界是企业IT系统的边界,主要起到隔离外部访问与内部系统的作用.通过API网关对外发布的通常是OpenAPI,在它的后

Ocelot允许您指定服务发现提供程序,并使用它来查找Ocelot正在将请求转发给下游服务的主机和端口.目前,这仅在GlobalConfiguration部分中受支持,这意味着所有ReRoute将使用相同的服务发现提供程序,以便在ReRoute级别指定ServiceName. Consul GlobalConfiguration中需要以下内容. 提供者是必需的,如果你没有指定主机和端口,默认使用Consul. "ServiceDiscoveryProvider": { "Ho

Tip: 此篇已加入.NET Core微服务基础系列文章索引 一.关于App.Metrics+InfluxDB+Grafana 1.1 App.Metrics App.Metrics是一款开源的支持.NET Core的监控插件,它还可以支持跑在.NET Framework上的应用程序(版本 >= 4.5.2).官方文档地址:https://www.app-metrics.io/ 1.2 InfluxDB InfluxDB是一款开源的分布式时序.时间和指标数据库,使用go语言编写,无需外部依赖.官

前言 我们都知道,API网关是工作在应用层上网关程序,为何要这样设计呢,而不是将网关程序直接工作在传输层.或者网络层等等更底层的环境呢?让我们先来简单的了解一下TCP/IP的五层模型.     (图片出自http://www.cnblogs.com/qishui/p/5428938.html)   具体的每一层的工作原理想必大家都已经滚瓜烂熟了,笔者也不在重复的复述这内容.回到上面的问题,为何API网关需要工作在应用层上的问题就变得一目了然,物理层面的网关是交给物理设备进行的,例如物理防火墙,而

[.NET Core项目实战-统一认证平台]开篇及目录索引 一.什么是RPC RPC是"远程调用(Remote Procedure Call)"的一个名称的缩写,并不是任何规范化的协议,也不是大众都认知的协议标准,我们更多时候使用时都是创建的自定义化(例如Socket,Netty)的消息方式进行调用,相比http协议,我们省掉了不少http中无用的消息内容.因此很多系统内部调用仍然采用自定义化的RPC调用模式进行通信,毕竟速度和性能是内网的关键指标之一,而标准化和语义无关性在外网中举足

原文 Ocelot使用标准的日志接口ILoggerFactory和ILogger<T>.它们封装在IOcelotLogger 和 IOcelotLoggerFactory中,因为ocelot要添加一些额外的信息(eg:request id)到日志中去. 还有一个内置的全局error handler,用来捕获异常并打日志. 如果日志级别设置为trace, ocelot将log starting, finishing和任何中间件抛出的异常. Warning 如果日志是设置输出到Console的,那

Ocelot在github的地址 https://github.com/TomPallister/Ocelot , 非常给力的是在课程当天完成了.NET Core 2.0的升级,升级过程请看https://github.com/TomPallister/Ocelot/issues/114 .昨天我花了半小时就把我的另外一个POC项目Nanofabric   https://github.com/geffzhang/NanoFabric 升级到了.NET Core 2.0, 这个POC项目也是我的

本文主要介绍通过Docker来部署通过.Net Core开发的微服务架构,部署的微服务主要包括统一网关(使用Ocelot开发).统一认证(IdentityServer4).应用服务(asp.net core web api): 本文不针对微服务进行说明,后续会针对我对微服务的理解在做记录. 一.Docker原理 对 Docker 最简单并且带有一定错误的认知就是 “Docker 是一种性能非常好的虚拟机”. 但是这是有一定错误的说法.Docker 相比于传统虚拟机的技术来说先进了不少,具体表现在

Ocelot允许您指定服务发现提供程序,并使用它来查找Ocelot正在将请求转发给下游服务的主机和端口.目前,这仅在GlobalConfiguration部分中受支持,这意味着所有ReRoute将使用相同的服务发现提供程序,以便在ReRoute级别指定ServiceName. Consul GlobalConfiguration中需要以下内容. 提供者是必需的,如果你没有指定主机和端口,默认使用Consul. "ServiceDiscoveryProvider": { "Ho

Ocelot——初识基于.Net Core的API网关 Ocelot API网关的实现剖析 微服务网关Ocelot API网关Ocelot 使用Polly 处理部分失败问题 谈谈微服务中的 API 网关(API Gateway) Ocelot网关 Ocelot统一权限验证 应用监控怎么做? ASP.NET Core之跨平台的实时性能监控 .Net Core 2.0+ InfluxDB+Grafana+App Metrics 实现跨平台的实时性能监控 应用程序的8个关键性能指标以及测量方法 使用M

Ocelot API网关的实现剖析   在微软Tech Summit 2017 大会上和大家分享了一门课程<.NET Core 在腾讯财付通的企业级应用开发实践>,其中重点是基于ASP.NET Core打造可扩展的高性能企业级API网关,以开源的API网关Ocelot为基础结合自己的业务特性,当天课程只有40分钟,有很多内容都没有展开,接下来就用一篇小文章来聊下Ocelot 的实现原理,大家在使用的过程中也可以一起来贡献. 总体来说这是一个ASP.NET Core 高级编程的内容,之前在公众号

Ocelot允许您指定服务发现提供程序,并使用它来查找Ocelot正在将请求转发给下游服务的主机和端口.目前,这仅在GlobalConfiguration部分中受支持,这意味着所有ReRoute将使用相同的服务发现提供程序,以便在ReRoute级别指定ServiceName. Consul GlobalConfiguration中需要以下内容. 提供者是必需的,如果你没有指定主机和端口,默认使用Consul. "ServiceDiscoveryProvider": { "Ho

网上搜索发现多篇文章指出ocelot的性能有问题,可是在ocelot项目issue提问中,维护者指出,ocelot的性能问题不大.瓶颈在于.net的httpclient. 我参考文章 https://www.cnblogs.com/myzony/p/10401298.html 制作了一个测试项目,并将代码传到了github,供有需要的人自行测试. wrk我在ubuntu wsl中未能编译通过,所以改用了ab测试. 源码请见: https://github.com/wswind/Ocelot-Pe

前言: 上一篇 介绍了Ocelot网关和认证服务的结合使用,本篇继续介绍Ocelot相关请求聚合和Ocelot限流 一.请求聚合 Ocelot允许声明聚合路由,这样可以把多个正常的Routes打包并映射到一个对象来对客户端的请求进行响应. 例如:在获取订单记录时,也需要查看订单中对应的商品信息,这里的数据就来源于两个微服务:订单服务.商品服务.如果不使用聚合路由时,对于现实一个订单信息时,客户端需要调用两次服务请求,实际上会造成服务端额外的性能消耗.这是如果配置了聚合路由时,客户端只需要请求一次