《大型网站技术架构-核心原理与案例分析》阅读记录（第二章）

第一篇 概述

第二章 大型网站架构模式

模式的关键在于模式的可重复性，问题与场景的可重复性带来了解决方案的可重复使用。

2.1 网站架构模式

2.1.1 分层

分层是最常见的一种架构模式，将系统在横向维度上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后通过上层对下层的依赖和调用组成一个完成的系统。

如：应用层负责业务和视图，服务层负责提供服务与支持，数据层提供数据存储访问服务。

分层必须合理规划层次边界和接口，在开发过程中，严格遵守分层架构的约束，禁止跨层次的调用（应用层调用数据层）及逆向调用（数据层调用服务层或者服务层调用应用层）。

2.1.2 分割

分割是纵向方面对软件进行切分，将不同的功能和服务分割开来，包装成高内聚低耦合的模块单元，一方面有助于开发和维护，另一方面便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力。

如：在应用层，将购物、论坛、搜索、广告分割成不同的应用。

2.1.3 分布式

将不同模块部署在不同服务器上，通过远程调用协同工作。分布式意味着可以使用更多的计算机完成同样的功能，计算机越多，CPU、内存、存储资源越多，能够处理的并发访问和数据量就越大，进而能够为更多的用户提供服务。

2.1.4 集群

多台服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务。当某台服务器发生故障时，负载均衡设备或者系统的失效转移机制会将请求转发到集群中的其他服务器上。

2.15 缓存

缓存，快速响应，减少数据库压力。

2.1.6 异步

业务之间的消息传递不是同步调用，而是将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方式异步执行进行协作。

如：单一服务器多线程共享内存队列实现异步；分布式系统中，多个服务器集群通过分布式消息队列实现异步。

2.1.7 冗余

访问和负载很小的服务也必须部署至少两台服务器构成一个集群，其目的就是通过冗余实现服务高可用。

2.1.8 自动化

目前大型网站的自动化架构设计主要集中在发布运维方面。

2.1.9 安全

密码、手机验证码进行身份证认证；数据加密；验证码识别；编码转换；垃圾、敏感信息过滤；交易转账等操作进行风险控制。

2.2 架构模式在新浪微博的应用

最下层：基础服务，提供数据库、缓存、存储、搜索等数据服务，以及其他一些基础服务，这些服务支撑了新浪微博的海量数据和高并发访问。

中间层：平台服务和应用服务层，新浪微博的核心服务是微博、关系和用户，通过依赖调用和共享基础数据构成新浪微博的业务基础。

最上层：API和业务层，各种客户端和第三方应用通过调用AIP集成到新浪微博的系统中，共同组成一个生态系统。

新浪微博早期架构同步推送模式，用户发表微博后系统会立即将微博插入到数据库所有粉丝的订阅列表中，当用户量比较大时，会引起大量的数据库写操作，超出数据库负载，系统性能急剧下降，用户响应延迟加剧。

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

新浪微博还使用了多级缓存策略来提高系统性能；启用了多个数据中心，改善系统性能，同时数据冗余复制的灾备中心，挺高了系统的可用性。

新浪微博还开发了一系列的自动化工具，包括自动化监控、自动化发布、自动化故障修复等，改善运维水平提高系统可用性。

当然了新浪微博也遇到了一系列的安全挑战，垃圾内容、僵尸粉、微博攻击等。