前言：
什么是架构？"最高层次的规划，难以改变的决定"，这些规划和决定奠基了事物未来发展的方向和最终的蓝图。
从这个意义上说，人生规划也是架构，选什么学校，学什么专业、进什么公司、找什么对象、过什么样的生活，都是自己人生的架构。
软件架构：有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。
软件架构需要关注的点：
功能性需求
性能、可用性、伸缩性、扩展性和安全性
架构设计过程中需要平衡这5个要素之间的关系以实现需求和架构目标，也可以通过考察这些架构要素来衡量一个软件架构设计的优劣，判断其是否满足期望。
3.1 性能
任何软件架构的设计都必须考虑可能会带来的性能问题
浏览器端，可以通过浏览器缓存、页面压缩、合理布局页面、减少Cookie传输等手段改善性能。
使用CDN、反向代理服务器，缓存静态内容、热点数据，加快请求响应速度，减轻应用服务器负载压力。
应用服务器端，可以使用服务器本地缓存和分布式缓存，通过缓存在内存中的热点数据处理用户请求，加快请求处理过程，减轻数据库负载压力。
可以通过异步操作将用户请求发送至消息队列等待后续任务处理，而当前请求直接返回响应给用户。
在网站有很多用户高并发请求的情况下，可以将多台应用服务器组成一个集群共同对外服务，提高整体处理能力，改善性能。（无状态、幂等设计）
代码层面，可以通过多线程、改善内存管理等手段优化性能。
数据库服务器端，索引、缓存、SQL优化
NoSQL通过优化数据模型、存储结构、伸缩特性等手段
衡量网站性能有一系列指标，
响应时间
TPS
系统性能计数器
通过测试这些指标以确定系统设计是否达到目标。通过监控这些指标可以分析系统瓶颈，预测网站容量，并对异常指标进行报警，保障系统可用性。
对于网站而言，性能符合预期仅仅是必要条件，因为无法预知网站可能会面临的访问压力，所以必须要考察系统在高并发访问情况下，超出负载设计能力的情况下可能会出现的性能问题。网站需要长时间持续运行，还必须保证系统在持续运行且访问压力不均匀的情况下保持稳定的性能特性。
3.2 可用性
网站高可用架构设计的前提是必然会出现服务器宕机，而高可用设计的目标就是当服务器宕机时，服务或者应用依然可用。
网站高可用的主要手段时冗余，应用部署在多台服务器上同时提供服务，数据存储在多台服务器上互相备份，任何一台服务器宕机都不会影响应用的整体可用，也不会导致数据丢失。
对于应用服务器而言，多台应用服务器通过负载均衡设备组成一个集群共同对外提供服务，任何一台服务器宕机，只需把请求切换到其他服务器就可实现应用的高可用，但是一个前提条件是应用服务器上不能保存请求的会话信息。否则服务器宕机，会话丢失，即使将用户请求转发到其他服务器上也无法完成业务处理。
对于存储服务器，由于其上存储着数据，需要对数据进行实时备份，当服务器宕机时需要将数据转移到可用的服务器上，并进行数据恢复以保证继续有服务器宕机的时候数据依然可用。
除了运行环境，网站的高可用还需要软件开发过程的质量保证。通过预发布验证、自动化测试、自动化发布、灰度发布等手段，减少将故障引入线上环境的可能，避免故障范文扩大。
衡量一个系统架构设计是否满足高可用的目标，就是假设系统中任何一台或者多台服务器宕机时，以及出现各种不可预测的问题时，系统整体是否依然可用。
3.3 伸缩性
什么是伸缩性？
所谓伸缩性是指通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。
衡量架构伸缩性的主要标准：
是否可以用多台服务器构建集群，
是否容易向集群中添加新的服务器，
加入新的服务器后是否可以提供和原来的服务器无差别的服务。
集群中可容纳的总的服务器数量是否有限制。
对于应用服务器集群，只要服务器上不保存数据，所有服务器都是对等的，通过使用合适的负载均衡设备就可以向集群中不断加入服务器。
对于缓存服务器集群，加入新的服务器可能会导致缓存路由失效，进而导致集群中大部分缓存数据都无法访问。
虽然缓存的数据可以通过数据库重新加载，但是如果应用已经严重依赖缓存，可能会导致整个网站崩溃。需要改进缓存路由算法保证缓存的可访问性。
(带虚拟节点的一致性哈希算法）
关系型数据库的集群伸缩性方案必须在数据库之外实现，通过路由分区等手段将部署有多个数据库的服务器组成一个集群。
大部分NoSQL产品，天生为海量数据而生，伸缩性一般支持的比较好，可以做到较少的运维参与的情况下实现集群规模的线性伸缩。
3.4 扩展性
网站的扩展性架构关注的是网站的功能性需求。
衡量网站架构扩展性好坏的主要标准：
在网站增加新的业务产品时，是否可以实现对现有产品透明无影响，不需要任何改动或者很少改动既有业务功能就可以上线新产品。
不同产品之间是否很少耦合，一个产品改动对其他产品无影响，其他产品和功能不需要受牵连进行改动。
网站可伸缩架构的主要手段时事件驱动架构和分布式服务。
事件驱动架构在网站通常利用消息队列实现，将用户请求和其他业务事件构造成消息发布到消息队列，消息的处理者作为消费者从消息队列中获取消息进行处理。
通过这种方式将消息产生和消息处理分离开来，可以透明地增加新的消息生产者任务或者新的消息消费者任务。
分布式服务则是将业务和可复用服务分离开来，通过分布式服务框架调用。
新增产品可以通过调用可复用的服务实现自身的业务逻辑，而对现有产品没有任何影响。
可复用服务升级变更的时候，也可通过提供多版本服务对应用实现透明升级，不需要强制应用同步变更。
大型网站为了保持市场地位，还会吸引第三方开发者，调用网站服务，使用网站数据开发周边产品，扩展网站业务。
三方开发者使用网站服务的主要途径时大型网站提供的开放平台接口。
3.5 安全性
网站的安全架构就是保护网站不受恶意访问和攻击，保护网站的重要数据不被窃取。
衡量网站安全架构的标准就是针对现存和潜在的各种攻击与窃密手段，是否有可靠的应对策略。
3.6 小结
性能、可用性、伸缩性、扩展性和安全性时网站架构最核心的几个要素，这几个问题解决了，大型网站架构设计的大部分挑战也就克服了。