《大型网站技术架构》读后感

结束了毕业答辩和提交论文最终稿,又可以开心地去玩耍和学习了~~

这段时间又剁手买了很多书=-=



这本书说的并不是深入讲解某个技术,而是让大家了解到一个大型的网站,应该是如何设计和各种架构问题对应的解决方案,是一本很好的入门书了

下面记录的是学习这本书的架构设计知识点,对于大型网站有了基础了解。


服务分离

应用服务更多关注的是业务处理能力,需要更强大的CPU;数据库服务需要快速磁盘检索和数据缓存,因此需要更快的硬盘和更大的内存;文件服务器需要存储大量用户上传的文件,因此需要更大的硬盘。

应用和数据分离之后,不同特性的服务器承担不同的服务角色,可以很好的改善网站的并发能力和数据存储空间。


集群和负载均衡

前期功能不复杂的话,可能跟在学校做作业一样,使用单机就能解决。随着访问量和处理数据越来越多,单机的性能便会达到瓶颈,这是就需要增加机器,搭成集群,减少单机的压力,处理更多请求。

如图所示,当前端接收到请求后,根据负载均衡算法,路由到某个应用服务器上,将处理好的结果返回给前端,进行之后的业务操作。通过负载均衡技术将用户请求分发到不同的服务器上,以应对大量用户同时访问时产生的高并发负载压力。


负载均衡

HTTP重定向负载均衡

HTTP重定向服务器是一台普通的俄、应用服务器,其唯一的功能就是根据用户的HTTP请求计算一台真实的WEB服务器地址,并将该Web服务器地址写入HTTP重定向响应中返回给用户游览器。

DNS域名解析负载均衡

在DNS服务器配置多个A记录,例如:www.mysite.com IN A 127.0.0.1/ www.mysite.com IN A 127.0.0.2 / www.mysite.com IN A 127.0.0.3。

每次域名解析请求都会根据负载均衡算法计算一个不同的IP地址返回,这样A记录中配置的多个服务器就构成一个集群,并可以实现负载均衡。

该做法的优点是将负载均衡的工作交给了DNS,同时需要DNS还支持基于地理位置的域名解析,将域名解析成距离用户地理最近的一个服务器地址,加快用户访问速度,改善性能。但是同样也有缺点,目前的DNS是多级解析,每一级DNS都可能缓存A记录,当下线某台服务器之后(修改DNS的A记录),使其生效需要一段时间,在这段时间DNS仍然会解析到已下线的服务器,导致用户访问失败。

反向代理负载均衡

我们常用的Nginx就是通过反向代理,进行访问的负载均衡。反向代理服务器处于Web服务器前面,将请求根据分在均衡算法转发到不同Web服务器上。Web服务器处理完成的响应也需要通过反向代理服务器返回给用户。

如图所示,游览器发起请求,反向代理服务器根据负载均衡算法计算到真实无理服务器的地址,将请求转发给节点三。


分布式

大型网站一般都在使用分布式,进行性能平衡和伸缩扩展。无论是持久化数据、缓存还是应用程序,都可以通过增加机器,搭建集群,以增加计算处理能力和减缓原有的机器压力。

在业务中,将不同的功能进行模块化,经过分层和分割后,将软件分割成若干个低耦合的独立组件模块,然后这些模块进行单独部署,模块之间可以通过RPC或者消息进行交互。

阿里的DUBBO服务基本满足分布式应用的要求,而且可以做到服务升降级,当某些服务出问题或者占用太多计算机资源,可以选择将这些服务降级,降低访问量。例如淘宝双十一的时候会将评论等不重要的功能停用,确保订单服务的高可用。

在分布式中,消息服务也很重要,借助事件消息的通讯完成模块间的合作,常见的是生产者和消费者模式。例如ActiveMQ中,生成者可以发布两种类型的消息,队列消息和主题消息。队列消息生产一个,消费一个,一对一的关系,主题消息是生产一个,消费多个,一对多的关系。由于消息发送者不需要等待消息接收者处理数据就可以返回,系统具有更好的响应延迟。

伸缩性构架设计可以说简单,因为有很多开源的可以进行借鉴和使用;同时也是复杂的,因为没有一套通用的方案,需要根据自己的业务、物理机性能等众多因素结合在一起考虑,所以伸缩性架构设计要求架构师对于这个产品和技术路线要有个清晰的了解。


其它说说

除了功能业务之外,还需要关注日志服务、安全服务等基础服务的支持。

通过日志服务发现业务异常或者系统异常,当某些错误超过设定的阙值时,设定邮箱或者短信报警,让开发人员尽早了解,及早修复漏洞。

像在2011年,新浪微博遭XSS攻击,还有CSDN被脱库造成的用户密码等重要信息泄露,这些事件都在提醒,网站的安全需要重视,看了本书,了解到很多安全防范,例如参数清洗、布隆过滤器、Web防火墙等等。


这本书的内容确都是干货,讲了很多技术构架,一开始工作中没清晰的概念,通过本书都了解到了,而且配图很多,讲的内容也通俗易懂,墙裂安利~

自己还没到这些大牛的境界,这些知识点权当了解了解~