API网关架构与技术选型

  在公司提出了网关的概念，目的是将公共的部分，包括限流、认证鉴权、日志收集，下沉到网关，并做统一的流量入口，来合理的保护我们的服务。避免了重复的开发。做的技术调研。学习了蛮多课程，也看了满多架构的书籍，看了大公司的技术架构。最终选用这套技术架构，比较适合我们小的团队来维护，技术栈也比较匹配。

  我们做服务就是要考虑高可用，其实采用这套架构，最大的好处就是，我们小组可以做公共的服务，来给其他小组提供技术支持。来维护一套高可用的架构。对于多个系统，更容易升级。业务可以更加关注业务。此后想要开发新的业务根本不用关心用户中心，鉴权，限流，日志收集这些内容。

经过技术调研，平台的网关的技术架构选用如图：

 

从一个请求开始，请求首先进入的是nginx流量网关，
流量网关包括了：黑名单，和记录访问日志。记录的日志，将作为流量通过logstash进入ELK监控
选用ELK的搜集技术，将日志整理，并进行统计分析。如果做的足够好，ELK将会是系统平台的眼睛。ES帮助我们更新一份黑名单。从流量的入口来保护应用系统。
经由nginx流量网关的请求，到达业务网关，业务网关首选的技术是gateway
业务网关，对请求做统一的处理，其中包括了统一认证，统一鉴权，包括限流，最后经由注册中心，知道目标服务完成路由转发。

架构所包含的技术

• 从架构图上看到的包括了：
• 流量网关:nginx
• 日志收集：logstash
• 数据统计分析：es
• 数据可视化展示：kibana
• 业务网关：gateway（spring家族）
• 注册中心 + 配置中心：nacos（阿里）
• 鉴权：OAuth2、Security、JWT，包括支持第三方微信登录的支持。
• 流量控制，限流工具：sentinel（阿里）
• 以及需要设计用户中心，利于接入我们的其它项目。
• 由于是微服务，关于远程调用，计划使用OpenFeign，一种声明式接口。

关于技术选型

其实任何一个技术的选型，都可以从以下几个角度考虑

• 语言体系
• 社区的活跃度
• 以及扩展性包括团队可付出的定制化开发的成本
• 性能
• 还应该考虑在压力测试下
• 稳定性究竟如何

  流量网关

  关于nginx的选型应该是毋庸置疑的。ngin支持极高并发连接数访问量，单机1W的并发连接是没有问题的。nginx容易上手，好维护，也是市场上的主流。
• 语言体系：不太用关注，不需要做定制化开发。
• 社区的活跃度：非常活跃
• 以及扩展性包括团队可付出的定制化开发的成本：不太用关注，不需要做定制化开发。
• 性能：单台机器就可以支撑非常高大并发。轻量级，性能损失极少。
• 具体压力测试情况（能够支撑的峰值）：待测试
• 稳定性究竟：很稳定

ELK监控与可视化展示

1. 市场上比较主流的日志统计收集可视化展示的方案。ELK是一套成熟的解决方案。
2. 组内本身就在使用es，和kibana，只接入logstash，不是很困难。

业务网关 gateway

• 语言体系：java
• 社区的活跃度：非常活跃，spring的亲儿子，spring对其有很好的支持。
• 以及扩展性包括团队可付出的定制化开发的成本：基本不需要做定制化开发，即使需要做定制化，也是java语言，难度小。
• 性能：在可选的网关技术中，相对来说损耗较小。损失的性能，完全可以通过扩展机器来满足。
• 具体压力测试情况（能够支撑的峰值）：待测试
• 稳定性究竟：比较稳定

关于业务网关，市场上也有蛮多的技术。一些大的公司一般选择定制化开发。但是从开发语言，可维护性上出发，能选的只有getway和zuul，但是zuul使用的阻塞IO，损失性能极大，虽然新版本有支持，但是spring并没有很好的支持升级后的zuul。gatway是spring做出来的，性能也比较好，支持长连接。对于市场上其它的网关技术，如下图，图来自于《高可用可伸缩微服务架构》，百亿流量微服务亿级网关的设计与实现章节。

 

我看了这本书，上边单点截图也是来自这本书。
《高可用可伸缩为服务架构》书中，有介绍这几个网关的性能的损失，其中性能的话是这样一个顺序：

getway zuul2 < OpenRest < Kong
以直连为参照，getway 和 zuul2 是直连的百分之三十到四十， OpenRest 和 kong 大概是直连的 百分值六十到百分之七十。
对于性能的损失，我们是可以通过增加机器来弥补的。在书中说：其中zuul 的稳定性是非常差的，200用户，1000并发，返回错误竟然有百分之五十。

注册中心和配置中心，采用nacos

关于注册中心，市场上也是有比较多的成熟的方案，携程的Apollo（只作为配置中心）、doubbo（只作为注册中心）、Eruka（注册中心）、阿里的nacos

• Apollo是非常出色的配置中心，支持非常丰富的图形化界面，对权限管理也有很好的支持，非常适合大的团队，进行负责的权限管理。但是搭建比较复杂，支持的功能多，意味着操作起来比较困难，上手容易程度也比较困难。
• Doubbo是阿里的出色的注册中心，但是比较重量级。我们用不到那么多。
• Eruka，spring已经放弃支持了。
• nacos，是阿里的开源产品，社区比较活跃。经过大风大浪。并且nacos同时支持了注册中心和配置中心两项能力。对我们来说，尽可能多的解决问题，尽可能少的引入技术，尽可能少的运维。并且nacos引入非常的简单，也有图形化界面的支持。

鉴权：OAuth2、Security、JWT

关于鉴权，OAuth2、Security、JWT这套技术体系是比较成熟的，我们的鉴权系统也是采用的这套技术。但是对于第三方的登录这次，可能需要重新更改。但是无论如何，都是需要支持的。
鉴权相关内容，可以看这两篇文章，对原理实战都有不错的介绍。
https://blog.csdn.net/star1210644725/article/details/111877433?spm=1001.2014.3001.5501
https://blog.csdn.net/star1210644725/article/details/111878079

流量控制，限流工具：sentinel（阿里）

关于限流，有蛮多的限流算法，计时器法，漏桶算法，令牌桶算法。而阿里的sentinel，所以非常成熟的技术，对限流有着非常丰富的支持，根据ip限流，根据用户ip限流，根据流量大小限流等等。
使用gatway支持的基于redis的也是可以的。