Browsed by
标签:Nginx

由12306.CN谈谈网站性能技术

由12306.CN谈谈网站性能技术

閱讀本文約花費: 31 (分鐘) 12306.cn网站挂了,被全国人民骂了。我这两天也在思考这个事,我想以这个事来粗略地和大家讨论一下网站性能的问题。因为仓促,而且完全基于本人有限的经验和了解,所以,如果有什么问题还请大家一起讨论和指正。(这又是一篇长文,只讨论性能问题,不讨论那些UI,用户体验,或是是否把支付和购票下单环节分开的功能性的东西) 业务 任何技术都离不开业务需求,所以,要说明性能问题,首先还是想先说说业务问题。 其一,有人可能把这个东西和QQ或是网游相比。但我觉得这两者是不一样的,网游和QQ在线或是登录时访问的更多的是用户自己的数据,而订票系统访问的是中心的票量数据,这是不一样的。不要觉得网游或是QQ能行你就以为这是一样的。网游和QQ 的后端负载相对于电子商务的系统还是简单。其二,有人说春节期间订火车的这个事好像网站的秒杀活动。的确很相似,但是如果你的思考不在表面的话,你会发现这也有些不一样。火车票这个事,一方面会伴随着大量的查询操作,更BT的是下单的时候需要对数据库很多的一致性的操作,一方面是从起点到终点各个分段票的一致性,另一方面,买的人路线、车次、时间选择有很多,会不停地改变下单方式。而秒杀,直接杀就好了,没有那么多查询和一致性的问题。另外,关于秒杀,完全可以做成只接受前N个用户的请求(完全不操作后端的任何数据, 仅仅只是对用户的下单操作log),这种业务,只需…

Read More Read More

第五章 Gateway–服务网关

第五章 Gateway–服务网关

閱讀本文約花費: 15 (分鐘) 接上一篇文章开始网关之旅,首先告诉大家网关是什么,Gateway简介,怎么配置,怎么入门,执行流程等等相关介绍。 大家都都知道在微服务架构中,一个系统会被拆分为很多个微服务。那么作为客户端要如何去调用 这么多的微服务呢?如果没有网关的存在,我们只能在客户端记录每个微服务的地址,然后分别去 用。 这样的架构,会存在着诸多的问题: 客户端多次请求不同的微服务,增加客户端代码或配置编写的复杂性 认证复杂,每个服务都需要独立认证。 存在跨域请求,在一定场景下处理相对复杂。 上面的这些问题可以借助API网关来解决。 所谓的API网关,就是指系统的统一入口,它封装了应用程序的内部结构,为客户端提供统一服务,一些与业务本身功能无关的公共逻辑可以在这里实现,诸如认证、鉴权、监控、路由转发等等。 添加上API网关之后,系统的架构图变成了如下所示: 我们也可以观察下,我们现在的整体架构图: 在业界比较流行的网关,有下面这些: Ngnix+lua 使用nginx的反向代理和负载均衡可实现对api服务器的负载均衡及高可用 lua是一种脚本语言,可以来编写一些简单的逻辑, nginx支持lua脚本 Kong 基于Nginx+Lua开发,性能高,稳定,有多个可用的插件(限流、鉴权等等)可以开箱即用。问题: 只支持Http协议;二次开发,自由扩展困难;提供管理API,缺乏更易用…

Read More Read More

第三章 Nacos Discovery–服务治理

第三章 Nacos Discovery–服务治理

閱讀本文約花費: 12 (分鐘) 主要介绍了什么是服务治理,什么是nacos,以及nacos实战包括环境搭建,实现服务调用的负载均衡等相关。 先来思考一个问题 通过上一章的操作,我们已经可以实现微服务之间的调用。但是我们把服务提供者的网络地址(ip,端口)等硬编码到了代码中,这种做法存在许多问题: 一旦服务提供者地址变化,就需要手工修改代码 一旦是多个服务提供者,无法实现负载均衡功能 一旦服务变得越来越多,人工维护调用关系困难 那么应该怎么解决呢, 这时候就需要通过注册中心动态的实现服务治理。 什么是服务治理 服务治理是微服务架构中最核心最基本的模块。用于实现各个微服务的自动化注册与发现。 服务注册: 在服务治理框架中,都会构建一个注册中心,每个服务单元向注册中心登记自己提供服务的详细信息。并在注册中心形成一张服务的清单,服务注册中心需要以心跳的方式去监测清单中的服务是否可用,如果不可用,需要在服务清单中剔除不可用的服务。 **服务发现:**服务调用方向服务注册中心咨询服务,并获取所有服务的实例清单,实现对具体服务实例的访问。 通过上面的调用图会发现,除了微服务,还有一个组件是服务注册中心,它是微服务架构非常重要的一个组件,在微服务架构里主要起到了协调者的一个作用。注册中心一般包含如下几个功能: 1. 服务发现: **服务注册:**保存服务提供者和服务调用者的信息 **服务订阅:*…

Read More Read More

Kubernetes HPA 详解

Kubernetes HPA 详解

閱讀本文約花費: 32 (分鐘) Kubernetes HPA 详解 在前面的学习中我们使用用一个 kubectl scale 命令可以来实现 Pod 的扩缩容功能,但是这个毕竟是完全手动操作的,要应对线上的各种复杂情况,我们需要能够做到自动化去感知业务,来自动进行扩缩容。为此,Kubernetes 也为我们提供了这样的一个资源对象:HorizontalPodAutoscaling(Pod水平自动伸缩),简称 HPA,HPA 通过监控分析一些控制器控制的所有 Pod 的负载变化情况来确定是否需要调整 Pod 的副本数量,这是 HPA 最基本的原理: 我们可以简单的通过 kubectl autoscale 命令来创建一个 HPA 资源对象, HPAController默认 30s轮询一次(可通过 kube-controller-manager 的 –horizontal-pod-autoscaler-sync-period 参数进行设置),查询指定的资源中的 Pod 资源使用率,并且与创建时设定的值和指标做对比,从而实现自动伸缩的功能。 Metrics Server 在 HPA 的第一个版本中,我们需要 Heapster 提供 CPU 和内存指标,在 HPA v2 过后就需要安装 Metrcis Server 了, MetricsServer 可以通过标准的 Kubernetes …

Read More Read More

nginx使用手册+基本原理+优缺点

nginx使用手册+基本原理+优缺点

閱讀本文約花費: 4 (分鐘) 一、nginx优点 1.反向代理 1、正向代理: 客户端和原始服务器(origin server)之间的服务器,为了从原始服务器取得内容,客户端向代理发送一个请求并指定目标(原始服务器),然后代理向原始服务器转交请求并将获得的内容返回给客户端。 server不知道client是谁 2、反向代理:客户端请求服务器,中间也是经过一个代理服务器,客户端访问代理服务器就好像访问目标服务器一样。同时代理服务器将请求转发到后端具体服务器。 客户端不知道自己具体访问的服务器是谁 3、总结 https://blog.csdn.net/wnvalentin/article/details/88171847 正向代理是对客户端的代理,由客户端设立,客户端了解代理服务器和目标服务器,但目标服务器不了解真正的客户端是谁;使用正向代理可达到 突破访问限制、提高访问速度、对服务器隐藏客户端IP等目的; 反向代理是对服务器的代理,由服务器设立,客户端不了解真正的服务器是谁,使用反向代理可达到负载均衡、保障服务端安全、对客户端隐藏服务器IP等目的。 2.负载均衡 集群平摊请求压力 负载均衡策略: 轮询 :平均访问(默认方式) upstream myserver{ ip_hash; server 192.168.17.129:8000; server 192.168.17….

Read More Read More

CSRF的几种防御方法的利弊分析

CSRF的几种防御方法的利弊分析

閱讀本文約花費: 5 (分鐘) 本文直接从防御方式开始讨论,防御CSRF有4种方法: 使用POST替代GET检验HTTP Referer验证码Token 使用POST替代GET 一些程序员在开发的时候都是用GET、POST通用的函数来接收客户端的数据,这样也是某些接口有CSRF的原因之一,但是将全部接口都改成只允许POST方式访问,就能防范CSRF了吗?答案是:不能。只能说提高了一些成本。 原本是GET方式访问的接口,攻击者只需要构造接口的URL参数让受害者点击即可。现在改成使用POST方式访问,攻击者只需要利用其他站点,在站点上布置一个POST请求,让用户点击。 检验HTTP Referer HTTP Referer真是一个用于安全的字段,除了能防范CSRF,还能防JSONP劫持、盗链、站外提交等安全问题。但是HTTP Referer就一点问题都没有了吗?答案是:否定的,HTTP Referer只能检查点击的链接来源是来自站内还是站外,如果是GET方式的CSRF,那链接本身就是站内的,也就意味着检验HTTP Referer是无效的。 验证码 上面说的两种防御CSRF的方式,都有一定缺陷。但是使用验证码是完全可以做到防止CSRF的,因为验证码是用户在提交表单的时候,必须输入图片验证码,保证了服务器收到的是来自预期的请求。这里我补充一下,验证码功能必须没有缺陷才行,我之前测试过很多W…

Read More Read More

一文带你搞懂API网关

一文带你搞懂API网关

閱讀本文約花費: 19 (分鐘) 前言 假设你正在开发一个电商网站,那么这里会涉及到很多后端的微服务,比如会员、商品、推荐服务等等。 那么这里就会遇到一个问题,APP/Browser怎么去访问这些后端的服务? 如果业务比较简单的话,可以给每个业务都分配一个独立的域名(https://service.api.company.com),但这种方式会有几个问题: 每个业务都会需要鉴权、限流、权限校验等逻辑,如果每个业务都各自为战,自己造轮子实现一遍,会很蛋疼,完全可以抽出来,放到一个统一的地方去做。如果业务量比较简单的话,这种方式前期不会有什么问题,但随着业务越来越复杂,比如淘宝、亚马逊打开一个页面可能会涉及到数百个微服务协同工作,如果每一个微服务都分配一个域名的话,一方面客户端代码会很难维护,涉及到数百个域名,另一方面是连接数的瓶颈,想象一下你打开一个APP,通过抓包发现涉及到了数百个远程调用,这在移动端下会显得非常低效。每上线一个新的服务,都需要运维参与,申请域名、配置Nginx等,当上线、下线服务器时,同样也需要运维参与,另外采用域名这种方式,对于环境的隔离也不太友好,调用者需要自己根据域名自己进行判断。另外还有一个问题,后端每个微服务可能是由不同语言编写的、采用了不同的协议,比如HTTP、Dubbo、GRPC等,但是你不可能要求客户端去适配这么多种协议,这是一项非常有挑战的工作,…

Read More Read More

高性能短链设计

高性能短链设计

閱讀本文約花費: 17 (分鐘) 前言 今天,我们来谈谈如何设计一个高性能短链系统,短链系统设计看起来很简单,但每个点都能展开很多知识点,也是在面试中非常适合考察侯选人的一道设计题,本文将会结合我们生产上稳定运行两年之久的高性能短链系统给大家简单介绍下设计这套系统所涉及的一些思路,希望对大家能有一些帮助。 本文将会从以下几个方面来讲解,每个点包含的信息量都不少,相信大家看完肯定有收获 短链有啥好处,用长链不香吗短链跳转的基本原理短链生成的几种方法高性能短链的架构设计 注:里面涉及到不少布隆过滤器,snowflake 等技术,由于不是本文重点,所以建议大家看完后再自己去深入了解,不然展开讲篇幅会很长 短链有啥好处,用长链不香吗 来看下以下极客时间发我的营销短信,点击下方蓝色的链接(短链) 浏览器的地址栏上最终会显示一条如下的长链。 那么为啥要用短链表示,直接用长链不行吗,用短链的话有如下好外 1、链接变短,在对内容长度有限制的平台发文,可编辑的文字就变多了 最典型的就是微博,限定了只能发 140 个字,如果一串长链直接怼上去,其他可编辑的内容就所剩无几了,用短链的话,链接长度大大减少,自然可编辑的文字多了不少。 再比如一般短信发文有长度限度,如果用长链,一条短信很可能要拆分成两三条发,本来一条一毛的短信费变成了两三毛,何苦呢。另外用短链在内容排版上也更美观。 2、我们经常需要将链接转…

Read More Read More

Dockerfile部署Nginx、Apache、Tomcat

Dockerfile部署Nginx、Apache、Tomcat

閱讀本文約花費: 1 (分鐘) nginx #安装nginx并用CMD设置默认启动命令 #默认初始镜像为centos:7 FROM centos:7 RUN yum install -y epel-release && yum install -y nginx CMD [“nginx”,”-g”,”daemon off;”] apache #安装http并用CMD设置默认启动命令 #默认初始镜像为centos:7 FROM centos:7 RUN yum install -y httpd CMD [“httpd”,”-D”,”FOREGROUND”] tomcat #安装jdk tomcat并启动 #默认初始镜像为centos:7 FROM centos:7 ADD ./apache-tomcat-9.0.12.tar.gz /root ADD ./jdk-8u181-linux-x64.tar.gz /root ENV JAVA_HOME /root/jdk1.8.0_181 ENV PATH $JAVA_HOME/bin:$PATH RUN echo JAVA_OPTS=”-Djava.security.egd=file:/dev/./urandom” >> /root/apache-tomcat-9.0.12/bin/catalina.sh ENTRYPOI…

Read More Read More

Nginx代理80、代理443端口的说明

Nginx代理80、代理443端口的说明

閱讀本文約花費: 2 (分鐘) 端口协议80http443https 首先要安装nginx,这里采用yum安装方式 #yum -y install nginx安装完成后编辑其配置文件 #vim /etc/nginx/nginx.conf 配置代理80端口 server { listen 80; server_name www.prometheus.test.com; #自定义域名 root /usr/share/nginx/html; # Load configuration files for the default server block. include /etc/nginx/default.d/*.conf; location / { proxy_pass http://192.168.100.158:9090; #填写对应主机IP } } 配置代理443端口 因https方式需要涉及到证书,我这里使用openssl自创建证书 #openssl genrsa -out tls.key 2048 #openssl req -new -x509 -days 365 -key tls.key -out tls.crt -subj /C=CN/ST=Beijingshi/L=Beijing/O=devops/CN=cn server { listen 80; listen 443…

Read More Read More