•④ 如果想解决上边的2次内网的通信最理想的方式，上图中的2个节点都不要就可以了。
昨天的文章详细的介绍了mock，今天补充一个mock服务的实际使用场景——高并发性能测试时的依赖服务mock；
Nginx主要有两种限速方式：按连接数限速(ngx_http_limit_conn_module)、按请求速率限速(ngx_http_limit_req_module)。超出限制的请求会直接拒绝，可防御简单的cc攻击
PS：一般用nginx比较多就是反向代理，其实很多特殊的配置也是在大型互联网电商经常使用的。所以这个高速缓存和防盗链也是一个不错的功能。
常见的互联网架构中，一般都能看到spring+mybatis+mysql+redis搭配的身影，在我所服务的公司亦是如此。一般来说，应用内部的接口都是直接调用的，所谓的面向接口编程，应用间的调用直接调或者通过类似dubbo之类的服务框架来执行，数据格式往往采用json，即统一也方便各数据间做转换和取值，缓存一般使用redis或memcached，存储一些对象或json格式的字符串。对外提供的接口，一般都需要进行压力测试，以便估算其性能，并为后续的调优提供指导方向，以下接口便是在压测过程中出现的各种“奇怪现象”，所谓奇怪，指的是从表象上看与我们正常的逻辑思路不符，但其本质还是我们对压力下程序的表现出来的特征不熟悉，用惯用的知识结构试图去解释，这根本是行不通的。下文是我在一次全面压测过程后对数据进行的分析汇总，其中的现象是很多压测常见的，里面的分析过程及改进措施我认为有很大的参考意义。具体内容如下：（部分接口为了安全我省略了其名称，但不影响我们的分析，另外形如1N3T之类的表示的是1台nginx，3台tomcat,具体的tps数值只是为了说明优化前后的比照，没有实际意义）
1、PV（Page View）： 页面访问量，即页面浏览量或点击量，用户每次刷新即被计算一次
Nginx 的 upstream 模块会实现所谓的被动健康检查，也就是利用 max_fails 机制来实现，如果请求后端 upstream peer出现一些错误，当错误的累计次数达到 max_fails，那么该 upstream peer 会被 Nginx 摘掉 fail_timeout 时间，在这个时间内，这个 upstream peer 节点禁止对外提供服务。
为更好的理解用户，互联网公司会将用户的行为收集上来进行分析，打点系统应运而生。但互联网公司的用户数都比较多，而且每个用户的行为也很多，这样服务器收到的打点请求就非常多，QPS非常高，对web服务器的要求也会非常之高。为提升整个打点系统的性能，可以采用以下几个方式。
github 项目地址： https://github.com/SilentCC/nginx_lua_qps_count
其中第一种和第二种方案都要经过iptables 转发，第三种方案不经过iptables，本测试主要是为了测试这三种方案的性能损耗。
这两天遇到一个很有意思的应用场景：有一个业务应用部署在kubernetes容器中，如果将该应用以Kubernetes Service NodePort暴露出来，这时测试人员测得应用的页面响应性能较高，可以达到2w多的QPS；而将这个Kubernetes Service再用Ingress暴露出来，测试人员测得的QPS立马就较得只有1w多的QPS了。这个性能开销可以说相当巨大了，急需进行性能调优。花了一段时间分析这个问题，终于找到原因了，这里记录一下。
单位时间的请求数就是QPS,那么在nginx服务的网站下,如果要统计QPS并且按从高到低排列,需要使用awk配合sort进行处理 awk做的主要工作是把access每行日志按分隔符分开,然后循环每一行,存到一个数组里,如果只按时间不区分脚本路径,数组里存的数据是比如arr['[28/Nov/2019:14:12:23']=20 key是时间,value是次数
默认情况下，Kubernetes 的 Deployment 是具有滚动更新的策略来进行 Pod 更新的，该策略可以在任何时间点更新应用的时候保证某些实例依然可以正常运行来防止应用 down 掉，当新部署的 Pod 启动并可以处理流量之后，才会去杀掉旧的 Pod。
以往我们推崇异步 I/O 来实现高并发下的高性能，如今 NodeJS 步入 8.x 时代，async await 可以用同步的写法来实现异步处理，不知道对性能是否会有影响，来做个简单的测试。
开启此功能，在Nginx配置有多个server_name的情况下，会根据不同的server_name进行流量的统计，否则默认会把流量全部计算到第一个server_name上。
朱伟，微博广告SRE团队负责人，《智能运维：从0搭建大规模分布式AIOps系统》作者之一。目前负责微博广告业务可用性的保障与优化、资源利用率的提升、监控报警系统的建设以及自动化体系的推进。
1、TCP_NODELAY 你怎么可以强制 socket 在它的缓冲区里发送数据？ 一个解决方案是 TCP 堆栈的 TCP_NODELAY选项。这样就可以使缓冲区中的数据立即发送出去。
国内用Nginx的比较多，Nginx的监控比较老的方案可能是通过跑脚本定期收集nginx的status模块的数据，或者监控nginx的日志；后来阿里的tengine在国内开始流行，于是诞生了很多不错的lua模块;但是这些监控方案在有新的监控需求的时候，可能就需要再修改脚本或者更改nginx conf配置，有时候不是特别的方便。用Prometheus进行nginx的监控可以自动的对相关server_name和upstream进行监控，你也可以自定义Prometheus的数据标签，实现对不同机房和不同项目的nginx进行监控。 监控Nginx主要用到以下三个模块： nginx-module-vts：Nginx virtual host traffic status module，Nginx的监控模块，能够提供JSON格式的数据产出。 nginx-vts-exporter：Simple server that scrapes Nginx vts stats and exports them via HTTP for Prometheus consumption。主要用于收集Nginx的监控数据，并给Prometheus提供监控接口，默认端口号9913。 Prometheus：监控Nginx-vts-exporter提供的Nginx数据，并存储在时序数据库中，可以使用PromQL对时序数据进行查询和聚合。
HTTP1.1之后，HTTP协议支持持久连接，也就是长连接，优点在于在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。
Pod 在滚动升级部署中部署pod个数到可用指标更新速率 是衡量 Kubenetes 调度能力最核心指标
在之前的文章我介绍了下 Custom Metric 怎么实现自动扩容的。k8s基于自定义指标实现自动扩容
你的项目最大能承受多少请求 经常见到有人问：我的项目出现了 XXX 的错误（如崩溃，502）等等，是不是机器撑不住了？是不是该做负载均衡了？是不是需要优化 php-fpm？如果我根据他的问题再深一步问，几乎都对自己的项目到底能支撑多大的负载没什么概念。不能定位问题又怎么能解决问题呢？现在说一下怎么简单计算你的项目最大能支撑的访问（以 nginx+php-fpm 为例）。 常见单位 qps：每秒请求数（一秒内多少次请求） rpm：每分钟请求数（一分钟内承受多少次请求） 公式 项目最大负载量（假设单位是 qps
webman是一款基于workerman开发的高性能HTTP服务框架。webman用于替代传统的php-fpm架构，提供超高性能可扩展的HTTP服务。你可以用webman开发网站，也可以开发HTTP接口或者微服务。
在k8s集群中部署大量的Nginx服务，通过ApacheBench工具压测固定的一个服务，对比开启和不开启kube-router场景下的QPS，衡量kube-router带来的性能损耗。
深入了解nginx，get到nginx的一些性能优化方向。除了了解如何保持长连接，也通过本案例学习到开源中间件的一些常用定位思路和优化方法。
对于常用的服务器，大家可能更多的知道apache，tomcat，lls等服务器。我们跟多的了解到nginx常常用于反向代理。而实质是nginx也是一个高性能服务器。常用于前端页面资源静态化和负载均衡的反向代理。
web 服务器 nginx 以其高性能与抗并发能力越来越多的被用户使用。 作为一款服务器产品，其运行状态是我们密切关注的，因此，对 nginx 的实时监控就成为必须要关注的了。 nginx 提供了 ngx_http_stub_status_module 模块，这个模块提供了基本的监控功能。 作为官方企业版的 nginx plus 通过 ngx_http_status_module 提供了更加完善的监控功能: http://demo.nginx.com/status.html。
线上有几台QPS每秒几万请求的服务器，大致访问链路如下：client -> nginx -> web 服务器，由于每台机器上混布了多个web服务并通过nginx反向代理统一分发请求，在服务升级的时候经常出现端口被占用的情况，排查问题时，发现系统过存在几万多个 time_wait状态。统计命令如下：
功能测试用python、shell之类的脚本，勉强可以胜任。性能压力测试再手动写脚本，就有点力不从心了。
现在的 Web 服务有一个很重要的性能指标叫 QPS，QPS 的全称是 Queries Per Second 意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。QPS 越高，说明并发度高，服务器每秒可以服务更多的用户。
PHP语言从1995年发布，至今已经有29多年的历史，在期间涌现了成千上万的MVC框架，大致可以将其分为以下三大类:
秒杀活动主要涉及的前端页面有活动推广页、商品详情页，涉及到的后端服务主要有商品服务、库存服务、订单服务，简要流程图如下：
我们先来看看这张图，首先我们可以思考一下，这个架构中，哪些地方可以做负载均衡，来承载更高的 QPS 呢？
学习了一些东西，如何才是真正自己能用的呢？好像就是看自己的潜意识的反应，例如解决了一个问题，那么下次再碰到类似的问题，能直接下意识的去找到对应的信息，从而解决，而不是和第一次碰到一样，从头开始查一遍，如果是，那么这个问题对于你来说，可能依旧是一个新的问题。
网关，就是指一个流量的集中式出入口。而 API Gateway，顾名思义，就是在 Gateway 上再添加了一些 API 相关的功能后得到的东西。 具体而言，API Gateway 就是比普通的网关多干了一些以前我们在应用内部实现的事：身份认证，权限控制，基于来源的流量控制，日志服务等，甚至是直接在第七层魔改 HTTP 请求的内容。好处有：
此时通过http://IP地址:port/status就可以看到nginx的状态信息了。
项目某后台接口QPS出现周期性的掉坑现象。每一次耗时的峰值，都对应一次QPS掉坑。
Nginx Ingress Controller 基于 Nginx 实现了 Kubernetes Ingress API，Nginx 是公认的高性能网关，但如果不对其进行一些参数调优，就不能充分发挥出高性能的优势。Nginx Ingress工作原理：
最近在一个客户的项目拓展和做过程中，希望客户在IDC中自建的容器服务能够部分使用云上的容器服务，基于IDC环境和虚拟机上的容器服务之间，做了一些静态和动态的性能对比测试。测试过程终于到一些问题，针对问题前后经过多轮分析对比，在问题定位和分析上的一些总结，希望能供大家借鉴。
本文为霍格沃兹测试学院优秀学员课程学习系列笔记，想一起系统进阶的同学文末加群交流。
首先nginx的日志是按照时间顺序的。因此计算QPS，只需要先统计条数，再计算时间差，二者相除就可以得到。
在开始做压测计划之前，一定要先明确压测的目标是什么，虽然最终的目标肯定都是优化系统的性能，但是不同的出发点，可能需要采取不同的方法。
如今 Twemproxy 凭借其高性能的优势, 在很多互联网公司得到了广泛的应用，已经占据了不可动摇的地位，
近年来，在云计算、大数据和人工智能等技术的快速发展下，数据中心的计算能力也面临着越来越高的挑战。就数据中心的 CPU 处理器选择而言，AMD 因其最新一代 EYPC 处理器的强劲性能、低功耗以及低成本的优势逐渐赢得主流云厂商的青睐。
一说起CLB的负载均衡策略， 可能很多人都耳熟能详：轮询、加权轮询、源地址hash、目标地址hash，但知道这些就够了吗？
QPS ：Queries Per Second 从字面意思就可以理解：是每秒查询率 ,是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准, 即每秒的响应请求数，也即是最大吞吐能力。
作为后端的程序开发人员，经常听到高并发，但是高并发到底有多高？其实是没有数值定义的
漏桶(Leaky Bucket)算法思路很简单,水(请求)先进入到漏桶里,漏桶以一定的速度出水(接口有响应速率),当水流入速度过大会直接溢出(访问频率超过接口响应速率),然后就拒绝请求,可以看出漏桶算法能强行限制数据的传输速率。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
云直播
