架构师训练营总结 -20200705

本周的课程中，我们对于大型互联网软件体系中的缓存、消息队列、负载均衡等机制进行了探讨。这三部分内容在我之前的工作过程中或多或少都有所涉及，但是只停留在会用的程序。

举例来说，对于缓存的概念，个人在几年之前曾经在互联网媒体公司工作过，那个时候 WEB2.0 的概念刚刚兴起，iPhone3 刚刚惊艳的世人。在那个时代大部分的同行网站仍然停留在 WEB1.0 的时代，主要的维护精力会集中在资讯和论坛两大部分——前者是内部员工（也就是编辑）们主要生产内容的地方，关系到广告投放、企业收入等和生存息息相关的问题；后者是广大最终用户（或者说网友）们主要生产内容的地方，可以提高用户留存率，增加用户粘性，从而为编辑们的文章阅读、广告投放等打好基础。对于这样一个标准的 WEB1.0 产品，在资讯部分会使用三层缓存来支撑并发访问，从离最终用户最近到最远，分别是：CDN 缓存、静态内容缓存（Squid）和 memcached 缓存。前两部分缓存由运维团队自行解决（例如采购蓝讯的 CDN 服务），对于开发人员而言，memcached 缓存则更为熟悉；我们当时通过 URL 和页码组成唯一的 KEY 值，将网页的 HTML 代码做为 VALUE，来提高访问速度。因此由于三层缓存的共同作用，实际上最终穿透缓存达到服务器中的访问压力并不很高，因此没有涉及到太多缓存增、减节点时出现缓存命中率下降倒置的严重问题。对于本次课程中提到的分布式缓存，特别是一致性哈希算法，之前的工作中更是没有涉及到，因此在老师讲解这部分内容的时候我会觉得相当吃力。特别是对于算法部分，我之前在工作中只是会使用 JAVA 自带的取哈希值的函数进行调用，没有关注过算法本身的实现思路，一致性哈希算法更是只听说过名字。估计在写本周的作业的时候会相当吃力，一直以来我们都被各种封装的很好的框架“惯坏了”，只需要关注业务逻辑即可，无需过多的关注内部原理和算法的实现。

对于负载均衡层面也类似，之前工作的经验中负载的问题大多是通过花钱购买 CDN 服务来解决，后续的工作也没有涉及过高的并发访问压力。因此我对于负载均衡的理解也只停留在通过 Nginx 同时实现反向代理和负载均衡的程度，虽然就工作而言支撑目前我们所开发的小型系统足以胜任，但是通过本周的课程我确实意识到如果访问量上升的话，我就会面临手中无牌可打的尴尬境地。老师介绍的通过 IP 地址设置修改 MAC 地址来进行负载均衡的方式我在之前甚至都没有意识到还有这种实现方法。而在答疑环节有同学提问中涉及到的 TCP 包和 HTTP 包之前的对应关系问题更是让我觉得欠缺的知识还很多，后续需要花费大量精力查询资料，弥补自己知识上的短板。

所以总归来看，本周的课程让我认识到了自己知识上的短板在哪里，也同时为我指明了后续需要补充哪些方面的知识，可以说获益匪浅。