openresty开发系列1--网关API架构及选型

Posted 2022-09-07 reblue520

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了openresty开发系列1--网关API架构及选型相关的知识，希望对你有一定的参考价值。

    微服务架构在项目中的应用越来越多，我们知道在微服务架构风格中，一个大应用被拆分成为了多个小的服务系统提供出来，这些小的系统他们可以自成体系，也就是说这些小系统可以拥有自己的数据库，框架甚至语言等，这些小系统通常以提供 Rest Api 风格的接口来被 H5, android, ios 以及第三方应用程序调用。
但是在UI上进行展示的时候，我们通常需要在一个界面上展示很多数据，这些数据可能来自于不同的微服务中，举个例子。
    在一个电商系统中，查看一个商品详情页，这个商品详情页包含商品的标题，价格，库存，评论等，这些数据对于后端来说可能是位于不同的微服务系统之中，可能我后台的系统是这样来拆分我的服务的：

    产品服务 - 负责提供商品的标题，描述，规格等。
    价格服务 - 负责对产品进行定价，价格策略计算，促销价等。
    库存服务 - 负责产品库存。
    评价服务 - 负责用户对商品的评论，回复等。

现在，商品详情页需要从这些微服务中拉取相应的信息，问题来了？
问题由于我们使用的服务系统架构，所以没办法像传统单体应用一样依靠数据库的 join 查询来得到最终结果，那么如何才能访问各个服务呢？
按照微服务设计的指导原则，我们的微服务可能存在下面的问题：

    服务使用了多种协议，因为不同的协议有不同的应场景用，比如可能同时使用 HTTP, AMQP, gRPC 等。
    服务的划分可能随着时间而变化。
    服务的实例或者Host+端口可能会动态的变化。

那么，对于前端的UI需求也可能会有以下几种：

    粗粒度的API，而微服务通常提供的细粒度的API，对于UI来说如果要调用细粒度的api可能需要调用很多次，这是个不小的问题。
    不同的客户端设备可能需要不同的数据。Web,H5,APP
    不同设备的网络性能，对于多个api来说，这个访问需要转移的服务端会快得多

以上，就是我们构建微服务的过程中可能会遇到的问题。那么如何解决呢？
这种情况下， API 网关（API Gataway）诞生了。
API 网关API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。
API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。
API网关网关的价值：

    网关层对外部和内部进行了隔离，保障了后台服务的安全性。
    对外访问控制由网络层面转换成了运维层面，减少变更的流程和错误成本
    减少客户端与服务的耦合，服务可以独立发展。通过网关层来做映射。
    通过网关层聚合，减少外部访问的频次，提升访问效率。
    节约后端服务开发成本，减少上线风险。
    为服务熔断，灰度发布，线上测试提供简单方案。