openresty

点击上方“朱小厮的博客”，选择“ 设为星标” 后台回复" 加群 "，加入新技术群 Redis的作者在博客上宣布：Redis 6.0.0 稳定版发布了。原文地址：http://antirez.com/news/132 那么，从RC1到今天，除了稳定之外，还有什么变化呢？ 1、重新设计了客户端缓存，特别是放弃了caching slot，而只使用key names。 2、现在Redis支持这样一种模式：如果用于复制的RDB文件不再有用，它将立即删除。在某些环境中，最好不要将数据放在磁盘上，而只放在内存中。 3、acl在特点方面变得更好。首先，有一个新的ACL日志命令，它允许查看所有违反ACL的客户机、访问不应该访问的命令、访问不应该访问的密钥，或者验证尝试失败。日志实际上在内存中，因此每个外部代理都可以调用“ACL log”来查看发生了什么。这对于调试ACL问题非常有用。 4、改进了复制协议PSYNC2。Redis能够更频繁地部分重新同步，使副本和主副本找到公共偏移。 5、带有超时的Redis命令现在不仅BLPOP并且以前可以接受秒的命令现在可以接受十进制数。 6、RDB文件现在加载速度更快。根据文件的实际组成（较大或较小的值），可以预期20/30%的改进。当有很多客户机连接时，信息也更快了，这是一个老问题，现在终于解决了。 7、我们有一个新命令STRALGO，它实现了复杂的字符串算法

自动支持图片webp格式压缩，图片服务器升级webserver webp server 是开源免费的。 图片服务器升级，自动支持webp，得先升级openresty 用go写的 webserver 请求到jpg png gif这些，再缓存起来，外面请求还是jpeg这些，实际先到go返回的webp格式，当浏览器不支持webp的才返回源文件。 提升加载时间，图片从434KB减少到340KB，1/4（25%）的压缩率。 根据 caniuse 的统计情况， 主流浏览器（接近80%）都支持 webp 了，如果遇到 Safari 这样的奇葩，直接返回原图。 最重要的一点是——我们访问的 URL 可以完全不用改变，访客访问的依然是xxx.jpg ，但是得到的图片格式为：image/webp，而且体积减少了不少（25%）。 WebP的有损压缩算法是基于VP8视频格式的帧内编码[17]，并以RIFF作为容器格式。[2] 因此，它是一个具有八位色彩深度和以1:2的比例进行色度子采样的亮度-色度模型（YCbCr 4:2:0）的基于块的转换方案。[18] 不含内容的情况下，RIFF容器要求只需20字节的开销，依然能保存额外的 元数据(metadata)。[2] WebP图像的边长限制为16383像素。 WebP 是一种衍生自 Google VP8 的图像格式，同时支持有损和无损编码。当使用有损模式

resty-gateway github: https://github.com/fengjx/resty-gateway 基于openresty + etcd实现的网关服务 依赖 resty.roundrobin lua-resty-jit-uuid lua-resty-etcd lua-resty-http lua-typeof 整体架构 服务启动时，将自己的节点信息注册到etcd，包括：服务名称、ip、端口 网关服务从etcd监听服务节点信息，保存到缓存中，从客户端请求的url中提取服务名称，通过服务名称查找节点信息，将请求转发到后端服务 todo 服务发现，动态路由 自动生成requestId，方便链路跟踪 动态ip防火墙 限流器 用户登录认证 接口协议加解密 文档 详细文档查看： https://blog.fengjx.com/openresty/gateway/ 来源： oschina 链接： https://my.oschina.net/u/4352984/blog/4260632

arthas 是阿里巴巴开源的强大的jvm 应该分析工具，以下是使用arthas 生成jvm 火焰图的一个学习 项目使用docker-compose 运行，对于生成的火焰图使用nginx 提供一个访问入口 环境准备 docker-compose 文件 version: "3" services: web: image: openresty / openresty: alpine ports: - "8090:80" volumes: - "./flamegraph:/opt/mywebs" - "./nginx.conf:/usr/local/openresty/nginx/conf/nginx.conf" app: build: . / cap_add: - ALL ports: - "8080:8080" volumes: - "./flamegraph:/usr/local/tomcat/arthas-output" tomcat 集成arthas dockerfile FROM tomcat # copy arthas COPY -- from = hengyunabc / arthas: latest / opt / arthas / opt / arthas nginx config worker_processes 1; user root; events {

整体流程 filebeat收集openresty应用日志传输到Redis集群中 Logstash从Redis集群中拉取数据，并传输到Elasticsearch集群 使用Kibana可视化索引 使用Elasticsearch-head管理lasticsearch集群 注：Logstash不支持集群模式 环境 均为CentOS 7.4 x64系统 openresty 192.168.0.10 1.15.8版本 filebeat 192.168.0.10 7.3.0版本 Redis集群 192.168.0.11 6381-6386端口(暂采用伪集群的方式) 5.0.5版本 Logstash 192.168.0.12 7.3.0版本 Elasticsearch集群 192.168.0.13-15 7.3.0版本 Kibana 192.168.0.16 7.3.0版本 Elasticsearch-head 192.168.0.17 软件下载地址 filebeat|Logstash|Elasticsearch|Kibana： https://www.elastic.co/cn/downloads/past-releases#elasticsearch Elasticsearch-head： https://github.com/mobz/elasticsearch-head Redis：

前言 组织的容器支持docker-compose部署，组织的容器支持kubernets部署。 以php框架thinkphp为示例，演示php项目的kubernets部署。 多容器方式（3容器）分别为： appphp（php代码），openresty（nginx webserver），php-fpm（php的运行环境） dockerfile 和 yaml文件 docker iamges仓库 PHP项目在Docker中如何部署运行？ PHP应用的运行方式 PHP应用的运行方式一般有Apache mod_php 模式、Nginx（FastCgi）+PHP-FPM模式、Swoole常驻内存Daemon模式。 Docker单容器 Apache mod_php 模式和Swoole常驻内存Daemon模式本身就是单程序，那么在Docker中入口运行程序直接为应用程序即可。 Nginx（FastCgi）+PHP-FPM模式需要nginx和php-fpm 2个程序，这样Docker中就需要运行多个程序，需要有进程守护类软件来运行多个程序。 推荐使用s6-overlay Docker Hub中PHP官方镜像包已经包括Apache mod_php 模式的镜像包，Kubernets官方PHP项目实例GuestBook中就是采用这种模式的镜像包。 Docker多容器配合 Docker官方倡导容器单一职责

你们知道淘宝，京东这些购物商场吗？他们到了双11，双12为什么能支持全国14亿人口同时购物下单呢，因为他们的程序做到了高并发、高性能、高可用。那么你对程序员的三高了解多少呢？ 高并发指标有哪些？ 响应时间：系统对进来的请求反应的时间，比如你打开一个页面需要1秒，那么这1秒就是响应时间 吞吐量：吞吐量是指每秒能处理多少请求数量，好比你吃饭，每秒能吃下多少颗米饭。 秒查询率：秒查询率是指每秒响应请求数，和吞吐量差不多。 并发用户数：同时承载正常使用系统功能的用户数量。例如一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数。 什么是高性能呢？ 高性能是指程序处理速度非常快，所占内存少，cpu占用率低。高性能的指标经常和高并发的指标紧密相关，想要提高性能，那么就要提高系统发并发能力，两者互相捆绑在一起。应用性能优化的时候，对于计算密集型和IO密集型还是有很大差别，需要分开来考虑。还有可以增加服务器的数量，内存，IO等参数提升系统的并发能力和性能，但不要浪费资源，要考虑硬件的使用率最高才能发挥到极致。 高可用 高可用通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。高可用注意如果使用单机，一旦挂机将导致服务不可用，可以使用集群来代替单机，一台服务器挂了，还有其他后备服务器能够顶上。或者使用分布式部署项。比如现在redis的高可用的集群方案有：

我们基于gitbase 暴露的mysql 服务，可以方便的查询数据，但是如果需要长时间计算的就不太好了 还是我们可以通过bloom通过配置的方式就可以解决，以下是一个实践以及一些问题的解决访问 环境准备 docker-compose 文件 version: "3" services: lb: image: openresty / openresty: alpine volumes: - "./nginx-lb.conf:/usr/local/openresty/nginx/conf/nginx.conf" ports: - "9000:80" bloom: image: dalongrong / bloom: v1 .28.0 volumes: - "./bloom.cfg:/etc/bloom.cfg" ports: - "8811:8811" - "9001:8080" redis: image: redis ports: - "6379:6379" gitbase: container_name: gitbase hostname: gitbase image: srcd / gitbase: v0 .24.0 - rc2 volumes: - "./git-demos:/opt/repos" ports: - "3306:3306" sqler: image:

本文作者：HelloDeveloper 1 背景 起初，在网盘快速发展期，为了快速上线，采用了服务单体化 + 主干开发模式进行研发，随着用户规模爆发式的增长以及产品形态的丰富，单体化的不足就体现出来了，于是架构上采用了微服务架构，开始对业务逻辑进行拆分部署。 服务拆分之后，也引入了新的问题，具体如下： 请求路由： 服务部署从物理机向虚拟化方式迁移中，有大量的切流量操作，需要相关的上游都进行升级上线修改，效率低下 故障管理： 单实例异常、服务级别异常、机房故障异常、网络异常等，严重缺失或者不完善，同时配套的故障定位也没有，服务稳定性不足 流量转发： 不同的服务采用了不同的框架，甚至裸框架，策略不完善，导致负载不均衡 研发效率： 相同的功能点，需要在不同的语言框架上实现一次，浪费人力，同时升级周期比较长，收敛效率低 2 解决方案 - UFC 2.1 UFC 发展史 为了解决这个问题，从2015年底开始思考解决方案，确定了解决问题的 核心在于管控请求流量 ，在2016年开始 自研网络流量转发中间件 - UFC(Unified Flow Control) ，业务通过同机部署的agent进行服务通信，相关的发展史如下： 2.2 UFC 和 Service Mesh的关系 后来在调研业界相关技术的时候，发现了istio(业界Service Mesh的典型代表) ，从而发现了Service

前言 在微服务架构中，由于系统和服务的细分，导致系统结构变得非常复杂， 为了跨平台，为了统一集中管理api，同时为了不暴露后置服务。甚至有时候需要对请求进行一些安全、负载均衡、限流、熔断、灰度等中间操作，基于此类种种的客观需求一个类似综合前置的系统就产生了，这就是API网关（API Gateway）。API网关作为分散在各个业务系统微服务的API聚合点和统一接入点，外部请求通过访问这个接入点，即可访问内部所有的REST API服务。目前常用的微服务网关有zuul、gateway，今天来简单介绍一下另一种选择——Kong 。说到Kong可能对大家有点陌生，我们来先了解下另一种不陌生的中间件——OpenResty。 OpenResty OpenResty® 是一个基于 Nginx 与 Lua 的高性能 Web 平台，其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。因此，我们可以做出各种符合我们需要的网关策略的Lua脚本，以其为基础构建高性能的网关系统。 Kong Kong基于OpenResty，是一个云原生、快速、可扩展、分布式的Api 网关。继承了OpenResty的高性能、易扩展性等特点。Kong通过简单的增加机器节点，可以很容易的水平扩展。同时功能插件化