在早期阶段.很多互联网服务的后台架构非常简单.如图所示.
从上图可以看出.业务后台HTTP服务器直接绑定公网IP地址与客户端建立连接.DNS服务器对其域名的解析结果就是HTTP服务器的一个公网IP地址.这种架构非常轻量 清晰.但是存在如下问题.并不适合作为互联网公司后台架构.
1.可用性低:
如果某个业务服务实例宕机.那么DNS服务器将无法高效的感知到其IP地址已不可用.导致被DNS解析到的此IP地址的用户请求均不可用.
2.可扩展性差:
当业务服务需要扩容时.总需要配置额外的DNS.而且受限于DNS解析的生效周期.扩容后的服务新地址难以实时生效.
3.安全风险高:
业务系统的IP地址都是公网的IP地址.这相当于后台的所有网络地址都暴露在公网环境中.存在网络安全隐患.
在软件领域有一句经典的话"计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决".我们也可以在客户端和业务服务的连接之间引入一个中间层:一方面,它需要负责提高业务服务的可用性和可扩展性.这要求中间层有丰富的功能.另一方面.它还要充当客户端访问业务的总代理.将用户流量按规则转发到某个业务服务的实例上.这又要求中间层有非常高的性能.
Nginx:
Nginx是一种自由的 开源的 高性能的HTTP服务器和反向代理服务器.同时也是IMAP POPS SMTP的代理服务器.Nginx既可以作为HTTP服务器进行网站的发布处理.也可以作为反向代理实现负载均衡可能.
代理的含义非常简单.比如我们需要做某件事但是又不想亲自去做.这时可以找另一个人帮忙去做.这个人就是我们做某件事的代理.再比如租房中介公司就是我们租房的代理.在网络接入层.代理分为正向代理和反向代理.
在日常工作中.正向代理很常见.比如很多公司为了自身网络安全.不允许居家的员工使用互联网直接访问公司的办公网络环境.而是必须手动配置公司的VPN(虚拟专用网络)后才能接入访问.这里VPN充当的就是正向代理的角色.即代理客户端去访问网络.
反向代理的运行方式是代理服务器对外接收互联网上的客户端请求.然后将请求转发到内部网络的目标服务器.并将目标服务器的执行结果返回给客户端.反向代理对外表现的就像目标服务器一样.客户端并不会知道自己访问的其实就是一个代理.
总结起来.正向代理与反向代理的核心区别就是:正向代理代理的是客户端.反向代理的是服务器.
Nginx能很好地充当反向代理.是因为它有强大的基于域名和HTTP URL的路由转发功能.只需要配置文件nginx.conf做一些简单配置就能轻易的搭建出一台反向代理服务器.
假设Friendy应用内置了内容推荐 点赞和评论功能.这三个功能在服务器对应于三个HTTP业务服务.每个服务都有两个实例.如图所示.
Friend应用的内容推荐 点赞 评论功能与后台副武器的HTTP通信接口URL分别为/feed /like /comment/且均以api.friendy.com作为域名.
因为Nginx服务器作为三个后台服务的反向代理.提供公网IP地址122.14.229.192.对域名api.friendy.com进行DNS解析会得到这个IP地址.所以Friendy客户端在进行内容推荐 点赞 评论操作时.用户请求将通过网络传递到这台Nginx服务器.
server配置块中的配置代表Nginx实际启动的HTTP服务器所需的各种参数.
listen:
HTTP服务器监听的端口号.
server_name:
用于设置虚拟主机服务名称.用户请求的HTTP请求头会根据Host字段与server_name进行匹配.如果匹配成功.则用户请求被对应的server配置块处理.这里的匹配支持正则表达式.
location:
这是Nginx作为反向代理最重要的配置项之一.每个location都用于指定一个HTTP URL相对路径的处理规则.
location配置块中的proxy_pass是反向代理的另一个重要配置项.它决定了某个HTTP URL需要被谁代理.代理者可以是一个明确的网络地址.也可以是一个服务池名称.对于这里的配置而言.分别代理到了服务池.
upstream配置块表示一个服务池.其中的server配置项表示这个服务池中有哪些服务实例.以及这些服务器的实例地址.当用户请求被代理到某个服务池后.Nginx会默认以轮询的方式从服务池中选择一个服务器实例作为目标服务器转发请求.
综上所述.Nginx服务器先以80为端口启动对外服务.当收到请求头Host为api.friendy.com的HTTP 请求后.根据请求的HTTP URL相对路径作进一步处理.
如果相对路径是/feed.则在api_friendy_feed服务池中选择一个服务实例作为目标服务器转发请求.
如果相对路径是/like.则在api_friendy_like服务池中选择一个服务实例作为目标服务器转发请求.
如果相对路径是/comment.则在api_friendy_comment服务池中选择一个服务实例作为目标服务器转发请求.
至于Nginx会在服务池中选择哪个服务器实例作为目标服务器.就是Nginx负载均衡的职责了.常见策略如下.
轮询:
将每个请求按时间顺序逐一分配到不同的后端服务器.如果某台后端服务器死机.则自动剔除故障系统.使用户访问不受影响.这是默认的策略.
加权轮询:
为服务示例配置引入访问权重(weight).权重值越大的服务器实例越容易被访问.
ip_hash:
为每个用户请求按照IP地址的哈希结果分配服务器实例.使得来自同一个IP地址的请求一直访问同一个服务器实例.Nginx使用ip_hash配置项指定此策略.需要说明的是.此策略不保证服务器实例的负载均衡.可能存在个别实例的访问量很大或很小的情况.
least_conn:
此策略将请求转发给连接数最少的服务器实例.轮询 加权轮询的策略会按照一定的比例分发到各服务器.但是有些请求的响应时间长.如果把这些响应时间长的请求大比例的发送到某台服务器.随着时间的推移.这台服务器的负载会比较大.这种情况下.适合采用这个策略.
url_hash:
来自第三方模块的nginx-upstream-hash.此策略与ip_hahs类似.不同之处是它需要对请求的URL做哈希运算.这种策略可以有效的提高同一个用户请求的缓存命中率.
fair:
来自第三方模块nginx-upstream-fair.此策略根据每个服务器实例的请求响应时间 请求失败数 当前总请求量.综合选择一台最为空闲的服务器.
Nginx的负载均衡决定了一个HTTP请求最终被路由到哪个服务器实例.而HTTP位于OSI七层模型的第七层(应用层).所以Nginx作为反向代理也被称为"七层负载均衡器".
综上所述.机房接入架构图如下.
需要注意的是.Nginx服务器需要将买个业务的网络地址设置在配置文件中.才能实现与业务服务的通信.但是业务的频繁迭代与扩容.意味着nginx的upstream服务池中的服务实例地址会频繁变更.好在Nginx有足够多的模块可以解决.
ngx_lua:
这个模块将Lua语言嵌入Nginx.从而允许开发人员编写Lua脚本并部署到Nginx执行.
ngx_http_dyups_module:
这个模块使得Nginx不用重新启动就能热更新upstream配置并生效.
1.每隔一段时间(如3s).就从服务注册中心获取一次nginx.conf配置文件中所有upstream配置的服务列表.
2.获取服务地址列表成功.生成最新的upstream配置.通过ngx_http_dyups_module模块将其更新到Nginx工作进程中.
Nginx优势:
1.DNS服务器指向Nginx服务器.业务服务器网络地址切换无须配置DNS.
2.在用户请求和业务服务器之间实现了负载均衡.更便于控制业务服务流量调度.
3.对外只暴露一个公网IP地址.节约了有限的IP资源.Nginx服务器与业务服务器之间通过内网通信.
4.对业务服务器起到了保护作用.外网看不到业务服务器.只能看到不涉及业务逻辑的Nginx反向代理服务器.
5.增强了系统的可扩展性.业务服务器扩容能做到准实时生效.
6.提高了业务服务器的可用性.任何一个业务服务实例挂掉.Nginx服务器都可以将用户请求迁移到其他服务实例.
语雀地址www.yuque.com/itbosunmian...?
《Go.》 密码：xbkk 欢迎大家访问.提意见.