码迷,mamicode.com
首页 > Web开发 > 详细

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

时间:2019-09-04 13:20:47      阅读:132      评论:0      收藏:0      [点我收藏+]

标签:redis   日志系统   目的   归类   好用   告诉   直接   应该   接受   

前言

对于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 小时的正常服务,有时可能因为数据库处理超时,网络请求超时,从而造成在一段时间内,不能正常响应。

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

这一块是结合 HttpClientFactoryPolly 来实现的,省了很多麻烦。

服务计次

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

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

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

业务指标监控

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

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

日志记录

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

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

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

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

技术图片

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

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

迭代更新

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

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

技术图片

总结

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

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

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

标签:redis   日志系统   目的   归类   好用   告诉   直接   应该   接受   

原文地址:https://www.cnblogs.com/catcher1994/p/11456994.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!