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

来源:互联网 发布:业界良心音乐软件 编辑:程序博客网 时间:2024/06/04 19:24

**1. 最近新项目一边做项目一边拜读了一下《大型网站技术技术架构》,一直对架构很感兴趣,听说这本书是比较好的架构入门资料,在网上找电子档试读了一下,感觉非常不错所以就去买了下来打算认真研读一下,书不厚但是内容比较全面,主要介绍大型网站架构主要涉及的技术栈及几个案例,主题宏大却篇幅有限因此大都是浅尝辄止,在某瓣的评价也的确两级分化。部分的读者出于对于作者出身(作者李智慧阿里巴巴的技术总监)感兴趣去拜读,很多技术未能深层次讲解,比较失望。另一部分从最开始就明确这本书定位因此读起来收获颇多。
2. 开篇作者一直强调了架构是一种随着业务需求演化的过程,不是为了架构而架构,尤其是需求变化极快的互联网行业。传统的行业,例如银行,它的最开始会做好充分的需求分析,预估了多少的用户量,如何使用,从性能,扩展性,伸缩性,安全性,稳定性都可以有比较明确的需求模型。而小的互联网公司很难明确未来业务走向,最开始不可能去像银行投入巨大的成本,而是从一个小网站开始,迭代,变成一个大型架构。这是传统网站于互联网网站的主要区别。
3. 传统的行业构建一个软件系统,可能会采用瀑布模型的方式,首先是需求分析,然后是开发测试上线。记得我一个之前在银行工作过的同事一个项目周期光做需求分析文档就厚厚一叠,这样一个阶段完成才能完成下一个阶段,瀑布模型也是由此得名。这样的项目从底层可能就采用比较成熟稳定的方案,例如应用服务器采用IBM的大型机,存储网络采用EMC的机器。
4. 互联网网站主要是从小型网站演化而来,最开始应用服务器存与储服务器可能就只需要一台服务器即可,后面随着用户数量的增加,系统硬件资源有限必然导致系统的性能降低,而且普通的服务器还意味着系统的稳定性和不可靠性较难保证,接下来开始将应用服务器和存储服务器分开部署。
5. 应用和存储分开部署,用户访问数据在大部分业务场景下也是符合二八定律的,数据库的资源比较宝贵,缓存机制是优化系统性能的重要手段,将部分不容易改变且访问频繁的数据放在缓存里,这样用户获取这部分数据可以避免访问数据库,缓存也包括本地和远程缓存。
6. 当用户数量增加,分开部署的应用服务器和存储服务器也不堪重负,这个时候应用服务器可以复制出多台服务器组成集群,分摊用户的访问请求,如何让用户能够比较均衡的分配到应用服务器,这里在访问应用服务器之前采用一个负载均衡服务器,采用一定的算法策略,将请求均衡的分发到应用服务器。由于应用服务器是无状态的,共享数据session可以部署session服务器,还有就是添加session服务器如何让原来的请求继续访问到对应的session,这里需要采用一致性哈希算法来保证缓存的命中率,解决了session共享的问题,然后应用服务器几乎就是无状态的,工程师当用户数量增加系统应用服务器负载过高之后直接加应用服务器即可scale out(横向扩展)服务,达到比较好的伸缩性。
7. 缓存可以采用分布式的部署,如果某一台机器宕机(由于集群采用廉价的服务器,当集群规模比较大宕机可以想象成必然事件)而如何能够及时的将访问转移正确的机器上,如何去保证缓存添加新机器之后能够保证系统的正常运行保证新的数据能够尽快恢复,这里有的观点认为缓存也要保证强的一致性,有的则不以为然,这里笔者认为没必要花巨大的代价去保证。然而缓存是一个非常好的设计模式,从CPU的cache到内存到硬盘缓存到硬盘,缓存的应用十分广泛,这也是优化系统性能的重要手段,但是缓存的失效时间和应用范围是值得思考的。考虑的因素可能有数据的稳定性,文件大小,失效时间等等。很多前端的静态文件也可以采用cdn缓存的方式加速访问,让用户从离自己最近的ISP服务器上去获取,而不用到中央服务器获取。
8. 持久化存储从数据库的类型可以分为传统的关系数据库和NoSQL,基于CAP理论,关系数据库在分布式的环境下很难保证性能,在严格的ACID的事务要求下,导致大部分关系数据库在分布式环境下性能急剧降低,数据库的优化我们最开始可以采用主从分离(读写分离),一个主服务器,一个从服务器,从服务器定时从主服务器同步数据,写数据访问主服务器,读数据访问从服务器。再后来我们可能会采用按照业务去分库的方式降低数据库的压力。优化的最后手段就是采用分布式的数据库。这里我们为了提高响应的性能我们采取弱化集群的一致性,最终一致性。我们还会采用memcache内存数据库或则Redis充当缓存。
9. 系统的扩展性是业务功能的未来新需求的变更应该避免在现有系统改动,这也是OOD的开闭原则,这里强调的是系统的低耦合高内聚,业务复杂后我们可以按照业务拆分出一些公共的模块,为了达到复用公共模块的效果一般有两种解决方案,消息队列和分布式服务,消息队列将生产者和消费者解耦,而且异步也可以加快生产者的响应,但是现在代表性的分布式MQ kafka还主要应用在监控日志等方面。分布式服务框架比较有代表性的为Alibaba的Dubbo,把公用的服务独立出来服用。恰当运用设计模式思想以及实践面向对象原则是实现扩展性的重要方法。
10. 大型网站的模式是一系列比较常见的应用场景下的比较好的解决方案,复用这些方案可以较好的解决问题,例如在开发层面会有分层思想,分层思想贯穿整个计算机体系,无论是网络通信OSI模型还是网站比较流行的MVC,不同的层面解决不同的问题给高层提供底层服务,这样有利于模块的解耦以及分布式部署。分割思想是一种纵向的拆分模块,这样不同的功能模块进行拆分,形成高内聚低耦合的服务也是有利于独立部署与复用。分层与分割都是有利于分布式部署。
11. 不要想着靠技术解决所有的问题,例如12306的售票方式,最开始采用整点售卖的方式是业务不合理,后来改为分时间段去售卖,这样就大大的降低了系统的压力。至于一些大的访问请求,我们可以降低服务的方式来降低服务器的压力,在特殊时期也可以采取关闭部分服务的方式来缓解服务器的压力,例如在双11的促销活动中暂时关闭无关紧要的评论功能来保证购买交易功能的可用性,活动过后空闲的服务器资源还可以售卖成云服务利用。**

1 0
原创粉丝点击