前言

  • 传统的企业应用系统主要面对的技术挑战就复杂凌乱、千变万化人所谓业务逻辑，而大型网站主要面对的技术挑战是处理超大量的用户访问和海量的数据处理；前者的挑战来自功能性需求，后者的挑战来自非功能性需求。既然大型网站架构解决了海量数据的管理和高并发事务的处理，那么就可以把这些解决方案应用到网站自身以外的业务上去。

  • 我们看到目前许多大型网站都开始建设云计算平台，将计算作为一种基础资源出售，中小网站不需要再关心技术架构问题，只需要按需付费，就可以使网丫随着业务的增长逐渐获得更大的存储空间和更多的计算资源。

  • 在网站还很小的时候就去追求网站的架构是舍本逐末，得不偿失和。小型网站最需要做的就是为用户提供好的服务来创造价值，得到用户的认保，活下去，野蛮生长。

大型网站架构演化

架构演化

  • 应用程序、数据库、文件服务器部署在同一台机器
  • 应用程序、数据库、文件服务器独立部署
  • 使用缓存，加速数据读取
  • 应用程序集群化，负载均衡
  • 数据库读写分离
  • CDN加速
  • 分布式文件系统、分布式数据库
  • NoSQL + 搜索引擎
  • 业务拆分，数据库共享
  • 服务化，业务分库

演化价值观

  • 逐步发展、灵活应对
  • 业务驱动技术发展：业务成就技术、事业成就人

误区

  • 追随大公司解决方案：”taobao/facebook就是这么搞的”
  • 为了技术而技术：一味追求新技术，误入崎岖道路
  • 企图用技术解决所有问题：考虑通过业务手段解决业务问题（12306排队机制、调整放票时段，不搞秒杀）

大型网站架构模式

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

  • 面临高并发访问、海量数据处理、高可靠运行等挑战，总结出许多解决方案和可重复的模式，以实现高性能、高可用、易伸缩、可扩展、安全等各种技术架构目标。

分层

定义：将系统在横向维度上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后通过上层对下层的依赖和调用组成一个完整系统。

举例： OSI 7层协议，计算机架构(硬件、OS、应用软件)，网站系统(应用层、服务层、数据层)， MVC。

注意事项：

  • 合理规划层次边界和接口
  • 避免跨层调用
  • 避免逆向调用

分割

定义： 在纵向对软件进行切分。

举例：网站业务拆分(购物、论坛、搜索、广告等)，购物业务拆分(酒店业务、3C业务、小商品业务等)

分布式

目标： 分层和分割后的模块拥有更小的粒度，目的是分布式部署，便于使用更多资源(CPU、内存、存储等)，提供更多服务。

注意事项：

  • 服务间调用通过网络，造成性能影响。
  • 服务器越多，宕机概率越大，服务可用性降低。
  • 数据一致性问题。
  • 依赖复杂。
  • 开发管理苦难。
  • 切莫为了分布式而分布式。

分布式方案：

  • 分布式应用和服务：分层和分割后的应用和服务模块分布式部署。
  • 分布式静态资源：静态资源(JS、CSS、图片等)分布式部署，动静分离。
  • 分布式数据和存储：海量数据存储，分布式NoSQL。
  • 分布式计算：实时计算，搜索引擎、MapReduce分布式计算框架。
  • 分布式配置：服务器配置实时更新。
  • 分布式锁：分布式环境下的并发和协同。
  • 分布式文件系统：云存储。

集群

定义： 多台服务器部署相同应用或模块，通过负载均衡对外提供服务。提高并发性和可用性。

缓存

定义：将数据存放在距离计算最近的位置以加快处理速度。

举例：

  • CDN： 缓存静态资源。
  • 反向代理：缓存静态资源。
  • 本地缓存： 数据缓存在本机内存，减少访问数据库。
  • 分布式缓存： 可以缓存更多地数据。

缓存使用前提：

  • 数据访问热点不均衡。
  • 数据有一段有效期，不会很快过期，否则很容易脏读。

异步

目标：降低系统间耦合性。

类型：

  • 单一服务：多线程共享内存队列。
  • 分布式系统：分布式消息队列。 多个服务器集群通过分面式消息队列实现异步，分布式消息队列可以看作内存队列的分布式部署。

异步消息队列特性：

  • 提高系统可用性：消费者故障不影响生产者继续处理业务请求。
  • 加快网站响应速度： 生产者处理业务请求后将数据写入队列，无需等待消费者处理完毕，减少响应延迟。
  • 消除并发访问高峰：突发事件、促销活动、热点事件。

冗余

目标：数据冗余备份，当某台服务器宕机，可以将其上的服务和数据访问转移到其他机器，提高服务可用性。

类型：

  • 冷备份： 定期备份，存档保存。
  • 热备份： 主从分离，主从同步。
  • 灾备数据中心：实时同步网站程序和数据到多个数据中心，抵抗地震、海啸等不可抗力因素。

自动化

目标：一切自动化。

类型：

  • 自动化代码管理：针对开发，代码版本控制、代码分支创建合并自动化。
  • 自动化测试：自动部署到测试环境，运行测试用例，发送测试报告，反馈测试结果。
  • 自动化安全检查：代码静态安全扫描，安全攻击测试。
  • 自动化部署：自动化部署到生产环境。
  • 自动化监控
  • 自动化报警
  • 自动化失效转移：将失效服务器从集群中隔离。
  • 自动化失效恢复：故障消除后重启服务，同步数据。
  • 自动化降级：遇到访问高峰时拒绝部分请求及关闭部分不重要服务，将系统负载降至安全水平。
  • 自动化分配资源：将空闲资源分配给重要服务，扩大其部署规模。

安全

安全手段：

  • 用密码和手机校验码进行身份认证。
  • 加密通信。
  • 验证码机制防止机器人。
  • 进行编码转换等防止XSS、SQL注入。
  • 垃圾信息、敏感信息过滤。
  • 交易信息进行风险控制。

大型网站架构要素

  • 架构：最高层次的规划，难以改变的决定。

  • 软件架构：有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。除了系统功能需求外，软件架构还需要关注性能、可用性、伸缩性，扩展性、安全性这5个架构要素。

性能

手段

  • 浏览器端： 浏览器缓存、页面压缩、页面布局、减少Cookie传输、CDN等；
  • 应用服务器端：本地缓存、分布式缓存、消息队列、集群，多线程、改善内存管理；
  • 数据库服务器端：索引、缓存、SQL优化，NoSQL(优化数据模型、存储结构、伸缩性);

指标

  • 响应时间
  • TPS
  • 系统性能计数器

可用性

手段：冗余

  • 应用服务器： 负载均衡 + 流量切换；
  • 存储服务器： 实时备份 + 访问转移 + 数据恢复

伸缩性

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

  • 应用服务器： 无状态；
  • 缓存服务器： 改进缓存路由算法。注意严重依赖缓存场景下，缓存失效导致整个网站崩溃；
  • 关系数据库： 需在数据库外实现伸缩性，通过路由分区等手段将多个数据库组成集群；
  • NoSQL：先天为海量数据而生，线性伸缩。

扩展性

标准：

  • 网站快速发展，功能不断扩展，系统架构能够使其快速响应需求变化；
  • 新增业务，对现有产品透明无影响；
  • 产品间很少耦合。

手段：

  • 事件驱动架构：通过消息队列实现，用户请求和其他业务事件是生产者，消息处理者是消费者，可以透明增加新的消息生产者任务或者消费者任务；
  • 分布式服务：将业务和可复用服务分离开来，通过分布式服务框架调用。新增产品可以通过调用可复用的服务实现自身业务逻辑。可复用服务升级变更时，通过多版本方式对应用实现透明升级。

安全性

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

高性能架构

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

不同视角下的网站性能

  • 用户视角

    关注点： 关注响应时间，包括浏览器和服务器通信时间 + 服务器处理时间 + 浏览器构造请求和解析响应的时间；

    优化手段： 前端架构优化

  • 开发人员视角

    关注点： 关注应用及相关子系统性能，包括响应延迟、系统吞吐量、并发处理能力、系统稳定性等技术指标； 优化手段： 缓存加速数据读取、集群提高系统吞吐量、异步消息加快请求响应和削峰、代码优化提升性能；

  • 运维人员视角

    关注点：关注基础设施性能、资源利用率。

    优化手段： 建设优化骨干网、高性价比定制服务器、利用虚拟化技术优化资源利用率；

性能测试指标

响应时间

定义：执行一个应用需要的时间，包括从发出请求开始到收到最后响应数据所需要的时间。反映系统快慢。

常用系统操作响应时间表

图1 常用系统操作响应时间表

并发数

定义：系统能够同时处理请求的数目。反映系统负载特性。

网站系统用户数 >> 网站在线用户数 >> 网站并发用户数

吞吐量

定义： 单位时间内系统处理的请求数量。反映系统的整体处理能力。 单位：TPS每秒事务数，HPS每秒HTTP请求数，QPS每秒查询数

并发数由小增大，服务器资源消耗逐渐增大，吞吐量先增大后下降，直至资源耗尽，吞吐量为零。

性能计数器

定义：描述服务器或操作系统性能的一些数据指标。比如load、对象与线程数、内存、CPU、磁盘/网络IO。

性能测试方法

性能测试

以系统设计规划的性能指标为预期目标，验证系统在资源可接受范围内是否能达到性能预期。

负载测试

不断增大并发请求增加系统压力，直到系统某项或多项性能指标达到安全临界值。此时如果继续施压，系统处理能力不升反降。

压力测试

对系统持续加压超过安全负载，直到系统崩溃，以此获得系统最大压力承受能力。

稳定性测试

被测系统在特定硬件、软件、网络环境下，给系统加载一定业务压力，使系统运行一段较长时间，以此检测系统是否稳定。

测试性能曲线

图2 测试性能曲线

a-b是网站日常运行区间，c是系统最大负载点，d是系统崩溃点。

性能优化策略

Web前端性能优化

  1. 浏览器访问优化
    • 减少HTTP请求：合并CSS/JS/图片，sprite技术。
    • 使用浏览器缓存静态资源：Cache-Control、Expires
    • 启用压缩：gzip(文本文件压缩率80%以上)
    • CSS放在页面最上面(浏览器下载完CSS才开始渲染)、JS放在页面最下面(浏览器加载JS后立即执行，避免某些操作阻塞页面)。
    • 减少Cookie传输：减少Cookie中数据量、为静态资源使用独立域名，避免发送Cookie。
  2. CDN加速：CDN本质是缓存，将数据(静态资源)缓存在离用户最近的地方。
  3. 反向代理：缓存静态资源，加速请求响应速度、负载均衡，改善性能、安全

应用服务器性能优化

##### 分布式缓存 网站性能优化第一定律：优先考虑使用缓存优化性能。第二异步，第三集群。

  1. 缓存基本原理：Hash表
  2. 合理使用缓存：
    • 不频繁修改的数据：读写比2:1以上。
    • 有热点的访问：遵循二八定律。
    • 应用能够容忍短期数据不一致和脏读，最终一致。
    • 缓存可用性：防止出现缓存雪崩，即系统性能已经严重依赖缓存，没它不行。
    • 缓存预热： 缓存启动时把热点数据预热(warm up)好。
    • 防止缓存穿透：恶意请求不存在的Key，使请求落到数据库，一个对策是将不存在的数据也缓存起来，令其值为null。
  3. 分布式缓存架构：
    • 需同步更新副本的分布式架构(JBoss Cache)
    • 互不通信的分布式架构(Memcached：简单地通信协议、丰富的客户端程序、高性能网络通信(Libevent、事件触发)、高效的内存管理(slab、chunk)、一致性hash)
异步操作

使用消息队列将调用异步化，降低响应延时。

  1. 避免高并发请求数据直接落到数据库。
  2. 削峰，消除并发访问高峰。
  3. 任何晚点做的事情都应该晚点再做。
使用集群

负载均衡，避免单一服务器压力过大而响应缓慢。

代码优化

多线程

启动线程数 = [任务执行时间/(任务执行时间-IO等待时间)] * CPU核数

注意线程安全问题：

  • 将对象设计为无状态：对象无成员变量，在OOP看来是一种不良设计。
  • 使用局部对象。
  • 并发访问资源使用锁。
资源复用

尽量减少那些开销很大的系统资源的创建和销毁，比如数据库连接、网络通信连接、线程、复杂对象等。

两种模式：

  • 单例(Singleton): 贫血模式，例如Service、Dao等无状态对象，无需重复创建。(对应有状态的充血模式)
  • 对象池(Object Pool)：复用对象实例，减少对象创建和资源消耗，例如连接池、线程池等。
数据结构
  • 优化算法
  • 优化数据结构，以短字符串取信息指纹，再对信息指纹求HashCode获得好的随机散列。
垃圾回收

理解垃圾回收机制，程序优化和参数调优，减少Full GC。

JVM垃圾回收：年轻代+老生代。年轻代包括Eden Space、From、To，进行Young GC；老生代进行Full GC。新对象从Eden Space创建，Eden满了以后YGC，将存活对象复制到From区。当Eden再次满后再次YGC，将Eden和From中的存活对象复制到To。当Eden再次满后再次YGC，将Eden和To中的存活对象复制到From。多次YGC未释放的对象进到老生代，老生代空间满时Full GC。

存储性能优化

  1. 机械硬盘升级为固态硬盘
  2. B+树：文件系统或数据库系统通过B+数对数据排序后存储，加快数据检索速度。
  3. LSM树：目前这么多NoSQL产品采用LSM树作为主要数据结构，在LSM树上进行一次数据更新不需要磁盘访问，在内存即可完成，速度远快于B+树，当数据访问以写操作为主，而读操作则集中在最近定入的数据上时，使用LSM树可以极大程度地减少磁盘的访问次数，加快访问速度。
  4. RAID：可通过硬件或者软件实现。
    • RAID0: 并发读写N块磁盘，速度快，无冗余，数据可靠性低，磁盘利用率100%。
    • RAID1: 镜像磁盘，访问速度慢，数据可靠性高，磁盘利用率50%。
    • RAID10: 结合RAID0和RAID1，将磁盘分成2份，互为镜像，同RAID1，每一份磁盘中的数据并发读写。访问速度较快，数据可靠性高，磁盘利用率50%。
    • RAID3/5/6: 冗余存储校验数据，使少数盘破坏的情况下数据能恢复。访问速度较快，数据可靠性较高，磁盘利用率较高。

高可用架构

可用性度量与考核

#### 度量 衡量方式：多少个9。

网站不可用时间(故障时间) = 故障修复时间点 - 故障发现(报告)时间点

网站年度可用性指标 = (1-网站不可用时间/年度总时间) * 100%

  • 2个9：基本可用，年度不可用时间小于88小时
  • 3个9：较高可用，年度不可用时间小于9小时
  • 4个9：具有自动恢复能力的高可用，年度不可用时间小于53分钟
  • 5个9：极高可用，年度不可用时间小于5分钟

考核

故障分：对网站故障进行分类加权计算故障责任。故障分 = 故障时间(分钟) * 故障权重。

  • 事故级故障(100): 严重故障，网站整体不可用
  • A类故障(20): 网站访问不顺畅或核心功能不可用
  • B类故障(5): 非核心功能不可用，或核心功能少数用户不可用
  • C类故障(1): 以上故障以外的其他故障

高可用网站架构

高可用架构设计不仅要考虑软硬件故障，还要考虑网站升级发布引起的不可用。

主要手段： 数据和服务的冗余备份和失效转移。

典型分层模型：

  • 应用层： 负责具体业务逻辑处理。思路：负载均衡设备
  • 服务层： 负责提供可复用的服务。思路：集群，分布式服务调用框架，客户端软件负载均衡
  • 数据层： 负责数据的存储与访问。思路：数据冗余

高可用的应用

主要特点：无状态

无状态应用是指应用服务器不保存业务的上下文信息，仅根据每次请求提交的数据进行相应业务逻辑处理，多个服务实例完全对等。

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

  • 应用访问量小也使用负载均衡技术构建一个小型集群保证高可用
  • 平滑升级

应用服务器集群的Session管理

  • Session复制：Session在集群中同步，大集群不适用。
  • Session绑定：Session Sticky，会话黏滞。Hash(Source IP)、Hash(Cookie)，无法实现高可用。
  • 利用Cookie记录Session：服务器端不记录Session，每次从Cookie中解，服务器可线性伸缩。缺点：大小受限、增大传输数据量、用户关闭Cookie时不可用。
  • Session服务器：独立部署Session服务器集群，通过 分布式缓存+数据库 实现。可用性高、伸缩性好、性能不错。

高可用服务

主要特点： 无状态

  • 分级管理：核心业务隔离部署、用更好更稳定的硬件。
  • 超时设置
  • 异步调用，利用状态机改造流程，当然不是所有的服务调用都可以异步调用，对于获取用户信息这类调用，采用异步方式会延长响应时间，得不偿失。
  • 服务降级：拒绝服务(拒绝低优先级任务、随机拒绝)、关闭功能。
  • 幂等性设计：允许重复调用。

高可用数据

主要手段：数据备份和失效转移机制

含义：

  • 数据持久性
  • 数据可访问性

  • 数据一致性：

    • 数据强一致：最强，各副本数据在物理存储中一致；
    • 数据用户一致： 较强，在物理存储中可能不一致，但是通过纠错和校验机制，可以返回一个一致且正确地的数据给用户；
    • 数据最终一致，较弱，用户得到的数据可能不一致，但是最终会达到一致。

CAP理论: 数据一致性(Consistency)、数据可用性(Availibility)、分区容忍性(Partition Tolerance)。大型网站中，通常会选择强化分布式存储系统的可用性(A)和伸缩性(P)，在某种程度上放弃一致性(C)。

缓存服务讨论，两种观点：

  • 缓存需要高可用：缓存承担了业务中绝大多数数据读取访问，缓存服务失效会影响整个网站可用性。
  • 缓存不需要高可用：缓存服务不是数据存储服务，缓存失效引起服务器负载太大的问题应用通过其他手段解决。比如扩大缓存集群规模，单台缓存服务器失效带来影响较小。

数据备份

  • 冷备份：定期将数据备份到某种存储介质(磁带、光盘……)并物理存档保管。简单、廉价、技术难度低，无法保证数据最终一致，可能丢数据，无法保证数据可用性。
  • 热备份：
    • 异步热备：Master-Slave架构。写Master，返回操作成功响应，再由Master同步到Slave，这个过程可能失败。例子：MySQL半同步复制、读写分离等。写操作只访问Master,读操作只访问Slave。
    • 同步热备：存储服务器互相间对等。数据多副本写入同步完成。

失效转移

  • 失效确认：1. 心跳检查。2. 应用程序访问失败报告。
  • 访问转移：数据读写重新路由
  • 数据恢复：恢复副本数量

高可用网站软件质量保证

  • 网站发布：平滑升级，从LB下线->更新程序->挂回LB，分批替换发布。
  • 自动化测试，大型网站也会开发自己的自动化 测试工具，可以一键完成系统部署，测试数据生成，测试执行，测试报告生成等全部测试过程。
  • 预发布验证：预发布服务器与线上机器的唯一不同就是没有配置在负载均衡上，外部用户无法访问。避免验证过程污染生产环境数据。
  • 代码控制：1. 主干开发、分支发布。2. 分支开发、主干发布。
  • 自动化发布：周四发布，火车发布模型(基于规则驱动的流程，一级级评审)
  • 灰度发布：分批次升级，等一批稳定运行后再上下一批。灰度发布也常于用户测试，即在 部分服务器上发布新版本，其余服务器保持老版本，这种手段也称作AB测试。

网站运行监控

准则：“不允许没有监控的系统上线”

监控数据采集

  • 用户行为日志收集：服务器端日志、客户端日志， 实时计算框架Storm日志统计与分析工具
  • 服务器性能监控 广泛的开源性能监控工具是Ganglia,它支持大规划服务器集群，并支持以图形的方式在浏览器展示实时性能曲线。
  • 运行数据报告：业务场景相关

监控管理

  • 系统报警
  • 失效转移
  • 自动优雅降级

伸缩性架构

“大型“定义：

  • Facebook: 大量用户及大量访问，10亿用户。
  • 腾讯： 功能复杂，产品众多，1600+种产品。
  • Google：大量服务器，100w台服务器。

网站架构的伸缩性设计

  • 所谓伸缩性：是指不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力。

  • 一般网站的伸缩性设计可以分为两类：一类是　根据功能进行物理分享实现伸缩，一类是单一功能通过集群实现伸缩。前者是不同的服务部署不同的服务，提供不同的功能；后者是集群内的多台服务器部署相同的服务，提供相同的功能。

  • 集群伸缩性又可分为应用服务器集群和数据服务器集群伸缩性。这两种集群由于对数据状态管理的不同，技术实现也有非常大的区别。而数据服务器集群也可分为缓存数据服务集群和存储数据服务器集群，这两种集群的伸缩性设计也不大相同。

  • 不同功能进行物理分离实现伸缩

    单一服务器处理所有服务 -> 数据库从应用服务器分离 -> 缓存从应用服务器分离 -> 静态资源从应用服务器分离

    横向分离(分层后分离)、纵向分离(业务分割后分离)

  • 单一功能通过集群规模实现伸缩

    当一头牛拉不动车的时候，不要去寻找一头更强壮的牛，而是用两头牛来拉车。

    集群伸缩性：应用服务器集群伸缩性、数据服务器集群伸缩性(缓存数据服务器集群和存储数据服务器集群)

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

负载均衡：实现网站伸缩性，改善网站可用性。

HTTP重定向负载均衡

通过一台HTTP重定向服务器，返回302实现负载均衡。实践中很少见。

优点：简单 缺点：性能差(2次请求)、伸缩性有限(重定向服务器容易成为瓶颈)、被搜素引擎判为SEO作弊(302请求)，

DNS域名解析负载均衡

在DNS服务器中配置多个A纪录。大型网站用于进行第一级负载均衡。

优点：支持基于地理位置域名解析，加快用户访问速度。 缺点：DNS多级解析，生效和失效时间久。

反向代理负载均衡

利用反向代理服务器(缓存资源、安全等)进行负载均衡。应用层负载均衡。

优点：反向代理功能和负载均衡功能集成，部署简单。 缺点：反向代理服务器容易成为瓶颈。

IP负载均衡

在网络层通过修改请求目标地址进行负载均衡。

  • 负载均衡服务器修改目的IP的同时修改源地址，将数据包源地址设为自身IP。(SNAT)
  • 负载均衡服务器同时作为Real Server的网关服务器。(LVS/NAT模式)

优点：相比应用层负载均衡(反向代理)有更好的性能。 缺点：进出流量走负载均衡服务器，依然存在瓶颈。

数据链路层负载均衡

在通信协议的数据链路层修改mac地址进行负载均衡(LVS/DR)。数据三角传输模式，流量从用户->负载均衡服务器->Real Server->用户。

目前使用最广泛。 在Linux平台上最好的链路层负载均衡开源产器是LVS(Linux Virtual Server)。

负载均衡算法

  • 轮询(Round Robin, RR)
  • 加权轮询(Weighted Round Robin, WRR)
  • 随机(Random)
  • 最少连接(Least Connections)
  • 源地址散列(Source Hashing)

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

  • 目标：必须让新上线/下线的缓存服务器对整个分布式缓存集群影响最小，也就是说经过调整使整个缓存服务器集群中已经缓存的数据尽可能还被访问到。

  • 一致性Hash：解决集群扩减容时过多节点缓存失效问题。 使用虚拟节点的一致性Hash环：避免集群扩减容造成的节点负载不均问题，通过增加一层虚拟节点与物理节点的映射来使节点增删带来的影响平均到所有节点。 １／４（Ｘ／（Ｎ＋Ｘ））Ｎ为原物理节点，Ｘ为新加入物理节点数。虚拟数据推荐150合适。

  • 计算机领域有句话：计算机的任何问题都可以通过增加一个虚拟层来解决。计算机硬件，计算机网络，计算机软件都莫不如此。

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

数据存储服务器必须保证数据可靠存储、可用性、正确性，伸缩性设计原则与缓存不同。

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

  • 主从读写分离
  • 业务分隔、数据分库。跨库不能Join操作、避免事务

  • 数据分片：通过分布式关系数据库访问代理，比如Amoeba、Cobar(Ali)。伸缩性：一致性Hash + 数据迁移

  • Cobar的伸缩有两种：Cobar服务器集群的伸缩和ＭySQL服务器集群的伸缩。 Cobar可以看作无状态的应用服务器，因此其集群伸缩可以简单使用负载均衡来实现。而ＭySQL中存储着数据，要想保证集群扩容后数据一致负载均衡，必须做数据迁移。 GreenPlum 可支持分布式JOIN操作但延时较大，一般用于在数据仓库非实时业务中。

  • zookeeper:一个支持分布式一致性的数据管理服务选举一个主服务器。

  • 救世主定律：遇到问题，分析问题，最后总能解决问题。

NoSQL数据库的伸缩性设计

HBase伸缩性: 依赖可分裂的HRegion及可伸缩的分布式文件系统HDFS实现。

可扩展架构

扩展性和伸缩性：

  • 扩展性(Extensibility)： 指对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。目标是当系统新增功能时，不需要对现有系统的结构和代码进行修改。
  • 伸缩性(Scalability)：指系统能够通过增加/减少自身资源规模的方式增强/减少自己计算处理事务的能力。目标是利用集群的方式增加服务器数量，提高系统的整体事务吞吐能力，实现线性伸缩性。

构建可扩展的网站架构

  • 终极目标：系统间低耦合。如何分解系统的各个模块、如何定义各个模块接口、如何复用组合不同的模块构造一个完整的系统。

  • 核心思想：模块化，并在此基础上降低模块间耦合性，提高模块复用性。

  • 软件架构师最大的价值不在于掌握多少先进的技术，而在于具有将一个大系统切分成Ｎ个低耦合的子模块的能力，这些子模块包含橫向的业务模块，也包含纵向的基础技术模块。这种能力一部分源自专业的技术和经验，还有一部分源自架构师对业务场景的理解，对人性的把握，甚至对世界的认知。

  • 模块分布式部署以后具体聚合方式主要有分布式消息和分布式服务。

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

分布式消息队列通过消息对象分解系统耦合性，不同子系统处理同一个消息。

事件驱动架构

  • 定义：事件驱动架构(Event Driven Architecture)通过在低耦合的模块之间传输事件消息，以保持模块的松散耦合，并借助事件消息的通信完成模块间合作。

  • 典型的EDA架构比如生产者消费者模式。利用分布式消息队列的发布-订阅模式工作。生产者只需生产消息到队列，消费者从队列获取消息进行处理。新增业务，只要对某类消息感兴趣，即可订阅该消息，对原有系统和业务没有任何影响。

  • 因此基于事件（消息对象）驱动的业务架构可是一系列的流程再造。

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

分布式服务通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务调用。

巨无霸系统带来的问题：

  • 编译、部署困难
  • 代码分支管理困难：多个团队共同维护一份代码。
  • 数据库连接容易耗尽：数据库连接数与应用数量成正比。
  • 新增业务困难：老人不敢碰，新人不能接。

解决方法：拆分、模块独立部署

  • 纵向拆分：将大应用拆分为多个小应用。
  • 横向拆分：将复用业务拆分出来，独立部署为分布式服务，新增业务只需调用这些分布式服务，不需要依赖具体的模块代码。

Web Service与企业级分布式服务

Web Service: 服务提供者通过WSDL描述服务(接口)，客户端通过WSDL生成客户端调用代码，通过SOAP协议与服务提供者通信，传输层协议可以是HTTP、SMTP、TCP等。

缺点：

  • 臃肿的注册与发现机制
  • 低效的XML序列化手段
  • 开销相对较高的HTTP远程通信
  • 复杂的部署与维护手段

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

  • 服务注册与发现
  • 负载均衡：支持服务请求者使用可配置的负载均衡算法访问服务。
  • 失效转移
  • 高效的远程通信
  • 整合异构系统
  • 对应用最小侵入：适应服务架构的进化和反复(分布式或集中式部署)。
  • 版本管理：支持服务接口的多版本。
  • 实时监控，没有监控的服务是不可能实现高可用的。

分布式服务框架设计

  • Thrift(远程服务调用框架)：Facebook用它管理其分布式服务(注册、发现和调用)，但是未开源基于Thrift的分布式服务框架。
  • Dubbo：阿里开源的分布式服务框架，较为成熟。

服务消费者程序通过服务接口使用服务，而服务接口通过代理加载具体服务。

可扩展的数据结构

NoSQL: 宽列存储模型、ColumnFamily(列族)设计、面向列族的稀疏矩阵存储格式

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

开放平台架构：

  • API接口：RESTful、Web Service、RPC等。
  • 协议转换：将API输入转成内部服务可识别的形式，将内部服务返回值封装成API格式。
  • 安全：身份识别、权限控制。
  • 审计：监控、计费。
  • 路由：将开放平台访问路由映射到具体的内部服务。
  • 流程：将一组离散的服务组织成一个上下文相关的新服务，隐藏服务细节，提供统一接口。

安全性架构

网站应用攻击与防御

XSS攻击

跨站脚本攻击(Cross Site Script, XSS)指攻击者通过篡改网页，注入恶意HTML脚本，在用户浏览网页时，控制用户浏览器进行恶意操作的一种攻击方式。

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

防御手段：

  • 消毒：特殊字符(‘<’,’>‘等)转义。
  • HttpOnly: 不能避免XSS，但是能避免攻击者通过XSS获取Cookie，导致敏感信息泄露。

注入攻击

两种形式：SQL注入攻击、OS注入攻击。本质是将数据当做程序执行。

攻击者如何获取数据库表结构信息？

  • 开源：表结构本身公开。
  • 错误回显：服务器500错误回显到浏览器。
  • 盲注：攻击者根据页面变化情况判断SQL语句的执行情况，据此猜测数据库表结构。

防御手段：

  • 消毒：过滤数据中可能注入的SQL。
  • 参数绑定：预编译(两大好处：1.提升性能，2.防止SQL注入)

CSRF攻击

跨站请求伪造(Cross Site Request Forgery, CSRF)指攻击者通过跨站请求，以合法用户的身份进行非法操作。核心是利用浏览器Cookie或服务器Session策略盗取用户身份。

防御手段：识别请求者身份

  • 表单Token: 每次页面请求，服务器写入一个随机数到Cookie，下次页面表单提交，表单域携带随机数，服务器端以此判断Cookie中随机数与表单域中值是否一致。这个方法有效的前提是Cookie不泄露，否则不生效。CSRF配合XSS攻击盗取Cookie会带来严重后果。
  • 验证码：用户体验不好。
  • Referer cheker：判断Referer域中请求来源是否合法。

其他攻击和漏洞

  • Error Code: 服务器端500错误异常信息直接显示在浏览器。
  • HTML注释
  • 文件上传：上传不可靠文件类型。
  • 路径遍历：URL路径部分填入相对路径，暴露服务器文件系统。

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

加密技术

  • 单项散列加密
  • 对称加密
  • 非对称加密
单向散列加密

通过对不同输入长度信息进行散列计算，得到固定长度输出，不可逆。

常见算法：MD5、SHA

对称加密

加密和解密使用的密钥是同一个(或者可以互相推算)。算法简单，加解密效率高，系统开销小，适合大量数据加密，如何保存密钥是个难题。

常见算法：DES、RC

非对称加密

加密和解密使用的密钥不是同一个。安全性高。

常见算法：RSA

密钥安全管理

  • 密钥和算法放在一个独立的服务器上，甚至做成一个专用硬件设施，对外提供加密和解密服务，应用系统通过调用这个服务实现加解密。
  • 加解密算法放在应用系统中，密钥放在独立服务器，并且密钥分片存储，分别由专人保管。

信息过滤和反垃圾

  • 文本匹配：Trie算法、多级Hash表
  • 分类算法：数据挖掘、贝叶斯分类算法
  • 黑名单：Hash表(精确)、布隆过滤器(不完全精确)

电子商务风险控制

风险

  • 账户风险
  • 买家风险
  • 卖家风险
  • 交易风险

风控

  • 规则引擎：业务规则和规则处理逻辑相分离。规则处理逻辑写好后，由运营人员负责通过页面编辑规则。
  • 统计模型：数据挖掘、机器学习

淘宝技术主要研源系统

  • Tair 分布式k/v
  • TFS 分布式文件
  • OceanBase 分布式数据库系统
  • TDDL : 分库分表和具有从多特性的动态数据源

  • Doris 数量分布大k/v

  • 瞬时故障: 毫秒或秒级, 手段: 重试多次
  • 临时故障, 临时故障期间,临时故障恢复期间, 故障期间写入临时服务器,恢复期间,数据再迁回
  • 永久故障, 临时服务器,数据从正常态的迁移过来

秒杀系统:

  1. 独立部署
  2. 秒杀商品页面静态化
  3. 租借活动网络CDN带宽
  4. 动态生成随机下单页面URL
  5. 开拍按钮用个小脚本生成器

大型网站典型故障

  1. 应用日志,第三方日志, DEBUG写到爆
  2. 首页不访问数据库,静态化
  3. 锁要小心
  4. 缓存不被穿透
  5. 启动顺序要保证,用个kl文件也行
  6. 大文件读写
  7. 滥用生产环境作测试,哈哈
  8. 不规范的流程,缓存代码没注释,没有review
  9. 不好的编程习惯,null

一是将软件设计的很复杂,以使其缺陷没那么明显. 一种是将软件设计得很简单,以使其没有明显的缺陷

架构师领导艺术

一群优秀的人做一件他们热爱的事,一定能取得成功

是事情成就人,而不是人成就了事

成就他人

不要只有架构师拥有架构

把”我的问题”表述成”我们的问题”

给上司提封闭式问题,给下属提开放式问题

用赞同的方式提出问题

漫画架构师

按作用划分架构师

  1. 设计型架构师
  2. 救火型架构师
  3. 布道型架构师
  4. Geek型架构师

按产品分 1. 产品架构师 2. 基础服务架构师 3. 基础设施架构师

按关注层次划分架构师

  1. 只关注功能的架构师
  2. 关注非功能的架构师
  3. 关注团队组织与管理的架构师
  4. 关注产品运营的架构师
  5. 关注产品未来的架构师