一. 微服务 二. Api Gateway 三. Kong 的使用
一. 微服务 对于一些传统的 大型项目,传统的方式会有一些缺陷,比如说 新人熟悉系统成本高(因为整个系统作为一个整体,彼此会有一定的牵连),项目重 启时间长,重构困难(对于一个新技术的引入,可能需要对整个项目推到重来),不易于更换新的技术,并且整个项目会慢慢变成巨无霸。 所以说就会有微服务这种概念,一个服务实现一个不同的特性或者功能。每一个独立的微服务都是一个小型应用。一些微服务可能会暴露一些api 给 其他的一些微服务或者是客户。如下图1(把各个业务拆分): 图1
对于微服务,目前 像Netflix ,亚马逊,ebay 等都有应用。 当然,微服务也有一定的缺陷,比如说 每个服务(每个应用) 如果都有一个 数据库的话,那么如何维持 数据库事务。再比如说,服务之间的调用可
能会由于 网络的原因变得不可达,那么 代码中要额外增加 请求失败的代码。
二. Api Gateway api gateway 即 api 网关。所有的请求首先会经过这个网关。这有点类似于前端控制器模式,也有点类似于 Facade模式。如下图2所示: 图2
由于所有的请求会先经过这个 api 网关,所以 可以在 这里做 权限控制,安全,负载均衡,请求分发,监控等等。 那么,为什么要用 这个 api gateway 这个东西,主要原因在于 一个客户可以直接请求每一个服务。每一个服务都有一个 url。这些url 会和 负载均 衡设备相映射。为了得到产品信息,客户需要发很多的 request 请求。这样就不是很好。另外一个问题就是 可能协议不同,不一定是 http,比如说可能 由于防火墙或者什么的限制,可能需要用到其他的协议。再另外,以后重构的时候可能要拆分接口,或者合并接口,由于客户端和 API 直接打交道,所以 比较难。 所以说,如上 图1 加入了 api gateway 就可以变为 如下图3所示: 图3
当然,任何技术都有缺陷, api gateway 也是一样,比如说 容易成为性能瓶颈。
三. Kong 的使用
Kong 是一个现成 的 api gateway 的解决方案,它在 nginx 上进行了开发。 api gateway 的实现方式有很多种,比如说 JVM 上可以用基于NIO 的框架比如Netty,Vertx,Spring Reactor,JOSS Undertow。现在一个比较流程的没有基于 JVM 的就是 NodeJs。其他的还有 Nginx Plus。 以下介绍 Kong 的使用。
参考:https:///install/ ,里面写得比较详细了,但是要预先安装一个 Cassandra 数据库(介绍:http://cassandra./)。安装之后,Kong 项目会监控两个端口,一个是 8000,一个是 8001。 8000端口是可以给用户访问,就是说用户发送请求先到 Kong 项目的 8000 端口,然 后Kong 项目帮你转到你的后端应用api。 8001 端口是管理端口,比如说,管理员可以通过 8001端口来得到你加入过的 api。 参考文档:https:///docs/0.5.x/admin-api/ ,
里面介绍了 api 的管理,包括 增删查改。下面介绍我第一次 使用时 还有有些不清楚的点: 3.2.1 列出 所加过的 api
单个加入:
上面这段命令表示:
3.2.3 删除 api
四. 参考: 1. API Gateway 模式: http:///patterns/apigateway.html 2. Nginx: https://www./blog/introduction-to-microservices/ 3. Kong 项目官网:https:///
|
|
来自: ThinkTank_引擎 > 《API Gateway》