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

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

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

服务计次

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

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

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

业务指标监控

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

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

日志记录

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

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

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

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

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

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

迭代更新

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

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

总结

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

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

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

时间: 2024-11-04 14:18:07

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

asp.net core api网关 实时性能监控

asp.net core api网关 实时性能监控 使用InfluxDB.Grafana Dockerfile 运行 InfluxDB.Grafana influxdb: image: influxdb ports: - "8086:8086" - "8083:8083" environment: - INFLUXDB_DB=TogetherAppMetricsDB - INFLUXDB_ADMIN_ENABLED=true - INFLUXDB_ADMIN_USE

微服务介绍及Asp.net Core实战项目系列之微服务介绍

0.目录 整体架构目录:ASP.NET Core分布式项目实战-目录 一.微服务选型 在做微服务架构的技术选型的时候,以"无侵入"和"社区活跃"为主要的考量点,将来升级为原子服务架构.量子服务架构的时候.甚至恢复成单体架构的时候,代价最小. 软件开发只需要组装,不再需要从头开发. 选型可以参考一下张队长的文章:https://mp.weixin.qq.com/s/UIFjm7W6bDfdmjpeMVJtqA 二.微服务架构是什么? 每一个微服务都是一个零件,并使用这

ASP.NET Core 企业开发架构概述

企业开发框架包括垂直方向架构和水平方向架构.垂直方向架构是指一个应用程序的由下到上叠加多层的架构,同时这样的程序又叫整体式程序.水平方向架构是指将大应用分成若干小的应用实现系统功能的架构,同时这样的系统叫做分布式系统.在架构上java和.net世界都有优秀的框架支持构建垂直和水平方向架构.ASP.Net Core非常轻量且具有很高的性能,不仅适合做整体式程序,也非常适合做分布式系统.随着微服务的兴起,各种语言的混合应用是个趋势. 转载:http://www.cnblogs.com/vipyoum

ASP.NET Core OceLot 微服务实践

1.OceLot中间件介绍 在传统的BS应用中,随着业务需求的快速发展变化,需求不断增长,迫切需要一种更加快速高效的软件交付方式.微服务可以弥补单体应用不足,是一种更加快速高效软件架构风格.单体应用被分解成多个更小的服务,每个服务有自己的独立模块,单独部署,然后共同组成一个应用程序.把范围限定到单个独立业务模块功能.分布式部署在各台服务器上. 而Ocelot开发的目标就是使用.NET运行面向微服务/服务的架构,要达到这个目标需要一个统的系统入口点(我们统称为API网关),同时需要与Identit

asp.net core 自定义认证方式--请求头认证

原文:asp.net core 自定义认证方式--请求头认证 asp.net core 自定义认证方式--请求头认证 Intro 最近开始真正的实践了一些网关的东西,最近写几篇文章分享一下我的实践以及遇到的问题. 本文主要介绍网关后面的服务如何进行认证. 解决思路 网关可以做一部分的认证和授权,服务内部有时候也会需要用户的信息,这时该怎么办呢,我们使用的是 JWT 认证,有一个 identity server去颁发,验证 token,一种简单方式可以把 token 直接往后传,传递给后面的具体某

[目录] ASP.Net Core 微服务搭建网站

我有一个心愿,可以用最优化的代码完成一个功能丰富的网站. 全文将围绕(1)设计模式  (2)敏捷开发 目的: 结构足够合理,代码足够优美,扩展性.可读性.易维护性做到最优. 以下目录仅为整体思路,后期逐渐完善补充. 1.配置linux环境实现持续集成 2.快速搭建 ASP.net core Web 应用 3.单元测试 4.数据库配置管理 5.服务注册中心 6.网站登录页面 7.用户管理 8.角色管理 9.租户(组织单位)管理(Saas) 10.模块管理 11.菜单(导航)管理 12.主题配置 1

Asp.Net Core 中IdentityServer4 实战之 Claim详解

一.前言 由于疫情原因,让我开始了以博客的方式来学习和分享技术(持续分享的过程也是自己学习成长的过程),同时也让更多的初学者学习到相关知识,如果我的文章中有分析不到位的地方,还请大家多多指教:以后我会持续更新我的文章,望大家多多支持和关注. 上几篇文章主要分享了IdentityServer4在Asp.Net Core 3.x 中的应用,在上面的几篇分享中有一部分博友问了我这么一个问题"他通过IdentityServer4 来搭建授权中心网关服务,怎么才能在访问受保护的Api资源中获取到用户的相关

ASP.NET Core微服务框架Ocelot+Consul+IdentityServer4实战演练

一.背景介绍 API网关的流行源于最近几年移动应用与企业间接口对接的兴起,使得原来单一的PC客户端,变化到PC客户端.各种浏览器.手机移动端及智能终端等.同时系统之间大部分都不是单独运行,经常会涉及与其他系统对接.共享数据的需求.随着微服务架构概念的提出,API网关成为了微服务架构的一个标配组件.随着业务快速发展,面向手机移动应用业务越来越多,为了减少客户端与服务的耦合,节约后端微服务的开发成本,建立一个高性能.高可用.减少上线风险的API网关成为一个迫切的需求. 1).目前面临现状:假设你正好

Asp.Net Core 项目实战之权限管理系统(7) 组织机构、角色、用户权限

0 Asp.Net Core 项目实战之权限管理系统(0) 无中生有 1 Asp.Net Core 项目实战之权限管理系统(1) 使用AdminLTE搭建前端 2 Asp.Net Core 项目实战之权限管理系统(2) 功能及实体设计 3 Asp.Net Core 项目实战之权限管理系统(3) 通过EntityFramework Core使用PostgreSQL 4 Asp.Net Core 项目实战之权限管理系统(4) 依赖注入.仓储.服务的多项目分层实现 5 Asp.Net Core 项目实