一次业务网关用ASP.NET Core 2.1重构的小结
前言
对于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来发布的，从测试到预发再到生产，流水线的操作。
总结
虽然这个项目挺小的，但是也可以用“麻雀虽小，五脏俱全”来形容。
最后问问，最近有那位大佬招小弟吗？有的话可以联系一下我哈。
