在所有互联网公司中，Nginx 作为最常用的 7 层负载均衡代理层，每个后端开发人员和运维人员都应该对其有较为深入的理解。 本文作者深入参与了[《容器 LB 的开发和建设》](https://gitbook.cn/gitchat/activity/5df6cef5981db64f3a458240)，从中积累了一些 Nginx 在实战中的一些经验，本文所涉及到的几块内容是 Nginx 中最常见的。 本文所涉及到的 Nginx 的一些高级实战应用包括： * Nginx upstream 的 max\_fails 和 fail_timeout 指标 * 具体指标的含义 * 线上最佳配置 * 线上没有合理配置而引发的一些问题说明 * max_fails 机制和主动健康检查机制需要共存的原因 * Nginx 惊群问题的重新思考 * 分别有哪些方案 * 作者经历过的 accept_mutex 方案下的一些问题 * 开启 reuse port 有些什么要求，直接开启会带来什么问题？ * 一个线上真实问题的排查解决思路，Nginx Reload 引发的 502 * 为何 Nginx Reload 会引发 502 ？ * 分析和解决问题的思路？ * 抓包分析的结果

云原生下 Kubernetes 容器编排方案是当下最优选择，各个中型、大型互联网公司统统拥抱 Kubernetes，没有其他方案可以与 Kubernetes 匹敌。 所有业务（尤其是高并发业务）的访问必然要通过负载均衡 LB 代理层，服务端高并发系统离不开负载均衡，大中型公司下，负载均衡代理层都是有专人进行独立开发和建设的，云原生 Kubernetes 容器平台下的 LB 代理层，同样需要有专人来负责建设和维护。那么 Kubernetes 容器平台基础下的的 LB（Nginx） 负载均衡代理层要怎么建设？和非容器平台下的 LB 建设有什么异同？建设的核心要点和当下最优的方案是什么？ 在本 Chat 中，作者结合自身经验（主导建设和优化容器 LB 体系），总结输出如下内容： * 容器 LB 建设的背景 * 负载均衡的基础知识概览 * 容器化下 LB 的异同点 * 容器 LB 负载均衡怎么建设 * 业务功能需求 * 运维管理需求 * 基本方案和基本原则 * 容器 LB 体验优化（LB 架构产品设计） * 怎么优化使用体验 * 有哪些痛点 * 容器 LB 开发设计的核心考量点 * 核心需求 * 核心功能 * 关键设计 * 基于 Kubernetes 的 nginx-ingress-controller 方案概要 * nginx-ingress-controller 方案是什么 * nginx-ingress-controller 方案的关键点有哪些 **适应人群** ：Kubernetes 开发者、LB 开发者、Kubernetes 基础运维人员、LB（Nginx）从业者、容器平台开发 or 架构设计人员。 **相信任何人看完本 Chat，都会对 Kubernetes 容器平台的 LB（Nginx）负载均衡了然于心，并且能够在今后的工作中，站在前人的肩膀上，快速超越同龄人。并且可以快速深入 Kubernetes 开发，尤其是快速深入建设 Kubernetes LB（Nginx）负载均衡体系。**

性能压测，是保障服务可用性和稳定性过程中，不可或缺的一环，但是有关性能压测的体系化分享并不多。我们将从性能压测的设计、实现、执行、监控、问题定位和分析、应用场景等多个纬度对性能压测的全过程进行拆解，以帮助大家构建完整的性能压测的理论体系，并提供有例可依的实战。 通过本场 Chat，您将在以下 4 方面获得收益： 1. 为什么要做性能压测； 2. 性能压测的基本概念； 3. 如何选取性能压测工具； 4. 工具选型对比，包括 Apache Bench(ab)/LoadRunner/JMeter/PTS。 本场 Chat 适合于：在工作中会使用到性能压测的研发、测试、质量和运维工程师。 ----- 第二期分享嘉宾：殷成涛，花名风起，阿里云 PTS 开发工程师，专注于性能压测与高可用架构领域。

性能测试在日常的开发工作中是常规需求，用来摸底服务的性能。 那么如何做性能测试？要么是通过编码的方式完成，写一堆脚本，用完即弃；要么是基于平台，在平台定义的流程中进行。对于后者，通常由于目标场景的复杂性，如部署特定的 workload、观测特定的性能项、网络访问问题等，往往导致性能测试平台要以高成本才能满足不断变化的开发场景的需求。

本实践简单介绍了如何使用 chart 在树莓派 k8s 集群用 Helm 部署一个 Spring Cloud 示例项目，该 Spring Cloud 示例项目虽然简单，但相对完整地整合了注册中心、调用链、网关、配置中心、断路器面板和具体业务模块的集成，并将所有组件容器化、成功部署到树莓派 k8s 集群环境，对启发其它 Spring Cloud 项目容器化改造有一定参考价值。 在本场 Chat 中，会讲到如下内容： - 树莓派 k8s 集群部署 Spring Cloud 微服务项目 适合人群： 拥有树莓派 k8s 集群的 Java 开发者，对 Spring Cloud 项目有容器化改造的实践者

性能测试在日常的开发工作中是常规需求，用来摸底服务的性能。 那么如何做性能测试？要么是通过编码的方式完成，写一堆脚本，用完即弃；要么是基于平台，在平台定义的流程中进行。对于后者，通常由于目标场景的复杂性，如部署特定的 workload、观测特定的性能项、网络访问问题等，往往导致性能测试平台要以高成本才能满足不断变化的开发场景的需求。

本实践简单介绍了如何使用 chart 在树莓派 k8s 集群用 Helm 部署一个 Spring Cloud 示例项目，该 Spring Cloud 示例项目虽然简单，但相对完整地整合了注册中心、调用链、网关、配置中心、断路器面板和具体业务模块的集成，并将所有组件容器化、成功部署到树莓派 k8s 集群环境，对启发其它 Spring Cloud 项目容器化改造有一定参考价值。 在本场 Chat 中，会讲到如下内容： - 树莓派 k8s 集群部署 Spring Cloud 微服务项目 适合人群： 拥有树莓派 k8s 集群的 Java 开发者，对 Spring Cloud 项目有容器化改造的实践者

本篇是“SpringCloud 应用在 Kubernetes 上的最佳实践”系列文章的第六篇，主要介绍了如何保障生产环境服务稳定，做到随时发布，从而加快业务的迭代和上线速度。