大型网站技术架构核心原理剖析

什么是软件架构

*** 定义： 软件架构是指有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计 。

软件架构5大要素：

• 性能
• 可用性
• 伸缩性
• 扩展性
• 安全性

可以通过考察这5大要素来衡量一个软件架构设计的优劣。

高性能

网站性能是客观的指标，具体体现到 响应时间 、 吞吐量 等技术指标。

性能优化的最终目的： 改善用户体验 。

网站性能测试是性能优化的前提和基础，也是性能优化结果的检查和度量标准。

下面从三个视角来看看网站性能的不同标准：

用户视角

网站响应速度快慢（通信时间，处理时间、解析响应数据的时间）。

开发人员视角

关注程序本身及其相关子系统的性能，包括响应延迟、系统吞吐量、并发处理能力、系统稳定性等技术指标。

运维人员视角

关注基础设施性能和资源利用率，如 *** 运营商的带宽能力、服务器硬件配置、数据中心 *** 架构、服务器和网路带宽的资源利用率等。

性能测试指标

网站性能测试的主要指标主要有：

• 响应时间：应用执行一个操作需要的时间（从发出请求开始到收到最后响应数据所需要的时间）。
• 并发数：系统能够同时处理请求的数目，反映了系统的负载特性。。
• 吞吐量：单位时间内系统处理的请求数量，体现系统的整体处理能力。存在一个极限值。
• TPS：每秒事务数
• HPS：每秒HTTP请求数
• QPS：每秒查询数
• 性能计数器：描述服务器或操作系统的一些数据指标。主要包括：
• System Load：系统负载，指当前正在被CPU执行和等待被CPU执行的进程数目总和（反映系统忙闲程度的重要指标）。
• 对象与线程数
• 内存使用
• CPU使用
• 磁盘与 *** I/O

性能测试 ***

性能测试是一个不断对系统增加访问压力，以 获得系统性能指标、更大负载能力、更大压力承受能力的过程。性能测试主要包括以下几种 *** ：

• 性能测试：对系统不断施压，验证系统在资源可以接受范围内，是否能达到预期。
• 负载测试：对系统不断增加并发请求，直到系统的某项或多项性能指标达到安全临界值。
• 压力测试：在超过安全负载的情况下，对系统继续施压，直到系统崩溃或不能再处理请求，已获得系统更大承受能力。
• 稳定性测试：系统在特定的硬件、软件、网路环境条件下，给系统加载一定压力，使系统运行一段较长时间，以检查系统是否稳定。

性能分析与优化

排查网站的性能瓶颈的 *** ：检查请求处理的各个环节的日志，分析哪个环节响应时间不合理、超过预期；然后检查监控数据，分析影响性能的主要因素是内存、磁盘、 *** 还是 CPU，时代吗问题还是架构设置不合理，或者系统资源确实不足。

定位到了性能具体问题后，然后根据性能产生的原因进行性能优化。性能优化主要从三个方面进行优化：

• Web前端性能优化
• 应用服务器性能优化
• 存储服务器性能优化

性能优化策略

Web前端优化

1. 浏览器访问优化

• 减少HTTP请求：分别合并CSS、 *** 、图片等资源，减少浏览器的请求次数。
• 使用浏览器缓存：浏览器将CSS、 *** 、图标等静态资源缓存在浏览器中，那样就不用每次都去请求服务器，可以极好地改善性能。设置HTTP头中 Cache-Control 和 Expires 属性。
• 启用压缩：在服务器端对文件进行压缩，在浏览器端对文件进行解压，可有效减少通信传输的数据量。压缩比80%以上。压缩和解压缩会消耗服务器和浏览器所在的系统的CPU资源。
• CSS放在页面最上面， *** 放在页面最下面：加载 *** 后会立即执行，可能会阻塞页面渲染。
• 减少Cookie传输：减少Cookie中传输的数据量，请求静态资源没有必要发送Cookie。

2. CDN加速

CDN（Content Distribute Network，内容分发 *** ），是指将数据缓存在离用户最近的地方，使用户以最快的速度获取数据，提升网页的打开速度。

CDN适合缓存 静态资源 ，如图片、文件、CSS、脚本、静态文件等。

3. 反向 ***

反向 *** 是指服务器根据客户端的请求，从其关联的一组或多组后端服务器上获取资源，然后再将这些资源返回给客户端，客户端只会得知反向 *** 的IP地址，而不知道在 *** 服务器后面具体的真实服务器的存在。

反向 *** 的作用：

• 安全功能
• 通过缓存配置加速Web请求（静态资源）
• 负载均衡，通过构建集群，提高系统总体处理能力

应用服务器优化

1. 分布式缓存

网站性能优化之一定律： 优先考虑使用缓存优化性能 。

原理：将数据存储在访问速度较高的存储介质中，加快访问速度。

缓存作用：

• 缓存访问速度快，减少数据访问时间
• 缓存计算结果，节省计算的时间

合理使用缓存：

• 缓存读写比高，变化少的数据
• 尽量缓存热点数据
• 确保数据有效性，根据业务场景，选择是否能容忍数据一定时间内不一致，还是及时更新
• 对缓存设置失效时间，缓存数据丢失或者不可用，会从数据库直接获取数据
• 缓存预热：在缓存启动的时候就把热点数据加载好。
• 避免缓存穿透：将不存的数据也缓存起来。

2. 异步操作

使用消息队列将调用异步化，以改善网站的性能。

使用消息队列后，用户请求的数据发送给消息队列后就立即返回，再由消息队列的消费者从消息队列中获取数据，再进行逻辑处理（如写入数据库）。

3. 使用集群

使用负载均衡技术为应用构建一个由多台服务器组成的服务器集群，将并发访问请求分发到多台服务器上处理，避免单一服务器因负载压力过大而响应缓存，降低用户请求响应延迟，提升用户体验。

4. 代码优化

代码优化主要关注以下几个方面：

• 多线程：涉及线程安全问题，多线程并发对某个资源进行修改，解决办法：
• 将对象设计为无状态对象
• 使用局部对象
• 并发访问资源时使用锁
• 资源复用：减少开销较大的系统资源的创建和销毁，如数据库连接、 *** 通信连接、线程、复杂对象等。
• 单例（Singleton）
• 对象池（Object Pool）
• 数据结构
• 垃圾回收

存储性能优化

磁盘是系统最严重的瓶颈。

1. 机械硬盘 & 固态硬盘

在网站应用中，大部分应用访问数据都是随机的，机械硬盘由于需要移动磁头臂，所以性能较差。SSD具有更好的性能。

2. B+树 & L *** 树

为了改善数据访问特性，文件系统或数据库系统通常会对数据排序后存储，以加快检索速度，这样就需要保证数据在不断更新、插入、删除后依然有序。

传统关系数据库使用B+树，B+树是一种专门针对磁盘而优化的N叉排序树，以树节点为单位存储在磁盘中，从根开始查找所需数据所在的节点编号和磁盘位置，将其加载到内存中然后继续查找，直到找到所需的数据。

L *** 树是一个N阶合并树。数据的插入、修改和删除都是在内存中进行，并且都会创建一个新记录，这些数据在内存中以树结构排序，当数据量超过设定的阈值后，会和磁盘上最新的的排序树合并。在合并的过程中，会用最新更新的数据覆盖旧的数据。读操作先从内存中排序树开始搜索，如未找到，再从磁盘上排序树顺序查找。

在L *** 树上进行一次数据更新不需要磁盘访问，在内存即可完成，速度远快于B+树。

对于写多，集中读最近写入数据的场景，使用L *** 树可以极大的减少磁盘的访问次数，加快访问速度。

3. RAID & HDFS

RAID

廉价磁盘冗余阵列，主要是为了改善磁盘的访问延迟，增强磁盘的可用性和容错能力。

多块磁盘通过使用RAID技术，实现数据在多块磁盘上的并发读写和数据备份。

常用RAID技术：

• RAID0：在写的时候，根据磁盘数量将数据分成N份，并发写入N块磁盘。在读的时候，从N块磁盘上并发读。RAID0具有极快的数据读取速度，但是未做备份。
• RAID1：数据写入的时候，将一份数据同时写入两块磁盘，一块磁盘损坏不会导致数据丢失，插入新磁盘可以通过复制数据方式自动修复，可靠性高。
• RAID10：将所有磁盘平均分成两份，数据同时在两份磁盘写入，结合RAID0和RAID1两种方案，既提高了可靠性又改善了性能，但是RAID10的磁盘利用率较低，一般磁盘用来备份数据。
• RAID3：数据写入的时候，将数据分成N-1份，并发写入N-1块磁盘，并在第N块磁盘记录校验数据，任何一块磁盘损坏（包括校验数据磁盘），都可以利用其它N-1块磁盘的数据修复。在数据修改较多的场景，会导致第N块磁盘频繁重写校验数据，容易造成磁盘损坏，所以一般少在实践中使用。
• RAID5：与RAID3类似，但是校验数据是螺旋写入所有磁盘，避免频繁写一块盘。
• RAID6：与RAID5类似，数据值写入N-2块磁盘，螺旋式地在两块磁盘中写入校验信息（不同算法），数据可靠性更高。

HDFS

系统在整个存储集群的多台服务器上进行数据并发读写和备份。HDFS以块（Block）为单位管理文件内容，一个文件被切分成多个Block，当应用程序写文件时，每写完一个Block，HDFS会将其自动复制到另外两台机器上，保证3副本（默认）。在处理文件的时候（MapReduce），可以同时启动多个任务并行读取文件的不同Block，并发处理，提升读取效率。

HDFS配置MapReduce等并行计算框架进行大数据处理时，可以在整个集群上并发读写访问所有的磁盘安，无需RAID支持。

高可用

网站的可用性描述 网站可有效访问 的特性。

可用性度量：服务7*24可用，可用性超过99.99%。

网站不可用时间（故障时间） = 故障修复时间点 - 故障发现（报告）时间点
网站年度可用性指标=（1-网站不可用时间/年度总时间）*100%

硬件故障是常态，网站的高可用架构设计主要目的： 保证服务器硬件故障时服务依然可用、数据依然能保存并能被访问 。

高可用架构的主要手段：数据和服务 冗余备份 及 失效转移 。

一个典型的网站设计通常遵循三层架构模型：

• 应用层：负责具体业务逻辑处理
• 服务层：负责提供可复用的服务
• 数据层：负责数据的存储于访问

高可用的应用

应用的显著特点：无状态性。

无状态应用是指应用服务器不保存业务的上下文信息，仅根据每次请求提交的数据进行相应的业务逻辑处理。多个服务器实力之间完全对等，请求提交到任意服务器，处理结果都是完全一样的。

通过负载均衡进行无状态服务的失效转移

通过负载均衡手段，将流量和数据均匀分配到一个集群组成的多台服务器上，以提高系统的整体负载处理能力。

应用服务器集群的Session管理

Session管理手段：

1. Session复制应用服务器开启Web容器的Session复制功能，在集群中的几台服务器之间同步Session对象，使得每台服务器上都保存所有用户的Session信息，这样任何一台机器宕机都不会导致Session数据的丢失。适合小规模集群。当集群比较大时，集群服务器间需要大量的通信进行Session复制，会占用大量服务器和 *** 资源。

2. Session绑定利用负载均衡的源地址Hash算法实现，负载均衡服务器总是将来源于同一IP的请求分发到同一台服务器上，也可以根据Cookie信息将同一个用户的请求总是分发到同一台机器上，这样在整个会话期间没用户所有的请求都在同一台服务器上处理，即Session绑定在某台特定服务器上，又称 会话黏滞 。

缺点：不符合对系统高可用的需求，某台服务器宕机，那么该机器上的Session会丢失。很少使用。

3. 利用Cookie记录Session

利用浏览器支持的Cookie记录Session。每次请求的时候，将Session放在请求中发送到服务器，服务器处理完请求之后再将修改过的Session响应给客户端。

缺点：受Cookie大小限制，记录信息有限；每次请求都需传输Cookie，影响性能；如用户关闭Cookie，访问就会异常。

4. Session服务器

利用独立部署的Session服务器集群统一管理Session，应用服务器每次读写Session时，都访问Session服务器。

将应用服务器的状态分离，分为无状态的应用服务器和有状态的Session服务器，针对这两种服务器的不同特性分别设计其架构。

Session服务器实现：分布式缓存、数据库等。

高可用的服务

高可用的服务模块为业务产品提供 基础公共服务 ，一般是 独立部署 。

高可用的服务策略：

1. 负载均衡

通过负载均衡的失效转移策略实现高可用。

2. 分级管理

根据应用和服务的重要程度进行分级管理，不同重要程序的服务使用不同的硬件资源，越重要的的服务使用越好的硬件资源。核心服务和数据部署在不同地域的数据中心。

3. 超时设置

设置服务调用的超时时间，一旦超时，通信框架抛出异常，应用程序根据服务调度策略，选择继续重试或将请求转移到相同服务的其他服务器上。

4. 异步调用

应用对服务的调用通过消息队列等异步方式完成，避免一个服务失败导致整个应用请求失败。

5. 服务降级

网站访问高峰期，服务可能因为大量的并发调用而性能下降，严重时可能会导致服务宕机。为了保证核心应用和功能的正常运行，对服务进行降级。

降级手段：

• 拒绝服务：拒绝低优先级应用的调用，减少服务调用并发数，确保核心应用正常使用；或随机拒绝部分请求调用，节约资源。
• 关闭服务：关闭部分不重要的服务，或者服务内部关闭部分不重要的功能，节约系统开销，重要功能让出资源。

6. 幂等性设计

服务层必须保证重复调用和调用一次产生的结果相同，即服务具有幂等性。

高可用的数据

1. CAP

为了保证数据的高可用，会牺牲 数据一致性 。

高可用的数据含义：

• 数据持久性：保证数据持久存储，不会出现数据丢失的问题。
• 数据可访问性：在多份数据副本分别存放在不同存储设备的情况下，一个数据存储设备损坏需要将数据访问切换到其他数据存储设备上。
• 数据一致性：多副本之间数据一致。

CAP原理：一个提供数据服务的存储系统无法同时满足 数据一致性(Consistency) 、 数据可用性(Availibility) 、**分区耐受性(Partition Tolerance，系统具有跨 *** 分区的伸缩性)**这三个条件。

在大型网站应用中，数据规模总是快速扩张的，因此可伸缩即分区耐受性必不可少，规模变大以后，机器数量也会变得庞大，这是网路和服务器故障会频繁吹安，要想保证应用可用，就必须保证分布式处理系统的高可用。所以在大型网站中，通常会选择强化分布式存储系统的可用性（A）和伸缩性（P），而在某种程度上放弃一致性（C）。

数据不一致出现原因：系统高并发写操作或者集群状态不稳定（故障恢复、集群扩容）。

数据一致性分为：

• 数据强一致：各副本的数据在物理存储中总是一致的；数据更新操作结果和操作响应总是一致的，即操作响应通知更新失败，那么数据一定没有被更新，而不是出于不确定状态。
• 用户数据一致：数据在物理存储中的各个副本的数据可能是不一致的，但终端用户访问时，通过纠错和校验机制，可以确定一个一直的且正确的数据返回给用户。
• 数据最终一致：物理存储的数据可能不一致，终端用户访问到数据可能不一致，但系统经过一段时间的自我恢复和修正，数据最终达到一直。

保证数据存储高可用的手段：

2. 数据备份

保证数据有多个副本，任意副本的失效都不会导致数据的永久丢失，从而实现数据完全的持久化。

数据备份方式：

• 冷备：简单、廉价、成本和技术难度低。缺点不能保证数据最终一致。
• 热备：
• 异步热备：多份数据副本的写入操作异步完成。
• 同步热备：多份数据副本的下入操作同步完成。

3. 失效转移机制

保证当一个数据副本不可访问时，可以快速切换访问数据的其他副本，保证系统可用。

失效转移操作组成：

• 失效确认：通过 心跳检测 和 应用程序访问失败报告 判断服务器是否宕机
• 访问转移：将数据的读写访问重新路由到其他服务器（不路由到宕机的服务器）
• 数据恢复：从健康的服务器复制数据，将数据副本数目恢复到设定值

高可用网站的软件质量保证

为了保证线上系统的可用性采取的一些质量保证手段：

• 网站发布：每次关闭服务器中的一小部分，并在发布完成后立即可以访问。
• 自动化测试：Selenium自动化测试工具。
• 预发布验证：先发布到预发布机器上，然后进行预发布验证，验证典型的业务流程，确认没有问题后正式发布。
• 代码控制：主干开发、分支发布；分支开发，主干发布。工具：SVN，Git。
• 自动化发布：火车发布模型。
• 灰度发布：将集群服务器分成若干部分，每天只发布一部分服务器，观察运行是否稳定，第二天继续发布一部分服务器。

网站运行监控

监控数据采集

• 用户行为日志收集
• 服务器端日志收集
• 客户端浏览器日志收集
• 服务器性能监控
• 系统Load
• 内存占用
• 磁盘
• *** IO
• 运行数据报告：监控一些与具体业务场景相关的技术和业务指标。

监控管理

需要根据实时监控数据进行风险预警，并对服务器进行失效转移，自动负载调整，更大化利用集群所有机器资源。

• 系统报警：对超过阈值的指标进行报警，如邮件、短信、语音等。
• 失效转移：发现故障主动通知应用，进行失效转移。
• 自动优雅降级：为应对访问高峰，主动关闭部分功能，释放部分系统资源，保证网站核心功能正常访问。

可伸缩

伸缩性是指通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长大数据存储需求。

衡量架构伸缩性标准：

• 是否可以用多台服务器构建集群
• 是否容易向集群中添加新的服务器
• 加入新的服务器后是否可以提供和原来的服务无差别的服务
• 集群中可容纳的服务器数量是否有限制

网站的伸缩性设计分类

网站的伸缩性设计主要分成以下两类：

1. 根据功能进行物理分离实现伸缩

通过物理上分离不同的网站功能，实现网站伸缩性的手段，可以在网站发展的任何阶段使用。不同服务器部署不同的服务，提供不同的功能。

分离主要分为两种情况：

• 纵向分离（分层后分离）：将业务处理流程上的不同部分分离部署，实现系统伸缩性。
• 横向分离（业务分割后分离）：将不同的业务模块分离部署，实现系统伸缩性。

2. 单一功能通过集群实现伸缩

随着网站访问量的逐步增加，单一的服务器也不同满足业务规模的要求，需要使用服务器集群，将相同服务部署在多台服务器上构成一个集群整体对外提供服务。

应用服务器集群的伸缩性设计

负载均衡技术

1. HTTP重定向负载均衡

利用HTTP重定向协议实现负载均衡。

HTTP重定向服务器会根据用户的HTTP请求计算一台真实的Web服务器地址，并将该Web服务器地址写入HTTP重定向响应（响应状态码302）中返回给用户浏览器，浏览器自动重新请求实际物理服务器。

优缺点：

• 优点：实现简单
• 缺点：浏览器需要两次请求服务器才能完成一次访问，性能较差；重定向服务器自身处理能力会成为瓶颈；使用302重定向，可能会让搜索引擎判断为SEO作弊，降低搜索排名。

HTTP重定向负载均衡在实际生产环境中很少使用。

2. DNS域名解析负载均衡

通过DNS处理域名解析请求的同时进行负载均衡处理的一种方案。

每次域名解析请求都会根据负载均衡算法计算一个不同的IP地址返回，可以将请求分布到多台服务器上，实现负载均衡。

优缺点：

• 优点：将负载均衡的工作转交给DNS，省去了网站管理维护负载服务器的麻烦；DNS还支持基于地理位置的域名解析，会将域名解析成距离用户地理最近的一个服务器地址，从而加快用户访问速度，改善性能。
• 缺点：DNS是多级解析，每级DNS都会缓存服务器配置，修改了DNS配置，需要较长时间才能生效。

DNS域名解析一般作为之一级负载均衡。

3. 反向 *** 负载均衡

利用反向 *** 服务器进行负载均衡。

优缺点：

• 优点：和 *** 服务器集成简单
• 缺点：反向 *** 服务器是所有请求和响应的中转站，其性能可能会成为瓶颈。

4. IP负载均衡

在 *** 层通过修改请求目标地址进行负载均衡。在内核进程中完成数据分发，性能较好。集群的更大响应数据吞吐量受制于负载均衡服务器网卡带宽。

5. 数据链路层负载均衡

在通信协议的数据链路层修改mac地址进行负载均衡。Linux平台更好的链路层负载均衡开源产品 LVS 。

负载均衡算法

1. 轮询（Round Robin，RR）

所有请求被依次分发到每台应用服务器上，即每台服务器需要处理的请求数目都相同，适合于所有服务器硬件都相同的场景。

2. 加权轮询（Weight Round Robin，WRR）

根据应用服务器硬件性能的情况，在轮询的基础上，按照配置的权重将请求分发到每个服务器，性能高的服务器分配更多请求。

3. 随机（Random）

请求被随机分配到各个应用服务器。实现简单。

4. 最少连接（Least Connections）

记录每个应用服务器正在处理的连接数（请求数），将新到的请求分发到最少连接的服务器上。更符合负载均衡定义的算法。

5. 源地址散列（Source Hashing）

根据请求来源IP地址进行Hash计算，得到应用服务器，这样来自同一个IP地址的请求总在同一个服务器上处理，该请求的上下文信息可以存储在这台服务器上，在一个会话内重复使用，从而实现会话黏滞。

分布式缓存集群的伸缩性设计

分布式缓存服务器集群中不同服务器中缓存的数据各不相同，缓存访问请求不可以在缓存服务器集群中的任意一台处理，必须先找到缓存有需要数据的服务器，然后才能访问。

缓存的目的： 加速数据读取的速度 并 减轻数据存储服务器的负载压力 。

分布式缓存集群伸缩性设计的主要目标：新加入缓存服务器应使整个缓存服务器集群中已经缓存的数据尽可能还被访问到。

一致性哈希算法

一致性Hash算法通过一致性Hash环的数据结构实现Key到缓存服务器的Hash映射。

算法过程：先构造一个长度为 0~的整数环（一致性Hash环），根据节点名称的Hash值（ 范围0~）将缓存服务器节点放置在这个Hash环上。然后根据需要缓存的数据的Key值计算得到其Hash值，然后再Hash环上顺时针找距离这个Key的Hash值（范围 0~）最近的缓存服务节点，完成Key到服务器的Hash映射查找。

扩容的时候，将新加入的节点的Hash放入一致性Hash环中，由于Key是顺时针查找距离最近的节点，因此新加入的节点只影响整个换中的一小段。

解决一致性Hash算法带来的负载不均衡的问题

将每台物理缓存服务器虚拟为一组虚拟缓存服务器，将虚拟服务器的Hash值放置在Hash环上，Key在换上先找到虚拟服务器节点，在得到物理服务器的信息。这样新加入的物理服务器节点是一组虚拟节点，如果虚拟节点足够多的，这组虚拟节点将会影响同样多数目的已经在环上存在的虚拟节点。

物理节点对应的虚拟节点越多，各个物理节点之间的负载越均衡，新加入物理服务器对原有的物理服务器的影响越保持一致。

根据经验，一台物理服务器虚拟为150个虚拟服务器节点。

数据存储服务器集群的伸缩性设计

数据存储层必须保证数据的可靠存储，任何情况下都必须保证数据的 可用性 和 正确性 。

1. 关系数据库集群的伸缩性设计

架构设计：主从架构、主从读写分离、主从复制、分库

分库：不同业务数据表部署在不同的数据库集群上。缺点：夸库不能Join。

2. NoSQL数据库的伸缩性设计

NoSQL数据库产品都放弃了关键数据库的两大重要基础：

• 以关系代数为基础的结构化查询语言（SQL）
• 事务一致性保证（ACID）

NoSQL更关注： 高可用性 和 可伸缩性

可扩展

软件设计的终极目标： 低耦合 系统。

低耦合系统更容易扩展，低耦合模块更容易复用，低耦合的系统设计会让开发过程和维护变得更加轻松和容易管理。

主要目的：网站的架构能够快速响应需求变化。

可扩展架构的核心思想： 模块化，并在此基础之上，降低模块间的耦合性，提高模块的复用性。

衡量标准：网站增加新的业务产品时，是否可以实现对现有产品透明无影响，不需要任何改动或者很少钙能既有业务功能就可以上线新产品。不同产品之间低耦合。

网站可伸缩架构主要手段是 事件驱动架构 和 分布式服务 。

利用分布消息队列降低系统耦合性

事件驱动架构

事件驱动架构（Event Driven Architecture）：通过在低耦合的模块之间传输事件消息，以保持模块的松散耦合，并借助事件消息的通信完成模块间合作。如生产者消费者模式。

常用的事件驱动架构：分布式消息队列。

利用消息队列，将用户请求和其他业务事件构造成消息发布到消息队列，消息的处理者作为消费者从消息队列中获取消息进行处理。通过这种方式将消息产生和消息处理分离开来，可以透明地增加新的消息生产者任务或者新的消息消费者任务。

分布式消息队列

消息 生产者 应用程序通过远程访问接口将 消息 推送 给 消息队列服务器 ，消息队列服务器将消息写入本地内存队列后即立即返回成功响应给消息生产者。消息队列服务器根据消息订阅列表查找订阅该消息的消息消费者应用程序，将消息队列中的消息按照 先进先出 的原则将 消息 通过远程通信接口发送给消息 消费者 程序。

利用分布式服务打造可复用的业务平台

将业务和可复用服务分离开来，通过分布式服务框架调用。

巨无霸应用存在问题：

• 编译、部署困难
• 代码分支管理困难
• 数据库连接耗尽
• 新增业务困难

解决方案就是 拆分 ，将模块独立部署，降低系统耦合性。

• 纵向拆分：将一个大应用拆分为多个小应用，如果新增业务比较独立，那么就直接将其部署为一个独立的应用系统。
• 横向拆分：将复用的业务拆分开来，独立部署为分布式服务，新增业务只需调用这些分布式服务，不需要依赖具体的模块代码。

大型网站分布式服务的需求和特点

• 服务注册与发现
• 服务调用
• 负载均衡
• 失效转移
• 高效的远程通信
• 整合异构系统
• 对应用最少侵入
• 版本管理
• 实时监控

利用开放平台建设网站生态圈

• API接口：Restful、WebService、RPC等
• 协议转换：将各种API输入转换成内部服务可以识别的形式，并将内部服务的返回封装成API的格式。
• 安全：身份识别、权限控制、分级的访问带宽限制。
• 审计：记录第三方应用的访问情况，并进行监控、计费等。
• 路由：将开放平台的耕种访问路由映射到具体的内部服务。
• 流程：将一组离散的服务组织成一个上下文相关的新服务，隐藏服务细节，提供统一接口供开发者调用。

安全性

安全性是指保护网站不受恶意访问和攻击，保护网站的重要数据不被窃取。

衡量标准：针对现存和潜在的各种攻击与窃密手段，是否有可靠的应对策略。

网站攻击和防御

XSS攻击

XSS攻击即 跨站点脚本攻击 （Cross Site Script），指黑客通过篡改网页，注入恶意HTML脚本，在用户浏览网页时，控制用户浏览器进行恶意操作的一种攻击方式。常见攻击类型有：

• 反射型：攻击者诱使用户点击一个嵌入恶意脚本的连接，达到攻击目的。
• 持久型：黑客提交含有恶意脚本的请求，保存在被攻击的Web站点的数据库中，用户浏览网页时，恶意脚本被包含在正常页面中，达到攻击的目的。

XSS防攻击手段：

• 消毒：对html危险字符进行转义。消毒几乎是所有网站最必备的XSS防攻击手段。
• HttpOnly：浏览器进制页面JavaScript访问带有HttpOnly属性的Cookie。HttpOnly主要是防止XSS攻击者窃取Cookie。

注入攻击

注入攻击主要由 SQL注入攻击 和 OS注入攻击 两种。

SQL注入攻击

攻击者在HTTP请求中注入恶意SQL命令，服务器用请求参数构造数据库SQL命令（如删除数据库表）时，恶意SQL被一起构造，并在数据库中执行。

SQL注入攻击前提：攻击者需要对要攻击的数据库结构有所了解。

攻击者获取数据库表结构信息手段：

• 开源：开源软件搭建的网站数据结构是公开的。
• 错误回显：攻击者可以通过服务端返回的异常信息，猜测数据库表结构。
• 盲注：攻击者根据页面变化情况判断SQL语句的执行情况，猜测数据库表结构。

防御

首先应避免被攻击者猜测到表名等数据库表结构信息。

除此之外还有以下两种方式：

• 消毒：通过正则匹配过滤请求数据中可能注入的SQL。请求参数消毒是一种比较简单粗暴又有效的手段。
• 参数绑定：使用预编译手段，绑定参数是更好的防SQL注入 *** 。

CSRF攻击

CSRF（Cross Site Request Forgery， 跨站点请求伪造 ），指的是攻击者通过跨站请求，以合法用户的身份进行非法操作，如转账交易、发表评论等。

CSRF攻击的主要手法：利用跨站请求，在用户不知情的情况下，以用户的身份伪造请求。

核心是利用了浏览器Cookie或服务器Session策略，盗取用户身份。

CSRF攻击防御主要手段是 识别请求者身份 。主要有下面几种 *** ：

• 表单Token：通过在请求参数中增加随机数的 *** 来阻止攻击者获得所有请求参数。正常请求会包含token随机数，每次请求都不一样，伪造请求无法获得该值，服务器检查请求参数中token的值是否存在并且正确以确定请求提交者是否合法。
• 验证码：在请求提交时，需要用户输入验证码，以避免在用户不知情的情况下被攻击者伪造请求。但是输入验证码是一个很糟糕的用户体验。
• Referer Check：通过检查HTTP请求的Referer域中记录的请求来源，验证其是否合法。常见场景如：图片防盗链。

其他攻击和漏洞

1. Error Code

错误回显，指的是服务器端未处理异常堆栈信息直接输出到客户端浏览器。

防御：配置web服务器参数，跳转500页面到指定的错误页面，避免将异常堆栈信息直接返回给用户。

2. HTML注释

在浏览器中是可以看到HTML代码中注释的部分，这样会给黑客造成攻击便利。

防御：程序在最终发布前需要进行代码review或自动扫描，避免HTML注释漏洞。

3. 文件上传

攻击方式：上传一个可执行的程序，并通过该程序获得服务器端命令执行能力。

防御：设置上传文件白名单，只允许上传可靠的文件类型。此外还可以修改文件名、使用专门的存储等手段，保护服务器免受上传文件攻击。

4. 路径遍历

攻击方式：攻击者在请求的URL中使用相对路径，遍历系统为开放的目录和文件。

防御：将 *** 、CSS等资源文件部署在独立服务器，使用独立域名，其他文件不适用静态URL访问，动态参数不包含文件路径信息。

信息加密技术及密钥安全管理

为了保护网站的敏感数据，需要对这些敏感数据进行加密处理，信息加密技术分为三类：

单向散列加密

通过对不同输入长度的信息进行散列计算，得到固定长度的输出，散列计算是单向的，即不能对固定长度的输出进行计算从而获得输入信息。

使用场景：密码加密保存，生成信息摘要，计算具有高离散程度的随机数等。

常用单向散列算法：MD5、SHA等。

对称加密

加密和解密使用的密钥是同一密钥（或者可以互相推算）。

使用场景：Cookie加密，通信加密等。

优缺点：

• 优点：算法简单，加密效率高，系统开销小，适合对大量数据加密。
• 缺点：加解密使用同一个密钥。

常用对称加密算法：DES、RC算法。

非对称加密

加密和解密使用的密钥不同，其中一个对外界公开，叫做 公钥 ，另一个只有所有者知道，被称为 私钥 。用公钥加密的信息必须用私钥才能解开，反之，用私钥加密的信息只有公钥才能解开。理论上不可能通过公钥计算获得私钥。

使用场景：信息安全传输，数字签名等。

常用非对称加密算法：RSA算法。

HTTPS传输中浏览器使用的数字证书就是经过权威机构认证的非对称加密的公钥。

信息过滤与反垃圾

常用的信息过滤与反垃圾手段有以下几种：

文本匹配

主要用来解决敏感词过滤问题。

快速判断信息中是否包含敏感词 *** ：

• 正则匹配：适用于敏感词较少，信息文本较短场景。正则表达式的效率一般较差。
• Trie树及变种：算法本质是确定一个有限状态的自动机，根据输入数据进行状态转移。

分类算法

算法原理：先将批量已经分好类的样本数据输入分类算法进行训练，可以得到一个分类模型，然后再利用分类算法结合分类模型对待处理邮件进行识别。

简单实用的分类算法：贝叶斯分类

实用场景：反垃圾、信息自动分类等

黑名单

将需要过滤的内容加入到黑名单中，然后从黑名单中进行查找，如果找到，就过滤掉。

常用数据结构：Hash表、BloomFilter。

电子商务风险控制

交易安全是电子商务网站的底线。

风险

主要风险：

• 账户风险：如账户被黑客盗用、恶意注册账号等。
• 买家风险：买家恶意下单占用库存进行不正当竞争；黄牛利用促销抢购低价商品。
• 卖家风险：不良卖家进行恶意欺诈。
• 交易风险：信用卡盗刷、支付欺诈、洗钱套现等。

风控

风控手段包括 自动 和 人工 两种。

自动风控技术：

• 规则引擎：将 业务规则 和 规则处理逻辑 分离的技术。缺点：规则冲突，难以维护，规则越多性能越差。
• 统计模型：使用统计模型进行风险控制。分类算法或者更复杂的机器学习算法。

来源：博客，欢迎分享本文！