nginx

我们先认识一下SpringCloud的各个组件，然后知其所以然。 Spring Cloud架构的各个组件的原理分析 原理讲解前，先看一个最经典的业务场景，如开发一个电商网站，要实现支付订单的功能，流程如下： 创建一个订单之后，如果用户立刻支付了这个订单，我们需要将订单状态更新为“已支付” 扣减相应的商品库存 通知仓储中心，进行发货 给用户的这次购物增加相应的积分 如上，微服务的应用场景和核心竞争力： 降低耦合： 每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。 独立部署： 由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。 选型灵活： 微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。由于每个微服务相对简单，故需要对技术栈进行升级时所面临的风险就较低，甚至完全重构一个微服务也是可行的。 容错机制： 当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中

1. 前言 本文排查的问题是经典的TCP队列溢出问题，因TCP队列问题在操作系统层面没有明显的指标异常，容易被忽略，故把排查过程分享给大家。 2. 问题描述 A服务调用B服务接口超时，B服务主机IOWAIT高，具体超时情况分为两种： A服务的请求在B服务日志中可查到，但B服务的响应时间超过了A服务的等待超时时间3S。 A服务的请求在B服务日志中无法查到。 3. 问题分析 此种超时请求集中在很短的一段时间（通常在2分钟之内），过后便恢复正常，所以很难抓到问题现场分析原因，只能搭建测试环境，A服务持续请求B服务，在B服务主机上通过DD命令写入大量数据造成主机IOWAIT高，同时通过TCPDUMP在两端抓包分析。 部分服务超时日志： 服务A：Get http://xxx&id=593930: net/http: request canceled (Client.Timeout exceeded while awaiting headers) 服务B: "GET xxx&id=593930 HTTP/1.1" 200 64 "-" "Go-http-client/1.1" "-" "-" 165000（单位微秒） 服务A发起请求3S后没有收到服务B响应，断开连接，服务B日志显示处理时长为0.165S，远低于3S，服务A侧看服务B的响应时间为网络传输时间

简介 在平时的工作中，docker接触很多，除了经常使用的docker run ，docker stop等命令，docker还有很多十分有用但是却不经常使用的命令，下面我就总结一下。 整理了一份Java面试宝典完整版PDF 操作 1、docker top 这个命令是用来查看一个容器里面的进程信息的，比如你想查看一个nginx容器里面有几个nginx进程的时候，就可以这么做 ➜ ~ docker top 3b307a09d20d UID PID PPID C STIME TTY TIME CMD root 805 787 0 Jul13 ? 00:00:00 nginx: master process nginx -g daemon off; systemd+ 941 805 0 Jul13 ? 00:03:18 nginx: worker process 2、docker load && docker save 我一般使用这两个命令去下载打包k8s的镜像，因为你知道的中国的网速并不像国外那么快 docker save可以把一个镜像保存到tar文件中，你可以这么做 docker save registry:2.7.1 >registry-2.7.1.tar 同时docker load可以把镜像从tar文件导入到docker中 docker load < registry-2.7.1

百度云智能运维产品（Noah）的监控系统（Argus）是保障百度内外服务高可用的基石。它具有诸如机器监控、实例监控、HTTP监控、域名监控、日志监控、自定义监控等多种监控手段，具备“海陆空”全方位的监控能力，让服务异常无处遁形。 如果你看过本公众号之前的系列文章，相信你会觉得我所言非虚。 然而如此强大的监控系统所产生的“辣么多”报警，如果不能及时精准地送达给运维人员，那么一切都还只是个传说。今天我们就聊聊报警如何送达的问题。 注意，我们今天不谈报警，我们只谈报警的搬运工—— 百度云Noah通告平台。 一个都不能少 报警不同于普通的通知，它反映的是线上服务即将或正在遭受损失。如果我们把核心报警搞丢了，造成线上故障得不到及时解决，这个责任是巨大的。由于报警系统天然就这样要求高可靠性，因此我们奉行“at-least-once”的投递原则，确保报警至少有一次能成功抵达用户，做到“该报的报警一个都不能少”。 为了实现这个目标我们经历过不少坑。 机房网络连通性问题 我们发送报警要依赖四个底层发送网关（电话网关、短信网关、IM网关、邮件网关）来向用户发送消息，如下图所示。由于公司网络环境的原因，这些网关部署在某些特定机房，和上游的监控系统部署在不同机房中，这样机房间的网络拥塞或抖动将直接影响报警发送。 解决这种问题 ，可以将底层发送网关主备部署到不同的机房，由上游系统重试解决

在接口测试过程中，用例设计是关键中的关键，需要重点关注的一些维度 接口测试 什么是接口 接口就是内部模块对模块，外部系统对其他服务提供的一种可调用或者连接的能力的标准，所谓的接口是模块与模块之间的一种连接 接口测试 上图为一个典型的接口，一个接口通常是有输入输出的，输入就是我们常见的入参，输出有时有，有时没有。调用相关接口，接口会执行相关处理逻辑 接口测试的用例设计，主要从输入和接口处理两方面考虑： 针对输入，可按照参数类型进行设计 针对接口处理，可按照逻辑进行用例设计 针对输出，可根据结果进行分析设计 典型问题 接口测试经常遇到的bug和问题，如下： 传入参数处理不当，导致程序crash 类型溢出，导致数据读出和写入不一致 因对象权限未进行校验，可以访问其他用户敏感信息 状态处理不当，导致逻辑出现错乱 逻辑校验不完善，可利用漏洞获取非正当利益等 用例设计 前面说明什么是接口以及什么是接口测试，接下来详细看看如何才能更好的进行接口用例设计 一、参数校验 对于接口来说，输入就是入参。常见参数类型有： 数值型(int、long、float、double等） 字符串类型 数组或链表 结构体 1.1 数值型 数值型参数主要考虑的设计思路 1.1.1 等价类 取值范围内 取值范围外 1.1.2 边界值 取值范围边界（边界最小、最大、边界最小-1、边界最大+1等） 数据类型边界

以下源码基于 PHP 7.3.8 array array_unique ( array array[,intarray[,intsort_flags = SORT_STRING ] ) (PHP 4 >= 4.0.1, PHP 5, PHP 7) array_unique — 移除数组中重复的值 参数说明： array：输入的数组。 sort_flag：（可选）排序类型标记，用于修改排序行为，主要有以下值： SORT_REGULAR - 按照通常方法比较（不修改类型） SORT_NUMERIC - 按照数字形式比较 SORT_STRING - 按照字符串形式比较 SORT_LOCALE_STRING - 根据当前的本地化设置，按照字符串比较。 array_unique 函数的源代码在 /ext/standard/array.c 文件中。由于 PHP_FUNCTION(array_unique){ // code... } 篇幅过长，完整代码不在这里贴出来了，可以参见 GitHub 贴出的源代码。 定义变量 zval *array; uint32_t idx; Bucket *p; struct bucketindex *arTmp, *cmpdata, *lastkept; unsigned int i; zend_long sort_type = PHP_SORT_STRING;

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

1、安装编译 Nginx 所需的依赖包 # yum install gcc gcc-c++ make automake autoconf libtool pcre pcre-devel zlib zlib-devel openssl openssl-devel 2、上传 Nginx #gzip on; server { listen 88; server_name localhost; #charset koi8-r; #access_log logs/host.access.log main; location / { root html; index index.html index.htm; } #error_page 404 /404.html; # redirect server error pages to the static page /50x.html error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } } } 修改 Nginx 欢迎首页内容（用于后面测试，用于区分两个节点的 Nginx）： # vi /usr/local/nginx/html/index.html 192.168.1.51 中的标题加 1 <h1>Welcome to nginx! 1</h1>

一、负载均衡高可用 Nginx作为负载均衡器，所有请求都到了Nginx，可见Nginx处于非常重点的位置，如果Nginx服务器宕机后端web服务将无法提供服务，影响严重。 为了避免负载均衡服务器的宕机故障，需要建立一个备份机。主备机上都运行高可用（High Availability）监控程序，通过传送心跳信息来监控对方的运行状况。当备份机不能在一定的时间内收到对方的正常心跳时，它就接管主服务器的服务IP并继续提供负载均衡服务；当备份管理器又从主管理器收到“I am alive”这样的信息时，它就释放服务IP地址，这样的主服务器就开始再次提供负载均衡服务。 二、使用keepalived+Nginx实现负载均衡高可用 1、提供两个Nginx负载服务器 这里方便演示，分别在本机上添加2个虚拟服务器，分别安装Nginx 2、分别在两台服务器上安装keepalived Keepalived的安装方式不外乎检查配置、编译、安装那几个命令，这里就不再赘述，为方便管理，将相关配置文件进行移动，重启keepalived服务 3、配置keepalived 安装好keepalived后 ，进入/usr/local/keepalived/etc/keepalived，修改keepalived.conf文件 1）主机 2）备机 通过对两台服务器的keepalive进行配置，区分出主机和备机服务器，state

　　自己最近用node.js + react 做了个网站。在PC端上的访问是这样的： 　　 　　手机访问居然是这样的: 　　 　　　　这样用户体验很不好。 所以做了一个移动端的版本。 　　　　需求: 需要判断用户是否手机还是电脑 访问网站，从而进入不同的版本。 　　　　解决方案： 　　　　　　1. 解析 xxx.com 域名到pc版。 　　　　　　2. 解析m.xxx.com 域名到 移动版。 　　　　　　3.通过nginx 判断用户 是移动端访问还是PC端 从而进入不同的域名 实现： server { listen 80; server_name xxx.com; location / { proxy_pass http://localhost:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; if ($http_user_agent ~* "(mobile|nokia|iphone|ipad|android|samsung|htc|blackberry)") { //判断是否为移动设备访问 rewrite ^/(.*)$ http://m.xxx.com