《周志明的软件架构课》学习笔记 Day12

主动学习

理解透明多级分流系统的设计原则

整个链路请求：请求首先是从浏览器出发，在 DNS 的指引下找到系统的入口，然后经过了网关、负载均衡器、缓存、服务集群等一系列设施，最后接触到了系统末端存储于数据库服务器中的信息，然后再逐级返回到用户的浏览器之中。

第一个原则是尽可能减少单点部件，如果某些单点是无可避免的，则应尽最大限度减少到达单点部件的流量。
恰如其分地引导请求分流至最合适的组件中，避免绝大多数流量汇集到单点部件（如数据库），同时依然能够、或者在绝大多数时候能够保证处理结果的准确性，在单点系统出现故障时，仍能自动而迅速地实施补救措施，这便是系统架构中多级分流的意义。

第二个原则是奥卡姆剃刀原则，它更为关键。
如无必要，勿增实体

因为并不是每一个系统都要追求高并发、高可用的，从系统的用户量、峰值流量和团队本身的技术与运维能力出发，来考虑如何布置这些设施，才是最合理的做法。
在能满足需求的前提下，最简单的系统就是最好的系统。

DNS 域名解析查询系统

无论是使用浏览器，还是在程序代码中访问某个网址域名，如果没有缓存的话，都会先经过 DNS 服务器的解析翻译，找到域名对应的 IP 地址，才能开始通讯。
第一步，客户端先检查本地的 DNS 缓存，查看是否存在并且是存活着的该域名的地址记录。
第二步，客户端将地址发送给本机操作系统中配置的本地 DNS（Local DNS）。这个本地 DNS 服务器可以由用户手工设置，也可以在 DHCP 分配时或者在拨号时，从 PPP 服务器中自动获取。
第三步，本地 DNS 递归查找，直到查询到根域名服务器

缺点：响应速度会受影响。在极端情况（如各级服务器均无缓存）下，域名解析可能会导致每个域名都必须递归多次才能查询到结果，显著影响传输的响应速度。

所以，为了避免产生这种问题，专门就有一种前端优化手段，叫做DNS 预取（DNS Prefetching）：如果网站后续要使用来自于其他域的资源，那就在网页加载时便生成一个 link 请求，促使浏览器提前对该域名进行预解释，如下所示：

写在最后

1 dns解析，域名解析配置多个IP，利用DNS本身得解析做分流

2 dns加速，通过缓存一些静态资源，达到加速得效果

3 静态资源分离，图片，css，js等静态资源独立部署，像现在的前后端分离，我觉得也算是达到分流的效果

4 SLB,做负载均衡，分发给多个服务

5 redis，memcached缓存服务，对数据库压力进行分流

6 mongodb，es等文档存储，缓解数据库单点风险

7 中间件kafka,mq 起到削峰填谷，分流的作用（当然还有一个解耦作用）

8 数据库的主从，读写分离，从数据库的维度做分流