微服务之应用网关

API网关
customer.service 1.0.0
没有流量
所有流量 customer.service 1.0.1
Ops:金丝雀发布（Canary Releases）
API网关
customer.service 1.0.0
100%流量
%0流量 customer.service 1.0.1
API网关
Customer Customer
Customer Customer
总结：API网关的功能
统一接入 流量管控 协议适配 安全维护
常见的应用网关
Nginx+Lua Kong Spring Cloud Zuul
Zuul
Zuul是Netflix开源的微服务网关 核心是一系列过滤器
到各个Server，来应对大批量的网络请求
可扩展性: 通过简单地添加更多的服务器，可以轻松地进行横向扩展，这意味着您的平台 可以在一个较低负载的情况下处理任何请求；
模块化: 可以通过添加新的插件进行扩展，这些插件可以通过RESTful Admin API轻松配置； 在任何基础架构上运行: Kong网关可以在任何地方都能运行。您可以在云或内部网络环境
API网关
{
LB
OOrdredrer
“id”:”order_123”, “customer_id”: “cus_123”,
“item_name”:…
}
GET /customers/{id}
LB
InIvnoviociece
{
{
“order_id”: “order_123”,
“customer_id”: “cus_123”,
而实现更复杂的特性。 有一些特性Kong默认是缺失的，如API级别的超时、重试、fallback策略、
缓存、API聚合、AB测试等，这些功能插件需要企业开发人员通过Lua语 言进行定制和扩展。 综上所述，Kong API网关默认提供的插件比较丰富，适应针对企业级的 API网关定位。
OpenR百度文库sty API网关
OOrdredrer
Data Schema
LB
InIvnoviociece
Data Schema
优化后的端点（Optimized Endpoints）
{
“id”:”cus_123”,
“customer_name”: “Bob”,
LB
CCusutsotmomerer
“address”:… }
Client
OpenResty 是一个基于 Nginx 与 Lua 的高性能 Web 平台
其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。 用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。
Better agility in the long term
Micro services: easy to learn
Isolation for scalability and damage control
More moving parts
Complex infrastructure requirements
协议转换插件：
请求转换（在转发到upstream之前修改请求）、响应转换（在upstream响应返回给客户端之前 修改响应）。
日志应用插件：
TCP、UDP、HTTP、File、Syslog、StatsD、Loggly等。
Kong总结
Kong作为API网关提供了API管理功能 围绕API管理实现了一些默认的插件 具备集群水平扩展能力，从而提升整体吞吐量。 Kong本身是基于OpenResty，可以在现有Kong的基础上进行一些扩展，从
各个Filter间没有直接联系，是通过RequestContext共享一些状态数据 Filter Types
PRE Filter：在请求路由到目标之前执行。一般用于请求认证、负载均衡和日志记录。 ROUTING Filter：处理目标请求。这里使用Apache HttpClient或Netflix Ribbon构造对目
Consistency and availability
Harder to test
为什么需要API网关？
API Gateway
Micro Services
API网关模式（API Gateway Pattern）
Client
API网关
LB
CCusutsotmomerer
Data Schema
LB
Public APIs
Private APIs Partner APIs
Faas （function as a service）
Ops: 蓝/绿发布（Blue/Green deployments）
API网关
customer.service 1.0.0
所有流量
没有流量 customer.service 1.0.1
“price”: “99.99”,
“name”: “Bob”,
}
“address”:…
“orders”: {…},
“invoice”:{…},
}
中心化中间件
Client
API网关
• Authentication • Security • Traffic Control • Ops • Logging • Transformations • etc
Kong
Kong是一个基于OpenResty(Nginx + Lua模块)的开源的API Gateway项目 基于NGINX和Apache Cassandra或PostgreSQL构建 通过插件扩展（认证，安全，流量控制，分析&监控，转换，日志） 水平扩展多个Kong服务器，通过前置的负载均衡配置把请求均匀地分发
优势 缺点 总结
Zuul 1.0
Zuul 2.0
同步阻塞模式的编程模型比较简单，整个请 求->处理->响应的流程(call flow)都是在一个 线程中处理的，这样开发调试比较方便易于 理解，比如出了问题跟踪调试比较方便
异步非阻塞模式启动的线程很少，一
个CPU core上只需启一个事件环处理 线程，可以以接受的连接数大大增加
Client
LB
CCusutsotmomerer
Data Schema
LB
OOrdredrer
Data Schema
LB
InIvnoviociece
Data Schema
Event Handler
微服务架构的优缺点
Better architecture for large applications
中部署Kong，包括单个或多个数据中心设置，以及public，private 或invite-only APIs。
Kong结构
Kong组件
Kong Server
基于nginx的服务器，用来接收API请求。
Apache Cassandra/PostgreSQL
用来存储操作数据。
Kong dashboard
Cons:
Not ideal for growing codebase
Slower iterations in the long term
Harder to innovate
IDE support
Steep code learning curve
微服务架构（Microservice-Oriented Architecture）
使用的多样化
Spring Cloud对Zuul进行了整合与增强
Eureka用于服务的注册于发现 Feign支持服务的调用以及均衡负载 Hystrix处理服务的熔断防止故障扩散
Filter工作原理
Zuul是围绕一系列Filter展开的 Zuul Filter有以下几个特征：
Type：用以表示路由过程中的阶段（内置包含PRE、ROUTING、POST和ERROR） Execution Order：表示相同Type的Filter的执行顺序 Criteria：执行条件 Action：执行体
Kong网关插件
身份认证插件：
Kong提供了Basic Authentication、Key authentication、OAuth2.0 authentication、HMAC authentication、JWT、LDAP authentication认证实现。
安全控制插件：
ACL（访问控制）、CORS（跨域资源共享）、动态SSL、IP限制、爬虫检测实现。
官方推荐UI管理工具，当然，也可以使用 restfull 方式 管理admin api。
Kong层次架构
• Kong核心基于OpenResty构建，实现了请求/响应的Lua处理化； • Kong插件拦截请求/响应，等价于拦截器，实现请求/响应的AOP处理； • Kong Restful 管理提供了API/API消费者/插件的管理； • 数据中心用于存储Kong集群节点信息、API、消费者、插件等信息 • Kong集群中的节点通过gossip协议自动发现其他节点，
Order
Invoice
Database Schema
单体应用的优缺点（Monolithic Application Pros and Cons）
Pros:
Simplicity for small codebases
Faster early development
speed
Easy testing
2019/04
内容
单体架构 单体架构的优缺点 微服务架构 微服务架构的优缺点 应用网关及作用 Zuul、Kong和OpenResty介绍 总结
单体架构（Monolithic Architecture）
Monolithic Architecture
Client
LB
Customer
同步阻塞模式的线程切换开销；容器线程池
的数量一般是固定的，造成对连接数有一定 限制，当后台服务慢，容器线程池易被耗尽
异步模式让编程模型变得复杂，它的
流程是通过事件触发的，内部实现要 通过一些关联id机制才能把整个执行 流再串联起来，给开发调试运维引入 了很多复杂性
同步阻塞模式比较适用于计算密集型(CPU 异步非阻塞模式比较适用于IO密集型 bound)应用场景。对于IO密集型场景(IO (IO bound)场景，这种场景下系统大 bound)，同步阻塞模式会消耗很多线程资源，部分时间在处理IO，CPU计算比较轻， 它们都在等待IO的阻塞状态，没有做实质性 少量事件环线程就能处理。 工作
流量控制插件：
请求限流（基于请求计数限流）、上游响应限流（根据upstream响应计数限流）、请求大小限 制。限流支持本地、Redis和集群限流模式。
分析监控插件：
Galileo（记录请求和响应数据，实现API分析）、Datadog（记录API Metric如请求次数、请求 大小、响应状态和延迟，可视化API Metric）、Runscope（记录请求和响应数据，实现API性能 测试和监控）。
customer.service 1.0.0
90%流量
10%流量 customer.service 1.0.1
Ops:负载均衡（ Load Balancing）
1.
Client
API网关
LB
Customer Customer
2.
Client
API网关
3.
Client
API网关
Service • etcd Discovery • consul
标的HTTP请求。 POST Filter：在目标请求返回后执行。一般会在此步骤添加响应头、收集统计和性能数据
等。 ERROR Filter：整个流程某块出错时执行。
Zuul请求生命周期
Zuul1.0 和 2.0
18年5月，Netflix开源了支持异步调用模式的Zuul网关2.0版本 支持异步高并发(Zuul1仅支持同步)特性
1. 身份认证和安全：识别每个资源的验证要求，并拒绝那些与要求不符的请求。 2. 审查与监控：在边缘位置追踪有意义的数据和统计结果，从而带来精确的生产视图。 3. 动态路由：动态地将请求路由到不同的后端集群。 4. 压力测试：逐渐增加指向集群的流量，以了解性能。 5. 负载分配：为每一种负载类型分配对应容量，并弃用超出限定值的请求。 6. 静态响应处理：在边缘位置直接建立部分响应，避免其转发到内部集群。 7. 多区域弹性：跨越AWS Region进行请求路由，旨在实现ELB（Elastic Load Blancing）