模块九——IM 架构实战：演变的架构

作业部分——毕业设计

设计电商秒杀系统

【业务背景】

你作为一个电商创业公司的架构师，负责设计 6.18 大促秒杀系统的设计，你们的业务模式如下：

1. 你们挑选选品各大电商平台上畅销和好评的商品进行销售，每个品类不超过 20 个商品，目前做了 10 个品类；

2. 本次 6.18 秒杀选择了 1000 个充电宝，10 台 iPhone 12 作为秒杀商品；

3. 正常的日活大约 100 万用户；

4. 老板要求万无一失。

【技术背景】

1. 技术团队以 Java 为主，已经落地了微服务架构；

2. 主要渠道是自有的 App（包括 iOS 和 Android）和微信小程序，为了促进用户转化为 App 用户，只有下载 App 才能参加秒杀活动；

3. 目前只有单机房。

【毕设要求】

1. 设计完整的架构，例如存储、负载均衡、缓存、高可用、可扩展等；

2. 大约 10 页以内的 PPT，每页 PPT 说明一项设计，包括架构设计和设计理由，无需详细解释备选方案。

【提示】

1. 分析考虑要全面，但并不意味着架构设计要面面俱到，如果分析后认为某些设计点可以不做，就在作业最后统一说明原因即可；

2. 如果没有思路，请对照模块 9 的 IM 案例；

3. 如果有的信息觉得不够全或者不够细，可以做出一定的假设，但不能天马行空，需要对照已有的业务背景和技术背景进行合理推断。

PPT

笔记部分

1、架构重构技巧

1.1、什么是架构重构

1.1.1、代码重构

在不影响输出结果的前提下，以增加可读性或者简化结构为目的的代码改动行为。

• 目的：增加可读性、增加可维护性、可扩展性

• 关键点：不影响输出、不修正错误、不增加新的功能

代码重构的时候发现有个功能实现逻辑不合理，可以直接修改么？

不可以直接修改。如果真的要修改，就需要仔细的分析。表面上不合理的背后可能是为了处理特殊的情况，如果轻易修改，就可能造成 bug。

1.1.2、架构重构

在不影响系统整体功能的前提下，以修复系统质量问题为目的的调整系统架构（4R）的行为。

• 目的：修复质量问题（性能、可用性、可扩展……）；

• 关键点：修复质量问题、不影响整体系统功能、架构本质没有发生变化（复杂度没有变化，这点与架构演进不同）

把某个子系统的实现方式从硬编码改为规则引擎，是代码重构还是架构重构？

从硬编码改为规则引擎，相当于改变了 Role，所以属于架构重构。

1.1.3、代码重构 vs 架构重构

代码重构与架构重构的异同

1.2、架构重构技巧

就是对 4R 中的 Role、Relation、Rule 进行增、删、改、拆、合，如下（下面的是排列组合的关系）

架构重构手段

架构重构是否可以修改 4R 中的 Rank ？

不可以，提高或者降低系统的 Rank，属于战略层面的调整，比如将支付宝独立出来。

1. 先局部优化后架构重构

• 局部优化：对部分业务或者功能进行优化，不影响系统架构，比如

• 数据库添加、优化索引

• 某个数据缓存更新策略采用后台更新

• 增加负载均衡的数量

• 优化代码里并发的逻辑

• 修改 InnoDB buffer pool 配置，分配更多内存

• 调整接口的参数个数

• 架构重构：优化整体架构，提升整体质量，会影响架构的 4R 定义，比如

• 引入消息队列（增加 Role）

• 去掉 ZooKeeper，改为内置实现 Raft 算法（删除 Role）

• 将 Memcached 改为 Redis（改变 Role）

• 按照稳定性拆分微服务（拆分 Role）

• 将粒度太细的微服务合并（合并 Role）

• 将服务间的通行方式由 HTTP 改为 gRPC（修改 Relation）

• SDK 从读本地配置文件改为从管理系统读取配置（修改 Rule）

1. 一个例子（数据库服务器的优化步骤）：

先局部优化后架构重构

2. 有的放矢

不是所有的问题都是通过架构重构来解决的，需要先把问题分类，找到那些“对症”的问题，在明确的时间段内，得到可以量化的结果。

代码重构的过程要具体

• 将问题分门别类，找出需要架构重构解决的那些问题（忽略代码等其它方面的问题）；

• 独立版本，不要混在业务版本里做架构重构；

• 至于结果的衡量

  可以收集重构前后的数据做对比

  如果不好收集数据，可以在改造前后分别发放调查问卷来手机结果

一个例子：

架构重构时要有的放矢

上图中只使用架构重构的手段解决了 P 业务和 M 系统耦合在一起的问题，解耦之后，在慢慢优化其余问题，这样的话优化其余问题也会降低难度和风险。

3. 合纵连横

• 合纵。说服业务方和老板，即不同层级或不同环节的利益干系人；

3. 不讲技术语言：

• 以数据说话；

• 以案例说话：如果没有数据，就讲极端案例。

• 连横。说服其它团队，即相同层级或环节的利益干系人。

• 换位思考：对其它团队一定是也有好处的；

• 合作双赢：对外体现出各方的付出，比如汇报和总结的时候，把其它团队也带上。

3. 极端案例的说服力比数据更强。

   哪些信息容易被记住？心理学研究发现，事物的新近性、显著性、生动性、可想象性等影响人的记忆。

4. 运筹帷幄

• 问题分类：一段时间集中处理一类问题，避免对照问题表，逐条解决；

• 问题排序：分类后将问题按照优先级顺序来落地，避免见缝插针式的安排重构任务；

• 逐一攻破：每一类问题里面先易后难，一是可以增强信息，而是简单问题解决后，困难问题可能就变得简单了。

1.3、架构重构的典型问题

• 是否可以引入新技术？

• 可以，但是尽量少，因为架构重构要求快和准；

• 业务不给时间重构怎么办？

• 暴露风险和问题，向业务方暴露、向老板暴露；（会哭的孩子有奶吃）

• 其它团队不配合怎么办？

• 说服上级，利用上级的力量。

• 业务进度很紧，人力不够怎么办？

• 收集证据，充分论证架构重构的必要性；时间可以调整，但必须给出一个明确的时间表（比如说 3 个月后）。

1.4、思考题

架构重构的时候是否可以顺手将代码重构也做了？因为反正都安排版本了。

不可以。

• 架构重构有明确的时间点和里程碑，做代码重构会影响整体进度；

• 目的和手段不一样，要解决的问题不一样，还是分开做专项改造比较好；

• 代码重构和业务版本关联性较强，不应该和架构重构的版本耦合在一起；

2、架构演进技巧

2.1、架构演进剖析

2.1.1 定义

以设计新的系统架构（4R）为收单，以应对业务和技术的发展变化为目的的操作。

• 目的

• 应对新的复杂度（业务发展带来的）

• 用新的技术手段、技术方法解决现有的复杂度问题

• 关键

• 新架构

• 新复杂度

• 新方法

2.2、架构重构与架构演进的不同

架构重构与架构演进的不同

从上面可以看出，两者在技术手段上并没有什么不同，技术手段不是区分架构重构和架构演进的方法，复杂度是否变化才是判断关键 !所谓新的复杂度，从业务规模上来说，十倍量级变化才是新的复杂度，比如对下图来说

不同用户规模的架构挑战

• 上面单体 -> 百万 -> 千万 -> 亿级用户量的变化才使用架构演进的办法；

• 100 万到 200 万时如果架构有问题，使用架构重构的办法来解决。

2.3、架构演进的原则、驱动力和模式

• 1 个原则：架构演进是为了促进业务发展

• 2 个驱动力——业务发展和技术发展

• 业务发展带来新的复杂度，对于 ToC 业务来说，主要体现在用户规模增长和业务多样性；

• 技术发展带来新的复杂度应对方法，例如国产化、大数据、云计算，使用开源技术应该也算；

• 2 种模式——主动和被动

• 主动演进：架构师主动识别和规划架构演进

• 被动演进：架构师被迫进行架构演进

架构的演进

2.4、业务驱动的架构演进技巧

2.4.1、业务的发展模式

• 业务规模发生变化

• 业务多样性发生变化

• 业务方向发生变化

2.4.2、业务发展模式和架构演进模式的关系

不同的业务发展模式，需要不同的架构演进模式才可以应对

• 主动演进

• 主动演进用来应对业务规模的变化和业务多样性的变化

• 业务规模：量变带来质变，一般 10 倍量级变化才考虑架构演进

• 业务多样性：业务规模可能没有变化，但是系统支持的业务类型越来越多。

• 被动演进

• 业务方向调整（比如从图文转为短视频）这种不可预料、不可计划的大变动（高层调整），架构师只能被迫演进架构，以适应一个完全不同的业务域。

2.4.3、业务驱动的主动演进技巧

做好预判，提前布局。

• 预判：提前一年做好准备。

• 以增长数字为标准：下一阶段用户规模的 60%的时候就可以开始准备了；比如当前用户 60 万，下一级的典型用户规模是 100 万，那么就可以开始考虑架构演进了，别等到 100 万再演进；

• 以时间为标准，提前一年预判。比如计划明年计划用户量级上一个台阶，那今年就开始考虑架构演进。

• 布局：团队和技术先行。

老板画大饼怎么办？

告知其时间、成本、人力投入在两个方案之间的差异。

2.4.4、业务驱动的被动演进技巧

快速响应，拿来主义。

• 快速响应：熟悉什么就用什么；

• 拿来主义：尽量用现成的方案。

这个阶段，业务方向发生了调整，用户量不多，主要任务是进行用户核心需求的验证，用户体验可以留待后续优化。

2.5、技术驱动的架构演进技巧

2.5.1、第 1 原则——新瓶旧酒原则

以解决老的问题或老的复杂度为目标，不要为了尝试新技术而演进。那新技术的选择标准是什么呢？

因为此时的复杂度和问题没有变化，所以下面几个方面的举例可以反过来思考，项目目前的痛点是什么，为了解决这些痛点，我应该寻找哪些技术？

• 降本，降低成本，包括硬件、人力、运营等成本等

• （目前对这个点无感，可能公司太不注意成本了，体质问题）

• 增效，提升效率，包括处理、运营、开发运维效率等，比如

• 大数据平台提升大数据分析效率

• 容器化提升运维效率

• 微服务提升开发效率

• 提质，提升质量，包括业务、管理、开发等，比如

• 推荐系统提升用户转化率

• 容器化支持弹性扩容应对业务峰值

• 中台提升多业务的开发效率

• 提升业务竞争力

2.5.2、第 2 原则——价值原则

新技术要带来典型（即产出远远大于投入）的价值才考虑演进。计算价值时是绝对价值，而不是比例，所以此时业务的基数影响很大，比如：

• 20 台服务器降到 10 台？2000 台降到 1500 台？后者的绝对价值大，虽然比率没有前者高。

• 2000 人日降到 1000 人日？100 人日降到 10 人日？前者的绝对价值大，虽然比率没有后者高。

• 转换率提升 2%？用户留存提升 10%？无法计算，需要先转换为对应的金钱的价值，用金钱去衡量。

如果价值不明显，可以为了晋升而引入新技术吗？

如果业务没有不会有很大发展，而制度又指引人，考虑大环境，也可以这么做，但首先要挖掘、归纳出新技术能带来什么价值，否则仍有可能失败。

2.5.3、如何说服老板进行演进

也可以作为归纳总结项目意义的出发点。

• 谈钱，别谈感情（适合成熟技术）

• 从“当下”出发。带来的价值是第一位的，提升技术水平，提升团队动力是附带的，不要本末倒置！

• 谈竞争对手（适合全新技术）

• 从“未来”出发，看看竞争对手是否引入了，“吓唬吓唬”老板！

• 谈大环境（适合法律政治相关）

• 从“上”出发，跟老板谈政治意义和大环境变化（比如国产化）

2.5.4、做好洞察，提前布局

• 洞察：识别新技术能够为业务带来的价值。要求既懂技术本质又懂业务本质。

• 布局：团队和技术现行

• 也可以作为自我学习的出发点。

2.6、思考题

你觉得合理的架构演进频次应该是怎样的？

架构演进是为了应对新的复杂度或者用新的技术手段来解决既有的问题。

• 新的复杂度是业务发展带来的，业务发展可以规划，但没有固定的频次；

• 新的技术手段的出现也没有固定的频次

所以，架构的演进应该根据业务的发展和技术的发展来进行，没有一定的频次。

3、十万用户规模 IM 架构设计

3.1、背景

3.1.2、业务背景

私密聊天 IM。私密性通过如下技术手段来保证：

• 每个用户都会通过算法生成非对称的公钥和私钥；

• 用户发送的消息会通过公钥加密，接收用户的消息使用自己的私钥解密；

3.1.3、团队背景

1. 技术团队大约 10 个人，后端 6 个，前端 2 个，Android 2 个，iOS 还没有；

2. 后端 Java 为主，大部分是 P6~P7；

3. 后端具备 MySQL、微服务、Redis 等开发使用经验；

4. 后端没有大数据和推荐相关经验。

3.2、业务基本场景

• 登陆注册

• 加好友

• 聊天

限定：

• 只能创建一对一聊天！

• 聊天消息“阅后即焚”，最多只保存 60 分钟。

3.3、总体架构思路

这里总体架构思路的意思是按照哪个用户量级来设计：十万、百万还是千万量级的用户？

• 因为是初创公司，此时的任务是验证核心需求是否真正的满足了用户的需要，所以一定不能选择按照千万级用户的目标进行设计；

• 至于是按照十万级用户规模还是按照百万级用户规模，要按照实际情况或者比较明确的推算来选择；

• 对于初创项目，最好是按照十万级用户规模进行设计。

• 如果以千万级用户为目标，真的可以确保架构三年内不用改造么？

  不可以。

  只看业务规模的话，可以 3 年内不用改造；

  但是架构演进的功力还包括业务多样性的变化，而业务多样性是和市场、大环境等多个因素相关的，是无法预测的；同时，多样性的变化，会促使团队情况发生变化，团队人数变化到多少是无法预测的；

  架构演进的另外一个动力是技术发展是无法预测的，尤其是和法律、政策相关的部分更是无法预测（例如区块链、国产化等）；

后面两个因素导致架构还是存在变化的不确定性。

3.4、存储架构设计

3.4.1、性能估算

按场景进行。

• 注册：十万用户注册信息

• 登录：由于是全新产品，按照 40%活跃用户估算，则登录信息每天是 4 万

• 加好友：最多 20 个好友，那么好友关系数 4 万 * 20 = 80 万关系数据

• 聊天：假设每个人每天向 5 位好友发送 100 条消息，则消息数量为 4 万 * 5 * 100 = 2000 万。由于消息当天基本都被删除（“阅后即焚”），所以写入、读取、删除次数都可以估算为 2000 万。

3.4.2、存储架构设计

• 用户相关信息使用 MySQL 进行存储，简单的主备架构即可满足需求，因为用户数据量不大；

• 聊天信息由于不需要长久保存，所以采用 Redis 来存储，高可用使用主备复制架构即可。

无需采用读写分离架构，因为数据量本身不大，且读写比没有很高，采用读写分离架构并不能带来额外的收益，却引入了额外的复杂度。

这里的 Redis 是作为存储而不是缓存来使用的。但可以“兼职”整体系统上的分布式缓存。

3.5、计算架构设计

3.5.1、性能估算

计算的性能估算主要是 TPS/QPS，不涉及总量的估算

• 注册：一年达到十万用户注册，TPS 很低；

• 登录：按照之前的估算，40%的活跃用户，且 IM 的使用高峰具有明显的规律，假设登录集中在早晚 4 小时，登录 TPS 均值 = 40 万 / (4 * 3600) = 3

• 加好友：如上，每人最多 20 个好友，好友关系数 80 万，按年来算的话，TPS 可忽略不计

• 聊天：同 3.4.1 节估算，消息数量为 2000 万，时间分布假设集中在早中晚 6 个小时（早上 1 小时中午 1 小时晚上 4 小时）

  发送消息 TPS：2000 万 / （3600 * 6）~= 1000

  读取 QPS ~ 发消息 TPS，删除消息 TPS ~= 发送消息 TPS

3.5.2、计算架构之负载均衡

使用 Nginx + 业务服务器即可。

十万级负载均衡架构

3.5.3、计算架构之缓存架构

采用三级缓存架构。这里的分布式缓存直接使用保存聊天消息的 Redis 即可。

十万级缓存架构

3.6、其它架构设计

根据目前的业务发展阶段以及用户级别，下面几个设计列入“其它架构设计”。

3.6.1、可扩展架构设计

就是整个系统拆成几个服务。因为是创业阶段，所以可以直接使用单体系统或根据团队状况（3 个火枪手原则）简单的拆分成两个服务（从业务场景分析可以看出，整体上是分为用户服务、关系服务和聊天服务，但是用户和关系两个业务域很紧密，所以分成两个服务即可）。如果拆分成两个服务，因为服务数量很少，所以也不需要微服务基础设施（比如配置文件即可满足配置的需求）。

3.6.2、高可用架构设计

采用同城数据灾备的形式即可。

注意：此时 Redis 存储的消息不用做跨机房部署，因为这个系统的特点是消息“阅后即焚”。

4、百万用户规模 IM 架构设计

4.0、业务场景的变化

在前期的基础上，增加了群聊功能，每个私密群聊限制人数为 5 人。

4.1、核心复杂度的变化

如第 2 节所述，架构演进主要是为了应对业务复杂度的变化或者是用新的技术方法解决现有的复杂度。从十万架构演进到百万架构，核心复杂度从快速验证核心需求演变为了快速扩展（辅助需求）：

百万级用户复杂度演进

对于此时的用户量级，运维、测试等这些基础设施的系统和架构设计还不是最主要的，因为百万规模 IM 业务的系统复杂度没有那么高：

• 下面两项内容不会由于运维平台的缺失而显著下降

• 系统质量

• 团队效率

• 不能带来足够的收益

并不能带来更多的收益。所以此时仍然不会涉及到。

背景：随着业务的发展，用户数量已经上升到 60 万了。

团队也发生了变化：

1. 技术团队从 10 人增长到 30 人，后端 18 个，前端 4 个，Android4 个，iOS 4 个。

2. 公司招聘了 2 名增长黑客数据分析师，希望能够从数据里面挖掘更多用户痛点和需求。

根据 2.4.3 节的描述：“下一阶段用户规模的 60%的时候就可以开始准备架构演进”了，所以准备启动架构演进。

4.2、总体架构思路

还是决定设计目标面向的用户量级别：是选择百万、千万还是亿级用户规模。

此时是由于业务规模发展带来的架构演进，所以

• 如果业务稳健发展，那么以百万用户规模为设计目标。

• 如果用户规模从 100 万跃升到 300 万，那么还可以通过架构重构来解决。

• 如果老板强烈要求演进到千万级，那么会面临落地慢、成本高的问题，必须要给老板讲明白。如果老板仍然强烈要求，那么也可以作为目标。

• 千万不能以亿级架构为目标。

• 因为除了落地慢、成本高的问题之外，亿级架构和十万级架构还是有本质区别的，难以直接演进。团队情况也不足以支撑。除了成本和人员以外，时间是老板最大的敌人，所需时间会超出老板的想象力和忍耐力。

还是用架构设计三原则：合适、简单、演进去判断什么样的架构最合适。但是如何说服老板，让老板信服呢？

• 这么快就要架构演进？

• 说明这是由业务不确定性决定的

• 是由技术团队的规模确定的

• 架构演进的驱动力有两种：业务的（规模/多样性）和技术的，此次演进不是技术原因（技术团队没有问题），而是由业务规模的扩展决定的。

• 关键点是说明业务快速发展是老板的英明。

• 为什么不一劳永逸的挑战千万或者亿级架构

• 团队规模决定百万级架构是最适合的

• “得加钱”：多机房、异地多活

• 还有，如 3.3 节所分析的那样，除了规模以外，业务多样性和复杂度是不好预测的，所以没有一劳永逸的架构

4.3、存储架构设计

4.3.1、性能估算

• 注册、登录、加好友、聊天

• 性能估算直接就是在“十万级”架构的基础上乘以 10，比如

• 聊天消息就是 2000 万乘以 10 等于 2 亿，考虑数据当天都被删除，那么总的"写入 + 读取 + 删除 = 6 亿"。

• 注册信息 10 万 * 10 = 100 万

• 登陆请求 4 万 * 10 = 40 万

• 关系数据：80 万 * 10 = 800 万

• 群聊

• 假设活跃用户中有 10%发起群聊，平均每人每天 2 个，每个群聊每天 200 条消息：

• 消息写入：40 万 * 10% * 2 * 200 = 1600 万数据

• 消息删除次数：等于消息写入数量

• 消息读取量：1600 万 * 5（每个群最多 5 人） = 8000 万/天

4.3.2、存储架构设计

• 用户以及关系数据：100 万用户注册信息，40 万登录请求，800 万关系数据。仍然可以用 MySQL 主备架构。

• 聊天数据：聊天：6 亿读写请求/天；群聊：1 亿读写请求/天。考虑到数据量比较大，同时性能估算是以一百万用户进行的，为了应对 2 百万、3 百万等情况，所以采用 Redis Cluster 架构。

4.4、计算架构设计

4.4.1、性能估算

• 注册、登陆、加好友、聊天的性能估算数据

• 直接在 10 万级用户的基础上乘以 10，此时唯一值得引起注意的是聊天的 TPS 为：2 亿 / (3600 * 6) * 3（发+收+删） ≈ 30000。

• 群聊

• 消息写入和删除：1600 万数据 * 2（写 + 删）/ （3600 * 6） = 1600TPS

• 消息读取量：消息写入和删除 TPS * 5 (每个群最多 5 个人) = 8000QPS（似乎计算有问题）

总结：聊天的 TPS + QPS 约等于 4 万。

4.4.2、计算架构之负载均衡

此时的 TPS + QPS 约等于 4 万，所以负载均衡架构和十万级的相同。如果用户规模达到 300 万，则 TPS + QPS 会达到 12 万，Nginx 可能会不够用，所以可以重构后换成 LVS。

百万用户级架构的负载均衡架构重构

4.4.3、计算架构之缓存架构

和 10 万级架构一样。

4.5、其它架构设计

4.5.1、可扩展架构设计

微服务拆分。

• 团队人员组成可以支持拆分为更多的服务；

• 服务多了，就需要引入微服务基础设施。

4.5.2、高可用架构设计

演进为同城双中心。

百万用户时，同城灾备即可；

用户量增长更多时，可以再演进到双活，这样做

• 一来最适合业务规模，成本适当

• 二来可以让团队有个适应的过程

4.5.3、大数据架构设计

团队中已经引入了数据分析师。

百万规模 IM，可以引入 ClickHouse，因为它兼容 SQL，维护使用简单，性能也够用。

后续有需要，可以引进 Hadoop + spark。

5、千万用户规模 IM 架构设计

5.0、业务场景的变化

增加支付功能，用于 2 个私聊用户之间转账或者红包。

1. 技术团队从 30 人增长到 100 人，覆盖完整的技术栈，包括大数据、风控安全等;

2. 由于公司的业务发展良好，证明了业务模式，业内已经有几家竞争对手出现了。

5.1、核心复杂度的变化

随着用户规模增长到千万级，相比十万级、百万计用户规模，核心复杂度也演变成了全面完善整体的架构

千万级用户复杂度演进

此时的核心复杂度从面向业务需求变为面向技术了。因为业务模式已经得到了验证，应该就是到了“还技术债的时候了”。

同 5.4 节的注释中相同的视角，在总（公司）分（公司）的模式下，虽然总部整体视角上已经是千万用户规模，但是分部并不完全是，在组织架构、规定章程上并不能照搬总部的。所以还是要具体问题具体分析，或者“总分”的组织结构在组织和制度上应该要配套。

5.2、总体架构思路

此时并不是将 100 万的性能计算公式扩大 10 倍，而是采用分级架构，分为两个方面：

• 业务分级

• 总架构师（P9）按照业务域进行拆分（每个业务域再拆分成微服务），分成不同的级别，然后每个业务域在交给下级的架构师再按照百万用户规模那样做架构设计。

• 基础技术

分级架构

此外，还有如下几个问题需要考虑：

• 不同架构师的职责

• 总架构师的核心职责：划分业务域、基础技术平台完善

• 业务架构师的核心职责：划分业务域内的微服务、按照用户规模设计架构

• 每个技术域（不是业务域？）都要由一个 P8 负责，但总架构师每个领域都要懂一些。

• 各个业务域内的架构，总架构师基本不需要关注；除非某个域问题很多（线上质量问题、开发效率问题等）；

• 千万级业务域的划分并不是由总架构师一个人进行划分（不是纯技术问题），实际上由老板、业务方、总架构师一起讨论确定的（还是一个权力决策的过程）。

5.3、业务域划分

5.3.1、业务域划分粒度

基本上还是延续了三个火枪手原则：

• 每个微服务由 3 个人负责

• 每个子域分成三个微服务

• 每个业务域拆分成三个子域

• 所以负责每个业务域的 P8 管理范围大约是 30 人

管理幅度

一个人能够指挥多少人，在管理学上被称为“管理幅度”。如果人多了，一个人管不过来，就要分层，即形成“管理层级”。

管理幅度是思考组织架构的重要内容，但是，管理幅度究竟多大合适，却要具体问题具体分析。

这里，根据微服务的“三个火枪手”原则，管理幅度大概是 3~4 人。

最后的划分如下：

千万级用户IM业务域划分

5.4、基础技术建设

下面的各项建设，都是有成本的，不仅体现在系统建设上，还体现在制度运行有成本，个人感觉最重要的就是流程、审批比较麻烦，“处理五分钟，审批几小时”。千万级用户体量是很有必要，可是对于“总（公司）分（公司）”体系结构中的“分部”层级，团队规模并没有那么大，并不直接面对千万级用户，下面的全套家伙什儿总会有各种水土不服。

5.4.1、“四化”建设

• 规范化：统一的各类规范

• 日志规范

• 开发框架

• RPC 框架

• 接口规范

• 代码管理规范

• 平台化：基于规范实现的统一平台

• 测试平台

• 运维平台

• 大数据平台

• 自动化：统一平台自动实现各类功能

• 接口自动化测试

• 全链路压测

• 故障自动分析

• 可视化：状态、功能、操作等可视化

• 系统状态可视化

• 任务管理可视化

• 任务执行可视化

5.4.2、四个核心平台

• 运维平台

• 配置

• 部署

• 监控

• 应急

• 测试平台

• 用例管理

• 资源管理

• 任务管理

• 数据管理

• 存储平台

• SQL 平台

• NoSQL 平台

• 小文件存储

• 大文件存储

• 大数据平台

• 离线处理

• 在线处理

• 推荐系统

相比百万级用户架构，千万级用户架构由于系统复杂度、团队规模的原因，如下几个方面会使得运维平台的建设成为必要：

• 系统质量

• 团队效率

• 投入产出比

5.5、其它架构设计

把百万及以下规模级的计算架构放在这里了。

5.5.1、计算架构 - 单机房内负载均衡

最重要的变化是上了硬负载均衡

千万级用户单机房负载均衡架构

5.5.2、计算架构之缓存架构

和百万级用户、十万级用户的一样。因为是私密聊天，群聊规模不大，不需要把一个群聊的计算都集中在一个计算节点上，这样进程内缓存的必要性就不是很大了。

5.5.3、高可用架构

千万级用户 IM 直接使用双活架构。千万级用户也是一个很宽阔的范围，（根据演进原则）华仔给出了如下的演进路线图：

1. 同城双活

2. 异地多活

6、亿级用户规模 IM 架构设计

6.0、业务场景的变化

1. 技术团队增长到上千人，IM 业务分了很多业务线；

2. 所谓业务线，个人理解还是和业务域差不多，只是更加适配更大规模的组织架构：

亿级用户的业务线组成

2. 很多外部企业想合作；

3. 以前老板说“钱和人不是问题”，现在老板一看成本就觉得是大问题。

6.1、核心复杂度的变化

千万用户规模的时候已经全面完善了，亿级的时候还能做什么呢？好像没事可做了。其实不然，需要做的，是从稳定、成本、开放三个方面做全面优化。

亿级用户复杂度演进

6.2、总体架构思路

• 稳定

• 分区架构

• 自建机房：像抖音都在一定的用户规模之后，开始自建机房。

• 虽然银行等行业也是自建机房，但个人体会华仔课程里的自建机房阶段是用户规模达到一定程度，且基础设施在千万级规模时已经完善的基础上进行的；银行业则不同，虽然自建机房的初衷稳定性也是一个出发点，但是合规因素也是很重要的考量点；且银行业自建机房是基于上一代技术浪潮的基础技术之上的，如何在现有基础之上迭代升级，这就是所谓的“先发劣势”吧。

  现在的互联网还都比较年轻，没有经历代际的技术迭代升级，他们如何面对，还没有经验可循。

• 开放

• 开放平台：对外开放内部能力；

• 每个巨大体量的平台，其能力应该是独特的，比如支付宝和微信，可以向外开放。但是银行有很多家，大家都差不多，没有一个像微信这样统治某个领域的巨无霸（如果说有的话，只能看银联了，但是它又太松散），可以说没有独特的能力，又不可能合并，所以银行的开放平台开放不起来。

  虽然各个互联网巨头看似领域不同，但在 C 端流量的争夺上，他们是一回事，所以可以和银行业做对比，争夺同一块蛋糕。

  这个问题应该只有经济学可以解答了。

• 生态建设：基于用户规模的生态建设，依赖于开放平台向外开放内部能力，同时还要引入外部能力。

• 生态建设，一定是有一个中心的，这个中心体量显著大于生态内的其它节点；反之，向腾讯和阿里之间是没有生态建设的。反观银行业，比如头部银行，就类似于腾讯和阿里，没有生态，只有互联互通。现在国家也强制要求互联网巨头互联互通，会怎么演化呢？

• 成本

• 优化：降低硬件、网络、机房成本

• 创新：自研代替开源，或者深度定制化

6.3、稳定性架构设计

• 分区架构：即按用户地理位置进行分区。

• 自建机房

1. 省成本；

2. 自定义标准；

3. 安全。

6.4、开放平台架构设计

6.4.1、开放平台架构设计原则

• 安全：主要是数据安全，包括用户数据、财产、隐私安全

• 认证

• 授权

• 漏洞扫面等

• 稳定：保证应用和系统的稳定

• 不仅提供对三方的生产支持，还有提供测试支持

• 三方应用和主应用隔离

• 易用：保证第三方的开发和运营效率

• 开发者工具

• 支撑文档

• 数据分析

• 推广系统

• 共赢

• 流量分配

• 收入分成

• 广告营销

6.4.2、开放平台基本架构

开放平台基本架构

从上图来看，一个三方应用接入的网关和开放平台之间：

• API 都有

• SDK，只有开放平台有，网关只有接口

• 开发平台：网关是没有的，三方只是按照接口自行开发

• 沙箱环境：网关没有，双发自行搭建、连通测试环境

• 管理后台：网关和三方各自有管理后台

• 运营后台：网关和三方各自有运营后台

• 分析后台：网关和三方各自有分析后台

• 结算后台：网关和三方各自有结算后台

可见，一个三方应用接入网关和开放平台相比，最大的不同就是网关对中小商户的支持不好，对开发能力有要求。微信开发平台对这各种三方都考虑到了：

• 公众号

• 小程序

• 三方授权开发

6.5、其它架构设计

6.5.1、降成本设计

• 调优：根据业务场景优化各种参数，比如数据库调优、Linux 调优等；

• 定制化：根据业务场景定制各种系统，比如 Linux 定制、JVM 定制；

• 自建：用自建系统替换开源或商业系统

需要各类技术专家。

6.5.2、创新

主要驱动因素：降成本、突破性的解决方案，和人才、组织、业务都有关系。

7、架构演进总结

架构演进总结