大型网站需要关注的一些架构要素

关于大型网站的架构设计过程中，我们除了关心当前系统的功能性需求外和非功能性需求的设计外，还需要关心一些系统架构要素，架构设计过程中，基本需要满足这些架构要素，要平衡这几个要素之间的关系以实现需求和架构目标。

一、性能

性能是网站的一个重要指标，可以说性能是网站架构设计的一 个重要方面， 任何软件架构设计方案都必须考虑可能会带来的性能问题。

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

浏览器端:

使用页面缓存、cookie、使用页面压缩、使用CDN，将网站静态部分分发到离用户最近的机房，使用户通过最短路径获取数据。

应用服务端:

可以使用本地缓存和分布式缓存，通过缓存热点数据来返回用户请求，减少数据库连接查询压力。

可以使用异步的方式，使用将请求发送到消息队列后等待后续任务处理，当前请求直接响应给用户，消息队列中的消息如果执行失败了，可以做补偿机制。

可以使用集群的方式，利用多台服务器处理大量请求内容。

使用多线程并发编码设计，处理请求。

提高内存优化，垃圾回收等手段。

数据库端:

使用索引、缓存、SQL优化等性能优化手段。使用非关系型数据库，处理数据结构。

衡量一个网站性能的指标

1、响应时间
2、TPS
3、系统性能计数器等。

最后总结一下，对于网站来说，性能符合预期是必要条件，因为无法预知网站突然面临巨大访问的压力，所以需要测试系统在高并发情况下，超出负载设计能力的情况下可能会出现的问题，网站需要长时间持续运行，还必须保证持续运行时访问压力不均匀的情况下，保持稳定的性能。

二、可用性

对于大型网站而言，特别是知名网站，网站宕机，服务不可用是一个重大事故。一般而言，可用性都是指在一段时间内比如7*24小时内可用的时间占总时间的比例来衡量的，一些知名网站可用性达到99.99%已经非常高了。

一般主要的原因都是因为服务器会宕机，毕竟时24小时在线的，高可用设计的前提就是服务器宕机的时候，服务还需要保证可用。

高可用的主要设计手段其实就是冗余，这个我之前的架构模式已经说过了。冗余服务器，冗余备份数据。

还有一种手段我们可以做集群负载均衡，任何一台机器宕机，我们可以把请求切换到其他服务器实现应用的高可用。

对于存储数据的服务器，可以对数据进行多中心备份，当服务器宕机时将数据访问转移到可用的服务器上，并对数据恢复以保证继续有服务器宕机的时候，数据可用。

关于高可用设计手段可以看我这篇文章，里面会总结的更详细:
互联网高可用设计手段

三、伸缩性

所谓伸缩性是指通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。

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

这里区分几种情况:

对于应用型服务器集群，新加入的服务器只要服务器上不操作数据，可以使用合适的负载均衡设备不断像集群中加入服务器。

对于缓存服务器，比如redis，如果部署的是集群，可以使用一致性hash算法，来保证伸缩性。

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

四、拓展性

不同于其他架构要素比较关注非功能性需求，网站的拓展性关注的是功能性需求，如何设计网站使其能够快速响应需求变化，就是网站可拓展性架构的目的了。

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

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

事件驱动架构通常采用消息队列实现，将用户请求和其他业务事件构成消息发布到消息队列，监听该事件的服务或者说消费者就会从消息队列中获取消息并处理。通过这种方式，能够解耦。

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

五、安全性

网站的安全架构就是保护网站不受恶意访间和攻击，保护网站的重要数据不被窃取。

衡量标准:针对现存和潜在的各种攻击与窃密手段，是否有可靠的应对策略。

后续文章会对这几个方面要素进一步分析。

摘自《大型网站技术架构核心原理与实践》在这里插入代码片