模式:每一个模式描述了一个在我们周围不断重复发生的问题以及该问题解决方案的核心,这样你就能重复使用该方案而不必重复工作。
说人话:经验、解决方案。
为了解决大型网站面临的高并发访问、海量数据处理、高可用运行等一系列问题与挑战,大型互联网公司在实践中提出了许多解决方案,以实现网站高性能、高可用、易伸缩、可扩展、安全等技术架构目标。
分层
分层使得分工合作开发与维护变得容易,各层之间具有一定的独立性,必须合理规划层次边界与接口,开发过程中,禁止跨层次调用和逆向调用。共包括三层,应用层、服务层、数据层。
- 应用层:负责决堤业务和视图展示,可细分为视图层和业务逻辑层
- 服务层:为应用层提供服务支持,可细分为数据接口层和逻辑处理层
- 数据层:提供数据存储访问服务
分割
分层是横向划分,分割是纵向划分
将不同的功能和服务分割开来,包装成高内聚低耦合的模块单元,便于软件的开发与维护和分布式部署。
分布式
将不同的模块部署在不同的服务器上,使用RPC(远程过程调用)协同工作。
分布式意味着服务调用必须通过网络,这样可能对性能造成严重的影响,其次,服务器越多,服务宕机的概率也会变大,一台服务器宕机可能导致很多应用不可访问,使得网站可用性降低,另外,分布式使数据保持一致性变得困难。
常见的分布式方案有以下几种:
- 分布式应用和服务
- 分布式静态资源,如JS、CSS、图片等
- 分布式数据和存储,NoSQL就是分布式的
- 分布式计算,Hadoop MapReduce、Spark等
集群
多台服务器部署相同应用构成一个集群,通过负载均衡设备共同提供服务。
缓存
CDN、反向代理、本地缓存、分布式缓存
异步
异步可降低系统耦合性,业务之间的消息传递不是同步调用,而是将业务操作分成多个阶段,每个阶段之间通过共享数据方式异步执行进行协作。
在单一服务器内部可通过多线程共享内存队列的方式实现异步,处在业务操作前面的线程将输出写入到队列,后面的线程从队列中读取数据进行处理,如安卓handler机制,netty的异步等。在分布式系统中,多个服务器集群通过分布式消息队列实现异步,如kafka、redis、beanstalkd等。
异步架构是典型的生产者消费者模式,两者不存在直接调用,只要保持数据结构不变,彼此功能实现可以任意变化而不互相影响,这对网站扩展新功能非常便利。除此之外,使用异步消息队列还有以下特性。
- 提供系统可用性,消费者服务器发生故障,数据会在消息队列服务器中存储堆积,生产者服务器可以继续处理业务请求,系统整体表现为无故障。消费者服务器恢复正常后,继续处理队列的数据。
- 加快网站响应速度,处在业务处理前端的生产者服务器在处理完业务请求后,将数据写入消息队列,不需要等待消费者服务器处理就可以返回,响应延迟减少。
- 消除并发访问高峰 ,将突然增加的访问请求数据放入消息队列中,等待消费者依次处理,就不会对整个网站负载造成太大的压力。
冗余
数据冗余备份,数据库除了定期备份,存档保存,实现冷备份外,为了保证在线业务高可用,还需要对数据库进行主从分离,实时同步实现热备份。还可以对整个数据中心在全球范围内部署灾备数据中心。
自动化
自动化发布、自动化代码管理、自动化测试、自动化安全检测、自动化部署、自动化监控、自动化报警、自动化失效转移、自动化失效恢复、自动化降级、自动化分配资源。
安全
验证码、加密、XSS攻击、SQL注入漏洞、垃圾信息、敏感信息过滤、风险控制。
架构模式在新浪微博的应用
系统分为三个层次,最下层是基础服务层,提供数据库、缓存、存储、搜索等数据服务,以及其他一些基础技术服务,这些服务支撑了新浪微博的海量数据和高并发访问。
中间层是平台服务层和应用服务层,新浪微博的核心服务是微博、关系和用户。他们被分割成独立的模块,通过依赖调用和共享基础数据构成新浪微博的业务基础。
最上层是API和业务层,各种客户端和第三方调用,通过调用API集成到新浪微博的系统中。
异步的使用:用户发表微博后系统将微博写入消息队列后立即返回,用户响应迅速,消息队列的消费者任务将微博推送给其当前在线粉丝的订阅列表中,非在线用户登录后将根据关注列表拉去微博订阅列表。
多级缓存的使用:热门微博和明星用户的微博缓存在所有微博服务器中,在线用户的微博和近期微博缓存在分布式缓存服务器中,刷微博基本都是在访问缓存。
多个数据中心:用户访问最近的数据中心以加快访问速度,同时达到冗余的功能,所有的用户和微博数据在数据中心间通过RPC进行同步,提高系统可用性。