一次业务网关用ASP.NET Core 2.1重构的小结

Posted 2022-09-30 catcher1994

目录

• 前言
• 统一鉴权
• 服务限流
• 路由转发
• 参数重组
• 链路跟踪
• 熔断降级
• 服务计次
• 业务指标监控
• 日志记录
• 迭代更新
• 总结

前言

对于API网关，业界貌似对它进行下划分，有下面几个分类/场景。

• 面向Web App
• 面向Mobile App
• 面向Partner OpenAPI
• 面向Partner ExternalAPI
• 其他。。。

在18年8月份的时候，有幸用.NET Core 2.1重构了一个对外的业务网关项目，这个项目的作用其实就是将公司内部能提供的数据能力公开出来，可以让有需要的公司使用。

这个项目按照分类，应该是要归类到 面向Partner OpenAPI 。

这个项目刚开始是用Nancy写的，那个时候要向外提供一个新的能力的时候，都是要加这个能力的代码，发布后才能真正的对外提供，不过当时对外提供的东西比较少，负责的同事也要闪人了，所以也还是可以接受。

在18年7月份的时候，越来越多的能力要对外提供，而且每次都要改代码，受不了，就提出了重构。

这个项目目前每天大概有1500万左右的有效调用量，部署在6台4c4g的CentOS虚拟机上面(其实用不了那么多机器，每台机器的基本都是20%以下的cpu和10%左右的内存)，用Jexus去托管。大入口是nginx，所以最后的流向是：

Request -> Nginx -> Jexus -> dotnet

下面就分别来说说这个网关涉及到的一些东西。

统一鉴权

鉴权这一块用的还是很古老的做法，用的是用户名和密码的方式来处理，这个可以理解成是验签的一个过程。

这里支持两种形式，一种是参数明文传输，还有一种是参数加密传输。

其实就是有部分公司觉得我不能直接传明文的123给你，要传一个加密后的123，让你解密然后去处理。

服务限流

限流功能就是限制调用方过于频繁的调用，这个限制，根据业务场景分为秒、天、月三个层级。

不同调用方，不同数据服务都有不同的限制，这个是基于Redis来实现的。

路由转发

路由转发用的是HttpClientFactory。

刚开始的时候还是用steeltoe来处理服务注册和发现，不过发现并不好用，然后也有很多服务没有接入 Eureka， 所以最后就没有处理服务注册和发现，而是直接用域名的方式来请求。

参数重组

用户的请求参数基本上都会是透传给下游服务，当然不能排除会有一些特殊的需求。

举个简单的例子说明一下，好比只想让调用方查广州的天气，不想让他查深圳的天气，而下游服务是这两个城市都可以查的，所以要有一些特殊的参数去告诉下游服务。

这个时候，我们就需要对用户的入参进行一次重组，重新构造了一个JSON参数丢给下游服务，相当于特殊情况会有固定的参数格式给到下游服务，用的是JObject来处理。

链路跟踪

由于调用链有的时候非常复杂，为了记录调用方一个请求完整的调用链，网关这边会生成一个traceId在请求头，路由转发的时候会一起发过去。

不同服务在记录日志的时候就会把这个traceId也统一记录起来，这样所有的日志都可以通过这个traceId从日志系统中找到。

熔断降级

下游服务不一定能保证 7*24 小时的正常服务，有时可能因为数据库处理超时，网络请求超时，从而造成在一段时间内，不能正常响应。

这个时候网关就不应该每次都去真正的请求服务，而要断开一段时间，直接返回失败给调用方。

这一块是结合 HttpClientFactory 和 Polly 来实现的，省了很多麻烦。

服务计次

计次可以说是这个网关的一大核心，因为要赚钱，要收调用方的钱。钱基本就是按次数算出来的。

之前写过一篇博客，实现是类似的。

按次计费接口的简单实现思路。

业务指标监控

需要知道最近某段时间范围内，不同调用方，不同数据服务的调用情况(成功，失败，有效，总次数等)

这里用的是prometheus，程序负责写指标数据，prometheus会去拉取这些数据，然后结合Grafana来做成不同的看板来展示。

日志记录

日志记录为分两大类，一类是程序日志，一类是调用日志。

程序日志目前是拓展NLog，把数据丢到Kafka，然后运维那边会抽数据到Elasticsearch。

为了避免Kafka抽风，所以丢数据到Kafka失败的话，会落盘到日志文件，然后由Filebeat收集，然后丢到Elasticsearch。

最后的展现形式是 graylog， 大概如下

调用日志是和调用方结算的依据之一，所以这个的重要性还是挺高的。

目前用的是异步写入加容错。调用日志最终是落到数据库归档。

迭代更新

更新对一个程序来说是必不可免的，所以有一个好的发布流程可以减少一些困难。虽说重构后，这个项目也就更新了3次。

这里用的是Go CD来发布的，从测试到预发再到生产，流水线的操作。

总结

虽然这个项目挺小的，但是也可以用“麻雀虽小，五脏俱全”来形容。

最后问问，最近有那位大佬招小弟吗？有的话可以联系一下我哈。