基于 OpenResty 的接口网关设计_曲奇不可以吃的博客-CSDN博客_openresty做网关
基于 OpenResty 的接口网关设计
曲奇不可以吃
于 2019-05-08 17:48:28 发布
2724
收藏
12
本文讲述基于 OpenResty 的接口网关设计，主要谈及接口网关的请求路由与安全认证（IP 与 URI 白名单、加解密与验签名流程等）这两部分内容，其中涉及到的 Nginx、OpenResty 等相关内容会作简单介绍。
温馨提示：文章图片中的文字较小，为了更好的阅读体验，建议 PC 端阅读。
谈谈基于 OpenResty 的接口网关设计〇、前言一、什么是接口网关
1.1 定位1.2 功能二、为什么需要接口网关
2.1 请求路由2.2 安全认证三、如何开发接口网关
3.1 Nginx 与 OpenResty 简介
3.1.1 Nginx 简介3.1.1 OpenResty 简介3.2 接口网关的架构
3.2.1 两层 HAProxy 代理3.2.2 接口网关
3.2.2.1 主流程设计3.2.2.2 配置服务设计3.2.2.3 安全服务设计3.2.3 架构总结
〇、前言
笔者曾参与开发两个接口网关的项目，一个是基于 Tomcat 的应用提供的网关服务，另一个是基于 OpenResty 的 Nginx 应用提供的网关服务。经过两个网关项目的开发，笔者在接口网关开发方面稍微积累了一些经验，故在此把这些经验分享出来一起交流学习。由于基于 OpenResty 的 Nginx 网关普遍被认为是更优的方案，故本文主要针对基于 OpenResty 的 Nginx 网关进行讲述。当然，由于不同的并发数量级，不同的业务场景，接口网关的设计多种多样，本文所述其中较为简单且轻量级的一种。
注：由于笔者经验与知识有限，文章中如有错误或偏颇，欢迎探讨和指正（作业部落提供文章按块批注功能，非常欢迎提批注，笔者会及时修正）。
一、什么是接口网关
1.1 定位
接口网关，顾名思义，是企业 IT 在系统边界上提供给外部访问内部接口服务的统一入口。这里的外部可以指客户端、浏览器或者第三方应用等，在这种情况下，接口网关可以有多种定位：
提供后端服务面向 Web App 或者 Mobile App 的 APIGateway作为开放平台面向 Partner 的 OpenAPI...
在笔者的工作中，同样把面向客户端的网关称作 APIGateway，把作为开放平台提供给第三方服务的网关称作 OpenApi。本文主要以 OpenApi 作为接口网关为例来讲述。
1.2 功能
作为企业 IT 系统的统一入口，接口网关可提供请求路由与组合、协议转换、安全认证、服务鉴权、流量控制与日志监控等服务。在笔者的工作中，主要在接口网关上实现了请求路由与安全认证的功能，题目中所说的“设计”，主要是指请求路由与安全认证方面，暂不涉及流量控制或日志监控等其他方面的设计。
二、为什么需要接口网关
正如上文所言，网关接口为企业应用提供了丰富的功能，而笔者在工作中开发的接口网关主要提供请求路由与安全认证的功能，那么在回答“为什么需要接口网关”的时候，需要对这两者多加阐述。
2.1 请求路由
企业提供内外两网，在没有接口网关时，提供外部服务的应用需要部署在外网。随着服务的增多，部署在外网的应用越来越多，在服务的安全压力与维护成本增大的情况下，需要一个统一的接口网关“隔离”内外服务。企业提供的服务（无论内部服务还是外部服务）均部署在内网，而由部署在外网的网关接受请求，并路由到内网服务。在这种情况下，既有利于对外屏蔽企业内部服务部署细节，提供统一的服务访问地址，又便于管理与维护内外部服务接口，便于演进与重构服务。这是接口网关提供请求路由的作用。
2.2 安全认证
在没有接口网关时，企业对外服务直接由外部访问，身份验证与数据加解密等工作都需要每一个对外服务本身去处理，增加了服务本不该有的职责，并且增加了服务开发的难度与工作量。实际在大多数情况下，可以将身份验证与数据加解密等安全工作可以从服务抽离，统一由接口网关负责处理。接口网关作为入口，对外验证调用方的 IP，身份以及接口访问权限等，并且可以解密数据后再将请求路由到服务。这是接口网关提供安全认证的功能。
以上是实际工作中涉及的为什么需要接口网关的其中两个原因，当然原因远不止此，有兴趣的读者可以阅读其他文章，比如 《谈API网关的背景、架构以及落地方案》 或者 《微服务：从设计到部署》（英文原文：Microservices: From Design to Deployment）。接下来的章节我们开始探讨如何开发接口网关。
三、如何开发接口网关
我们先看看工作中设计的提供请求路由与安全认证功能的接口网关的架构。
不过在介绍接口网关的设计之前，我们先来了解一下关于 Nginx 与 OpenResty 的基础知识。
3.1 Nginx 与 OpenResty 简介
3.1.1 Nginx 简介
Nginx 是世界第二大 Web 服务器，仅次于 Apache，然而由于其极高的性能可处理海量的互联网请求，现在已经成为业界高性能 Web 服务器的代名词。
它的主要特征是高性能、高扩展性、高可靠性、低内存消耗、单机支持 10 万以上的并发连接，支持热部署，以及使用较自由的 BSD 许可协议。其中，Nginx 可以处理高并发压力下的并发请求的原因如下：
事件驱动模型设计全异步的网络 I/O 处理机制极少的进程切换内存消耗低，极度“压榨”服务器硬件资源
除了基于事件驱动的架构使其支持百万级的 TCP 连接，另外高度模块化的设计和自由的许可证使其拥有非常多扩展其功能的第三方模块，也是它的重要特性。所以，后来才会有 OpenResty 的诞生。
我们看一个 Nginx 作简单配置来提供服务的例子：
worker_processes 1;
events {
worker_connections 1024;
http {
upstream backend {
server 127.0.0.1:8080
server {
location /back {
proxy_pass http://backend;
上述配置文件中，分别在 event、http、server 以及 location 块配置项中做了一些简单的配置，当安装完并启动 Nginx后（监听 80 端口），访问到 /back 路径下的请求会被转发到本地 127.0.0.1:8080 服务上。
3.1.1 OpenResty 简介
根据官网定义，OpenResty 是一个通过 Lua 扩展 Nginx 实现的可伸缩的 Web 平台。其核心是基于 Nginx 一个 C 模块将 Lua 语言嵌入到 Nginx 服务器中，对外提供一套完整的 Lua Web 的 API，并透明支持非阻塞 I/O，提供协程 —— “轻量级线程”、定时器等，从而极大地降低了高性能服务端的开发难度和开发周期。
OpenResty 将两个极为优秀的组件 Nginx 与 Lua 进行糅合，一方面保留了 Nginx 高性能 web 服务特征，另一方面有提供 Lua 特性在极少损失性能情况下便于业务功能的开发。根据官网介绍，OpenResty 非常便于用来搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。
我们也是因为 OpenResty 的这些特性，特别是它对搭建动态网关的友好支持，才选择了基于 OpenResty 来开发我们的接口网关 —— APIGateway 与 OpenApi。
开发接口网关使用到的 OpenResty 一个重要知识：OpenResty 对于一个请求的处理流程。Nginx 把一个请求分为不同的阶段，从而让第三方模块通过挂载行为在不同的阶段来定制自己的行为；OpenResty 拥有同样的特性，不过在不同阶段挂载的是 Lua 脚本。下图是基于《OpenResty 最佳实践》原图重绘而来：
从上图可知，OpenResty 处理请求大致分为四个阶段：
初始化阶段（Initialization Phase）重写与访问阶段（Rewrite / Access Phase）内容生成阶段（Content Phase）日志记录阶段（Log Phase）
我们看一个 OpenResty 作简单配置来提供服务的例子：
worker_processes 1;
events {
worker_connections 1024;
http {
resolver 127.0.0.1;
lua_package_path '$prefix/lua/?.lua;;';
init_by_lua_block {
# ...
init_worker_by_lua_file lua/init_work_by_lua.lua;
server {
listen 80;
location / {
rewrite_by_lua_file lua/rewrite_by_lua.lua;
access_by_lua_file lua/access_by_lua.lua;
proxy_pass http://<url>;
上述配置文件中，分别在 event、http、server 以及 location 块配置项中做了一些简单的配置，当安装完并启动 Nginx后（监听 80 端口），首先执行 init_by_lua_block、init_worker_by_lua_file 进行初始化，接着接受请求，所有的请求都会匹配上 "/" 路径，进而执行 rewrite_by_lua_file、access_by_lua_file 进行重写与访问，最后转发请求到本地 127.0.0.1 服务上。
在实际的接口网关开发中，我们主要是使用到了 OpenResty 中初始化阶段的 init_by_lua*、init_worker_by_lua*、重写与访问阶段 的 rewrite_by_lua*、access_by_lua* 以及内容生成阶段 content_by_lua* 过程。
3.2 接口网关的架构
这一节是本文的核心内容，重点讲述接口网关的架构设计。如前文所述，本文主要以 OpenApi 为例来讲述接口网关的架构设计。先看图：
下面我们来一步步来分析架构图的各个部分，首先是两层的 HAProxy 。
3.2.1 两层 HAProxy 代理
根据维基百科定义，HAProxy 是一个使用 C 语言编写的自由及开放源代码软件，其提供高可用性、负载均衡，以及基于 TCP 和 HTTP 的应用程序代理。
如图所示，隔离的内网与外网上分别提供了 HAProxy 代理， 外层暂且称为 HAProxy internet ，内层称为 HAProxy internal。外层暴露于外网中，使用统一地址如 http://openapi.company.com 来接受外部请求（这里指第三方的请求）；中间是基于 OpenResty 的 Nginx 网关层，外部请求经过网关后通过 HAProxy internal 转发到内网的服务上，内网服务遵循 Restful 风格，网关转发到内网的地址由接口网关控制。
然而，目前的代理架构受到了当前整体架构的约束，实际上两层的 HAProxy 代理并不是必需的。
对于外层 HAProxy internet，由于我们使用了与 HAProxy 紧密结合的 Openshift 架构，所以多了一层 HAProxy 的转发；一般情况下，基于 OpenResty 的 Nginx 网关层可以直接在外网上提供服务。 对于内层的 HAProxy internal，由于我们当前还没有实现服务治理，所以需要内层的 HAProxy internal 进行一层转发；当实现了服务治理，可以消除内层 HAProxy 代理，减少转发消耗。
在我们当前的系统量级下，这两层 HAProxy 转发消耗非常小可以被接受，所以调整架构的优先级还不高，以后再慢慢演进。
3.2.2 接口网关
接下来这一节是最为重点的接口网关的设计。接口网关主要利用前文所述的 OpenResty 执行阶段对请求与响应进行流程处理，包括接口地址的重写，IP 与资源白名单的控制，请求的解密与验签，请求的路由以及响应的签名与加密等。
这里分成主流程，配置服务，安全服务三部分进行讲述。
3.2.2.1 主流程设计
主流程是网关的核心，是请求处理的控制中心；它是通过 OpenResty 的 Lua 脚本处理流程来实现对请求的处理。
A. 主流程
在 OpenResty 服务启动之后，首先通过 init_by_lua_block 阶段初始化常量（包括调用配置服务以及安全服务所需的主机地址、端口、URL 地址等）、引入依赖（包括常用的 http 以及 cjson 依赖等）等作为全局使用； 接着通过 init_worker_by_lua_file 阶段设置定时任务调用内网配置服务来缓存配置，为处理第三方的请求做准备，其中加载的配置可供 URL 重写（即接口映射）、IP 以及资源（URI）白名单限制、请求的解密验签以及响应的签名加密使用，详情查看配置服务一节。 当第三方请求通过 HAProxy Internet 进入到网关后，根据配置通过 rewrite_by_lua_file 阶段做 URL 重写（即接口映射）。
需要重写的原因可能有： 
服务接口 URL 发生变更，为了兼容旧的第三方调用，需要重写第三方请求 URL 到新服务接口上Restful 接口的 Path Variable 在 Nginx 环境与在 Tomcat 环境上正则匹配的差异 URL 重写后，通过 access_by_lua_file 进入访问控制阶段，此时根据授权的第三方 IP 白名单列表，授权予第三方的开放接口列表，校验请求的 IP 以及 URL。 IP 与 URI 校验通过后，同样在 access_by_lua_file 阶段根据配置调用内网的安全服务进行请求的解密与验签，获取明文。 在 content_by_lua_file 阶段通过 ngx.location.capture 将原请求头部信息以及参数等信息封装到子请求中，借助子请求转发原请求到开发接口服务中。
注意：根据官方文档说明，ngx.location.capture 发送子请求会缓存响应在内存中，直到整个请求处理结束。那么，当有响应报文特别长或者请求并发非常高时，需要使用 cosocket 来替代 ngx.location.capture，避免因内存不足造成网关服务失效。 同样在 content_by_lua_file 阶段根据配置调用安全服务进行响应的签名与加密，获取签名与密文返回给第三方。
B. 文件结构
项目的大致结构如下，主要分为 Lua 代码目录和环境配置目录
--openapi
--lua
--access_by_lua.lua
--cache_management.lua
--content_by_lua.lua
--init_work_by_lua.lua
--rewrite_by_lua.lua
--security.lua
--prod
--Dockerfile
--nginx.conf
--sit
--Dockerfile
--nginx.conf
--README.md
C. 主流程在 conf 中的配置
# Nginx worker 进程个数，直接影响性能。
# 如果确认不会出现阻塞式调用，那么有多少 CPU 内核设置多少个进程
# 如果有可能出现阻塞式调用，需要配置多一些进程
worker_processes 1;
events {
worker_connections 1024;
http {
# 内网地址
resolver xxx.x.x.xxx yyy.y.y.yyy;
# 日志格式配置
log_format graylog2_format '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" '
'<msec=$msec|connection=$connection|connection_requests=$connection_requests|millis=$request_time>';
# 日志路径配置
access_log syslog:server=<host>:<port> graylog2_format;
error_log syslog:server=<host>:<port> warn;
# 配置 Lua 包地址
lua_package_path '$prefix/lua/?.lua;;';
init_by_lua_block {
# 引入依赖（可能会污染全局环境，待研究）
http = require "resty.http"
cjson = require "cjson"
cache_management = require "cache_management"
...
# 设置定时任务缓存配置，及上面的 cache_management 模块
init_worker_by_lua_file lua/init_work_by_lua.lua;
# Nginx Web 服务配置
server {
listen 80;
# ngx.location.capture 子请求代理，转发原请求到接口服务
location = /ngx_proxy/ {
internal;
proxy_set_header Accept-Encoding '';
proxy_pass http://$context$http_host_suffix$proxy_uri;
# 匹配所有请求，进行 URL 重写、访问控制、转发请求以及响应处理（各阶段的处理在此配置）。
location / {
set $context '';
...
rewrite_by_lua_file lua/rewrite_by_lua.lua;
access_by_lua_file lua/access_by_lua.lua;
content_by_lua_file lua/content_by_lua.lua;
D. URL 规范
内网服务遵循的 URL 格式为 http://<host>:<port>/<context>/path/to/your/api，应用上下文根紧跟在 <host>:<port>之后，以便统一获取来找到配置。比如：http://172.0.8.177:8080/user/users/{uid}/info，其中 user 为应用上下文根，紧跟在 172.0.8.177:8080 之后。
E. 样例
内网用户信息服务由原来的 API：/user/users/{uid}/info 提供，后来迁移至 API：/user/users/{uid}/user-info，当第三方 CampA (IP 为 172.0.1.172) 发起 GET 请求时，请求 URL 为 http://openapi.company.com/user/users/27/info?thirdparty=CampA&cp=fj375x...sign=abxuos8nb...。
初始化常量和依赖等通过 CampA 与 user Context 获取第三方配置HAProxy Internet 接收请求发到 OpenApi 接口网关，OpenApi 把 /user/users/27/info URI 重写为 /user/users/27/user-info/校验第三方请求 IP，在 IP 白名单中，校验通过；校验 URI /user/users/27/user-info 在授权的 URI 中，校验通过调用安全服务对请求进行解密与验签，解密成功，验签通过，获取明文将拥有明文的请求转发到开放接口服务获取响应，调用安全服务对响应报文进行签名与加密，返回给第三方 CampA。
3.2.2.2 配置服务设计
A. 数据库表设计
openapi_thirdparty_config
idthird_partyneed_check_ipipsreq_need_verify_signresp_need_sign1CompA1172.0.25.187, 172.0.25.18811 openapi_api_config
idthird_partymethodurlreq_need_decryptresp_need_encrypt1CompAGET/user/users/[^/]+/userinfo11 openapi_api_mapping
idfrom_apito_api1GET /old/1/user/users/(.+)/userinfoGET /users/$1/userinfo
B. 配置服务接口响应
# 接口映射配置
"apiMapping":{
"$context":{
"$fromApi":"$toApi"
},
# 接口白名单配置、加解密配置
"apiConfig":{
"$channel $context":{
"$httpMethod $uri":{
"reqNeedDecrypt":false,
"respNeedEncrypt":false
},
# IP 白名单配置，验签名配置
"channelConfig":{
"$channel":{
ips:{
"$ip":1
},
"reqNeedVerifySign":false,
"respNeedSign":false,
"needCheckIp":false
3.2.2.3 安全服务设计
为了保证请求或响应的完整性、以及请求或响应来源的合法性，双方传输需要进行签名；另外，由于可能开放接口的请求或响应会包含敏感信息，需要进行加密传输。这里的安全服务就是指请求的解密与验签和响应的签名与加密服务。
A. 算法约定
对称加密算法：3DES（DESede/ECB/PKCS5Padding）非对称加密算法：RSA（RSA/ECB/PKCS1Padding）签名算法：SHA1WithRSA
B. 公钥约定
双方预先交换 RSA 公钥
双方公钥编码方式：UTF-8 编码的 Base64String双方进行加解密与验签名可使用同一把 RSA 公私钥或者分别使用各自的公私钥，双方约定即可
C. 第三方请求流程示意
其中，添加统一参数为必选步骤，请求签名、请求加密、响应解密、以及响应验签都是可选步骤。
无论是 GET、POST 或者其他方式的请求，第三方在访问平台开放接口前，都需要添加统一参数到 request parameter 中 
统一参数包括第三方应用名、请求时间戳、随机不重复字符串 nonce 等验签名属于应用维度 —— 针对应用做验签名（比如：按照约定需要对第三方应用 A 进行验签，则应用 A 访问平台任何接口都需要签名）加解密属于接口维度 —— 针对接口做加解密（比如：同一个第三方访问 A 接口需要加密，而访问 B 接口可以不需加密）
D. 加解密示意（以第三方请求为例）
E. 验签名示意（以第三方请求为例）
3.2.3 架构总结
由于 Nginx 与 Lua 本身杰出的性能，在当前的系统量级与整体 IT 架构下，我们使用这样的接口网关架构已经可以支撑较大的并发请求。在最后的这一节，我们不妨回顾一下前文讲述的接口网关架构，看看目前性能上仍存在着的两个主要待改进的地方。
两层 HAProxy 代理：在使用更优产品替代 Openshift 架构的情况下，直接部署接口网关到公网，可消除外层 HAProxy 代理；在实现服务治理的情况下，由接口网关直接转发请求到服务，可消除内层 HAProxy 代理。 安全服务性能：加解密验签名等安全服务是以内部服务的方式提供给接口网关，而且使用了性能不太好的 ngx.location.capture 转发原请求，在系统量级增大后会遇到性能瓶颈，可通过使用高性能的 Lua 脚本在接口网关层提供安全服务，从而提升安全服务性能。
除了以上主要的两点，随着系统量级的提升与整体 IT 架构的演进，接口网关的架构也会随之调整和演进，在各个方面都尽可能地优化性能，以适应更大系统量级的需求。
曲奇不可以吃
关注
关注
点赞
12
收藏
评论
基于 OpenResty 的接口网关设计
本文讲述基于OpenResty的接口网关设计，主要谈及接口网关的请求路由与安全认证（IP 与 URI 白名单、加解密与验签名流程等）这两部分内容，其中涉及到的Nginx、OpenResty等相关内容会作简单介绍。温馨提示：文章图片中的文字较小，为了更好的阅读体验，建议 PC 端阅读。谈谈基于 OpenResty 的接口网关设计〇、前言一、什么是接口网关1.1 定位...
复制链接
扫一扫
openresty实现网关功能
zhangxm_qz的博客
02-26
7884
什么是网关
从一个房间到另一个房间，必须必须要经过一扇门，同样，从一个网络向另一个网络发送信息，必须经过一道“关口”，这道关口就是网关。顾名思义，网关(Gateway)就是一个网络连接到另一个网络的“关口”。
那什么是 api 网关呢？
在微服务流行起来之前，api 网关就一直存在，最主要的应用场景就是开放平台，也就是 open api; 这种场景大家接触的一定比较多，比如阿里的开放平台。微服务流...
参与评论
您还未登录，请先
登录
后发表或查看评论
基于 OpenResty 的服务器架构设计
weixin_38170829的博客
01-29
101
这个服务器架构不一定能用上，记录在这里，算是一个小小的学习成果。
1. 技术选择
Cocos2d-x 3.x —— 客户端框架。
WebSockt —— 网络协议。
HTTP —— 网络协议。
OpenResty —— 基于 nginx+lua 实现 WebSocket 或 HTTP 服务器。
MySQL —— 数据库支持。
Redis —— NoSQL 支持。
...
使用OpenAPI提升网关安全的开源软件，诚邀小伙伴参与
最新发布
baijiafan的博客
11-18
579
新做了一个基于OpenAPI进行接口访问日志分析的开源项目，感兴趣的同学欢迎来参与和交流，谢谢
接口网关
just love code
10-23
5017
1、什么是接口网关？
接口网关的作用：拦截请求，类似Nginx（在nginx中配置拦截策略），对该请求进行权限控制，负载均衡、日志管理、接口调用监控等
所有请求都交给接口网关，让网关再进行转发（类似反向代理）
接口网关解决跨域问题
2、过滤器与网关的区别是什么？
过滤是拦截单个tomcat服务请求
网关是拦截整个微服务所有的请求
...
java-05 openResty做服务化网关
csfun1的博客
12-13
233
openResty后端服务化网关openResty介绍简单应用1、下载和安装2、wins下openResty网关开发2.3 负载均衡2.4 自定义lua模块Nginx的11个阶段
openResty介绍
openresty是基于 Nginx 与 Lua 的高性能 Web 平台，主要应用网关（API网关、负载均衡、CDN等）、web应用（mysql、redis、Memcached （一个分布式内存对象缓存系统））等。作者章亦春。
中文官网地址：https://openresty.org/cn/
简单应用
1、
OpenResty 执行流程阶段
weixin_30446197的博客
06-28
616
nginx有11个处理阶段，如下图所示：
指令所处处理阶段使用范围解释
init_by_luainit_by_lua_file
loading-config
http
nginx Master进程加载配置时执行；通常用于初始化全局配置/预加载Lua模块
init_worker_by_luainit_worker_by_lu...
基于OpenResty的弹性网关实践（二）
yfy的博客
09-25
481
五、11个指令介绍
OpenResty 有 11 个 *_by_lua指令，它们和 NGINX 阶段的关系如下图所示
其中， init_by_lua 只会在 Master 进程被创建时执行，init_worker_by_lua 只会在每个 Worker 进程被创建时执行。其他的 *_by_lua 指令则是由终端请求触发，会被反复执行。
所以在 init_by_lua 阶段，我们可以预先加载 Lua 模块和公共的只读数据，这样可以利用操作系统的 COW（copy on write）特性，来节省一些内
基于Openresty(nginx+lua）的计算密集型应用开发方法
Where there is life, there is hope.
07-03
413
基于openresty（nginx+lua）的系统框架，设计一种计算密集型的应用框架。本方案将有如下特点：
+ 1、可以避免计算进程阻塞Openresty框架的问题；
+ 2、可避免多个计算进程同时加载大量静态资源数据的问题；
+ 3、算法模块提供标准C接口模块，无需为做额外封装开发。......
什么是网关接口？
A13071066017的博客
11-23
561
银行接口是指各网站直接嵌入各类支付公司的直联网关，即用户在网站上选择银行进行支付，直接跳转到该银行网银进行支付的产品服务。
什么是直联网关，那是相对间联网关而言的。
间联网关是支付公司提供网银支付网关的最标准模式。
消费者需要支付时，商家向支付公司网关接口提交标准报文请求将消费者引导到“收银台”，没错，就是支付宝那个熟悉的选择支付银行的页面。用户在收银台选择银行后支付宝将用户引导到网银界面……后面大家都懂的。
直联网关是在标准网关基础上进行的衍生网关服务。
做电商的同学都知道，消费者完成消...
Openresty最佳案例 | 第9篇：Openresty实现的网关权限控制
weixin_30666401的博客
11-23
935
转载请标明出处：
http://blog.csdn.net/forezp/article/details/78616779
本文出自方志朋的博客
简介
采用openresty 开发出的api网关有很多，比如比较流行的kong、orange等。这些API 网关通过提供插件的形式，提供了非常多的功能。这些组件化的功能往往能够满足大部分的需求...
个推首席架构师Qcon分享 |微服务架构的那些事儿
weixin_33913377的博客
06-20
90
微服务架构需要注意哪些问题？微服务架构，首先考虑客户端与服务端之间的通信问题。有两种解决办法，一是客户端与多个服务端直接进行通信，但存在对外暴露接口细节、众多接口协议无法统一、客户端的代码复杂、服务端升级相对困难等问题。二是客户端访问统一的API网关，由API网关调用众多服务接口，易实现统一通信协议，降低客户端和服务端代码耦合，也可以达到统一的鉴权和流控，然而此方式存在延时...
openresty开发系列1--网关API架构及选型
reblue520的专栏
08-29
700
微服务架构在项目中的应用越来越多，我们知道在微服务架构风格中，一个大应用被拆分成为了多个小的服务系统提供出来，这些小的系统他们可以自成体系，也就是说这些小系统可以拥有自己的数据库，框架甚至语言等，这些小系统通常以提供 Rest Api 风格的接口来被 H5, Android, IOS 以及第三方应用程序调用。但是在UI上进行展示的时候，我们通常需要在一个界面上展示很多数据，这些数...
微服务之API网关接口设计
weixin_34130269的博客
10-28
774
微服务之API网关接口设计API网关，顾名思义，就是外部到内部的一道门，其主要功能：服务路由：将前段应用的调用请求路由定位并负载均衡到具体的后端微服务实例，对于前端应用看起来就是1个应用提供的服务，微服务对于前段应用来说就是黑盒，前段应用也不需要关心内部如何分布，由哪个微服务提供。主要有静态路由和动态路由。静态路由：有时候需要通过域名或者其他固定方式提供和配置路由表动态路由：通过服务发现服务，动态...
openresty服务管理框架(API网关)
Mental_history_T的博客
06-05
497
tl-ops-manage （tl-openresty-web-manage），基于openresty开发的一款基础服务管理工具，支持服务动态扩展，自定义URL路由，健康检查，服务熔断限流，动态配置检测，日志记录，数据版本控制，后台可视化管理，等等….....................
openresty 网关rsa+aes+redis鉴权解密
胡汉三
07-11
635
之前使用了openresty进行了rsa跟aes的加解密测试。现在我们整合一下、使用openresty连接redis做鉴权、解密。之前提到过，我们不使用cookie而是使用token来认证用户信息。而且token是我们自己加密的、加密的规则就是使用aes进行加密。我们再来缕一缕整个流程。客户端（浏览器）流程： 第一步：先获取token（临时token），返回的token是aes加密的，这里的密钥我们就使用固定的aes密钥就好了。token里面包含userId跟tokenId，我们使用token
openresty如何对url进行解码
chouzu8463的博客
09-11
1470
URL编码是HTTP所使用的一种编码方式，用于在一个URL钟传送各种参数。这种编码方式会将特殊字符（如'='、'&'、'+'）编码为'%<xx>'的形式，其中<xx>是字符的十六进制表示。此外，它还会将空格转化为"+"。例如，它会将字符串"a+b=c"编...
openresty用AES/ECB/NoPadding 128位解密
12-21
7448
--ECB 方式无需iv,传递一个16字节的iv以便用原始key进行EVP_DecryptInit_ex初始化
local price_decode = aes:new(dspkey,nil,aes.cipher(128,"ecb"),{iv=dspkey})
local base_decode_bytes = ngx.decode_base64(ad_base_decode)ngx.log(ng
利用OpenResty搭建动态API网关
weixin_33735077的博客
05-28
285
2019独角兽企业重金招聘Python工程师标准>>>
...
基于OpenResty的弹性网关实践（一）
yfy的博客
09-25
313
一、介绍
1. OpenResty简介
官方地址：http://openresty.org/cn/
github地址：https://github.com/openresty/
OpenResty最佳实践：https://moonbingbing.gitbooks.io/openresty-best-practices/content/
OpenResty是一个基于 Nginx 与 Lua 的高性能 Web 平台，其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便.
“相关推荐”对你有帮助么？
非常没帮助
没帮助
一般
有帮助
非常有帮助
提交
©️2022 CSDN
皮肤主题：大白
设计师：CSDN官方博客
返回首页
曲奇不可以吃
CSDN认证博客专家
CSDN认证企业博客
码龄5年
暂无认证
10
原创
11万+
周排名
61万+
总排名
12万+
访问
等级
1267
积分
18
粉丝
31
获赞
12
评论
127
收藏
私信
关注
最新评论
进程fork两次---解决一个进程不必等待子进程终止，也不希望子进程处于僵死状态
昨天那个谁谁:
两次fork也有开销啊
MySQL索引结构解析
木秀林:
看到这里可能有小伙伴会有疑问，那如果直接用height和weight来进行比较不可以吗？显然是不可以的，可以举个例子，我们把缺失的这一列写作一个问号，那么这条语句的查询条件就变成了?27，那么我们从这课B+树的根节点开始，根节点上有127和365，那么以height和weight来进行比较的话，走的一定是127这一边，但是如果缺失的列数字是大于3的呢？比如427，527，627，那么如果走索引来查询数据，将会丢失数据，错误查询。所以这种情况下是绝对不会走索引进行查询的。这就是最左前缀匹配原则的成因。
最左前缀匹配原则，MySQL会一直向右匹配直到遇到范围查询（>、<、between、like）就停止匹配，比如 a=3 and b=4 and c>5 and d=6,如果建立(a,b,c,d)顺序的索引，d是无法使用索引的，如果建立(a,b,d,c)的索引则都可以使用到，a、b、d的顺序可以任意调整。
=和in可以乱序，比如 a=1 and b=2 and c=3 建立(a,b,c)索引可以任意顺序，MySQL的查询优化器会帮你优化成索引可以识别的形式。
这个是怎么知道的？explain 好像没办法看到d是不是走了索引，
PHP中pack、unpack的详细用法（字节序）
进击的递归:
这个示例小猪笑死了，谢谢up主的详细讲解
gRPC 使用 protobuf 构建微服务
GhostRiderQin:
博主现在在哪里工作？
PHP-FPM 调优：使用 ‘pm static’ 来最大化你的服务器负载能力
Deep Learning小舟:
学到了，给博主递茶，谢谢啦！(^ ^)
您愿意向朋友推荐“博客详情页”吗？
强烈不推荐
不推荐
一般般
推荐
强烈推荐
提交
最新文章
Redis底层数据结构
浅谈MySQL并发控制：隔离级别、锁与MVCC
实例浅析epoll的水平触发和边缘触发
2020年5篇
2019年56篇
2018年61篇
目录
目录
最新文章
Redis底层数据结构
浅谈MySQL并发控制：隔离级别、锁与MVCC
实例浅析epoll的水平触发和边缘触发
2020年5篇
2019年56篇
2018年61篇
目录
评论
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
查看更多评论
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额
抵扣说明：
1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。 2.余额无法直接购买下载，可以购买VIP、C币套餐、付费专栏及课程。
余额充值