每天净瞎搞

关注:CS/AI/数学/自我提升等

0%

《沈剑架构师训练营》第2章 - 接入层架构

6、接入层:反向代理,负载均衡,我有话要说

  • no6:代理和反向代理是什么?
  • no6:一般用什么做反向代理?
    • 软件层面:nginx/apache
    • 操作系统层面:LVS
    • 硬件:F5
  • no6:反向代理能解决什么问题?带来了什么新的问题?
    • 解决的问题
      • 1.子 web 系统的性能,不再受到单台机器资源限制,可以扩展
      • 2.子 web 系统,实现了高可用(伪集群 -> 真集群)
    • 新问题
      • 1.多个 web 节点,带来负载均衡问题
      • 2.反向代理层需要解决 高可用
  • no6:反向代理如何实施负载均衡?
    • 负载均衡方法:随机、轮询、静态权重轮询、动态权重轮询,一致性哈希
    • 负载均衡抓手:四层(转发/交换),七层(转发/交换)
  • no6:反向代理如何实现高可用呢?
    • 使用两个节点使用相同的虚 IP,同时使用 keepalived 来检测 nginx 的可用性,由 nginx 把请求转发给后端实际处理的 web-server
    • 缺点:两个 nginx 实际上只有一台在对外提供服务

7、DNS轮询,以及接入层架构演进

  • no7:接入层的单体架构
  • no7:接入层的单体架构->DNS 轮询
  • no7:DNS轮询的缺点是?
    • 1.系统仍然是非高可用的,只是局部高可用
    • 2.扩容不是实时的
    • 3.暴露了太多的外网 IP
  • no7:接入层的DNS 轮询->反向代理
  • no7:接入层的反向代理->高可用反向代理
  • no7:接入层的高可用反向代理->多层高可用反向代理
    • 反向代理层可使用 lvs 和 f5
  • no7:接入层的多层高可用反向代理 -> 多层高可用反向代理+DNS 轮询

8、接入层:session一致性,要如何保证?

  • no8:什么是 session?
    • 服务器会为每个用户创建一个会话,存储用户的相关信息,以便多次请求,能够定位到同一个上下文
    • web 开发中,web-server 可以自动地为同一个浏览器的访问用户自动创建 session,提供数据存储功能
    • 最常见的,会把用户登录信息,用户信息存储到 session 中,以保持登录状态
  • no8:什么是 session 一致性问题?
    • 只要用户不重启浏览器,用户的每一次 http 短连接都能定位到session,定位到同一台 web-server 以保持会话
  • no8:解决一致性问题的方案?
    • all in one 架构
    • 反向代理架构
      • session 同步法
      • 客户端存储法
      • 反向代理 hash 一致性
      • 后端统一存储法
  • no8:反向代理架构,保证高可用的同时,保证 session 路由的一致性的session 同步法,即站点集群 session 同步
    • 优点
      • 由 web-server 支持,应用程序不需要修改任何代码
    • 缺点
      • session 的同步需要占用带宽,且数据量受到内存限制,无法进行水平扩展,仅有少量服务器没问题,多台 web-server 性能急剧下降
  • no8:反向代理架构,保证高可用的同时,保证 session 路由的一致性的客户端存储法,把 session 存储在客户端,把 session 存储在浏览器的 cookie
    • 优点
      • web-server 不需要存储 sesssion
    • 缺点
      • 每次 http 请求都需要携带 session,占用外网带宽
      • 存在泄露、篡改、窃取等的安全隐患
      • 存储量的大小受到浏览器端上的限制
  • no8:反向代理架构,保证高可用的同时,保证 session 路由的一致性的反向代理 hash 一致性(四层,七层),使用反向代理路由来保障
    • 使用 ip_hash 或 session_id hash 等
    • 优点
      • 仅需要修改 nginx 的配置,不需要修改应用层的代码,负载是均衡的
      • 能很好支持 web-server 水平扩展
    • 缺点
      • 一旦 web-server 重启,会丢失一部分 session
      • 如果 web-server 水平扩展,nginx 会进行重新 hash,session 重新分布,会导致一部分用户路由不到正确的 session
      • 以上两点等同于 session 失效,也是可以接受的
    • 建议
      • 推荐使用四层的 hash,让专业的软件做专业的事情,反向代理负责路由转发,尽量不要引入业务层的业务属性,http 请求中的属性最好不要让 nginx 关注
  • no8:反向代理架构,保证高可用的同时,保证 session 路由的一致性的后端统一存储法,不存储在站点,统一存储在后端(数据库,缓存)
    • 优点
      • 没有安全隐患,session 不用在外网上传输了
      • 可实现 web-server 层的任意水平扩展
      • 当数据量增大时,数据库或缓存进行水平切分即可
      • web-server 扩容或重启时,都不会有 session 的丢失
    • 缺点
      • 增加了一次网络调用
      • 需要修改应用层的代码

9、接入层:如何实现就近访问,CDN架构趣谈

  • no9:什么是 CDN(Content Delivery Network)
    • 即内容分发网络,它主要依靠部署在各地的服务器,通过内容分发,访问调度等技术,使用户就近获取所需的内容,降低网络阻塞,提高用户的访问速度
    • 适合静态资源的加速访问(js,css,jpg 等)
    • 核心是「就近访问」
  • no9:什么是「智能 DNS」?
    • 根据用户的访问 IP 来决定返回的域名 IP
  • no9:CDN 的架构组成有哪三部分?
    • 源:数据库
    • 镜像:多个「穿透缓存」
    • 智能 DNS:决定我们访问哪一个
  • no9:源里的abc.js更新了,镜像里的abc.js没更新,数据不一致,怎么办?
    • 方案一:源更新的时候,过期掉镜像里的abc.js (缓存淘汰)
      • 需要在源里维护一个镜像 list 的配置,每次源有静态文件更新的时候需要依次淘汰相关的镜像资源,是一个「反向依赖」的耦合设计,即源依赖了镜像,好的方案应该是源不需要知道镜像的配置
    • 方案二:等待镜像里的abc.js过期(缓存过期)
    • 方案三:版本号,升级为 abc_v1.2.3.js,就能解决(推荐)
  • no9:当资源更新,是采用源推送还是镜像拉取的方式?
    • 方案一:资源更新的时候,源一次性推送所有镜像(反向耦合设计)
    • 方案二:发现资源缺失时,镜像主动去源拉取(推荐)

10、TCP负载均衡,该怎么玩?

  • no10:TCP负载均衡的单体架构
    • 优点:可以保证请求的一致性
    • 缺失:没办法扩展,没办法保证高可用
  • no10:TCP负载均衡的客户端负载均衡(内置集群配置)
    • 客户端内置服务器集群的配置,通过搭建 tcp 集群来保证高可用
    • 缺点,每次连接前要多一次 DNS 访问,难以预防 DNS 劫持,解决方法是直接把 IP 配置到客户端中,但这样的扩展性比较差
  • no10:TCP负载均衡的服务端负载均衡(静态 IP 列表)
    • 新增一个 http 接口,将客户端的 IP 配置与负载均衡策略放到服务端的 http 接口上,客户端每一次访问 tcp-server 之前,首先调用新增的一个 http 的获取 tcp-server ip 的接口,对于客户端而言,这个 http 接口只返回一个可用的tcp 服务器的 ip
    • 缺点:如果 tcp-server 挂了,web-server 是无法感知的
  • no10:TCP负载均衡的服务端负载均衡(服务状态上报)
    • 缺点:反向依赖耦合
  • no10:TCP负载均衡的服务端负载均衡(服务状态拉取)
    • tcp-server就独立与解耦了,只需要专注于自身 tcp-server 业务相关的功能即可,而高可用,负载均衡,扩展性,存活性,都由 web-server 这个子系统去实施