微服务架构实践（API Gateway）

Posted 2021-04-14 周小叨

点击上方蓝字关注 周小叨

在微服务架构风格中，一个大应用通常会被拆分成为了多个小的服务系统提供出来，这些小的系统他们可以自成体系，也就是说这些小系统可以拥有自己的数据库，框架甚至语言等，这些小系统通常以提供 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 网关架构

在我们的内部规划中(部分功能未实现)，我们的 API 网关主要会分为三个部分，也就是上图中绿色的几部分： 1.多网关集群(Backends for frontends) 我们针对不同的客户端，都有相应的网关层来接入。现阶段这一部分已经实现的功能主要是：用户登录，鉴权，服务发现注册，协议转换，接口版本控制等。后续我们还规划的功能有：监控，APM调用链，日志，流控策略等。 2.聚合服务(Merge Service) 在某些客户端的需求中，比如上面提到的商品详情的页面，我们需要从多个服务拉取数据，为了减少客户端的复杂度，以及加快客户端的访问速度，我们会在前面加一个聚合层，用来做聚合查询，在某些接口中可以把多个服务的数据一次性返回给客户端。 3.仪表盘管理端(Dashboard) Dashboard 提供可视化的分析平台，包括服务的管理，监控数据报警配置，日志查询，灰度发布操作，API文档管理等，这些功能对于开发和日常运维来说是非常重要的。