openresty

最近生产环境在这两个参数之间遇到过几次坑。这里记录下。 client_max_body_size client_max_body_size 默认 1M，表示 客户端请求服务器最大允许大小，在“Content-Length”请求头中指定。如果请求的正文数据大于client_max_body_size，HTTP协议会报错 413 Request Entity Too Large。就是说如果请求的正文大于client_max_body_size，一定是失败的。如果需要上传大文件，一定要修改该值。 client_body_buffer_size Nginx分配给请求数据的Buffer大小，如果请求的数据小于client_body_buffer_size直接将数据先在内存中存储。如果请求的值大于client_body_buffer_size小于client_max_body_size，就会将数据先存储到临时文件中，在哪个临时文件中呢？ client_body_temp 指定的路径中，默认该路径值是/tmp/. 所以配置的client_body_temp地址，一定让执行的Nginx的用户组有读写权限。否则，当传输的数据大于client_body_buffer_size，写进临时文件失败会报错。 这个问题我们遇到过。 20648 open() "/usr/local/openresty-1.9

背景 传统Web应用中所有的功能部署在一起，图片、文件也在一台服务器；应用微服务架构后，服务之间的图片共享通过FTP+Nginx静态资源的方式进行访问，文件共享通过nfs磁盘挂载的方式进行访问，无论是单体架构还是微服务架构下的应用都存在大量图片、文件读写操作，但是昂贵的磁盘空间、高性能服务器无疑增加了运营成本。 所以我们希望文件服务也能微服务、独立化，这样既能降低运营成本，又能对文件进行统一的管理和维护，所以搭建独立的文件服务是解决文件共享、释放业务系统压力的最优选择。于是便诞生了随行付分布式文件系统简称OSS(Object Storage Service)，提供的海量、安全、低成本、高可靠的云存储服务。它具有与平台无关的RESTful API接口，能够提供数据可靠性和服务可用性。 文件服务的意义 随着互联网图片、视频时代的到来，对文件的处理成为各个业务系统面临的巨大挑战，没有文件服务器之前，系统之间处理图片的方式大相径庭：FTP、NFS、数据库存储等等，虽然都实现了对文件的存储、访问，但是系统之间很难达到文件共享，所以文件服务可以形成一个统一的访问标准，降低各个系统之间的互相依赖，提高开发效率、释放业务系统压力，所以文件服务的意义如下： 降低WEB服务器压力 分担业务服务器的I0、流程负载，将耗费资源的文件访问、读写操作分离到文件服务器，可以提高服务器的性能和稳定性

Nginx + Lua + Cookie 控制灰度发布 一、下载安装 1、 安装 OpenResty下载页 、 openresty-1.15.8.2.tar.gz包(点击下载 )、 包版本列表 2、 安装指导页 (点击打开) 3、 参考 CentOS 二、 命令安装 1、 - brew - $ brew install openresty/brew/openresty 2、 查看 openResty 安装目录 - $ nginx -t 如图： 3、 设置别名 - $ export PATH=/usr/local/opt/openresty/nginx/sbin:$PATH 4、 启动 - $ nginx 三、 设置工作目录如：配置文件 conf 如： nginx.conf 1、 通过 nginx -t 2、 拷贝 配置文件夹到 工作目录 - $ cp -r /usr/local/etc/nginx ~/work 修改 nginx 文件夹为 conf 名 - $ mv nginx conf 如图： 四、 修改 nginx.conf 引入 Lua 脚本 如图： 五、 设置 resty.cookie 1 、拷贝代码 https://github.com/cloudflare/lua-resty-cookie/blob/master/lib/resty/cookie.lua 2 、打开

前言 凹凸实验室从最初的前端团队成长为如今的全端团队，意味着我们不仅关注前端的技术能力，也重视全端及全栈的能力。在这一篇，我们从前端团队角度出发，阐述我们最初搭建服务端体系遇到的一些困难，已构建的服务体系架构，以及如何更好地助力业务增长。 些许似曾相识 首先，我们来看下日常工作中存在的一些场景。 场景A：在某些业务中，底层数据团队提供的数据接口并没有提供 HTTP 调用，需要去寻找其他服务端团队来封装，这时候需要等待其他团队排期，可能造成业务无法正常上线； 场景B：前端页面性能卡顿，由于调用接口过多，需要等待其他服务端团队聚合数据； 场景C：我们在一些项目需要SSR，前后端需要复用统一套模板； 场景D：我们内部孵化了一些项目，需要接口服务，需要等待其他服务端团队支持。 这些场景的背后，我们急需组建一个服务端研发团队来承担部分的业务服务开发以及更好地帮助团队未来发展。 成型 在团队组建上，主要采用「内部选拔」 + 「外部招聘」2 种方式。在团队发展上，我们主要经历了 3 个阶段。 雏形 在最初的阶段，选择以 NodeJS 作为服务端编程语言，主要以下有 2 点考虑： 团队大部分同学熟悉 Javascript，能够快速学习 NodeJS，上手成本较低； 在 SSR 方面有天然的优势，前后端能够共用部分代码。 在这个阶段，我们快速孵化了一系列的系统和平台，比如 Mock 平台

OpenResty 是一个开源的 Web 平台，用于开发高性能和高动态的 Web 网关或者 Web 应用。OpenResty 最早是为了支持全网搜索引擎周边的相关搜索的 API 接口，后来我们基于 Nginx 和 LuaJIT 重写了 OpenResty，用于支持淘宝量子统计这款产品的所有数据 API，再后来，我加入美国的 CDN 公司 Cloudflare，使用 OpenResty 驱动 Cloudflare 全球 CDN 网络的动态 http 和 https 代理系统。 从出生的第一天起，OpenResty 就是开源的。这些年来， OpenResty 社区尝试把它用于各种不同的业务场景，有些场景甚至是我们完全无法想象的。 比如有的公司使用它构建分布式网络存储系统的前端和后端（比如网盘应用）；有的用它来构建完整的 Web 应用，像电商平台的商品详情页的生成和大型体育赛事的 Web 管理系统；也有的公司基于它构建大型的互联网广告平台，或者更复杂的 Web API 管理系统；还有的公司拿它来驱动小流量调度的硬件盒子，或者驱动家居陪伴型机器人；当然，更多的还是用于实现那些流量非常庞大的 Web API。[似乎和流量相关的工作都有机会用到 OpenResty，我们也有用户使用完全基于 OpenResty 的权威 DNS 服务器。] OpenResty 的优势在于小巧灵活、高性动态。 基于

Openresty和Tengine基于 Nginx 的两个衍生版本，某种意义上他们都和淘宝有关系，前者是前淘宝工程师agentzh主导开发的，后者是淘宝的一个开源项目； Openresty的最大特点是引入了ngx_lua模块，支持使用lua开发插件； Tengine的特点是融入了因淘宝自身的一些业务带来的新功能； Tengine 简介 tengine官方网站： http://tengine.taobao.org/index_cn.html 在 Nginx官方版本的基础上增加的一些定制模块如下： 1、支持动态加载模块：通过加载so文件实现，不用再重新编译整个项目了，配置如下： dso { load ngx_http_lua_module.so; load ngx_http_memcached_module.so; } 2、ngx_proc_daytime_module模块，这个模块允许开一个独立的服务进程，该模块本身并未实现具体的业务逻辑，而是构建了一个TCP Server框架，等待开发者来实现自己的业务； 3、ngx_http_concat_module模块，用于合并多个文件的响应； 4、ngx_http_upstream_session_sticky_module模块，该模块是一个负载均衡模块，通过cookie实现客户端与后端服务器的会话保持,

OpenResty(又称：ngx_openresty) 是一个基于 NGINX 的可伸缩的 Web 平台，由中国人章亦春发起，提供了很多高质量的第三方模块。 OpenResty 是一个强大的 Web 应用服务器，Web 开发人员可以使用 Lua 脚本语言调动 Nginx 支持的各种 C 以及 Lua 模块,更主要的是在性能方面，OpenResty可以 快速构造出足以胜任 10K 以上并发连接响应的超高性能 Web 应用系统。 360，UPYUN，阿里云，新浪，腾讯网，去哪儿网，酷狗音乐等都是 OpenResty 的深度用户。 在公众号下，回复"ngxlua"，返回201页的PDF下载链接。 本文分享自微信公众号 - 糖果的实验室（mycandylab）。 如有侵权，请联系 support@oschina.cn 删除。 本文参与“ OSC源创计划 ”，欢迎正在阅读的你也加入，一起分享。 来源： oschina 链接： https://my.oschina.net/u/4580416/blog/4695754

开源waf是网络安全的重要部分，Cloudflare认为：十年后数字经济的网络安全基础设施会像水过滤系统一样普及，而这个过滤系统的核心就是waf。对于服务器来说，部署WEB应用防火墙十分重要，这方面的开源waf很多，但优秀的太少，笔者经过大量搜索，并结合市场热度，整理出2021年十大开源waf供大家参考。 1、OpenResty OpenResty 是由中国人章亦春发起，把nginx和各种三方模块的一个打包而成的软件平台，核心就是nginx+lua脚本语言。主要是因为nginx是C语言编写，修改很复杂，而lua语言则简单得多，国内很多大公司如360、京东、gitee等都在用来作为web应用防火墙。 项目地址： https://github.com/openresty/ 2、AIHTTPS aihttps是hihttps的升级版，也是由中国人编写。特点是兼容ModSecurity规则，并且已经向人工智能方向进化：使用机器学习自主生成对抗规则，来防御包括：漏洞扫描、CC 、DDOS、SQL注入、XSS等。其商业版也开源，是目前商业化开源程度最高的WAF。 项目地址： https://github.com/qq4108863/ 官网： http://www.hihttps.com 3、ModSecurity ModSecurity是开源WAF的鼻祖，是一个开源的跨平台Web应用程序防火墙