1.网站架构模式
-
分层:将系统在横向维度上切分成几个部分,每个部分负责一部分相对比较单一的职责,然后通过上下层的依赖和调用组成一个完整的系统。(网络的七层通信协议)
-
分割:分层是将网站横向切分,分割就是从纵向的角度去切分。将不同的功能和服务分割开来,一方面有助于软件的开发和维护,另一方面便于模块的分布式部署。
-
分布式:分层和分割的主要目的就是进行分布式部署。即将不同模块部署在不同的服务器上,通过远程调用协同工作。
分布式部署存在的问题:1.分布式调用必须通过网络,这可能对性能造成比较严重的 影响;2.服务器越多,服务器宕机的几率就越大;3.分布式很难保证数据一致性,分布式事物也难以保证;4.分布式导致网站错综复杂,开发管理维护困难。
常用的分布式方案有以下几种:
1.分布式应用和服务:将分层和分割后的应用和服务模块分布式部署。
2.分布式静态部署:网站的静态资源如JS,CSS,Logo图片等资源独立分布式部署,并使用独立的域名,动静结合。
3.分布式数据和存储:大型网站以P为单位的海量数据需要分布式存储。
4.分布式计算:后台业务计算如索引构建,数据分析等等。
5.分布式配置:支持网站线上服务配置实时更新。
6.分布式锁:分布式环境下实现并发和协同。
7.分布式文件系统:支持云存储的文件系统。
-
集群:虽然分布式已经将分层和分割后的模块单独部署,单对于用户访问集中的模块,还需要将独立部署的服务器集群化,即多台服务器部署相同的应用构建成一个集群,通过负载均衡设备对外提供服务。即使访问量很小的应用和服务,也至少部署两台服务器构成小集群,提高系统的可用性。
-
缓存:缓存就是将数据存放在距离计算最近的位置加快处理速度。使用缓存有两个条件:1.数据访问热点不均衡。2.数据在某个时间段内有效,不会很快过期。
1.CDN:内容分发网络,部署在距离终端用户最近的网络服务商,用户的网络请求总是先到达网络服务商那里,在这里会缓存一些静态资源(较少变化的数据)
2.反向代理:反向代理属于前段架构,部署在网站的前端,用户请求到达数据中心时最先访问的就是反向代理服务器,这里缓存着网站的静态资源。
3.本地缓存:在应用服务器本地缓存着热点数据,应用程序可以直接在本机内存中访问数据而无需访问数据库。
4.分布式缓存:大型网站的数据非常庞大,单机不能承受,所以将数据缓存在一个专门的分布式缓存中,应用程序通过网络通讯访问缓存数据。
使用异步消息队列的特性如下:
1.两者不存在直接调用,只要数据结构不变,彼此功能实现可以随意变化
2.提高系统可用性:消费者服务器发生故障,数据会在消息队列中堆积,生产者服务器可以继续处理请求,系统整体无障碍,等消费者服务器恢复后可以继续处理队列中的请求。
3.加快网站响应速度:生产者服务器将数据写入消息队列后,不需要等待消费者处理就可以返回,响应延迟减少。
4.消除并发访问高峰:消息队列可以将突然增加的访问请求数据放入消息队列中,等待消费者服务器以此处理,不会对整个网站负载造成太大压力。
1.发布过程自动化:减少认为干预,有效减少故障
2.自动化代码管理:代码版本管理,代码分支创建合并等过程自动化。
3.自动化测试:代码开发完成后,提交测试后,系统自动将代码部署到测试环境进行测试。
4.自动化安全检测:安全检测工具对代码进行静态安全扫描及部署到安全测试环境进行安全攻击测试,评估其安全性。
5.自动规划部署:将工程代码自动部署到线上生产环境。
6.自动化监控:对服务器进行心跳检测,并监控器各项性能指标。
7.自动化报警:如果发现异常,超出预设的阈值,就向相关人员发送报警信息。
8.自动化失效转移:将失效的服务器从集群中隔离出去,不再处理系统中的应用请求。
9.自动化失效恢复:故障消除后,重新启动服务器,同步数据保证一致性。
10.自动化降级:通过拒绝部分请求及关闭部分不重要的服务将系统负载降至一个安全的水平
11.自动化分配资源:将空闲资源分配给重要的服务,扩大其部署规模。
2.架构模式在新浪微博的应用
-
新浪在早期架构中,微博发布采用同步推模式:用户发表微博后系统会立即将这条微博插入到数据库所有粉丝的订阅列表中,当用户量比较大时,会引起大量数据库写操作,超出数据库负载,系统性能极具下降,用户响应延迟加剧。
-
后来新浪微博该用异步推拉结合的模式:用户发表微博后系统将微博写入消息队列后立即返回,用户响应迅速,消息队列消费者任务将微博推送给所有当前在线粉丝的订阅列表中,非在线用户登录后再根据关注列表拉去微博订阅列表。
3.小结