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