微服务架构实践之api-gateway _微服务架构

在微服务架构风格中，一个大应用通常会被拆分成为了多个小的服务系统提供出来，这些小的系统他们可以自成体系，也就是说这些小系统可以拥有自己的数据库，框架甚至语言等，这些小系统通常以提供 Rest Api 风格的接口来被 H5, Android, IOS 以及第三方应用程序调用。

我们通常需要在一个界面上展示很多数据，这些数据可能来自于不同的微服务中，比如在一个电商系统中，查看一个商品详情页，这个商品详情页包含商品的标题，价格，库存，评论等，这些数据对于后端来说可能是位于不同的微服务系统之中。我们要如何从这些微服务中拉取相应的信息回来呢？
基于以上背景，在微服务架构中，我们可能会遇到一下问题：

服务的划分可能随着时间或者需求变更而变化
服务实例会动态变化
服务的API粒度，相对而言在微服务架构中，每个服务都只提供相对细粒度的API
不同的客户端（H5,App等）可能需要不同的数据

这种情况下，我们就需要：API 网关（API Gateway）。API 网关模式意味着你要把API 网关放到你的微服务们的最前端，并且要让 API 网关变成由应用所发起的每个请求的入口，这样就可以明显的简化客户端实现和微服务应用程序之间的沟通方式。
API 网关API Gateway 可以分为两种：
1.单节点 API Gateway

文章插图
2.BFF(Backends for frontends) Gateway

文章插图
API 网关职责
在我们内部，API 网关需要承担包括但不限于下面的这些职责：
1.请求路由，版本控制
API Gateway 是微服务的入口，可以根据不同的请求路由到不同的服务上，也可以在 Gateway 上进行路由的版本控制，这样即使后服务发生了变化，Gateway 的路径依然可以不改变。
2.用户登录，权限认证
【微服务架构实践之api-gateway】客户端在与我们后端服务进行交互之前，需要先进行登录鉴权操作，这是后端所有的服务都需要有的共有逻辑，因此在 Gateway 做这个事情就再合适不过。
3.数据聚合
由于不同的客户端往往需要的数据完全不同，而这些数据又是不同的 service 提供的，比如上面提到的查看一个商品详情页，我们可能需要同时从商品服务，库存服务，评价服务等中拉取信息，我们可以借助 Gateway 方便完成来自不同 service 的数据聚合。
4.协议转换
在我们的实践中，CS（Client to Server）协议和SS（Server to Server）协议是不一样的，为了保证数据传输的可靠性，我们的CS协议会有鉴权以及加密解密的逻辑，而在内部的SS协议则不需要这些逻辑，因此在 Gateway 我们需要有一个协议转换的过程。
5.熔断，降级，限流
当监测到某个服务发生异常，或者当服务的流量超过我们服务的承载能力等情况时，我们可以采取相应的措施，对整个系统的容错性、稳定性有很大帮助。
6.负载均衡
API 网关知道所有服务实例的地址，所以可以根据不同服务采取不同的负载均衡策略。
7.灰度发布
有时候我不希望让所有的流量都一次性的到达程序的新版本，因为那个新版本也许并没有测试地很充分。灰度发布允许你直接只导入指定量的流量到新的版本，API 网关就可以帮你来做这件事情。你可以配置10%的请求到新的版本，然后一旦你确保了新版本没有bug，你可以把流量切换到100% 。
API 网关架构在我们的内部规划中(部分功能未实现)，我们的 API 网关主要会分为三个部分，也就是上图中绿色的几部分：
1.多网关集群(Backends for frontends)
我们针对不同的客户端，都有相应的网关层来接入。现阶段这一部分已经实现的功能主要是：用户登录，鉴权，服务发现注册，协议转换，接口版本控制等。后续我们还规划的功能有：监控，APM调用链，日志，流控策略等。
2.聚合服务(Merge Service)
在某些客户端的需求中，比如上面提到的商品详情的页面，我们需要从多个服务拉取数据，为了减少客户端的复杂度，以及加快客户端的访问速度，我们会在前面加一个聚合层，用来做聚合查询，在某些接口中可以把多个服务的数据一次性返回给客户端。
3.仪表盘管理端(Dashboard)
Dashboard 提供可视化的分析平台，包括服务的管理，监控数据报警配置，日志查询，灰度发布操作，API文档管理等，这些功能对于开发和日常运维来说是非常重要的。