持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第21天，点击查看活动详情
背景
最近在思考如何给研发人员提效，减少重复造轮子。以我最近的接手的项目举栗子，简单说说我自己的看法吧。这是一个公司内部自己用的运营管理的系统，大而全。
简单画了一下，服务的部署架构，admin和merchant分别是商户端和管理端服务。管理系统里面拆分了很多的微服务，但公用同一个数据库。很明显这个存在一个弊端。比如原本运营同学在后端点击了一个月账单查询的一个服务，xxx.com通过域名解析访问到ngnix服务器，转发到后端console服务，经过鉴权校验通过，concole后端生产区的服务直接调用微服务中心的服务。然后后端服务相互之间调用。
这边不讨论这样的微服务拆分是否合理？这里要讨论为什么需要引入微服务网关。 比如现在有两个对外前端，管理和商户端，明天我想在搭建一个dmp商户端。一套鉴权逻辑需要重新搭建一遍，上线之后运维需要重新配置ngnix策略。 后面如果运维机器变更，一些列配置修改非常容器出错，不要问我为什么会容易出错，因为我正在经历这种痛苦。
什么是服务网关？
主要两个功能，服务转发路由和过滤器， 过滤器就包括限流，鉴权，白名单，监控等等，通过网关这边统一处理，减少重复造轮子。
如何设计网关？
一些主要功能
- 路由
- 服务注册
- 负载均衡
- 限流
- 安全策略，鉴权
- 灰度发布
- api聚合
- api编排等等。
网关设计重点 高性能、高可用、高扩展
上面每一个点其实都可以展开来讲讲。
常见网关对比
前常见的开源网关大致上按照语言分类有如下几类：
- Nginx+lua：OpenResty、Kong、Orange、Abtesting gateway 等
- Java：Zuul/Zuul2、Spring Cloud Gateway、Kaazing KWG、gravitee、Dromara soul 等
- Go：Janus、fagongzi、Grpc-gateway
- Dotnet：Ocelot
- NodeJS：Express Gateway、Micro Gateway
按照使用数量、成熟度等来划分，主流的有 4 个：
- OpenResty
- Kong
- Zuul/Zuul2
- Spring Cloud Gateway
