大型网站技术架构（一）架构模式

大型网站技术架构（一）架构模式

一、引入——新浪微博中的架构模式

新浪微博最初也是通过LAMP支撑起来的：应用程序用PHP开发，所有的数据（包括微博、用户、关系都存储在MySQL数据库中），网站部署在Apache服务器上，操作系统为Linux。然而这样简单的架构无法支撑快速发展的业务需要，随着用户不断增加、系统不堪重负，最后形成如下的架构：

1.系统分为三个层次：
1）最下层是基础服务层，提供了数据库、缓存、存储、搜索引擎等数据服务，以及其他一些技术服务，这些服务支撑了新浪微博海量数据和高并发访问，是整个系统的技术基础。
2）中间层是平台服务和应用服务层。新浪微博的核心服务是微博、关系和用户，这些服务被分割成独立的服务模块，通过依赖调用和共享基础数据构成新浪微博的业务基础。
3）最上层是API和新浪微博的业务层，各种客户端（包括Web网站）和第三方应用，通过调用API集成到新浪微博系统中，共同组成一个生态系统。

2.采用集群与分布式部署：
这些被分层和分割后的业务模块和基础技术模块分布式部署，每个模块都部署在一组独立的服务器集群上，通过远程调用的方式进行依赖访问。分布式集群部署方案如MPSS（单服务器多端口：集群中的多台服务器上，每台都部署多个服务，每个服务采用不同的端口对外提供服务）在节末的拓展阅读中具体说明。

3.异步和缓存：
1）异步：
新浪微博早期架构中，采用同步推模式，用户发表微博后系统会立即将该微博插入到数据库所有粉丝的订阅列表，当用户量比较大特别是明星用户发布微博时，会引起大量的数据库写操作，超出负载，性能下降，造成用户延迟响应加剧。
后来采用异步推拉结合模式，用户发表微博后将该微博写入消息队列后立即返回，用户响应迅速；消息队列消费者任务将微博推送给所有当前在线粉丝的订阅列表中，非在线用户登录后根据关注列表拉取微博订阅列表。
2）缓存
由于微博频繁更新，新浪微博使用多级缓存策略，热门微博和明星用户的微博缓存在所有的微博服务器上；在线用户的微博和近期微博缓存在分布式缓存集群中。对于微博中最常见的“刷微博”操作，基本都是缓存访问操作，可以获得很好的系统性能。

4.冗余、自动化以及安全：
1）为了提高系统整体可用性和性能，新浪微博采用多个数据中心，用户可以就近访问最近的数据中心以加快访问速度，改善系统性能；同时也是数据冗余复制的灾备中心，所以用户和微博数据通过远程消息系统在不同的数据中心之间同步提高系统的可用性。
2）同时，新浪微博还开发了一系列自动化工具，包括自动化监控、自动化发布、自动化故障修复等。改善运维水平提高系统可用性。
3）由于微博的开放特性，新浪微博也遇到诸如垃圾内容、僵尸粉、微博攻击等安全问题，新浪微博在开放平台使用多级安全审核的策略以保护系统和用户。

总结体会：
分析网站架构模式时，可以将以下两种线索相结合进行分析说明
①技术路线，即架构模式路线：分层、分割——集群、分布式——异步、缓存——冗余、自动化安全等。
②应用功能和性能路线：应用程序层次由底向上功能服务技术介绍——部署——性能优化方案——系统整体状况，核心架构要素分析（如：可用性、伸缩性等）

拓展阅读：新浪微博架构分析和设计
https://blog.csdn.net/coolham/article/details/6583615
https://blog.csdn.net/bigtree_3721/article/details/79779249

二、 架构模式

2.1 分层

1.分层是企业应用系统最常见的一种架构模式，将系统在横向维度切分成几个部分，每个部分负责一部分相对比较单一的职责，然后通过上层对下层的依赖和调用组成一个完整的系统。
2.分层架构也有一些挑战，就是必须合理规划分层边界和接口，在开发过层中，严格遵循分层架构的约束，禁止跨层次调用及逆向调用。当然，大的分层结构内部还可以继续分层（如服务层可以分为数据接口层和逻辑处理层、应用层可以细分为视图层和业务逻辑层。）

3.一般将网站软件系统分为应用层、服务层、数据层三层。

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

拓展阅读：对分层的理解
https://blog.csdn.net/wqhlmark64/article/details/79918424

2.2 分割

如果所分层是将软件进行横向方面进行切分，分割就是在纵向对软件进行切分。
网站越大，功能越复杂，服务和数据处理的种类也就越多，将这些不同的功能和服务进行分割开来，包装成高内聚低耦合的模块单元，有助于开发维护，也有助于提高网站的并发处理能力和功能扩展能力。
大型网站分割的粒度可能会很小，比如在应用层，将不同业务进行分割，例如将购物、论坛、搜索、广告分割成不同的应用，由独立的团队负责部署在不同的服务器上。

2.3 分布式

1.分层、分割的一个主要目的是为了切分后的模块便于分布式部署，即将不同模块部署在不同的服务器上。
2.分布式意味着，可以使用更多的计算机来完成原本的功能，计算机越多，CPU、内存、存储资源也就越多，能够处理的并发访问和数据量就越大，进而能够为更多的用户提供服务。

3.但分布式也带来了其他问题：
首先，分布式意味着服务调用必须通过网络，可能会对性能造成比较严重的影响。
其次，服务器越多，服务器宕机的可能性越大，网站可用性降低；
另外，数据在分布式环境中数据一致性、分布式事务都很难保持。当然，开发管理维护也会变得复杂。

4.网站应用中分布式方案有以下几种：

分布式应用和服务	将分层和分割后的应用和服务模块分布式部署。 优点：可以改善网站性能和并发性，加快开发和发布速度，减少数据库连接资源的消耗，也因服务复用等因素便于业务功能扩展
分布式静态资源	网站的静态资源如JS、CSS、Logo图片等资源独立分布式部署，并采用独立的域名，即常说的动静分离。 优点：可以减轻应用服务器负载压力；通过使用独立域名加快浏览器并发加载的速度
分布式数据和存储	将海量数据进行分布式存储：传统关系型数据库进行分布式部署；为网站应用而生的各种NoSQL产品几乎都是分布式的
分布式计算	严格来说，应用、服务、实时数据处理都是计算。除此之外还有如搜索引擎索引构建、数据库仓库的数据分析统计之类的后台业务要处理，这些业务计算量庞大，目前普遍使用Hadoop及其MapReduce分布式计算框架进行批处理计算。特点是移动计算而不是移动数据：将计算程序分发到数据所在的位置以加速计算和分布式计算

2.4集群

1.使用分布式虽然已经将分层和分割后的模块独立部署，但是对于用户访问集中的模块（如网站首页），还需要将独立部署的服务器集群化，即多台服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务。
2.因服务器集群有更多服务器提供相同服务，因此可以提供更好的并发特性，当有更多用户访问时，只需要向集群中加入新的机器即可。同时因为一个应用由多台服务器提供，当某台服务器发生故障时，负载均衡设备或者系统的失效转移机制会将请求转发到其他服务器上，使服务器故障不影响用户使用。使用集群可以提高系统的可用性。

2.5缓存

1.缓存就是将数据存放在距离计算最近的位置以加快处理速度，其本质是一个内存hash表。
2.网站数据访问通常遵循二八定律：80%的访问落在20%的数据上，因此利用Hash表和内存的高速访问特性，将这20%数据缓存起来，可以提高数据读取速度，降低存储访问压力。
3.缓存是改善软件性能的第一手段，使用缓存有两个前提条件：
①数据访问热点不平衡：会被更频繁访问的数据应该放在缓存中。
②数据在某个时间段内有效，不会很快过期：否则会因数据失效引起脏读，影响正确性。
4.大型网站架构设计在很多方面都使用了缓存设计：

本地缓存	在应用服务器本地缓存着热点数据，应用程序可以在本机内存直接访问这些数据，而无需访问数据库
分布式缓存	本地缓存缓存数据有限，还需要将数据缓存在一个专门的分布式缓存集群中，应用程序通过网络通信访问缓存数据
CDN	内容分发网络，部署在离终端与用户最近的网络服务商，就近以最快速度返回给用户。缓存内容包括静态资源和访问量大的热点
反向代理	部署在前端，当用户请求到达网站的数据中心时，由反向代理服务器直接返回（无需将请求转发给应用服务器）缓存的静态资源

注：分布式缓存架构方式有两种
①需要更新同步的分布式缓存（JBoss Cache，应用程序和缓存部署在同一台服务器上，集群间的缓存数据进行更新同步）
②不互相通信的分布式缓存（Memcached，缓存与应用分离部署，缓存服务器间不通信，应用程序通过一致性Hash等路由算法选择缓存服务器远程访问的数据）。

个人理解：
 首先通过CDN（最近，网络第一跳）使得服务器最快返回缓存（绝大多数静态资源+部分热点）给用户；
 然后反向（反向：代理服务器一般位于浏览器一侧代理发送http请求）代理，反向代理服务器代理Web服务器，接收用户http请求直接返回对应缓存（静态数据）；
如果还没有，通过负载均衡调度服务器，查看对应服务器中的缓存（本地缓存）；
本地缓存也没有，则在分布式缓存集群中查找。（分布式缓存可以被视为数据层，在三层模型中作为缓存与数据库、存储、搜索引擎等提供数据服务）。

2.6异步

1.异步是除之前提到的分层、分割、分布外的另一重要系统解耦合手段。业务之间的消息传递不是同步调用，而是讲一个业务操作分成几个阶段，每个阶段之间通过共享数据的方式异步执行：
①单一服务器内部可以通过共享内存队列异步。
②分布式系统中，多个服务器通过分布式消息队列（可看作内存队列的分布式部署，架构原理位于书中P125）实现异步。

拓展阅读：
https://blog.csdn.net/lsxf_xin/article/details/80004526 消息队列应用场景和消息中间件示例
https://blog.csdn.net/u014427391/article/details/74436298 分布式消息队列kafka原理简介

2.使用异步消息队列有如下特性
①异步架构是典型的生产者消费者模式，两者不存在直接调用，主要保持数据结构不变，彼此的功能实现可以任意变化而不互相影响，故而异步使得网站拥有更好的扩展性。
②消费者服务器故障时，数据会在消息队列服务器中存储堆积，生产者服务器可以继续处理业务请求，系统整体无故障。消费者服务器恢复正常时，急需处理业务请求。故而异步可以提高网站的可用性。（若消费队列挂了就gg了）
③削峰——消除并发访问高峰。使用消息队列可以将突然增加的访问请求数据放入消息队列中，等待消费者服务器依次处理，就不会对整个网站造成太大压力。
④当然，异步会对业务流程乃至用户体验造成影响，需要网站产品设计方面的支持。

2.7冗余

网站需要7*24小时连续运行，服务器宕机是必然事件。所以要保证服务器宕机下网站仍然可以继续服务，就需要一定程度的服务器冗余运行，数据冗余备份。大型网站还会对整个数据中心进行备份，全球范围内部署灾备数据中心。
①访问和负载很小的服务也必须部署至少两台服务器构成一个集群，通过冗余实现服务高可用。
②数据库除了定期备份、存档实现冷备份外，还需要对数据库主从分离实现热备份（此为异步热备——主存储器异步写入从存储器，同步热备为无主从之分，两者完全等同，同步读写）。

2.8自动化

自动化代码管理、自动化测试、自动化安全监测、自动化部署等。

2.9安全

1.通过密码和手机校验码进行身份验证。
2.登陆、交易等操作需要对网络通信进行加密，网站服务器上存储的敏感数据如用户信息也需要加密处理。
3.为了防止机器人程序攻击 网站使用验证码识别。
4.对于常见的XSS攻击、SQL注入进行编码转换等处理；
5.对于垃圾及信息、敏感信息进行过滤；
6.对于交易转账等重要操作根据交易模式和交信息进行风险控制。

个人记忆方式：
分层分割分布，解耦合，方便扩展、伸缩，方便开发维护。
分布式集群部署（分布式，解耦提高扩展性，集群提高可用性和伸缩性。）
异步、缓存提高性能。（当然，异步解耦也改善网站的扩展性等，主要还是关注性能方面。其他也类似，不细究）。
冗余改善可用性
自动化、安全等其他问题

三、大型网站架构演化发展历程

https://blog.csdn.net/ztx114/article/details/81588064

1.初始阶段
①原始阶段：一台服务器同时部署应用程序、数据库、文件等所有资源。
②应用服务和数据分离。 获得更快的硬盘、更高的内存、更强大的CPU，并发处理能力和数据存储空间得到很大改善。

2.缓存+集群改善性能：
①集群：分担请求，使服务器的并发请求数目控制在最佳运行期间，获得最佳访问请求延时
应用层：应用服务器集群
服务层：分层分割，然后分离出服务，分布式部署。（集群与应用层集群性质一致。）
数据层：分布式缓存集群、存储数据服务器集群（关系型+NoSQL）
注：服务层、数据层的改善实际较晚出现，为归到集群，提到上面一起说明。
②缓存：加快数据访问速度

浏览器缓存	不考虑
前端缓存加速	CDN（最快，网络第一跳）和反向代理（有则直接返回，无需通过应用服务器）
本地缓存	负载均衡服务器进行调度 ，各服务器本地缓存一致
分布式缓存	通过网络通信调用，分布式缓存集群中缓存的数据各不相同

3.数据层：分布式数据库+分布式文件系统+Nosql+搜索引擎
首先数据库读写分离。（注：较早出现，为了统一数据层，归到下面）

分布式数据库
分布式文件系统

Nosql和搜索引擎

4.业务进一步拆分。分割后分布式部署——分布式服务
①.分割后分布式部署，消息队列的应用

②.业务细拆服务提取，分布式服务。