十万级到亿级用户 IM 系统实战

一、架构重构技巧

1、架构重构定义

　　代码重构

　　　　定义：对软件代码做任何改动以增加可读性或者简化结构而不影响输出结果。

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

　　　　关键点：不影响输出；不修正错误；不增加新的功能性。

　　　　特别要强调的是，在代码重构的时候，如果看到代码的实现逻辑不合理，想要加一个逻辑或者删除一个逻辑，多输出一个东西等等，千万不要这么做，因为虽然你看起来不合理，很有可能是为了应对一些特殊的场景而处理的，如果不经过求证直接修改，就会影响一些特定的功能。

　　架构重构：

　　　　定义：通过调整系统结构（4R）来修复系统质量问题而不影响整体系统能力。

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

　　　　关键点：修复质量问题，提升架构质量；不影响整体系统功能；架构本质没有发生变化。即不会从支持百万级用户变为可以支持千万级。因为架构重构的目的是为了修复质量，如果为了提升用户量级，就需要架构演进了。

　　对比：

　　　　　　　　 

2、架构重构技巧

　　架构重构的手段可以使用增删改拆合，增删改拆合的对象是4R架构的Role、Relation、Rule，例如Role就是架构重构最常见的对象，例如微服务拆分、微服务合并等，Relation也是可以重构的，例如将服务直接的交互方式由http改为rpc。

　　架构重构不会涉及Rank，因为Rank的调整一般是属于架构演进，例如支付宝从淘宝中拆出来，这就是改变了Rank，是属于架构演进，其对于团队和组织的影响是非常大的。

　　　　　　　　

 　　（1）技巧1 - 先局部优化后架构重构

　　　　局部优化：对部分业务或者功能进行优化，不影响系统架构。常见手段：1. 数据库添加索引，优化索引；2. 某个数据缓存更新策略采用后台更新；3. 增加负载均衡服务数量；4. 优化代码里面并发的逻辑；5. 修改 InnoDB buffer pool 配置，分配更多内存；6. 服务间的某个接口增加1个参数

　　　　架构重构：优化系统架构，整体提升质量，架构重构会影响架构的4R定义。常见手段：1. 引入消息队列（增加 Role）；2. 去掉 ZooKeeper，改为内置 Raft 算法实现（删除 Role）；3. 将 Memcached 改为 Redis（改变 Role）；4. 按照稳定性拆分微服务（拆分 Role）；5. 将粒度太细的微服务合并（合并 Role）；6. 将服务间的通信方式由 HTTP 改为 gRPC（修改 Relation）；7. SDK 从读本地配置文件改为从管理系统读取配置（修改Rule）

　　（2）技巧2 - 有的放矢

　　　　明确目标：不要试图解决所有的问题，抓住关键问题。技巧：问题分类：问题收集列表可能有100条，不要全部想着通过架构重构解决，分门别类，找出需要架构重构解决的问题。

　　　　明确时间：要有明确的时间点和里程碑，不要说“慢慢优化”。技巧：独立版本：不要混在业务版本里面做架构重构，否则不好协调资源。

　　　　明确结果：需要有量化的指标来衡量，不能说“提升 xxx 质量”。技巧：1. 先收集系统已有相关数据，适合项目投入、时间等；2. 调查问卷：适合效率、复杂度等

　　　　案例：

　　　　　　如下面的图示，原来的M系统既对接P业务，又对接其他业务的共享数据，造成的问题是：开发效率很慢，P业务和M系统互相影响；线上问题很多，尤其是数据类问题；M系统性能很低。 

　　　　　　针对上述几点问题，首先就是要抓关键，对于该问题，关键就是P业务和M系统互相影响，那么就可以重新拆分一个P业务后台出来，专门对接P业务。而其他的开发效率慢、线上问题多、性能低等问题，实际上只要拆分了系统，很多东西都会迎刃而解，就算还有问题，对于单一系统来说，优化也会简单很多。

　　　　　　　　 

　　技巧3 - 合纵连横

　　　　合纵：说服业务方和老板。以数据说话：把“可扩展性”转换为“版本开发速度很慢”，然后给出对应的项目数据。以案例说话：如果没有数据，就举极端案例，例如某个小功能，开发测试只要5天，但是等了1个月才上线

　　　　连横：说服其它团队。换位思考：思考对其它团队的好处，才能让人配合。合作双赢：汇报和总结的时候，把其它团队也带上

　　　　案例：还是以上述业务拆分为例。合纵：告诉产品经理和项目经理极端案例：设计2周、开发2天、一个月才上线，那么产品经理和项目经理听了之后就会认识到这个非常影响版本迭代，就会要求尽快做架构重构。连横：去和负责P业务的团队沟通，原来P业务和M业务融合在一起，那么迭代速度、问题排查都会有很大影响，同时业务还会相互影响，因此可以和P业务团队沟通重构的好处，就是P业务线上问题大大减少，P业务不会被其它业务影响，那么P团队也会欣然接受。

　　　　　　　　

　　技巧4 - 运筹帷幄

　　　　问题分类：将问题分类，一段时间集中处理一类问题。避免对照 Excel 表格，一条一条的解决。

　　　　问题排序：分类后排序，按照优先级顺序来落地。避免见缝插针式的安排重构任务。见缝插针虽然可以不影响业务，但是会造成两方面的问题：1、见缝插针的重构，产品侧有时候会要求业务进度，就导致不能安排大一点的重构任务；2、重构拆分的很细，会导致效果不明显，虽然自己做了很多工作，但是是将重构拆分为一点一点来处理的，最后却体现不出来很好的结果。

　　　　逐一攻破：每一类问题里面先易后难。把容易的问题解决掉，增强信心。另一方面，把简单的解决完之后，有可能难得问题就会变得简单，甚至消失不见。

　　　　案例：例如一个项目之前收集了1个100多行的 Excel 问题表格，然后采取的是见缝插针的方式一个一个的解决；为了不影响业务版本，那么只能专挑软柿子捏，见缝插针，最后导致一些核心的重构迟迟不能落地。

　　　　　　　后面为了更好落地重构，将问题分类，分为：性能、组件、架构、代码；然后指定阶段处理计划：优化 -> 架构重构 -> 架构演进；最后专项落地：明确时间、目标、版本。如下图所示，第一阶段是优化，第二阶段是组件化，也就是重构，第三阶段是解耦，也就是架构演进。

　　　　　　　　

　　架构重构的一些典型问题：

　　　　架构重构是否可以引入新技术：可以，但尽量少，架构重构要求快准。

　　　　业务不给时间重构怎么办：会哭的孩子有奶吃。

　　　　其它团队不配合怎么办：学会利用上级力量。

　　　　业务进度很紧，人力不够怎么办：收集需要重构的证据，技术汇报的时候有理有据。

二、架构演进技巧

　　1、架构演进剖析

　　　　通过设计新的系统架构（4R）来应对业务和技术的发展变化。其目的是：应对业务发展带来新的复杂度；应用技术发展带来的复杂度新的解决方法。架构演进的关键点是：新架构；新的复杂度；新的方法。

　　　　案例：淘宝去 IOE 是因为业务发展大了后，IOE 的成本和可控性难以满足，而不是性能。引入容器化来实现弹性部署，降低成本，提升运维效率。

　　　　架构重构 VS 架构演进

　　　　　　可以看到，我们不能从技术的角度来区分架构重构和架构演进，而应该是从复杂度的角度来看，修复复杂度，就是架构重构，如果是新的复杂度，则是架构演进。

　　　　　　　　

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

　　　　两个驱动力：业务发展带来新的复杂度，ToC 业务主要体现在用户规模增长和业务多样性；技术发展带来新的复杂度应对方法，例如国产化，大数据、云计算等。

　　　　两种模式：主动演进：架构师主动识别和规划架构演进；被动演进：架构师被迫进行架构演进。

　　　　无论是业务发展还是技术发展，主动演进还是被动演进，总体来说还是为了业务发展。

　　　　　　　　

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

　　　　业务驱动的架构演进主要是由于架构的规模、或者业务的多样性、或者业务的方向发生了变化。

　　　　　　　　

　　　　架构演进模式 vs 业务发展模式

　　　　　　主动演进：业务规模：量变带来质变，一般10倍量级变化才考虑架构演进；业务多样性：业务规模可能没有变化，但是系统支持的业务类型越来越多。

　　　　　　被动演进：业务方向：业务调整方向，例如从图文转为短视频

 　　　　不同用户规模的架构挑战

　　　　　　例如十万用户可能单体架构就可以，百万用户就需要微服务，千万用户就需要多机房部署，亿级用户就需要进行分区部署了。

　　　　　　　　

 　　　　业务驱动的主动演进技巧 - 做好预判，提前布局

　　　　　　预判：提前1年做好准备。以增长数字为标准：下一阶段用户规模60%的时候就要准备了；以时间为标准：提前1年预判

　　　　　　布局：团队和技术先行。招聘人员；储备技术。不能等到要做架构演进了才临时招聘人员。

　　　　　　例如： 当前用户60万，下一级的典型用户规模是100万，那么就可以开始考虑架构演进了，别等到100万再演进；今年用户30万，老板说明年就要达到100万，今年就开始考虑架构演进。

　　　　业务驱动的被动演进技巧 - 快速响应，拿来主义

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

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

　　　　　　例如：可能 Elasticsearch 更好，如果不熟悉，先用 MySQL 顶着；购买云服务的解决方案，例如直播、视频这样的业务；尽量多用开源的方案。但是最好的还是架构师要有尽量多的知识储备。

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

　　　　技术驱动演进的第1原则 - 新瓶旧酒原则

　　　　　　新瓶旧酒原则：使用新的技术来解决老的问题或者老的复杂度，不要为了尝试新技术而演进。那么新技术就需要在降本、增效、提质三个方面有效果才行。

　　　　　　降本：降低成本，包括硬件、人力、运营等成本。例如：上云来降低运维和机房成本；去 IOE 降低硬件成本；机器图片审核降低审核人员成本。

　　　　　　增效：提升效率，包括处理、运营、开发运维效率等。例如：大数据平台提升大数据分析效率；容器化提升运维效率；微服务提升开发效率。

　　　　　　提质：提升质量，包括业务、管理、开发等。例如：推荐系统提升用户转化率；容器化支持弹性扩容应对业务峰值；中台提升多业务的开发效率；提升业务竞争力。　　　

　　　　技术驱动演进的第2原则 - 价值原则

　　　　　　价值原则：新技术要带来典型的价值才考虑演进。

　　　　　　“典型”的定义：产出要远远大于投入！例如：20台服务器降到10台和2000台降到1500台，虽然前面的比例大，但是肯定是后面的情况价值更大；再例如2000人日降到1000人日和100人日降到10人日，也是同样的问题。至于转换率提升2%、用户留存提升10%这种，需要转换为具体的金额或者数字去做对比。

　　　　技术驱动演进的技巧 - 如何说服老板进行演进？

　　　　　　技巧1 - 谈钱，别谈感情（适合成熟技术）

　　　　　　　　将引入新技术带来的价值量化成 money，然后附带说提升技术水平，提升团队动力，不要本末倒置！

　　　　　　技巧2 - 谈竞争对手（适合全新技术）

　　　　　　　　如果你没办法量化为钱，那就看看竞争对手是否引入了，如果不引入就会落后等等，“吓唬吓唬”老板！

　　　　　　技巧3 - 谈大环境（适合法律政治相关）

　　　　　　　　例如国产化，跟老板谈政治意义和大环境变化……

　　　　技术驱动演进的技巧 - 做好洞察，提前布局

　　　　　　洞察：识别新技术能够为业务带来的价值。多关注业界技术大会；熟练掌握业务；把握技术本质。

　　　　　　布局：团队和技术先行。招聘人员；储备技术。

　　4、架构演进案例

　　　　下图是淘宝的业务驱动架构演进案例，最早的淘宝使用的是PHP+mysql，随着用户量的增加进而产生了性能问题，改为 Java + Oracle，再后来由于用户量的进一步增加，导致 IOE 成本特别高，因此就开始使用自己实现的中间件。

　　　　　　　　

 　　　　下图是技术驱动架构演进案例，这是一个推荐系统，例如最早的时候是嵌入到各个系统；第二阶段做成了平台化，已经有了推荐能力的平台；第三阶段是智能化，引入了人工智能技术，从而提升推荐能力；再后来是产品化，推荐能力标准化产品化，通过云平台输出给第三方。

　　　　　　　　

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

　　1、业务背景

　　　　假设你现在正在一个创业公司担任 CTO，因为微信工作生活娱乐不区分，已经发生了很多次将敏感信息（可以自行脑补一下）发错人甚至发错群的尴尬事件了！你司 CEO 决定做一款 IM 工具，为了区别微信和 QQ 大众化的 IM 需求，你们公司主打安全 IM，这款产品的竞争力如下：主打私密聊天，严格控制私密好友的数量，而不是像微信一样，买个菜都可能要加个微信。

　　　　公司背景：

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

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

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

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

　　　　基本业务场景：

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

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

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

　　　　　　　　只能创建一对一聊天；

　　　　　　　　聊天消息“阅后即焚”，最多只保留60分钟；

　　　　　　　　无需使用手机号注册；

　　　　　　　　每个用户最多20个好友。

　　2、总体架构思路

　　　　老板说我们3年内要做到1千万注册用户，作为 CTO 的你应该如何做架构设计？首先来看十万、百万、千万量级设计的优缺点：

　　　　　　十万：落地快，但是如果业务发展很快，架构很快不适应了怎么办？百万：落地慢一些，但同样面临业务发展过快的风险。 千万：落地时间可能要6个月以上，但基本上3年内无需再动架构

　　　　另外，超前设计，架构真的不用动么？

　　　　　　业务规模变化：可以超前化设计应对。

　　　　　　业务多样性：无法预测会做什么功能，业务多样性会导致团队人数增多到多少更加无法预测。

　　　　　　技术发展：无法预测，尤其是和法律政策相关的，例如区块链、国产化等

　　　　就算超前设计3年后的架构，也只能应对规模的变化，业务多样性和技术的变化是不可预知的

　　　　因此综上所述，可以先按照十万或者百万来设计，这里我更倾向于十万用户的设计，因为其可以快速上线，验证用户的需求，且刚上线时，用户本身也不会太多。

　　　　　　　　

　　3、存储架构设计

　　　　十万用户规模存储性能估算：

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

　　　　　　登录：虽然 IM 是比较活跃的产品，但由于是全新的产品，我们假设十万注册用户，每天活跃用户有40%，登录每天4万。

　　　　　　加好友：每个活跃用户最多20个好友，好友关系数 4万 * 20 = 80万 关系数据。

　　　　　　聊天：假设每个活跃用户每天向5位好友发送100条消息，则消息数量为：4万 * 5 * 100 = 2000万，且数据当天基本都被删除了，所以写入、读取、删除次数都可以估算为2000万。

　　　　存储架构设计：

　　　　　　10万用户注册信息，4万登录请求，80万关系数据。 2000万写入，2000万读取，2000万删除。那么综合来看，使用Mysql主备来存储用户数据和关系数据即可，用Redis主备存储聊天数据即可，这里没有用主从，是因为主备已经能满足业务需求，如果使用主从的化，反而会增加复杂度。

　　　　　　　　

　　4、计算架构设计

　　　　十万用户规模计算性能估算：

　　　　　　注册：1年达到十万用户注册，注册 TPS 很低。

　　　　　　登录：虽然 IM 是比较活跃的产品，但由于是全新的产品，我们假设十万注册用户，每天活跃用户有40%，假设登录时间集中在早晚4小时，登录 TPS均值：4万 / 14400 = 3。

　　　　　　加好友：每个活跃用户最多20个好友，好友关系数 4万 * 20 = 80万数据，按照1年内来计算，TPS 可以忽略不计。

　　　　　　聊天：假设每个活跃用户每天向5位好友发送100条消息，则消息数量为：4万 * 5 * 100 = 2000万；假设每天集中在早中晚3个时间段6小时内（早上1小时中午1小时晚上4小时）；发送消息 TPS：2000万/（3600*6）≈ 1000；读取消息 QPS = 发送消息 TPS，删除消息 TPS ≈ 发送消息 TPS。

　　　　计算架构之负载均衡：

　　　　　　根据性能估算，使用一个Nginx负载均衡即可，Nginx间使用KeepLived保证高可用。

　　　　　　　　

　　　　计算架构之缓存架构：

　　　　　　可以使用App缓存、Web缓存、分布式缓存，由于聊天数据已经使用了Redis存储，因此分布式缓存可以直接使用Redis，Web缓存这里主要存储的是一些静态资源，直接使用Nginx存储即可。

　　　　　　　　

　　5、其它架构设计

　　　　可扩展架构设计

　　　　　　在服务划分时，可以使用下面三种架构，在做架构选型时，会选择第二种。首先来说第三种，用户服务和关系服务的关系比较紧密，另外拆分成三个微服务后，就可能要引入一些微服务的基础设施，这个有点得不偿失，另外人员也就六七个人，拆分为三个服务也不是很合适；再说单体架构，由于用户服务和聊天服务的存储都不一致，放在一起并不是很合适；而拆分成两个服务，无论是服务的关系和开发人员来说，都比较符合三个火枪手原则，因此方案二会更好。

　　　　　　　　 

 　　　　高可用架构设计 - 同城数据灾备

　　　　　　可以看到，Mysql数据库使用了同城数据灾备，而Redis并没有，是因为Redis 存储的 IM 消息数据本来就是六十分钟就会删除或者是阅后即焚，因此没有必要做备份。

　　　　　　　　　

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

　　1、业务背景

　　　　经过公司上下努力，IM 业务蒸蒸日上，数据增长很快，用户活跃数量在短短1年多的时间里面已经上升到60多万了，很快就要迈上百万大关了，你作为公司 CTO，前瞻性的预判到业务发展给技术带来了挑战，于是准备启动架构演进。

　　　　公司背景变化：

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

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

　　　　业务基本场景：

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

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

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

　　　　　　只能创建一对一聊天；

　　　　　　聊天消息“阅后即焚”，最多只保留60分钟；

　　　　　　无需使用手机号注册；

　　　　　　每个用户最多20个好友；

　　　　　　增加群聊功能，每个私密群聊限制人数为5人。

　　2、总体架构思路

　　　　演进应该时按照百万、千万、亿级的哪个量级来做的？一般情况下，会按照百万来做。

　　　　　　　　

　　　　来自老板的两大挑战应对技巧：

　　　　　　挑战1：纳尼，这么快就要架构演进？ 

　　　　　　　　说明当时的业务不确定性；

　　　　　　　　说明当时的技术团队规模；

　　　　　　　　演进的驱动力是业务快速发展；

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

　　　　　　挑战2：为什么不直接做千万或者亿级架构，这样不就可以一劳永逸了么？

　　　　　　　　团队规模（“30~100人，按照百万规模设计最好”）；

　　　　　　　　“得加钱”：直接设计千万级别架构要很多钱（多机房、异地多活等）；

　　　　　　　　业务规模可以预测，但是业务复杂度不太好预测（例如：会不会支持比特币支付？）。

　　3、存储架构设计

　　　　百万用户规模存储性能估算

　　　　　　注册：百万用户注册信息。

　　　　　　登录：百万注册用户，每天活跃用户有40%，登录时读取用户信息是每天40万QPS。

　　　　　　加好友：每个活跃用户最多20个好友，好友关系数 40万 * 20 = 800万数据。

　　　　　　聊天：假设每个活跃用户每天向5位好友发送100条消息，则消息数量为：40万* 5 * 100 = 2亿，且数据当天基本都被删除了，所以写入 + 读取 + 删除 =6亿。

　　　　　　群聊：假设活跃用户中有10%的用户发起群聊，平均每人每天2个，每个群聊每天200条消息。• 消息写入：40万 * 10% * 2（群聊） * 200（消息） = 1600万数据；• 消息删除次数：等于消息写入数量；• 消息读取量：1600万 * 5（每个群最多5人） = 8000万/天。

　　　　存储架构设计：

　　　　　　根据上面的分析，100万用户注册信息，40万登录请求，800万关系数据。聊天：6亿读写请求/天；群聊：1亿读写请求/天。Mysql 还可以使用主备来存储，而Redis就由主备改为了 Redis Cluster存储，这是因为随着业务的发展，用户可能逐步达到100万、200万、300万，如果使用Redis Cluster，用户量的增加不需要变更存储方式，只需要加 Redis 服务器即可。

　　　　　　　　　　 　

　　4、计算架构设计

　　　　百万用户规模计算性能估算

　　　　　　注册：每日新注册用户不到1万，可以忽略。

　　　　　　登录：虽然 IM 是比较活跃的产品，但由于是全新的产品，我们假设百万注册用户，每天活跃用户有40%，假设登录时间集中在早晚4小时，登录 TPS 均值：40万 / 14400 = 30。

　　　　　　加好友：每个活跃用户最多20个好友，好友关系数 40万 * 20 = 800万数据，按照1年内来计算，TPS 可以忽略不计。

　　　　　　聊天：假设每个活跃用户每天向5位好友发送100条消息，则消息数量为：40万 * 5 * 100 = 2亿，假设每天集中在早中晚3个时间段6小时内（早上1小时中午1小时晚上4小时），TPS 计算为：2亿/（3600*6）* 3（发+收+删） ≈ 30000。

　　　　　　群聊：假设活跃用户中有10%的用户发起群聊，平均每人每天2个，每个群聊每天200条消息，时间段分布和聊天场景一样。• 消息写入和删除次数：40万 * 10% * 2 *200 * 2（写+删） /（3600*6） = 1600 TPS；• 消息读取量：1600 TPS * 5（每个群最多5人） = 8000 QPS。

　　　　计算架构之负载均衡

　　　　　　从上面的分析来看，聊天的TPS为3W，群聊的TPS为8K，综合的TPS约为4W，那么还使用Nginx即可。

　　　　　　　　

 　　　　　　但是随着用户量的增加，如果增加到300W，那么简单的估算，TPS就会达到12W，那么Nginx性能就不能满足，就需要改为LVS做负载均衡。

　　　　　　 计算架构之负载均衡 - 架构重构

　　　　　　　　

 　　　　计算架构之缓存架构

　　　　　　缓存架构没有变化，还是使用三级缓存即可。

　　　　　　　　

　　5、其它架构设计

　　　　可扩展架构设计 - 微服务拆分

　　　　　　随着用户的增加和开发人员的增加，就可以将服务进行微服务拆分，在微服务拆分的同时，就需要引入微服务基础设施。

　　　　　　　　

　　　　高可用架构设计 - 同城双中心

　　　　　　由于用户在不到百万时，单机房就可以满足业务，因此可以使用同城灾备部署，但是随着用户量的增加，就需要使用同城双活。这里有个问题，为什么不一开始就是用同城双活，这是因为同城双活的复杂度会提高很多，例如Redis Cluster，如何部署等等，都会提高复杂度，因此在满足业务需求时，使用同城灾备即可，如果不能满足，再使用同城双活。

 　　　　　　　　

 　　　　大数据架构设计

　　　　　　hadoop & spark：功能强大，可扩展性强；数据分析师不会用；支持后续的推荐等业务。

　　　　　　Clickhouse：兼容 SQL，维护使用简单；性能强劲，OLAP 分析平台。

　　　　　　根据上面对于 hadoop & spark 和Clickhouse的对比，前期可以使用Clickhouse。

　　　　架构要解决的核心复杂度：

　　　　　　当用户量十万时，核心是快速验证（核心需求）；当用户量百万时，核心是快速扩展（辅助需求）

　　　　十万用户架构 vs 百万用户架构 架构演进对比：

　　　　　　　　

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

　　1、业务背景

　　　　业务背景：

　　　　　　经过2年的努力，业务发展达到一个新的高度，很快就要迈上千万日活大关了，你作为公司 CTO，前瞻性地预判到业务发展给技术带来了挑战，于是准备启动架构演进。

　　　　　　公司背景变化：技术团队从30人增长到100人，覆盖完整的技术栈，包括大数据、风控安全等；由于公司的业务发展良好，证明了业务模式，业内已经有几家竞争对手出现了。

　　　　业务基本场景：

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

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

　　　　　　只能创建一对一聊天；

　　　　　　聊天消息“阅后即焚”，最多只保留60分钟；

　　　　　　无需使用手机号注册；

　　　　　　每个用户最多20个好友；

　　　　　　增加群聊功能，每个私密群聊限制人数为5人；

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

　　2、总体架构思路

　　　　实际的总体架构思路 - 分级架构

　　　　　　不同架构师的职责有什么区别？

　　　　　　　　总架构师（P9）的核心职责：1. 划分业务域；2. 基础技术平台完善。

　　　　　　　　业务域架构师（P8）的核心职责：1. 划分业务域内的微服务；2. 按照用户规模设计架构。

　　　　　　感觉总架构师要运维、测试、大数据都要懂，这个怎么做到的？

　　　　　　　　每个技术域需要一个P8的负责，但总架构师确实每个领域都要懂一些（技术广度）。例如：全链路压测什么时候实现？用什么方案？需要总架构师一起决策。

　　　　　　各个业务域内的架构，总架构师是不是不需要关注？

　　　　　　　　基本上是的，除非某个域问题很多，例如线上质量问题、开发效率问题等。

　　　　　　业务域划分是总架构师划分就可以了么？

　　　　　　　　实际上是由老板、业务方、总架构师一起讨论确定的，不单是一个技术决策，还是一个权力决策。

　　　　　　　　 

　　3、业务域划分

　　　　业务域划分粒度

　　　　　　三个火枪手原则的延续，一个业务域一个 P8，一个 P8 管理范围大约是30人！

　　　　　　　　 

 　　　　业务域划分

　　　　　　可以看到，随着业务的发展，用户域新增了VIP服务，聊天域新增了红包服务，综合域新增了支付服务。

　　　　　　　　

　　4、基础技术建设

　　　　基础技术的“四化建设”

　　　　　　规范化：统一的各类规范。例如：日志规范；开发框架；RPC 框架；接口规范；代码管理规范。

　　　　　　平台化：基于规范实现的统一平台。例如：测试平台；运维平台；大数据平台。

　　　　　　自动化：统一平台自动实现各类功能。例如：接口自动化测试；全链路压测；故障自动分析。

　　　　　　可视化：状态、功能、操作等可视化。例如：系统状态可视化；任务管理可视化；任务执行可视化。

　　　　基础技术的“四个核心平台”

　　　　　　运维平台：配置；部署；监控；应急。

　　　　　　测试平台：用例管理；资源管理；任务管理；数据管理。

　　　　　　存储平台：SQL 平台；NoSQL 平台；小文件存储；大文件存储。

　　　　　　大数据平台：离线处理；在线处理；推荐系统。

　　5、其它架构设计

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

　　　　　　随着用户量的增加和性能要求的增加，需要在Nginx上层再加一个F5来做负载均衡。

　　　　　　　　

 　　　　计算架构之缓存架构

　　　　　　　　

　　　　高可用架构设计1 - 同城双活

　　　　　　　　

　　　　高可用架构设计2 - 异地双活

 　　　　　　　　

　　　　　　至于到底要同城双活还是要异地双活，这个可以视情况而定，例如首先使用同城双活，如果用户量继续增加，可以在同城双活的基础上在异地再新增一个IDC，虽然两地三中心的方式会比异地双活更麻烦，但是这是从同城双活演进到的两地三中心，因此复杂度还是可以接受的。

　　　　架构要解决的核心复杂度

　　　　　　十万用户的核心要点是快速验证（核心需求）；百万用户的核心要点是快速扩展（辅助需求）；千万用户的核心要点是全面完善（基础技术）

　　　　百万用户架构 vs 千万用户架构 架构演进如下图所示：

　　　　　　　　

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

　　1、业务背景

　　　　业务背景：

　　　　　　经过N年的努力，公司的 IM 业务已经跻身业界前三，已经超过6000万用户，作为创业功臣的你，此时正享受成功带来的喜悦。虽然业务发展势头良好，你以为可以高枕无忧了，但“革命尚未成功，同志仍需努力”，业务的发展带来了新的技术挑战。

　　　　　　公司背景变化：技术团队增长到上千人，IM 业务分了很多业务线；很多外部企业想合作；以前老板说“钱和人不是问题”，现在老板一看成本就觉得是大问题。

　　　　业务线划分：

　　　　　　　　 

　　　　可以看到，红包业务从IM线移动到了基础线，因为用户量到达亿级之后，红包就可能用于其他很多地方，就不单单属于IM线了；同时增加了安全线，在安全线中有分控和合规两个微服务。

　　2、总体架构思路

　　　　架构要解决的核心复杂度：十万用户，快速验证（核心需求）；百万用户，快速扩展（辅助需求）；千万用户，全面完善（基础技术）；亿级用户，好像没事做了？

　　　　其实不然，亿级用户规模情况下，工作内容更多了，首先从总体架构思路来看，可以从稳定、开放、成本三方面进行建设：

　　　　　　　　 

　　3、稳定性架构设计

　　　　分区架构：

　　　　　　　　

 　　　　自建机房：

　　　　　　省成本；自定义标准；安全

　　4、开放平台架构设计

　　　　开放平台架构设计原则：

　　　　　　安全：保证用户数据、财产、隐私安全，包括授权、认证、漏洞扫描等。

　　　　　　稳定：保证应用和系统的稳定，包括第三方应用测试、第三方应用与主应用隔离等。

　　　　　　易用：保证第三方的开发和运营效率，包括开发工具、支撑文档、数据分析、推广系统等。

　　　　　　共赢：保证平台和第三方共赢，包括流量分配、收入分成、广告营销等。

　　　　开放平台基本架构

　　　　　　沙箱环境：第三方应用测试，数据与线上数据隔离；

　　　　　　管理后台：第三方应用审核、上架、下架；

　　　　　　运营后台：第三方应用流量分配、推广、曝光等；

　　　　　　分析后台：第三方应用统计分析，例如安装量、访问量、活跃数等；

　　　　　　结算后台：第三方应用分成结算等。

　　　　　　　　

　　5、其它架构设计

　　　　降成本设计：

　　　　　　调优：根据业务场景优化各种参数。例如：Linux 调优、数据库调优。

　　　　　　定制化：根据业务场景定制各种系统。例如：Linux 定制、JVM 定制、服务器定制、硬盘定制……

　　　　　　自建：用自建系统代替开源或者商业系统。例如：去 IOE、OceanBase。

 　　　　创新：

　　　　　　源于自建，超越过去！主要驱动因素：降成本，突破性的解决方案。分析一下如下几个案例的驱动因素：Google 的 GFS；蚂蚁的 OceanBase；Facebook 的 HHVM。

　　　　架构要解决的核心复杂度：

　　　　　　十万用户，快速验证（核心需求）；百万用户，快速扩展（辅助需求）；千万用户，全面完善（基础技术）；亿级用户，全面优化（稳定、成本、开放）

　　　　千万用户架构 vs 亿级用户架构 之 架构演进