十多年前我曾使用GoAccess搭建了一个NGINX日志分析工具，它以其轻量级、低资源消耗和实时更新的特性，非常适合个人和小站点使用。最近我的服务器做了次搬家，需要重新搭建日志分析系统，于是到网上查找GoAccess的用法时，发现官方站点的文档还是一如既往的晦涩，而其他站点介绍的用法则与我要搭建的架构不契合。所以干脆做了次总结，在这篇文章中，我将分享我如何搭建GoAccess，并使其通过Websocket协议提供实时日志分析。我的架构部署图如下所示：
这么部署的原因是为了经过NGINX走全站SSL加密，毕竟在NGINX统一管理SSL证书还是方便点。
本文首发于《中国金融电脑》第421期，今日头条地址链接。
随着信息技术的飞速发展，企业对于网络的依赖程度日益加深。传统的负载均衡技术曾经是企业数据中心的“守护神”，如今却在应对现代应用的快速交付、成本效益和自动化运维方面面临前所未有的挑战。分布式负载均衡技术可为企业网络带来革命性的改变。本文将深入分析从技术层面实现分布式负载均衡的关键要素，从弹性地址、“N+1”高可用系统到数据面与管理面的通信，介绍分布式负载均衡技术如何克服传统负载均衡技术的局限性，以确保网络的高性能和高可用性。
本文首发于《中国金融电脑》第420期，金网在线地址链接。
随着云原生、微服务的飞速发展，传统的负载均衡技术已逐渐难以满足日益复杂的业务需求。为了应对这一挑战，分布式负载均衡技术应运而生，它以其卓越的弹性、自助操作和可观测性，成为现代数据中心网络设计的核心。
本系列文章旨在深入探讨分布式负载均衡系统的多维度价值，从基础概念到技术实现，再到实际应用案例的全面分析。我希望通过这一系列的深入剖析，为读者提供一个全面的视角，理解分布式负载均衡技术如何为企业构建一个更加稳定、灵活和高效的网络环境。
系列概览：
当下性能测试已成为确保软件质量的关键环节。其中，wrk作为一款轻量级、高性能的HTTP基准测试工具，以其简洁的命令行界面和出色的性能著称。wrk通过-c参数能够模拟高并发的网络请求，帮助我们评估服务器在极端负载下的表现。如果你打算做C10K数万并发连接这个量级的测试，wrk是合适的（相比ab/jmeter等工具），然而，如果你想尝试进行数百万级别的高并发测试时，官方wrk就无能为力了。
首先，wrk不支持自定义源IP地址，这在需要模拟来自不同客户端的请求时尤为不便，做并发测试时TCP连接数也上不去（此时你在curl命令中验证会看到类似Cannot assign request address的错误）。其次，wrk在每个连接上预分配的内存相对较大，这在单机上尝试建立大量连接时，会导致内存资源迅速耗尽，wrk进程会因为OOM被内核杀掉（如果wrk进程突然消失，你通常可以在/var/log/messages中看到形如Out of memory的日志）。这些限制对于需要评估高性能服务的开发者来说，无疑是一个不小的障碍。
在接下来的内容中，我将探讨如何通过修改wrk源码解决上述问题，以期帮助读者更好地利用wrk进行极限并发测试。
有同学反馈：在配置Nginx四层限速时，proxy_upload_rate和proxy_download_rate有一定的概率不生效。我按照他的步骤也能复现，但这与官方Nginx很稳定（相对其他开源软件）的印象并不相符，是不是Nginx的官方BUG呢？这里的真实原因，其实是Nginx字节限速机制与时间更新频率的协商导致的，这篇文章我们就来研究下Nginx的字节限速。
首先看下测试场景：基于UDP协议搭建四层代理（UDP协议更简单，更容易复现BUG），在nginx.conf中配置每秒最大上传10个字节：
1 | proxy_upload_rate 10; |
客户端先发送10字节，服务器接收到后（用回包触发）客户端立刻再次发送10字节，预期服务器将在1秒后收到第2个报文，但实际上服务器有可能立刻收到报文，即proxy_upload_rate未生效或者不可控！一旦配置项处于不可解释的状态，这对于严谨的应用场景是不可接受的。而这个现象的原因，本质上是目前Nginx实现机制所致，接下来我会基于1.21版本的源码上解释其原理。
首先，我们要明确上例属于Nginx中的哪种限速。由于Nginx使用了内核协议栈，因此Nginx既不能对Packet级别的报文、也不能对TCP连接建立进行限速，而是只能在用户态基于调用socket编程API的时机，在字节转发速率、应用层协议的HTTP请求上（如官方的limit_req）做限制。