大型网站技术架构-核心原理与案例分析
浏览数：20 /
时间：2015年06月09日
阿里系的书，也是讲大型网站系统架构的，平常我们总是挂在嘴边的高性能、高可用、易扩展、安全性，这些所谓的系统非功能性指标到底如何实现，书里面讲了这些干货，作为网站架构师或者哪怕是应用系统的架构师，都值得了解，也许不一定都能用上，但是等需要用的那天，你肯定不会迷茫。
1.大型网站架构发展常见历程：应用/数据库分离--->使用缓存--->应用服务器集群--->数据库读写分离--->CDN及反向代理--->使用分布式文件系统和分布式数据库--->NoSQL及搜索引擎--->业务拆分,分库--->分布式服务
2.主要涉及的升级方案概要:横向业务分层(应用层，服务层，数据层)，纵向业务分割(购物，论坛，搜索，广告)，分布式服务(分布式应用和服务，分布式静态资源，分布式数据和存储，分布式计算，分布式文件系统)，集群服务，引入缓存(CDN，反向代理，本地缓存，分布式缓存)，异步调用(共享内存队列)，冗余设计(主从分离热备份，冷备份)，运维自动化(自动代码管理，自动测试，自动部署，自动安全检测，自动监控，自动报警，自动失效转移，自动失效回复，自动分配资源)，保证安全(防XSS，防SQL注入)
3.大型网站核心目标及实现手段：
(一)高性能
通过性能测试(性能测试，负载测试，压力测试，稳定性测试)找到系统的最佳性能点，最大负载点，系统崩溃点，通过多层次对系统进行优化，主要包括：
1：Web前端优化
a:浏览器优化（合并http请求，使用浏览器缓存，启动静态文件压缩GZip，CSS放页面最上面，js文件放页面最下面，静态资源使用独立域名访问减少Cookie）
b:CDN(Content Distriburte Network)缓存加速
c:反向代理实现缓存及负载均衡
2：应用服务器性能优化
a:针对热点不经常改变的数据用分布式缓存
b:引入消息队列实现异步化操作
c:服务器集群
d:代码优化(多线程，单例及池化，合理数据结构设计，JVM参数调优)
3：数据库端存储优化
a:使用固态硬盘替代机械硬盘
b:B+和LSM树的使用
c:RAID廉价磁盘冗余阵列 和分布式文件系统
(二)高可用
高可用架构主要通过数据和服务的冗余备份及失效转移来实现，针对应用层和服务层，采用集群来实现，数据层采用数据复制，冗余。主要包括：
1：负载均衡无状态服务进行失效转移(失效确认，访问转移，数据恢复)
2：Session一致性的管理(Session复制，Session绑定，利用Cookie记录Session，专门的Session服务器实现状态分离)
3：常用策略：分级管理，超时设置，异步调用，服务降级，幂等性设计
4：数据冷备份和热备份
5：强调借助系统监控来保证高可用，通过手机服务日志信息，客户端浏览器日志，服务器性能参数(system load,内存占用，磁盘IO，网络IO)进行系统报警，并做失效转移及自动优雅降级等处理。
(三)易伸缩
指不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或缩小服务处理能力。伸缩性包括应用服务器集群伸缩，缓存数据服务器集群伸缩，存储数据服务器集群伸缩
1：应用服务器集群需要通过负载均衡来实现分发，目前有多种软硬件负载均衡设备，包括商业产品及开源产品的，其主要通过以下几种技术实现负载：
a:HTTP重定向负载，通过重定向服务器获取真实服务IP然后访问，需要客户端浏览器两次请求存在瓶颈，且容易被所搜引擎判断为SEO作弊，一般使用较少。
b:DNS负载，利用DNS基于地理位置进行域名解析的特点来实现分发，缺点是多级解析容易出现更新不一致的情况。一般大型网站部分使用DNS分发到后端进行二次负载均衡分发。
c:反向代理负载均衡，在HTTP协议层由反向代理服务器根据负载算法向真实应用服务请求，并通过反向代理服务器再响应给用户。缺点是反向代理服务器是所有请求的中转站，容易发生瓶颈。
d:IP负载均衡，在网络层负载均衡服务器通过修改请求的目的ip的方式将服务转向真实服务器，然后再通过或修改源IP或将此负载服务器同时作为网关服务器的方式将响应接收回来，最后由负载均 衡服务器返回给客户端.缺点还是容易存在自身瓶颈。
e:链路层负载，配置集群下所有真实应用服务器虚拟IP和负载均衡服务器IP一致，负载均衡服务器只将请求的目的MAC地址修改成提供服务的服务器MAX，实现三角传输模式，避免负载均衡服务器自身瓶颈，LVS是Linux平台下最好的链路层负载均衡开源产品。
2：缓存数据服务器集群注意新增缓存服务器时对其他节点的影响已经数据雪崩现象，一般来说利用一致性Hash算法(并加上虚拟层)分摊多服务器的压力。
3：存储数据服务一般通过主从复制，读写分离，分库，分片以及NoSQL数据库实现
a:主服务器将数据同步到从服务器，读操作及数据分析等离线操作在从服务器上执行。
b:不同业务数据表部署在不同的数据库集群上实现分库，最大的制约是不同库的表不能做join
c:大表数据分库存储实现分片。Cobar可以实现分布式关系数据库访问的代理，但是跨库的join和事务仍是难点，必要时需要通过业务来约束
d:NoSQL数据库如HBase实现大数据的集群存储 HMaster--->HRegionServer--->HRegion--->HFile(HDFS)
(四)易扩展
对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力，各应用间较少依赖和耦合。
1:分布式消息队列
2:分布式服务，将复杂关系和结构的系统进行拆分，按模块独立部署，降低系统耦合性。
纵向拆分：将一个大应用拆分为多个小应用，如果新增业务较独立，则单独部署
横向拆分：将复用的业务拆分，独立部署，提供分布式服务并保持接口的一致性供新增的业务调用.
分布式服务框架的设计一般包括服务提供者，服务注册中心，服务消费者(接口访问代理,负载均衡，远程通信模块等)
(五)安全性
1:通过特殊字符转义(消毒)和Cookie设置HttpOnly的方式实现跨站点脚本攻击XSS的防御
2:通过特殊字符转义(消毒)和参数绑定执行sql的方式实现SQL注入攻击
3:通过表单Token，验证码，Referer check等手段可以实现跨站点请求伪造CSRF的防御
4:其他可能的攻击和漏洞：Error Code(Exception)太详细，HTML注释，文件上传未限制，web服务路径可遍历
5:加解密技术的应用
4.CAP原理：
一个提供数据服务的存储系统无法同时满足数据一致性(Consistency)，数据可用性(Availibility)，分区耐受性(Patition Tolerance)这三个条件
5.对于代码版本控制，前期可以采用分支开发，主干发布的形式，便于多个团队同步协作开发，后期产品成熟稳定，在持续性升级过程中可以采用主干开发，分支发布的形式，便于管理和控制产品版本。
6.负载均衡的算法：轮询，加权轮询，随机，最少连接，源地址散列。
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
