人人都是架构师-读书笔记思维导图模板

分布式服务案例

分布式系统的架构演变之路

单机系统

将 Web 服务器、文件服务器和数据库全都部署在同 台物理服务器上

优点：省钱

缺点：一旦宕机，影响范围大

独立部署，避免不同的系统之间相互争夺共享资源（比如 CPU 、内存、磁 盘等）

Web 务器集群，实现可伸缩性；

部署分布式缓存系统，使查询操作尽可能在缓存命中：

数据库实施读／写分离，实现 HA (High Availability ，高可用性）架构

集群架构Cluster

通过增加新的服务器来分散并发访问流量，只要业务系统能够随意支持服务器的横向扩容，那么 从理论上来说就应该无惧任何挑战，从而（优点：实现可伸缩性和高可用性架构。

Nginx 也应该具备高可用性，这可以依靠DNS 轮询来实现。

在集群环境中， Web 节点的数量越多，并行处理能力就越强，哪怕其中某些节点因为种种原因岩机，也不会使系统的整体服务不可用。

缺点：由于业务逻辑全部耦合在一起，除了扩展和维护困难，在生产环境中极有可能会因为某个业 务功能不可用而影响系统整体服务不可用。

利用 CDN 加速系统响应：

业务垂直化，降低藕合，从而实现分而治之的管理。

拆系统之业务垂直化

优点：了能够更清晰地规划和体现出每个子系统的职责，降低业务稠合，以及提升容错性。

缺点：共享业务重复建设和资源连接受限，太多人共同维护一个系统容易版本冲突。

为什么需要实现服务化架构

服务拆分粒度之微服务

系统服务化需求

服务化与RPC协议

如 Java RMI WebService Hessian Finagle 等

底层的网络通信协议处理 解决寻址问题 请求／响应过程中参数的序列化和反序列化工作。

使用阿里分布式服务框架 Dubbo 实现服务化

现在阿里内部主推 HSF

警惕 Dubbo 因超时和重试引起的系统雪崩

Failover 机制

服务治理方案

服务的动态注册与发现 服务的扩容评估： 服务的升／降级处理。

关于服务化后的分布式事务问题

分布式调用跟踪系统需求

淘宝的鹰眼（EagleEye ）、 Twitter Zipkin 、新浪的 Watchman ，以 及京东的 Hydra等

Google Dapper 论文简介

服务性能低损耗； 业务代码低侵人； 监控界面可视化； 数据分析准实时。

基于 Dubbo 实现分布式调用跟踪系统方案

跟踪每个请求的完整调用链 ·收集调用链上每个服务的执行耗时，以及整合孤立 日志。

Filter 接口

采样率方案

大流量限流／削峰案例

分布式系统为什么需要进行流量管制

五种分布式系统应对高并发、大流量的常规手段：

扩容动静分离缓存；服务降级限流。

限流的具体万案

常见的限流算法

令牌桶（Token Bucket ）算法

漏桶算法（Leaky Bucket ）

使用 Google的Guava 实现平均速率限流

使用 Nginx 实现接入层限流

使用计数器算法实现商品抢购限流

基于时间分片的削峰万案

活动分时段进行实现消峰

通过答题验证实现消峰

异步调用需求

使用 MQ 实现系统之间的解耦

使用 Apache 开源的 ActiveMQ 实现异步调用

Point-to-Point (P2P ，点对点）模型 • Publish/Subscribe (pub/sub ，发布／订阅）模型。

使用阿里开源的 RocketMQ 实现互联网场景下的 流量消峰

支持顺序消息： 支持事务消息： 支持集群与广播模式： 亿级消息堆积能力 完善的分布式特性； 支持Push Pull 两种消息订阅模式。

NameServer 其实就是一个注册中心， Broker Producer Consumer在启动时都会向其进行注册，它的主要功能是负责客户端的寻址操作。Broker 为消息服务端，提供消息的管理、存储及分发等功能。Producer 为消息生产者，用于向 Broker 推送消息；而 Consumer 为消息消费者，负责消费 Broker 中的消息。

基于 MQ 方案实现流量消峰的一些典型案例

前端埋点数据上报消峰案例分布式调用眼踪系统的埋点数据上报消峰案例。

分布式配置管理服务案例

本地配置

将配置信息搞合在业务代码中

将配置信息配置在配置文件中

集中式资源配置

分布式一致性协调服务 Zoo Keeper 简介

ZooKeeper 的下载与集群安装

ZooKeeper 的基本使用技巧

基于 Zoo Keeper 实现分布式配置管理平台方案

从配置中心获取 Spring Bean 定义实现 Bean 动态注册

容灾方案

使用淘宝 Diamond 实现分布式配置管理服务

Diamond与ZooKeeper 的细节差异

数据存储方案不同监听数据变更的机制不同容灾机制不同； • Znode 不适合存储大数据。

使用百度 Disconf 实现分布式配置管理服务

大促场景下热点数据的读／写优化案例

缓存技术简介Cache

利用 CDN 缓存静态资源数据

反向代理服务器

由于数据库的读／写能力远远比不上缓存的效率，因此除了可以使用 IDC 、反向代理等手段缓存静态资源、数据，业务系统从数据库等存储系统中获取的数据信息也可以进行缓存$这样当再次获取指定的数据时，可以优先从缓存命中，以减轻对数据库的负载

本地缓存分布式缓存。

Ehcache MemCache Redis

缓解应用系统或关系型数据库的负载压力；提升系统吞吐量。

使用 Ehcache 实现数据缓存

其实 Hibernate 中的二级缓存默认使用的就是Ehcache

LocalCache 存在的弊端

会共享JVM有限的内存资源。

本地缓存技术逐渐被分布式缓存技术所替代

将本地缓存与分布式缓存结合

神秘的 off-heap 技术

减少 GC 次数或降低暂停时间： 可以扩展和使用更大的内存空间：省去物理内存与 heap 之间的数据复制步骤

高性能分布式缓存 Redis 简介

对于 Redis 的使用除了常规的单点，如果希望利用数据水平存储或横向扩容来提升 Redis 的整体容量，那么可以采用 致性 Hash 算法将多个 Redis 节点构建成 Redis 集群。由于扩容可以是动态的，因此从理论上来说， Redis 集群后的容量是无限的。

使用 Jed is 客户端操作 Redis

使用 Red is 集群实现数据水平化存储

3.x 版本之前， Redis 并没有提供 Cluster 功能，如果我们想对 Redis 进行集群，则只能自行采取一致性 Hash 算法，

同一热卖商昂高并发读需求

Redis 集群多写多读方案

保障多写时的数据一致性

Loca!Cache 结合 Redis 集群的多级 Cache 方案。

实时热点自动发现方案

同一热卖商昂高并发写需求

lnnoDB 行锁引起数据库 TPS 下降

在Redis 中扣减热卖商品库存方案

分布式锁

Redisson

热卖商品库存扣减优化方案

控制单机并发写流量方案

使用阿里开源的 AliSQL 数据库提升秒杀场景性能

数据库分库分表案例

关系型数据库的架构演变

数据库读写分离

数据库垂直分库

数据库水平分库与水平分表

MySQL Sharding MySQL Cluster 的区别

MySQL Cluster

集群模式

优势只是扩展了数据库的并行处理能力，但是使用成本、维护成本相当高（目前在生产环境中使用者 较少，而且实施相对复杂）。

MySQL Sharding

分布式模式

成熟且实惠的方案，不仅可以提升数据库的并行处理能力，还能够解决因为单表数据量过大所产生的检索瓶颈。

Sharding 中间件

常见的 Sharding 中间件对比

Shark 简介

一款采用 Apache License 2.0 开源协议的分布式 MySQL 分库分表中间 件。

Shark 的架构模型

按照特定的路由算法和规则对多数据源进行动态切换

内部并没有实现自己的 DBConnectionPool

使用 Shark 实现分库分表后的数据路由任务

分库分表后所带来的影晌

多机 Sequence ID 解决方案

使用 Solr 满足多维度的复杂条件查询

Solr Apache 旗下的一个子项目，它是一种采用 Java 语言编写、开放源代码，并且扩展自 Lucene 的搜索引擎。

关于分布式事务

数据库的 HA 方案

HA 在广义上是指系统所具备的高可用性。

基于配置中心实现主从切换

基于 Keepalived 实现主从切换

保障主从切换过程中的数据一致性

写人 Master 之前也将同一份数据落到缓存中

开启半同步复制（ Semi-synchronous Replication ）功能。在峰值流量较大的场景下，笔者不建 议开启这项功能，这会对 TPS 产生一定的影响。

订单业务冗余表需求

冗余表的实现方案

数据同步写入 数据异步写入

保障冗余表的数据一致性

线上检测补偿”

“线下检测补偿”