大型网站技术架构 – 第三节读书笔记
作者：黄志成
博客：地址
每天坚持读书.定有收获.
大型网站核心架构要素
读了这么久,那架构到底是什么呢?
一种通俗的说法就是 "最高层次的规划,难以改变的决定"
具体到软件架构,维基百科是这样定义的："有关软件整体结构与组件的抽象描述,用于指导大型软件各个方面设计"
一般来说,除了当前系统的需求外,软件架构还需要关注性能、可用性、伸缩性、扩展性和安全性这5个架构要素。架构设计中需要平衡这五个要素之间的关系以实现需求和架构目标.
下面来简单说说这个五个架构要素吧.
性能
性能优化是一个老生常谈的话题了。性能是一个网站的重要指标.一个打开缓慢的网站会导致严重的用户流失,很多时候网站性能问题是网站架构升级优化的触发器。可以说性能是网站架构的一个重要方面,任何软件架构方案都必须考虑可能会带来的性能问题。
也正是性能问题无处不在,所以网站性能优化的手段也非常多.从客户端到服务端处理完数据,这每个环节都可以大做文章,对其优化.
浏览器端：可以通过浏览器缓存、页面压缩传输、合理布局页面、减少Cookie传输等手段，甚至可以使用CDN加速功能。
服务端：使用缓存技术.将热数据存在内存中,加快cpu读取速度.也可以将一些操作变为异步执行.当然还离不开分布式和集群了.采用连接池技术,复用连接。
数据库端：可用使用索引、缓存、SQL性能优化等手段，还可以使用NoSQL数据库来优化数据模型、存储结构等。
衡量网站性能有一系列指标，重要的有响应时间、TPS、系统性能计数器等，通过这些指标以确定系统设计是否达到目标。
下面附上一段面试对话：
面试官：你了解Redis 和 Memcached 吗?
应聘者：了解,上家公司最开始用的是Memcached 后来换成Redis了.
面试官：那为什么要换Redis呢?
应聘者：架构师说换的.Redis的数据类型支持的更多啊.
如果你是这个应聘者你会怎么回答?
很多人在架构这里,一直是理所当然的.所有人都说Redis好,那么Redis就是一定是最的.
不要忘记前一节说的：架构是根据业务场景来的,不是理所当然的设计.
如果你没有做过具体的调研测试,就不要断定的说,谁更适合这个业务场景.
可用性
在软件系统的高可靠性（也称为可用性，英文描述为HA，High Available）里有个衡量其可靠性的标准——X个9，这个X是代表数字3~5。X个9表示在软件系统1年时间的使用过程中，系统可以正常使用时间与总时间（1年）之比，我们通过下面的计算来感受下X个9在不同级别的可靠性差异。
1个9：(1-90%)*365=36.5天，表示该软件系统在连续运行1年时间里最多可能的业务中断时间是36.5天。
2个9：(1-99%)*365=3.65天，表示该软件系统在连续运行1年时间里最多可能的业务中断时间是3.65天。
3个9：(1-99.9%)*365*24=8.76小时，表示该软件系统在连续运行1年时间里最多可能的业务中断时间是8.76小时。
4个9：(1-99.99%)*365*24=0.876小时=52.6分钟，表示该软件系统在连续运行1年时间里最多可能的业务中断时间是52.6分钟。
5个9：(1-99.999%)*365*24*60=5.26分钟，表示该软件系统在连续运行1年时间里最多可能的业务中断时间是5.26分钟。
6个9：(1-99.9999%)*365*24*60*60=31秒， 示该软件系统在连续运行1年时间里最多可能的业务中断时间是31秒。
服务器出现故障是常见的事情.高可用的目标就是当服务器出现宕机的时候,服务依然可以使用.
高可用的主要手段就是冗余,应用部署在多台服务器上提供服务,数据存储在多台服务器上互相备份,其中一台服务器出现故障都不会影响整体.
这些服务器还可以放在不同的机房,避免那个机房发生意外,这样做到了异地容灾.
网站的高可用还需要软件开发过程中质量保证。通过发布验证、自动化测试、自动化发布、灰度发布等手段,减少故障引入线上环境的可能,避免故障范围扩大.
衡量一个系统架构设计是否满足高可用的目标,就是假设系统中任何一台或者多台服务器宕机,以及出现各种不可预期的问题时,系统整体是否依旧可用.
伸缩性
大型网站需要面对大量用户高并发访问和海量存储,不可能只用一台服务器就处理全部用户请求.网站将多台服务器构成一个集群,组成一个整体对外提供服务.所谓伸缩性是指通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的需求.
比如某个明星发生了新闻.那个明星的微博可能会突然间涌入大量用户访问.在底下评论.如果没有好的伸缩性.网站可能就会在一定大的访问量下崩溃.
如果做得足够好,可以快速的加入服务器.来应对此次事件.
对于应用服务器集群,只要服务器上不保存数据,所有服务器都是对等的,通过使用合适的负载均衡就可以向集群中不断加入新服务器.
对于缓存服务器集群,加入新的服务器可能会导致缓存路由失效,造成去读数据库,然后发生雪崩现象.如果对缓存高度依赖,可能会导致整个网站崩溃。需要改进路由算法。现在比较好的是一致哈希算法
关系型数据库虽然支持复制,主从热备,但很难做到大规模集群伸缩,因此关系型数据库的集群方案必须在数据库之外实现,阿里巴巴就开源了MyCat
大部分NoSQL天生就为海量数据而生,因此伸缩性都非常好。
扩展性
不同于其他架构要素,网站的扩展性直接关注网站的功能需求。网站快速发展，功能不断扩展.如何设计网站的架构使其能够快速响应需求变化，是网站可扩展性主要目的。
一个模块在扩展性方面应该是开放的而在更改性方面应该是封闭的. 著名的开放-封闭原则
网站可扩展架构主要手段是事件驱动和分布式服务。
事件驱动架构在网站通常利用消息队列实现,将用户请求和其他业务事件构成消息发布到消息队列,通过生产者消费者可以降低之间的耦合.可以透明地增加新的消息生产者任务或者新的消费者任务。
分布式服务则是将业务和可复用服务分离开来，通过分布式服务框架调用。新增产品可以通过调用可复用的服务实现自身业务逻辑，而对现有产品没有任何影响。可复用服务升级变更时,也可以通过提供多版本服务对应用实现透明升级。
安全性
互联网是Open的.任何有人访问的网站,就会存在被攻击的风险.常见的DDOS攻击.会导致你网站打不开.
还有更痛恨的就是通过漏洞进入你的系统窃取你的资料.这样会造成大量用户流失。
安全这一块也是至关重要的.成为大型网站,安全性自然少不了.
小结
前面这三节都是为后面的内容做铺垫.后面一章将会围绕这五点进行梳理.
下面一节等到周末在研究.这几天先把前几节的内容消化一下.
写于：2018年07月18日00:29
发表评论