openresty

本文将介绍开源API网关Kong。在GtiHub搜索API网关类的开源产品，可以看到Kong网关常年都是排第一的位置，而且当前很多都有一定研发能力的企业在API网关产品选型的时候基本也会选择Kong网关，并基于Kong网关进行二次开发和定制。 API网关概述 简单来说API网关就是将所有的微服务提供的API接口服务能力全部汇聚进来，统一接入进行管理，也正是通过统一拦截，就可以通过网关实现对API接口的安全，日志，限流熔断等共性需求。如果再简单说下，通过网关实现了几个关键能力。 内部的微服务对外部访问来说位置透明，外部应用只需和网关交互 统一拦截接口服务，实现安全，日志，限流熔断等需求 从这里，我们就可以看到API网关和传统架构里面的ESB总线是类似的，这些关键能力本身也是ESB服务总线的能力，但是ESB服务总线由于要考虑遗留系统的接入，因此增加了： 大量适配器实现对遗留系统的遗留接口适配，多协议转换能力 进行数据的复制映射，路由等能力 对于两者，我原来做过一个简单的对比，大家可以参考。 对于API网关进一步的功能介绍，可以我前面参考文章：《 一文详细讲解API网关核心功能和API管理扩展 》。 基于Openresty开发API网关 在谈API网关前，我们先谈下Openresty。在前面文章谈到过，当前适合用于API网关的架构，一种是基于Openresty的，一种是基于Go语言的。

背景 我们都知道，在微服务架构风格里，一个应用会被拆分成多个小的服务系统，并且这些小系统都可以自成体系，可以拥有自己的数据库、框架语言等。它们通常都可以提供接口来被各种应用程序调用。 但是在UI上进行展示的时候，我们通常需要在一个界面上展示很多数据，这些数据可能来自于不同的微服务中。 打个比方：要查看一个电商平台的商品详情页，这个商品详情页包括标题、价格、库存、评价等等，这些数据可能在不同的微服务系统之中，如下所示： • 产品 - 负责提供商品的标题，描述，规格等。 • 价格 - 负责对产品进行定价，价格策略计算，促销价等。 • 库存 - 负责产品库存。 • 评价 - 负责用户对商品的评论，回复等。 现在，商品详情页需要从这些微服务中拉取相应的信息，问题来了？ 由于用的是多个服务系统的架构，所以依靠单个数据库的 join 查询结果不可行，那么该怎么访问各个服务呢？ 按照微服务设计的指导原则，我们的微服务可能存在下面的问题： • 服务使用了多种协议，因为不同的协议有不同的应场景用，比如可能同时使用 HTTP, AMQP, gRPC 等。 • 服务的划分可能随着时间而变化。 • 服务的实例或者Host+端口可能会动态的变化。 那么，对于前端的UI需求也可能会有以下几种： • 粗粒度的API，而微服务通常提供的细粒度的API，对于UI来说如果要调用细粒度的api可能需要调用很多次

目录 文章目录 目录 Kong Kong 的软件架构 Kong 的插件 Lua Nginx Module 零信任网关 技术选型 Kong Kong 是一款由 Mashape 公司开源的 APIGW 软件，基于 OpenResty（Nginx + Lua 模块）实现，具有高可用、易扩展的特性。Kong 在 Mashape 上管理了超过 15,000 个 API，为 200,000 开发者提供了每月数十亿的请求支持。 官网 ：https://konghq.com/kong/ Github ：https://github.com/Kong/kong Docs ：https://docs.konghq.com/ 中文文档 ：https://github.com/qianyugang/kong-docs-cn Kong 的本质是一个在 Nginx 上运行的 Lua 应用程序，由 lua-nginx-module 实现。Kong 和 OpenResty 一起打包发行，其中已经包含了 lua-nginx-module。可以简单理解为：Kong > OpenResty > Nginx + lua-nginx-module。 Kong 的特性： 可扩展 ：Kong Server 支持水平扩展。 插件 ：Kong Server 实现了 Plugin 机制进行功能定制，通过 RESTful Admin

点击上方“ 开源社 ”关注我们 | 作者：温铭 | 转载自：技术琐话 | 编辑：王玥敏 | 设计：刘颖洁 | 责编：Corrie 开源社引言 开源归根结底是一种人类的文化，而全球化背景下的互联网，将全球的任何开发者链接起来，使得这种文化得以跨时空获得发展，具备全球视野的 APISIX 项目就是这样的典型的例子，从中国某个角落的几个胸怀梦想的编程热血青年，积极的拥抱Apache 基金会倡导的共同体胜于代码，开发出顶级的项目，也积极的和云计算厂商进行合作，为持续性发展奠定基础。作为联合创始人温铭的故事怎么可以错过？ 我是温铭， 深圳支流科技 的联合创始人，开源微服务 API 网关 Apache APISIX 的 PPMC， OpenResty 软件基金会 创始人和第一任主席，360 开源委员会发起人，极客时间 《OpenResty 从入门到实战》专栏 作者。 为什么写这篇文章？ 还不是今年春节假期，在家不能外出憋坏了嘛。闲着也是闲着，不如把最近 3 年在基础软件领域创业的经验和教训总结下。 关于中国的开源项目、社区和创业，很多的分享都是讲自己的成功经验，其实背后还有更多尚未成功者的身影，他们的经验也能提供另外一个维度的视角。 我希望能通过这篇文章，让大家能够更深层次的理解下面这些和开源相关的常见疑问： 如何运营开源社区？ 如何选择和评价开源项目？ 国内外开源文化为什么会有差异？

定义 灰度发布就是已一种平滑过渡的方式来发布，通过切换线上新旧版本之间的路由权重，逐步从旧版本切换到新版本；比如要上线新功能，首先只是更新少量的服务节点，通过路由权重，让少部分用户体验新版本，如果没有什么问题，再更新所有服务节点；这样可以在出现问题把影响面降到最低，保证了系统的稳定性。 灰度发布 一个系统往往有接入层比如nginx(Openresty)，网关层比如zuul，以及服务层比如各种rpc框架；在这几层都有路由功能，也就是说这几层都可以做灰度；接入层可以使用nginx+lua来实现灰度，网关层zuul可以结合ribbon来实现灰度，rpc框架如dubbo本身提供了路由功能可以直接做灰度处理；下面看看具体如何去实现； 接入层灰度 接入层我们这里使用功能更强大的Openresty，然后使用lua进行路由转发，相关的路由策略可以配置在分布式缓存redis里面，当然也可以持久化到数据库里面； 准备 准备一台Openresty，两台web服务器tomcat(端口分别是8081，8082)，以及redis；为了方便模拟在redis里面配置白名单，如果在白名单里面就走8082，不在则走8081； Openresty配置 需要在Openresty中配置支持lua，以及相关路由的lua脚本，nginx.conf配置如下： http { ... lua_package_path "

对于开发来说，我们在工作中多多少少都会遇到web服务的性能优化、高并发等问题，而 Nginx 是一个万能药。可以 在百万并发连接下实现高吞吐量的 Web 服务，同时诸多应用场景下的问题都可以通过种种 Nginx 模块得以解决。 我们都知道 Nginx 好用，但大多数人 对 Nginx 的理解和使用只停留在初步阶段，并没有挖掘出 Nginx 的效能，让它真正地为自己所用。 之前每次我发 Nginx 相关文章，总有粉丝留言说使用 Nginx 遇到的困惑，贴几个： Nginx 在工作中经常遇到，每次都是百度去查找，有时还搞不定，搞定了也不一定懂，这种一知半解的状态真的难受。 一开始公司让我来配置服务器，真的懵了，瞎复制，原理也不大懂。业务推着自己走，现在必须要搞懂 Nginx了，网上看了一堆资料，没个系统化，号主是怎么学的啊？ 号主有没有好的学习资料推荐？学了就能立马上手那种。 先给大家看一张 「Nginx知识框架图」，清晰得明白掌握Nginx需要学习哪些知识点。 此图谱出自于 Ngnix 领域的专家陶辉 之手 。 相信深入研究过 Nginx 的人都知道他，资历很硬核，先后在腾讯QQ空间、思科中国CRDC、阿里巴巴等公司待过，专注 Nginx 定制化应用很多年了。 更值得一提的是，这位大佬还在极客时间开了一个视频课程 —— 《Nginx核心知识100讲》 ，已经有超过 1.8+万人

在面试过程中几乎是必问到高并发一些问题，而本篇就是SpringCloud结合Nginx解答高并发开发、大厂面试的核心难题！本篇旨在帮助开发工程师弥补在Spring Cloud微服务、Nginx反向代理核心知识方面的短板！ 统筹全篇 这份手册前6章剖析Feign高并发RPC的底层原理，解析Hystrix高性能配置的核心选项，阐述Hystrix滑动窗口的核心原理。后4章介绍Nginx的核心原理及其配置，并结合秒杀场景实现Spring Cloud秒杀、Spring Cloud+Nginx Lua秒杀，为广大Java开发者提供一个全面学习高并发开发的实战案例。 同时这份笔记也是免费分享的，免费获取方式在文末！ 第1章Spring Cloud+Nginx高并发核心编程的学习准备 第2章Spring Cloud入门实战 第3章Spring Cloud RPC远程调用核心原理 第4章RxJava响应式编程框架 第5章Hystrix RPC保护的原理 第6章微服务网关与用户身份识别 第7章Nginx/OpenResty详解 第8章Nginx Lua编程 第9章限流原理与实战 第10章Spring Cloud +Nginx秒杀实战 总结 这份手册可以说是SpringCloud+Nginx高并发编程实战中一份弥足珍贵的笔记，无论是在日常开发之中开始面试前的准备，都是值得大家去阅读理解！

开发访问量比较大的系统是，爬虫的目的就是解决访问量大的问题；缓存穿透是为了保护后端数据库查询服务；计数服务解决了接近真实访问量以及数据库服务的压力。 架构图 限流 就拿十万博客来说，如果存在热点文章，可能会有数十万级别的并发用户参与阅读。如果想让这些用户正常访问，无非就是加机器横向扩展各种服务，但凡事都有一个利益平衡点，有时候只需要少量的机器保证大部分用户在大部分时间可以正常访问即可。 亦或是，如果存在大量爬虫或者恶意攻击，我们必须采取一定的措施来保证服务的正常运行。这时候我们就要考虑限流来保证服务的可用性，以防止非预期的请求对系统压力过大而引起的系统瘫痪。通常的策略就是拒绝多余的访问，或者让多余的访问排队等待服务。 限流算法 任何限流都不是漫无目的的，也不是一个开关就可以解决的问题，常用的限流算法有：令牌桶，漏桶。 令牌桶 令牌桶算法是网络流量整形（Traffic Shaping）和速率限制（Rate Limiting）中最常使用的一种算法。典型情况下，令牌桶算法用来控制发送到网络上的数据的数目，并允许突发数据的发送(百科)。 用户的请求速率是不固定的，这里我们假定为10r/s，令牌按照5个每秒的速率放入令牌桶，桶中最多存放20个令牌。仔细想想，是不是总有那么一部分请求被丢弃。 漏桶 漏桶算法的主要目的是控制数据注入到网络的速率，平滑网络上的突发流量。漏桶算法提供了一种机制

如何快速获得高并发编程经验？PCC性能挑战赛作品简介及源代码 PCC 是 Performance Challenge Championship （性能挑战杯）的缩写，是高可用架构后花园会员在线上组织的一个活动，由于反响热烈，考虑到线下进行可以更好的加深对高并发编程的理解，于是高可用架构在 3 月组织了本次 PCC 活动。 对于工程师来说，参加 PCC 编程挑战赛的部分意义： 体验完成一个技术小目标。高性能系统如何实现应当是每个工程师需要走的路。 学习优秀的架构方法，隔壁老王用的设计思想，可能你坐在办公室永远也无法想到。 有经验评委的点评，了解真实环境的高并发系统的追求目标。 类似主题、有同样级别参赛队员及评委参加的编程活动，可能仅此一次。 比赛方法说明 实现类似 facebook 中的 like 功能，需要： 可以对一个对象（一条feed、文章、或者url）进行 like 操作，禁止 like 两次，第二次 like 返回错误码 有 isLike 接口，返回参数指定的对象有没有被当前用户 like 过 需要看到一个对象的 like 计数 可以看到一个对象的 like 用户列表（类似 QQ 空间）； 上述列表加分项：Like优先显示我的好友列表(social list)。 数据量：每天新增的 like 对象数为 1 千万，每秒 like 计数器查询量为 30 万次 / 秒。 比赛盛况