代码重构
定义：对软件代码做任何改动以增加可读性或者简化构造而不影响输出结果。
目的：增加可读性、增加可掩护性、可扩展性。
关键点：不影响输出；不改动缺点；不增加新的功能性。
特殊要强调的是，在代码重构的时候，如果看到代码的实现逻辑不合理，想要加一个逻辑或者删除一个逻辑，多输出一个东西等等，千万不要这么做，由于虽然你看起来不合理，很有可能是为了应对一些分外的场景而处理的，如果不经由求证直接修正，就会影响一些特定的功能。
架构重构：
定义：通过调度系统构造（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万/（36006）≈ 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亿/（36006） 3（发+收+删） ≈ 30000。
群聊：假设生动用户中有10%的用户发起群聊，均匀每人每天2个，每个群谈天天200条，韶光段分布和谈天场景一样。• 写入和删除次数：40万 10% 2 200 2（写+删） /（36006） = 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 亿级用户架构 之 架构演进
