第一篇：概述 -- 2.大型网站架构模式 笔记

大型网站架构模式 笔记

模式，在建筑学中是这样定义的：

每一个模式描述了一个在我们周围不断重复发生的问题及解决该问题的核心。这样，那你就能重复地使用该方法而不必做重复工作。

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

---

一.网站架构模式

目的：为了解决大型网站面临的高并发访问，海量数据处理，高可靠运行等问题，以实现网站的高性能，高可用，易伸缩，可扩展，安全等各种技术为架构目标，即规划软件清晰的逻辑结构，以便于开发维护。

1.分层

将系统在横向维度上切分为几个部分，每个部分负责单一的职责，根据上层对下层的依赖和调用组成一个完整的系统。其中，在大型网站架构上分层，可分为：应用层，服务层和数据层。以下为这几个分层的具体的职责。

层级 职责 应用层 负责具体业务和视图展示，如网站首页及搜索输入和结果展示 服务层 为应用层提供服务支持，如用户管理服务，购物车服务等 数据层 提供数据存储访问服务，如数据库、缓存、文件、搜索引擎等

注意：只要维持调用接口的稳定，各层可以根据问题独立演化而不必对其他层做出调整。

对应挑战：显而易见，分层架构的问题就是如何合理地划分层次边界和接口。因为我们在确定边界之后，应当禁止跨层次的调用与逆向调用。

根据每层结构的职责，我们还可以继续划分：应用层可以分为试图层和业务逻辑层；服务层可以分为数据接口层和逻辑处理层。

虽然分层架构只是体现在逻辑上，理论上我们还是可以把三层结构放在同一个物理机器上，但是随着需求的增加，我们必须将分层的模块分开部署，从而使得网站有更多的资源以应对更多的用户访问。因此，我们应当在网站初始建设时就采用分层的架构，以便应对未来网站更大的建设。

2.分割

分割，顾名思义，就是在纵向对软件进行切分。
如果网站的功能越复杂，服务和数据处理的种类也就越多，将不同功能与种类的服务分割开来，组合成高聚合，低耦合的模块单元，不但有利于软件的开发和维护，也可以便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力。
例如，在应用层上，我们可以将不同的业务进行分割，将每个业务由不同的部门单独完成；如果一个业务规模过大，我们也可以继续进行分割；在服务层上我们也可以根据需求将服务分割成合适的模块。

3.分布式

分布式意味着可以使用更多的计算机完成相同的功能，计算机越多，CPU，内存，存储资源也就越多，处理的并发访问和数据量也就可以越多，从而为用户提供更多服务。

问题：

1. 分布式服务必须通过网络，对性能有较大影响；
2. 服务器越多，宕机的可能性就越大，从而使得网站可用性降低；
3. 分布式数据的一致性也有较大的困难，分布式事务也难以保证，对正常的业务有较大的影响；
4. 网络依赖复杂，开发管理维护困难；

常见的分布式方案：

• 分布式应用和服务

  将分层和分割后的应用和服务模块分布式部署，有助于提供网站性能和并发性，加快开发速度；还可以是不同应用复用服务，便于业务功能扩展。

• 分布式静态资源
  将诸如JS，CSS等静态文件独立分布式部署，并采用独立的域名，可以有效地减轻应用服务器的敷在压力，加快并发速度。

• 分布式数据和存储
  包括对传统的关系数据库进行分布式部署外，还有各种NoSQL数据库。

• 分布式计算
  特点是移动计算而不是移动数据，将计算程序发布到数据所在的位置上以加快计算和分布式计算。

• 分布式配置等

4.集群

将独立部署的服务器集群化，即多台服务器部署相同的应用构成一个集群，通过负载均衡设备沟通对外提供服务。当某台服务器出现故障，负载均衡设备或者失效转移机制会请求转发到集群中其他的服务器上，使得服务器故障不影响用户使用。

5.缓存

缓存是将数据存放爱距离计算最近的位置以加快处理速度。主要的缓存方法包括以下几种：

1. CDN
   内容分发网络，部署在距离终端用户最近的网络服务商上，可以以最快的速度返回给用户。

2. 反向代理
   部署在网站的前端，当用户请求到达网站的数据中心时，最先访问的是反向代理服务器，若有对应缓存，则直接返回给用户。

3. 本地缓存
   在应用服务器本地缓存热点数据，应用程序直接在本机访问数据，无需访问数据库。

4. 分布式缓存
   将数据缓存在一个专门的分布式缓存集群中，应用程序通过网络通信访问缓存数据。

前提：

1. 数据访问热点不均匀，更频繁被访问的数据应当放在缓存中。
2. 数据在某个时间段内有效，否则会产生脏读，影响结果的正确性。

6.异步

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

单一服务器内部：多线程共享内存队列方式。
分布式系统：多个服务器集群通过分布式消息队列进行异步。
分布式消息队列可以当做内存队列的分布式部署。

异步消息队列特点：

• 提高系统可用性
• 加快网站的响应速度
• 消除并发访问高峰

当有突发事件使得整个网站负载家中，可以使用消息队列将突然增加的访问请求数据放入消息队列中，等待消费者服务器依次执行，不会对整个网站造成过大的负载。但是可能会对用户体验和业务流程造成一定的影响。

7.冗余

当服务器规模较大时，很有可能会出现宕机事件，因此，要保证在宕机的情况下服务器可以继续服务，不丢失数据，需要一定数量的服务器冗余，这样可以保证网站的正常运行。
当访问和负载很小时，也必须至少部署两台服务器构成的集群，可以保证服务的高可用性。数据库应该保证定期备份存档的冷备份外，还应该实现主从分离，实时同步的热备份。
对于大型网站，还应当设置灾备数据中心，这样可以使数据与程序实时同步到灾备数据中心。

8.自动化

即在无人值守的情况下，网站可以正常运行。目前，大型网站的自动化架构主要集中在发布运维方面。
为了保证发布环节的正常，可以减少人为干预，使发布过程自动化，可以有效地减少故障。

发布过程主要包括：自动化代码管理，代码版本控制，代码分支创建合并，自动化测试，自动化安全检查。

为保证网站在运行时遇到问题时可以正常解决，网站需要对线上生产环境进行自动化监测，监测其各种性能指标和应用程序关键数据指标。如果有异常，就自动化报警，系统会自动化失效转移，将该服务器从集群中抽离进行修复，故障排除后系统进行自动化失效恢复，重新启动程序，保证数据一致性。当用户请求量过大时，系统会自动降级，拒绝部分请求或者关闭部分不重要的服务。必要时还会自动化分配资源，扩大其部署。

9.安全

网站安全可以通过密码和手机校验码进行身份认证；还可以通过验证码进行识别；对于常见的攻击进行过滤；对交易转账等信息进行风险控制。

---

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

在经历用户访问数据的增加，新浪微博的目前维持着以下的架构：

系统分为三层：

1. 基础服务层
   提供数据库，缓存，存储和搜索等数据服务，为新浪微博提供了海量数据和高并发访问，是整个技术的基础。

2. 平台服务和应用服务层
   新浪微博的核心服务时微博，关系和用户，这些服务被分割为独立的服务模块，提供依赖调用和共享基础数据构成业务基础。

3. API和业务层
   包括各种客户端和第三方应用，通过API集成到新浪微博的系统中，组成一个生态环境。

被分层和分割后的业务模块和基础技术模块被分布式部署，每个模块都部署在一组独立的服务器集群上，通过远端调用的方式进行依赖访问。在其早期还使用过MPSS（MultiPort Single Server 单服务多端口）的分布式集群部署方案和同步推模式。在集群中的服务器上，每台服务器都部署多个服务，使用不同端口对外提供服务，以此来改善负载均衡和可用性。在同步推模式里，用户信息会被实时的将该微博插入数据库所有粉丝的订阅列表中，当用户量大时，会使系统响应延迟加剧，性能急剧下降。后来使用异步推拉结合的方式，用户发布微博后系统将微博写入队列后立即返回，消息队列将微博推送给所有当前在线的用户，不在线的用户拉取关注列表订阅微博。这样可以有效的解决该问题。
与此同时，新浪微博还使用多级缓存，使用多个数据中心，开发了一系列的自动化工具，改善了系统的安全性与可用性。

最后，在程序设计与架构设计上，正确的模式始终不是模仿出来的，而是根据实际具体的需求“微创新”出来的，其中的关键，就是对问题和需求是否真正的把握和理解。