大型网站焦点架构要素
关于什么是 架构，一种比较通俗的说法是“ 最高条理的规划，难以改变的决定”，这些规划和决定奠定了事物未来发展的方向和最终的蓝图。详细到软件架构，维基百科是这样定义的：“有关软件团体布局与组件的抽象描述，用于指导大型软件系统各个方面的计划”。
系统的各个紧张构成部分及其关系构成了系统的架构，这些构成部分可以是详细的功能模块，也可以是非功能的计划与决策，他们相互关系构成一个团体，共同构成了软件系统的架构。
一样平常说来，除了当前的系统功能需求外，软件架构还必要关注性能、可用性、伸缩性、扩展性和安全性这5个架构要素，架构计划过程中必要平衡这5个要素之间的关系以实现需求和架构目标，也可以通过观察这些架构要素来衡量一个软件架构计划的优劣，判定其是否满意期望。
1 性能
一个打开缓慢的网站会导致严重的用户流失，很多时候网站性能题目是网站架构升级优化的触发器。可以说性能是网站架构计划的一个紧张方面，任何软件架构计划方案都必须考虑可能会带来的性能题目。
1.1 性能优化
也正是因为性能题目几乎无处不在，以是优化网站性能的本领也非常多，从用户欣赏器到数据库，影响用户请求的全部环节都可以进行性能优化。
在欣赏器端，可以通过如下方案改善性能：
[*]欣赏器缓存。
[*]使用页面压缩。
[*]公道布局页面。
[*]减少Cookie传输。
[*]使用CDN，将网站静态内容分发至离用户迩来的网络服务商机房，使用户通过最短访问路径获取数据。
[*]网站机房摆设反向代理服务器，缓存热点文件，加快请求响应速度，减轻应用服务器负载压力。
在应用服务端，可以通过如下方案改善性能：
[*]使用服务器本地缓存和分布式缓存，通过缓存在内存中的热点数据处理用户请求，加快请求处理过程，减轻数据库负载压力。
[*]通过异步操纵将用户请求发送至消息队列等待后续任务处理，而当前请求直接返反响应给用户。
[*]网站有很多用户高并发请求的情况下，可以将多台应用服务器构成一个集群共同对外服务，提高团体处理本领，改善性能。
在代码层面，可以通过如下方案改善性能：
[*]使用多线程。
[*]改善内存管理等本领。
在数据库服务器端，可以通过如下方案改善性能：
[*]索引。
[*]缓存。
[*]SQL优化。
[*]NoSQL数据库通过优化数据模型、存储布局、伸缩特性等本领在性能方面的优势也日趋明显。
1.2 性能度量
衡量网站性能有一系列指标：
[*]响应时间。
[*]TPS。
[*]系统性能计数器。
上述指标也是网站监控的紧张参数，通过监控这些指标可以分析系统瓶颈，猜测网站容量，并对异常指标进行报警，保障系统可用性。
对于网站而言，性能符合预期仅仅是必要条件，因为无法预知网站可能碰面临的访问压力，以是必须要观察系统在高并发访问情况下，超出负载计划本领的情况下可能会出现的性能题目。网站必要长时间持续运行，还必须保证系统在持续运行且访问压力不均匀的情况下保持稳固的性能特性。
2 可用性
对于大型网站而言，特别是知名网站，网站宕掉、服务不可用是一个庞大的事故，轻则影响网站荣誉，重则可能会摊上官司。
2.1 可用性指标
网站的总可用时间，这个时间可以换算成网站的可用性指标，以此衡量网站的可用性，一些知名大型网站可以做到4个9以上的可用性，也就是可用性超过99.99%。
2.2 可用性目标
因为网站使用的服务器硬件通常是平凡的商用服务器，这些服务器的计划目标本身并不保证高可用。很有可能会出现服务器硬件故障，也就是俗称的服务器宕机。大型网站通常都会有上万台服务器，每天都必定会有一些服务器宕机，因此网站高可用架构计划的条件是必然会出现服务器宕机，而高可用计划的目标就是当服务器宕机的时候，服务或者应用依然可用。
2.3 可用性方案
网站高可用的重要本领是冗余，应用摆设在多台服务器上同时提供访问，数据存储在多台服务器上互相备份，任何一台服务器宕机都不会影响应用的团体可用，也不会导致数据丢失。
任何一台服务器宕机，只需把请求切换到其他服务器就可实现应用的高可用，但是一个条件条件是应用服务器上不能生存请求的会话信息。
除了运行环境，网站的高可用还必要软件开发过程的质量保证。通过预发布验证、主动化测试、主动化发布、灰度发布等本领，减少将故障引入线上环境的可能，避免故障范围扩大。
2.4 可用性度量
衡量一个系统架构计划是否满意高可用的目标，就是假设系统中任何一台或者多台服务器宕机时，以及出现各种不可预期的题目时，系统团体是否依然可用。
3 伸缩性
大型网站必要面临大量用户的高并发访问和存储海量数据，不可能只用一台服务器就处理全部用户请求，存储全部数据。网站通过集群的方式将多台服务器构成一个团体共同提供服务。所谓伸缩性是指通过不停向集群中加入服务器的本领来缓解不停上升的用户并发访问压力和不停增长的数据存储需求。
3.1 伸缩性度量
衡量架构伸缩性的重要标准就是是否可以用多台服务器构建集群，是否容易向集群中添加新的服务器。加入新的服务器后是否可以提供和原来的服务器无差异的服务。集群中可容纳的总的服务器数量是否有限定。
3.2 伸缩性方案
3.2.1 应用服务器集群
对于应用服务器集群，只要服务器上不生存数据，全部服务器都是对等的，通过使用合适的负载均衡装备就可以向集群中不停加入服务器。
3.2.2 缓存服务器集群
对于缓存服务器集群，加入新的服务器可能会导致缓存路由失效，进而导致集群中大部分缓存数据都无法访问。固然缓存的数据可以通过数据库重新加载，但是如果应用已经严重依赖缓存，可能会导致整个网站瓦解。必要改进缓存路由算法保证缓存数据的可访问性。
3.2.3 关系数据库集群
关系数据库固然支持数据复制，主从热备等机制，但是很难做到大规模集群的可伸缩性，因此关系数据库的集群伸缩性方案必须在数据库之外实现，通过路由分区等本领将摆设有多个数据库的服务器构成一个集群。
3.2.4 NoSQL数据库产品
至于大部分NoSQL数据库产品，由于其先天就是为海量数据而生，因此其对伸缩性的支持通常都非常好，可以做到在较少运维到场的情况下实现集群规模的线性伸缩。
4 扩展性
不同于其他架构要素重要关注非功能性需求，网站的扩展性架构直接关注网站的功能需求。网站快速发展，功能不停扩展，如何计划网站的架构使其可以或许快速响应需求变化，是网站可扩展架构重要的目的。
4.1 扩展性度量
衡量网站架构扩展性优劣的重要标准就是在网站增加新的业务产品时，是否可以实现对现有产品透明无影响，不必要任何改动或者很少改动既有业务功能就可以上线新产品。不同产品之间是否很少耦合，一个产品改动对其他产品无影响，其他产品和功能不必要受连累进行改动。
4.2 扩展性方案
网站扩展性（可伸缩架构）的重要本领是事件驱动架构和分布式服务。
4.2.1 事件驱动架构
事件驱动架构在网站通常利用消息队列实现，将用户请求和其他业务事件构造成消息发布到消息队列，消息的处理者作为消耗者从消息队列中获取消息进行处理。通过这种方式将消息产生和消息处理分离开来，可以透明地增加新的消息生产者任务或者新的消息消耗者任务。
4.2.2 分布式服务
分布式服务是将业务和可复用服务分离开来，通太过布式服务框架调用。新增产品可以通过调用可复用的服务实现自身的业务逻辑，而对现有产品没有任何影响。可复用服务升级变更的时候，也可以通过提供多版本服务对应用实现透明升级，不必要强制应用同步变更。
大型网站为了保持市场职位，还会吸引第三方开发者，调用网站服务，使用网站数据开发周边产品，扩展网站业务。第三方开发者使用网站服务的重要途径是大型网站提供的开放平台接口。
5 安全性
互联网是开放的，任何人在任何地方都可以访问网站。网站的安全架构就是掩护网站不受恶意访问和攻击，掩护网站的紧张数据不被偷取。
5.1 安全性度量
衡量网站安全架构的标准就是针对现存和潜在的各种攻击与窃密本领，是否有可靠的应对策略。
6 小结
性能、可用性、伸缩性、扩展性和安全性是网站架构最焦点的几个要素，这几个题目解决了，大型网站架构计划的大部分挑衅也就克服了。
以上内容泉源于《大型网站技术架构》焦点原理与案例分析。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]