当前位置: 首页 > 后端技术 > Node.js

ChetuCubs的自我修养——【HTTP】常见B-S架构简单梳理

时间:2023-04-03 16:21:58 Node.js

前言客户端与服务器通信会经历以下几个阶段:客户端输入URLDNS服务器解析URL阶段Web服务器解析Http请求阶段应用服务器逻辑处理阶段数据库运行阶段Web服务器模板渲染阶段Web服务器返回Html给客户端解析URL阶段当一个客户在浏览器中输入某个URL,首先会经过域名解析阶段,即将目标URL解析到DNS服务器并返回目标URL对应的IP地址,然后根据请求请求对应的服务器目标IP地址。例如,在浏览器中输入www.xx.yy.com后,浏览器会在本地缓存中查找www.xx.yy.com对应的IP。如果没有找到www.xx.yy.com对应的IP,则向DNS服务器请求www.xx.yy.com对应的IP。如果DNS服务器解析不到,则向上级DNS服务器请求www.xx.yy.com对应的IP。如果DNS服务器无法解析,则向上级DNS服务器请求www.xx.yy.com对应的IP,直到发送给客户端返回对应的IP(192.0.0.1)用户发送Http请求到www.xx.yy.com(192.0.0.1)对应的IP地址。客户端获取到对应的IP后,就可以正式与web服务器进行交互了模型1客户端-(web+应用)服务器-数据库客户端向服务器发起Http请求。服务器中的Web服务层可以处理Http请求。服务器中的应用层可以调用业务逻辑。如果需要,服务器将与数据库交换数据。然后将模板+数据渲染成最终的Html,返回给客户端。Model2Client-webserver-applicationserver-database和model1类似,只是webservice和applicationservice从客户端到web解耦了。服务器发起Http请求。Web服务可以处理Http请求,并调用应用服务器暴露的RESTFUL接口。调用应用服务器的RESTFUL接口,会执行相应的暴露方法。如果需要与数据库进行交互,应用服务器将与数据库进行通信。交互完成后将json数据返回给web服务器。Web服务器将模板+数据组合渲染成html返回给客户端。Model3客户端-负载均衡器(Nginx)-中间服务器(Node)-应用服务器-数据库对外暴露的不是真正的web服务器地址,而是负载均衡器的地址。客户端向负载均衡器发起Http请求。负载均衡器可以将客户端的Http请求平均转发给Node服务器集群。Node服务器收到Http请求后,可以响应解析并调用使用应用程序服务器公开的RESTFUL接口。当调用应用服务器的RESTFUL接口时,会执行相应的暴露方法。如果需要与数据库进行交互,应用服务器会与数据库进行交互,将json数据返回给NodeNode层。+数据组合渲染成html返回给反向代理服务器。反向代理服务器返回相应的html给客户端。注意,首先要弄清楚Nginx的概念。Nginx的优点是:作为反向代理,可以起到负载均衡的作用。负载均衡就是可以承受大量的高并发请求,然后将这些请求平均转发给内部服务器来分担压力。而反向代理可以解决跨域带来的问题,因为Nginx、Node、应用服务器、数据库都在内网段。而且Nginx非常擅长处理静态资源(img、css、js、video),所以经常被用作静态资源服务器,也叫CDN。具体来说,前一个用户访问index.html,是通过Nginx-Node-应用服务器-数据库链接后,Nginx将index.html返回给用户,并将index.html缓存在Nginx上。当下一个用户要请求index.html时,他会请求Nginx服务器。所以不需要请求Node层,直接将缓存的页面(如果还没有过期)返回给用户。模型4客户端-(静态资源服务器CDN、负载均衡服务器Nginx)-中间服务器(Node)-应用服务器-数据库客户端的静态请求(图片、css、js等)都经过CDN的动态请求客户端(html页面的数据需要从数据库中获取,需要进行逻辑处理)和负载均衡器Nginx(反向代理)比如对于页面www.xx.yy.com/index.html,客户在浏览器中输入www.xx.yy.com/index.html,浏览器会搜索本地的DNS缓存,尝试找到该URLHostname对应的IP,如果在本地没有找到,浏览器会发送请求到最底层的DNS服务器,期望得到URL对应的IP。最低级别的DNS服务器解析域名。如果无法解析,则会向上级DNS服务器发送请求,期望得到该URL对应的IP,递归查找,直到找到该URL对应的域名,然后返回给客户端层等级。客户端拿到对应的IP,开始向这个地址发送Http请求。其实这个IP就是nginx服务器IPNginx服务器收到客户端的Http请求后,根据调度算法转发给合适空闲的Node服务器,调用RESTFUL接口,执行相应的暴露方法。如果需要和数据库交互,应用服务器会和数据库交互,返回json数据给NodeNode层,将模板+数据组合渲染成html,返回给反向代理服务器,Nginx服务器返回相应的html给客户端。客户端获取到的index.html如下......21

...客户端开始解析index.html,发现有img标签,只好向cdn.xx.xx请求1.png。域名cdn.xx.xx的IP,所以找本地DNS缓存。如果没有缓存,则向最底层的DNS服务器发起域名解析,期望得到cdn.xx.xx对应的IPDNS服务器。收到请求后,找到用户的Http-header,这里的请求是cdn.xx.xx,请求的是一个CDN服务器(其实是分布式集群)的IP地址。然后DNS会为这个域名对应的CDN服务器集群动态计算出哪个服务器离用户更近更快更合适DNS服务器计算出最合适的CDN服务器IP后返回给客户端。客户端向该IP请求静态资源。注:为什么CDN服务可以大大提高用户请求静态资源的效率?因为你请求的CDN服务器的URL对应的IP是DNS服务器计算出来的最优解。它会根据用户的IP地址进行计算,找到离用户最近/网络情况最好的CDN服务器对应的IP地址,返回给客户端。两个集群。比如一个集群在广州,一个集群在北京。那么当用户访问公司的URL时,首先会向DNS服务器请求URLHostname对应的IP地址。DNS服务器将使用用户的IP,判断是返回广州服务器IP还是北京服务器IP。如果用户当前IP段在天津,DNS会返回北京服务器的IP地址给客户端。如果用户当前IP段在深圳,DNS服务器会返回深圳服务器的IP给用户。这样大大提高了服务器的响应速度(试想如果你在北京,你家的对面就是公司北京服务器的机房。但是你发现你的请求最后被拒绝了,发到广州机房)而且不仅要提高服务器的响应效率,还需要部署多个机房进行容灾等(以防广州机房着火断电,可以配置DNS服务器,无论用户在哪个IP段,都会返回北京机房的IP地址,这样整个南区的请求只会变慢,不会完全瘫痪)结论懒得更新了。最后一张稍微复杂点的架构图醒醒