大型网站技术架构-3-大型网站核心架构要素

1 引子

关于什么是架构,一种比较通俗的说法是“最高层次的规划,难以改变的决定“,这些规划和决定奠定了事物未来发展的方向和最终的蓝图。

从这个意义上说,人生规划也是一种架构。选什么学校、学什么专业、进什么公司、找什么对象,过什么样的生活,都是自己人生的架构。

具体到软件架构,维基百科是这样定义的:“有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计“。系统的各个重要组成部分及其关系构成了系统的架构,这些组成部分可以是具体的功能模块,也可以是非功能的设计与决策,他们相互关系组成一个整体,共同构成了软件系统的架构。

一般说来,除了当前的系统功能需求外,软件架构还需要关注性能、可用性、伸缩性、扩展性和安全性这5个架构要素,架构设计过程中需要平衡这5个要素之间的关系以实现需求和架构目标,也可以通过考察这些架构要素来衡量一个软件架构设计的优劣,判断其是否满足期望。

2 核心架构要素

2.1 性能

性能是网站的一个重要指标,除非是没得选择(比如只能到www.12306.cn这一个网站上买火车票),否则用户无法忍受一个响应缓慢的网站。一个打开缓慢的网站会导致严重的用户流失,很多时候网站性能问题是网站架构升级优化的触发器。可以说性能是网站架构设计的一个重要方面,任何软件架构设计方案都必须考虑可能会带来的性能问题。

也正是因为性能问题几乎无处不在,所以优化网站性能的手段也非常多,从用户浏览器到数据库,影响用户请求的所有环节都可以进行性能优化。
(1)在浏览器端,可以通过浏览器缓存、使用页面压缩、合理布局页面、减少Cookie传输等手段改善性能。

还可以使用CDN,将网站静态内容分发至离用户最近的网络服务商机房,使用户通过最短访问路径获取数据。可以在网站机房部署反向代理服务器,缓存热点文件,加快请求响应速度,减轻应用服务器负载压力。
(2)在应用服务器端,可以使用服务器本地缓存和分布式缓存,通过缓存在内存中的热点数据处理用户请求,加快请求处理过程,减轻数据库负载压力。

也可以通过异步操作将用户请求发送至消息队列等待后续任务处理,而当前请求直接返回响应给用户。

在网站有很多用户高并发请求的情况下,可以将多台应用服务器组成一个集群共同对外服务,提高整体处理能力,改善性能。

在代码层面,也可以通过使用多线程、改善内存管理等手段优化性能。

(3)在数据库服务器端,索引、缓存、SQL优化等性能优化手段都已经比较成熟。而方兴未艾的NoSQL数据库通过优化数据模型、存储结构、伸缩特性等手段在性能方面的优势也日趋明显。

衡量网站性能有一系列指标,重要的有响应时间、TPS、系统性能计数器等,通过测试这些指标以确定系统设计是否达到目标。这些指标也是网站监控的重要参数,通过监控这些指标可以分析系统瓶颈,预测网站容量,并对异常指标进行报警,保障系统可用性。

对于网站而言,性能符合预期仅仅是必要条件,因为无法预知网站可能会面临的访问压力,所以必须要考察系统在高并发访问情况下,超出负载设计能力的情况下可能会出现的性能问题。网站需要长时间持续运行,还必须保证系统在持续运行且访问压力不均匀的情况下保持稳定的性能特性。

2.2 可用性

对于大型网站而言,特别是知名网站,网站宕掉、服务不可用是一个重大的事故,轻则影响网站声誉,重则可能会摊上官司。对于电子商务类网站,网站不可用还意味着损失金钱和用户。因此几乎所有网站都承诺7x24可用,但事实上任何网站都不可能达到完全的7x24可用,总会有一些故障时间,扣除这些故障时间,就是网站的总可用时间,这个时间可以换算成网站的可用性指标,以此衡量网站的可用性,一些知名大型网站可以做到4个9以上的可用性,也就是可用性超过99.99%。

因为网站使用的服务器硬件通常是普通的商用服务器,这些服务器的设计目标本身并不保证高可用,也就是说,很有可能会出现服务器硬件故障,也就是俗称的服务器宕机。大型网站通常都会有上万台服务器,每天都必定会有一些服务器宕机,因此网站高可用架构设计的前提是必然会出现服务器宕机,而高可用设计的目标就是当服务器宕机的时候,服务或者应用依然可用。

网站高可用的主要手段是冗余,应用部署在多台服务器上同时提供访问,数据存储在多台服务器上互相备份,任何一台服务器宕机都不会影响应用的整体可用,也不会导致数据丢失。

对于应用服务器而言,多台应用服务器通过负载均衡设备组成一个集群共同对外提供服务,任何一台服务器宕机,只需把请求切换到其他服务器就可实现应用的高可用,但是一个前提条件是应用服务器上不能保存请求的会话信息。否则服务器宕机,会话丢失,即使将用户请求转发到其他服务器上也无法完成业务处理。

对于存储服务器,由于其上存储着数据,需要对数据进行实时备份,当服务器宕机时需要将数据访问转移到可用的服务器上,并进行数据恢复以保证继续有服务器宕机的时候数据依然可用。

除了运行环境,网站的高可用还需要软件开发过程的质量保证。通过预发布验证、自动化测试、自动化发布、灰度发布等手段,减少将故障引入线上环境的可能,避免故障范围扩大。

衡量一个系统架构设计是否满足高可用的目标,就是假设系统中任何一台或者多台服务器宕机时,以及出现各种不可预期的问题时,系统整体是否依然可用。

2.3 伸缩性

大型网站需要面对大量用户的高并发访问和存储海量数据,不可能只用一台服务器就处理全部用户请求,存储全部数据。网站通过集群的方式将多台服务器组成一个整体共同提供服务。所谓伸缩性是指通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。

衡量架构伸缩性的主要标准就是：
(1)是否可以用多台服务器构建集群,
(2)是否容易向集群中添加新的服务器。
(3)加入新的服务器后是否可以提供和原来的服务器无差别的服务。
(3)集群中可容纳的总的服务器数量是否有限制。

对于应用服务器集群,只要服务器上不保存数据,所有服务器都是对等的,通过使用合适的负载均衡设备就可以向集群中不断加入服务器。

对于缓存服务器集群,加入新的服务器可能会导致缓存路由失效,进而导致集群中大部分缓存数据都无法访问。里然缓存的数据可以通过数据库重新加载,但是如果应用巳经严重依赖缓存,可能会导致整个网站崩溃。需要改进缓存路由算法保证缓存数据的可访问性。

关系数据库虽然支持数据复制,主从热备等机制,但是很难做到大规模集群的可伸缩性,因此关系数据库的集群伸缩性方案必须在数据库之外实现,通过路由分区等手段将部署有多个数据库的服务器组成一个集群。

至于大部分NoSQL数据库产品,由于其先天就是为海量数据而生,因此其对伸缩性的支持通常都非常好,可以做到在较少运维参与的情况下实现集群规模的线性伸缩。

2.4 扩展性

不同于其他架构要素主要关注非功能性需求,网站的扩展性架构直接关注网站的功能需求。网站快速发展,功能不断扩展,如何设计网站的架构使其能够快速响应需求变化,是网站可扩展架构主要的目的。

衡量网站架构扩展性好坏的主要标准就是在网站增加新的业务产品时,是否可以实现对现有产品透明无影响,不需要任何改动或者很少改动既有业务功能就可以上线新产品。不同产品之间是否很少耦合,一个产品改动对其他产品无影响,其他产品和功能不需要受牵连进行改动。

网站可伸缩架构的主要手段是事件驱动架构和分布式服务。

事件驱动架构在网站通常利用消息队列实现,将用户请求和其他业务事件构造成消息发布到消息队列,消息的处理者作为消费者从消息队列中获取消息进行处理。通过这种方式将消息产生和消息处理分离开来,可以透明地增加新的消息生产者任务或者新的消息消费者任务。

分布式服务则是将业务和可复用服务分离开来,通过分布式服务框架调用。新增产品可以通过调用可复用的服务实现自身的业务逻辑,而对现有产品没有任何影响。可复用服务升级变更的时候,也可以通过提供多版本服务对应用实现透明升级,不需要强制应用同步变更。

大型网站为了保持市场地位,还会吸引第三方开发者,调用网站服务,使用网站数据开发周边产品,扩展网站业务。第三方开发者使用网站服务的主要途径是大型网站提供的开放平台接口。

2.5 安全性

互联网是开放的,任何人在任何地方都可以访问网站。网站的安全架构就是保护网站不受恶意访问和攻击,保护网站的重要数据不被窃取。

衡量网站安全架构的标准就是针对现存和潜在的各种攻击与窃密手段,是否有可靠的应对策略。

性能、可用性、伸缩性、扩展性和安全性是网站架构最核心的几个要素,这几个问题解决了,大型网站架构设计的大部分挑战也就克服了。

3 要素总结

构建和维护一个大型网站涉及多个关键架构要素，这些要素共同作用以确保系统的高性能、高可用性、可扩展性和安全性。以下是几个核心的架构要素：

1、性能优化
(1)缓存机制：使用缓存减少数据库查询次数，如Redis或Memcached等内存缓存系统。
(2)内容分发网络（CDN）：将静态资源分布到地理位置不同的服务器上，以加速用户访问速度。
(3)异步处理：对于耗时操作采用异步处理方式，比如消息队列来解耦服务间的直接调用。

2、可扩展性
(1)水平扩展：通过增加更多的服务器节点来分散负载，而不是依赖单个更强大的硬件设备。
(2)微服务架构：将应用程序分解为一组小的服务，每个服务实现独立业务功能，并可以独立部署和扩展。
(3)弹性计算：利用云服务提供的自动伸缩能力，根据流量动态调整资源分配。

3、高可用性
(1)冗余设计：确保没有单点故障，包括数据存储、应用服务以及网络组件在内的所有层级都需要有备份方案。
(2)负载均衡：使用软件或硬件负载均衡器来均匀分布请求至后端服务器集群。
容错与恢复机制：建立有效的故障转移策略和灾难恢复计划。

4、安全防护
(1)身份验证与授权：实施强健的身份验证流程并严格控制权限级别。
(2)加密传输：使用SSL/TLS协议保护客户端与服务器之间的通信安全。
(3)防御DDoS攻击：部署专门的安全措施来抵御分布式拒绝服务攻击。

5、数据管理
(1)数据库复制与分区：为了提高读写性能及可靠性，通常会配置主从复制或多主复制模式，并对大表进行水平或垂直分割。
(2)事务一致性：在分布式环境中保证数据的一致性是一个挑战，可能需要采用两阶段提交或其他分布式事务解决方案。

6、监控与日志
(1)实时监控：持续监视系统状态，及时发现潜在问题。
(2)日志分析：记录详细的运行日志以便于故障排查和性能调优。

7、用户体验
(1)响应式设计：确保网站能在各种终端设备上良好显示。
(2)页面加载速度：优化前端代码，压缩图片大小等措施加快页面渲染速度。
综上所述，构建大型网站的核心在于综合考虑以上各个方面的需求，并且随着技术的发展不断迭代改进。每一点都至关重要，它们相互支持，共同构成了支撑大规模在线服务平台的基础架构。

4 缓存工具

选择适合大型网站的缓存工具是一个需要综合考量多个因素的过程。不同的缓存工具在性能、功能、易用性等方面各有特点，因此选择时应根据具体的业务需求和系统架构来决定。以下是一些关键点，可以帮助你做出合适的选择：

1、确定缓存类型
(1)内存缓存 vs 磁盘缓存：大多数情况下，对于响应速度要求极高的场景，会选择内存缓存（如Redis, Memcached），因为它们提供了更快的数据访问速度。而磁盘缓存则适用于数据量大但对访问速度要求不那么严格的情况。
(2)分布式缓存 vs 本地缓存：如果您的应用部署在多台服务器上，则可能更倾向于使用分布式缓存解决方案，这样可以共享缓存数据，减少重复计算或数据库查询。而对于单机环境或希望减少网络延迟的应用，可以考虑使用本地缓存。

2、性能与扩展性
(1)性能：评估不同缓存工具的读写性能，特别是对于高并发场景下的表现。
(2)扩展性：考虑缓存解决方案是否支持水平扩展，能否轻松地增加节点以应对增长的流量。

3、持久化需求
如果您的应用场景需要在重启后仍能保持部分或全部缓存数据，那么应该选择支持持久化的缓存工具（例如Redis）。相反，如果不需要持久化，Memcached可能是更好的选择，因为它专注于内存中的高速缓存。

4、数据结构支持
不同的缓存工具提供的数据结构支持有所不同。比如，Redis不仅支持简单的键值存储，还提供了列表、集合、哈希等多种复杂的数据结构，这使得它非常适合用于实现复杂的缓存逻辑。

5、社区支持与成熟度
选择一个活跃的开源项目通常意味着更好的文档支持、更多的第三方插件以及更快的问题修复周期。Redis和Memcached都是经过长期考验且拥有庞大用户基础的产品。

6、成本考虑
考虑到硬件成本、维护成本等因素。虽然某些高级特性可能会带来额外的好处，但也可能导致更高的运营成本。