您的位置:首页 > 运维架构 > 网站架构

大型网站技术架构笔记-第1篇 概述(2)

2017-12-14 11:27 337 查看
2 大型网站架构模式
模式(建筑学):每一个模式描述里一个在我们周围不断重复发生的问题及该问题的解决方案的核心。

2.1 网站架构模式

2.1.1分层

将系统在横向维度上切分成几个部分,每个部分负责一部分相对比较单一的职责,通过上层对下层的依赖和调用完整的系统

大型网站的采用的分层结构:应用层、服务层、数据层

应用层:负责具体业务和视图展示,如网站首页及搜索输入和结果展示,(再细分为视图层,业务逻辑层)

服务层:为应用层提供服务,如用户管理,购物车等(再分:数据接口层,逻辑处理层)

数据层:提供数据存储访问服务,如数据库,缓存,文件,搜索引擎等

分层的挑战:必须合理规划层次边界和接口,在开发过程中,严格遵循分层架构的约束,禁止跨层次的调用(应用层直接调用数据层)及逆向调用(数据层调用服务层,或是服务层调用应用层)

网站发展过程中,分层结构对网站支持高并发向分布式发展至关重要,因此网站规模很小的时候,就应该使用分层的架构。

2.1.2 分割

分层是将软件在横向进行切分,那么分割就是在纵向方面对软件进行切分。

将不同的功能和服务分割开来,包装成高内聚,低耦合的模块单元,方便维护和分布式部署,提高网站的并发处理能力和功能扩展能力

大型网站的分割粒度会更小:在应用层,将不同的业务进行分割,将购物、论坛、搜索、广告分割成不同的应用。

2.1.3 分布式

分布式意味着服务调用必须通过网络,可能会对性能造成比较严重的影响

服务器越多,服务器当机的概率也就越大

一台服务器当机造成的服务不可用,可能会导致很多应该不可访问,使网站可用性降低

数据在分布式的环境中,要保持数据的一致性非常困难

分布式网站依赖复杂,难以维护

常用的分布式方案:

分布式应用和服务

分布式静态资源

分布式数据和存储

分布式配置

分布式锁

分布式文件

分布式计算:应用、服务、实时数据处理都是计算。后台需要处理的内容,包括索引构建、数据仓库的数据分析统计等。

目前比较普遍的使用hadoop以及mapreduce 分布式计算框架进行此类批处理计算,特点是移动计算而不是移动数据,将计算程序分发到数据所在的位置以加速计算和分布式计算

2.1.4集群

多台服务器部署相同应用构成一个集群,通过负载均衡设备共同对外提供服务

2.1.5缓存

CDN:内容分发网络,到网络服务商

反向代理:属于网站前端架构

本地缓存:

分布式缓存:

使用缓存有两个前提条件:

数据访问热点不均衡,某些数据会被频繁的访问;

数据在某个时间内有效,不会很快过期

2.1.6异步

软件发展的一个重要目标和驱动力就是降低软件耦合性

在单一服务器内,可通过多线程共享内存队列的方式实现异步,处在业务操作前面的线程将输出写入到队列,后面的线程从队列中读取数据进行处理

分布式系统,多个服务器集群通过分布式消息队列实现异步,分布式消息队列可看成是内存队列的分布式部署

异步架构是典型的生产者消费者模式,两者不存在直接调用,只要保持数据结构不变,彼此功能实现可随意变化。

其他的特点:提供系统可用性、加快网站响应速度、消除并发访问高峰

2.1.7 冗余

备份

2.1.8自动化

自动化代码管理

自动化测试

自动化安全检查

自动化不是

自动化监控

自动化报警

自动化失效转移:将失效的服务器从集群中隔离出去

自动化失效恢复

自动化降级:通过拒绝部分请求及关闭部分不重要的服务将系统负载降至一个安全的水平

自动化分配资源

2.1.9 安全

通过手机、密码等进行身份认证

登录、交易对网络进行加密

使用验证码

xss,sql、csrf,

垃圾信息进行过滤

交易转账等,进行风险控制

2.2 架构模式在新浪微博的应用(需要单独研究,学习)

异步推拉结合的模式,用户发表微博后,系统将微博写入消息队列后,立即返回,用户响应迅速,消息队列消费者任务将微博推送给所用当前在线粉丝的订阅列表中,非在线用户登录后再根据列表拉取微博订阅列表

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: