一. 微服务

二. Api Gateway

三. Kong 的使用

一. 微服务

        对于一些传统的 大型项目，传统的方式会有一些缺陷，比如说 新人熟悉系统成本高（因为整个系统作为一个整体，彼此会有一定的牵连），项目重

启时间长，重构困难（对于一个新技术的引入，可能需要对整个项目推到重来），不易于更换新的技术，并且整个项目会慢慢变成巨无霸。

        所以说就会有微服务这种概念，一个服务实现一个不同的特性或者功能。每一个独立的微服务都是一个小型应用。一些微服务可能会暴露一些api 给

其他的一些微服务或者是客户。如下图1（把各个业务拆分）：

        对于微服务，目前 像Netflix ，亚马逊，ebay 等都有应用。

        当然，微服务也有一定的缺陷，比如说 每个服务（每个应用） 如果都有一个 数据库的话，那么如何维持 数据库事务。再比如说，服务之间的调用可

能会由于 网络的原因变得不可达，那么 代码中要额外增加 请求失败的代码。

二. Api Gateway

        api gateway 即 api 网关。所有的请求首先会经过这个网关。这有点类似于前端控制器模式，也有点类似于 Facade模式。如下图2所示：

        由于所有的请求会先经过这个 api 网关，所以 可以在 这里做 权限控制，安全，负载均衡，请求分发，监控等等。

        那么，为什么要用 这个 api gateway 这个东西，主要原因在于 一个客户可以直接请求每一个服务。每一个服务都有一个 url。这些url 会和 负载均

衡设备相映射。为了得到产品信息，客户需要发很多的 request 请求。这样就不是很好。另外一个问题就是 可能协议不同，不一定是 http，比如说可能

由于防火墙或者什么的限制，可能需要用到其他的协议。再另外，以后重构的时候可能要拆分接口，或者合并接口，由于客户端和 API 直接打交道，所以

比较难。

        所以说，如上 图1 加入了 api gateway 就可以变为 如下图3所示：

        当然，任何技术都有缺陷， api gateway 也是一样，比如说 容易成为性能瓶颈。

三. Kong 的使用

        Kong 是一个现成 的 api gateway 的解决方案，它在 nginx 上进行了开发。

        api gateway 的实现方式有很多种，比如说 JVM 上可以用基于NIO 的框架比如Netty，Vertx，Spring Reactor，JOSS Undertow。现在一个比较流程的没有基于 JVM 的就是 NodeJs。其他的还有 Nginx Plus。

        以下介绍 Kong 的使用。

• 3.1 安装 Kong

• 3.2 加入 API

    参考：https://getkong.org/install/ ，里面写得比较详细了，但是要预先安装一个 Cassandra 数据库（介绍：http://cassandra.apache.org/）。安装之后，Kong 项目会监控两个端口，一个是 8000，一个是 8001。 8000端口是可以给用户访问，就是说用户发送请求先到 Kong 项目的 8000 端口，然

后Kong 项目帮你转到你的后端应用api。 8001 端口是管理端口，比如说，管理员可以通过 8001端口来得到你加入过的 api。

        参考文档：https://getkong.org/docs/0.5.x/admin-api/ ， 里面介绍了 api 的管理，包括 增删查改。下面介绍我第一次 使用时 还有有些不清楚的点：

3.2.1  列出 所加过的 api

curl localhost:8001/apis/

curl -i -X POST --url http://localhost:8001/apis/ --data 'upstream_url=http://camp.uats.cc' --data 'request_path=login' 

curl -i -X POST --url http://localhost:8001/apis/ --data 'upstream_url=http://183.131.76.124:4100/' --data         'request_host=183.131.76.122'

curl -i -X DELETE localhost:8001/apis/00f90ca9-cf2d-4830-c842-3b90f6cd08af