微服务API网关框架课程

课程下载连接：https://pan.baidu.com/s/1ql1J4IvGJ1wTBOa2EKtFgg 提取码: b65w

老顾这系列课程就给你们介绍一下nignx + lua方式的网关框架，也是不少公司经常使用的网关框架

最近 微服务架构在项目中的应用愈来愈多，咱们知道在微服务架构风格中，一个大应用被拆分红为了多个小的服务系统提供出来，这些小的系统他们能够自成体系，也就是说这些小系统能够拥有本身的数据库，框架甚至语言等，这些小系统一般以提供 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注册和管理服务。