架构师训练营第五周总结

本周主要探讨了三种技术/架构的应用，分别是：缓存、消息队列、负载均衡。

缓存：

主要讨论了广义的缓存，而不仅仅是程序员眼中熟悉的 Application 缓存。而且越靠近用户的缓存，从节约计算资源和带宽的角度来看，越有意义。比如最靠近用户的 CDN，如果很有多图片或者视频，使用 CDN 缓存可以节省大量带宽和应用的压力。

再者是反向代理缓存，如果用户访问的资源有缓存，可以直接返回给用户而不用转发请求给应用服务器。

同时 CDN 和反向代理缓存属于通路缓存，如果缓存没有命中的话，由他们转发请求给应用服务器，而不需要程序员做额外处理。

程序员最熟悉的 Redis 或者 Memcache 等分布式缓存，属于应用缓存，需要程序员设置缓存策略，生存时间等。另外，他们属于旁路缓存，如果缓存没有命中，也需要程序员写代码去数据库取数据同时更新缓存。

消息队列：

讨论了消息队列与异步应用，并解释了使用消息队列带来的好处。

异步调用，使得可以直接返回响应给用户，提升了响应速度，从而提高了用户满意度（因为整个流程没有完成，需要考虑调用失败后如何处理，以及该返回什么样的响应内容给用户）

削峰填谷：可以通过控制消费者的数量来控制处理消息的峰值，从而避免高峰期过多的请求压垮服务器，而当高峰期过后，可以继续维持处理消息的峰值来处理队列中积攒的消息。

解耦：通过发布订阅模式，使得业务逻辑松耦合，从而更符合单一职责原则，也便于修改。

负载均衡：

讨论了实现负载均衡的方式以及各个方式的优缺点。

HTTP 重定向：“史前”时代的做法，相当于一个简单的应用，接收请求并做 http 重定向转发，一是这个转发应用的并发同样有限，二是重定向需要转发后的应用服务器可以被用户之间访问，所以应用服务器需要公网 IP，同时 IP 用户可见，非常容易被攻击。

DNS 负载均衡：大型互联网一般都会使用到，适用于有多个机房的服务。用户返回域名时，可以通过策略（如距离最近，负载最低等）返回某个机房的 IP。（一般是机房内的负载均衡服务器）

反向代理（Nginx）：优点是简单，搭建非常快速。缺点也很明显，就是反向代理的服务器有并发上的上限，因为还是转发较重的 HTTP 请求，一般只可以代理十几台服务器，超过这个数量后，反向代理服务器本身很可能被压垮。

IP 负载均衡：在 TCP/IP 层进行转发，通过修改 tcp 包的目标 ip 地址和源 ip 地址，将发往负载均衡服务器的包发往具体的应用服务器，性能非常好，唯一的不足是返回用户的数据包同样需要经过负载均衡服务器，造成网络出口的压力。

数据链路层负载均衡：在 IP 负载均衡的基础上进一步改进，通过直接修改目标地址为具体应用服务器的 mac 地址来进行转发，这样，返回的响应数据可以由应用服务器直接返回，而不需要通过负载均衡服务器，降低了网络出口的压力。