5 大型 站核心架构要素

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

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

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

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


1 性能

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

也正是因为性能问题几乎无处不在,所以优化 站性能的手段也非常多,从用户浏览器到数据库,影响用户请求的所有环节都可以进行性能优化。

在浏览器端,可以通过浏览器缓存、使用页面压缩、合理布局页面、减少Cookie传 输等手段改善性能。

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

在应用服务器端,可以使用服务器本地缓存和分布式缓存,通过缓存在内存中的热 点数据处理用户请求,加快请求处理过程,减轻数据库负载压力。

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

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

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

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

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

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


2 可用性

对于大型 站而言,特别是知名 站, 站宕掉、服务不可用是一个重大的事故, 轻则影响 站声誉,重则可能会摊上官司。对于电子商务类 站, 站不可用还意味着 损失金钱和用户。因此几乎所有 站都承诺7×24可用,但事实上任何 站都不可能达到 完全的7×24可用,总会有一些故障时间,扣除这些故障时间,就是 站的总可用时间, 这个时间可以换算成 站的可用性指标,以此衡量 站的可用性,一些知名大型 站可 以做到4个9以上的可用性,也就是可用性超过99.99%。
.
因为 站使用的服务器硬件通常是普通的商用服务器,这些服务器的设计目标本身 并不保证高可用,也就是说,很有可能会出现服务器硬件故障,也就是俗称的服务器宕 机。大型 站通常都会有上万台服务器,每天都必定会有一些服务器宕机,因此 站高 可用架构设计的前提是必然会出现服务器宕机,而高可用设计的目标就是当服务器宕机 的时候,服务或者应用依然可用。

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

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

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

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

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


3 伸缩性

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

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

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

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

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

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


4 扩展性

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

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

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

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

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

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


5 安全性

互联 是开放的,任何人在任何地方都可以访问 站。 站的安全架构就是保护 站不受恶意访问和攻击,保护 站的重要数据不被窃取。
衡量 站安全架构的标准就是针对现存和潜在的各种攻击与窃密手段,是否有可靠 的应对策略。


6 小结

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

声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2021年4月6日
下一篇 2021年4月6日

相关推荐