即使我们以分层思想解决了大型网站技术架构的结构和主要细节,但是还不够全面。
本节笔者会把大型网站技术架构的核心问题提出来,让读者对其有足够全面的理解。
性能是所有软件的一个重要指标,网站系统也不例外。网站系统的性能问题可以分为两个,即“网站系统的响应速度是否足够迅速”和“网站系统是否能支撑足够多的在线用户”。一个响应速度很慢或者不能支撑足够多在线用户的网站,一定会被大量用户所诟病。
衡量网站性能有一系列指标,如响应时间、TPS(Transactions PerSecond,每秒的事务数)及并发量等。通过测试这些性能指标,可较为客观地评估网站系统的性能。在上线前,可以通过压力测试模拟预期的用户量,从而测试网站性能是否达标。
性能问题无处不在,前端部分需要对浏览器的访问进行优化,后端部分需要考虑缓存、读写分离、代码和数据结构优化,整体部署上需要考虑CDN加速、负载均衡、集群和服务器配置调优等问题。
性能调优是网站上线后比较重要的工作,因为在上线前即使做了充分的模拟测试,也很难把正式上线后的所有性能问题都解决。但是也并不意味着网站的性能问题全部都要等到网站上线后才能解决。如集群化、读写分离和缓存等一些优化问题涉及大量编码工作,如果在开发过程中不重视的话,那么很可能会由于网站系统的性能过差且优化工作量过大而推迟上线和运营。
笔者曾参与过一个开发过程中没有考虑缓存问题的项目,网站上线后由于数据库压力过大而导致网站响应速度非常慢,而加入缓存会涉及大量的编码工作,最后那个网站的上线时间推迟了几个月。
可用性(也可理解为稳定性)是网站系统的另一个重要指标。对于绝大多数大型网站而言,保证每天24小时正常运行是最基本的要求。但事实上,网站系统总会出现一些程序错误或服务器故障,也就是说,服务器宕机本身是难以避免的。高可用性设计指的是,当一部分服务器宕机时,网站系统仍可正常使用。
网站的可用性指标一般是正常运行时间占总时间的百分比,网站上线后要密切监控网站的健康状况。
高可用性有几个基本的处理手段:第一是冗余,如热备(确保主服务器宕机后备用服务器可以马上取代主服务器)和数据备份(在一定程度上规避硬件故障带来的风险)等;第二是监控,如完整的日志机制(发生故障时有迹可循)和服务器监控等;第三是软件质量;第四是定期维护,如手动重启或清理服务器等,这样能防止很多奇怪的问题发生(如硬盘读写问题或程序崩溃等)。
伸缩性指的是网站系统对当前用户使用量的适应性。简单地说,具备伸缩性的网站系统可以通过简单地添加或者减掉服务器来适应当前的用户量。
网站在运营中,其用户数量会不断地攀升或持续地下降,也有可能由于营销活动使得某几天的用户量激增。因此,网站系统的用户量是阶段性变化的,这就需要通过添加或者减少服务器来适应当前的用户量。
另外,一些大型网站(如电商网站和视频网站等)不可能在一天之中的每个时段的用户量都是稳定的。在一般情况下,其用户量会在某几个时段激增,而在其他时段会下降。如果时刻都保持满足峰值用户量的服务器数量,一定会造成大量的资源浪费。因此,大部分大型网站需要实现自动弹性伸缩服务器以动态适应用户量。
实现自动弹性伸缩服务器有两种手段:第一是通过监控服务器的CPU和内存等基本指标来伸缩服务器;第二是根据业务编写专门的弹性伸缩策略软件,根据业务指标来弹性伸缩服务器。
需要注意的是,增减服务器的手段不是关键,关键是能做到新增的服务器可以马上协同工作(无须进行多余的调控),而减掉的服务器也不影响网站系统的正常运行。
注意:公有云和私有云都提供弹性伸缩服务器的服务。一般来说,我们不需要关心弹性伸缩服务器的实现过程,而只需要制定好弹性伸缩的策略即可。如果按照监控服务器的基本指标进行弹性伸缩,则只需要配置弹性伸缩的性能指标就可以;如果根据业务定制弹性伸缩策略,则需要根据实际业务策略向公有云或私有云发送请求。
扩展性评价的是,在新增功能时,能否对已有功能做到无影响或少影响,以及新功能能否快速上线。如何响应网站快速发展所带来的需求变化是一定需要考虑的。
扩展性跟其他几个核心问题有所区别,其好坏更多与应用软件部分(前端、后端和云计算服务)相关,也就是与团队编写的代码有很大的关系。好的扩展性要求代码质量过关、业务功能模块划分清晰等。因此,在一开始规划业务功能模块或子系统时就需要仔细斟酌。
分布式服务是解决扩展性的很好方法,通过使用一些分布式框架,便可以增加独立程序来添加新的功能模块。
安全性指的是网站对恶意访问和恶意攻击等的抵抗性。网站系统的安全性,一方面是保证网站的正常运行,另一方面是保证数据不被泄露。近年来,用户数据被泄露的事件对知名网站的影响很大,因此网站的安全性也越来越受到平台的重视。
安全性大多是一些琐碎或者经常被忽略的问题,保证网站的安全性需要做大量的安全性测试,如请第三方公司做渗透测试,或请相关机构做等保(信息系统安全等级保护)测评等。
本篇把大型网站架构细分成业务架构和技术架构,比较全面地论述其基本问题和设计思路。其中,提及的业务架构图和技术架构图不是唯一的标准,应根据实际情况进行设计。
在本篇的最后提出了大型网站技术架构的核心问题,解决了这几个问题,基本就勾勒出了大型网站技术架构的全貌。从宏观上讲,大型网站架构其实就是这些内容。
读者在有了清晰认知的同时,应该还会有很多疑问,那是因为我们还不知道怎么去做。
下篇文章给大家讲解的内容是大型网站架构的技术细节:前端架构,前端的工作原理
觉得文章不错的朋友可以转发此文关注小编;
感谢大家的支持!