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 这个子系统去实施