现状

我记得去年脉脉的论调还都是 客户端已死，前后端还都是一片祥和，有秀工资的，有咨询客户端转前端的，怎么最近打开脉脉一看，风向变了？

随便刷几下，出来的信息都是 前端已死，这种悲观信息，还有失业找不到工作的。

思考

我有时候会想，开源是个好东西，拉低了技术的门槛，好像再难的需求，只要善用搜索引擎，都能找到前人喂到嘴边的答案，如果没有开源文化，甚至自己能不能进入互联网开发行业都不好说。

记得那一年：

我第一次接触技术领域，开始在百度输入前端开发相关的问题，发现出来的结果都是 csdn、博客园、简书等网站的内容，打开了新天地，我开始吸取前辈们的经验和心得，他们分享的各种书上学不到的知识让我解决了工作中遇到的各种问题，让我感叹 开源真好；

我发现程序员们都推崇谷歌搜索和谷歌浏览器，于是自己也开始使用，发现 真香；

我日夜沉迷在技术研究上，为自己找到了一份兴趣爱好和职业相结合的工作而庆幸和兴奋；

大佬们都说要追求 高复用、高内聚、低耦合、易拓展，于是我忙不停蹄的学习这些概念和应用实践；

后来社区开始讨论 低代码，自动化，人工智能，大家好像都蛮兴奋的；

后来听说 客户端开发 不行了，小程序、h5 分走了大量的市场需求，我很庆幸，当初选择了前端，但我隐隐有些不安，因为我发现自己达到了 瓶颈，从业务开发中已经难有太多的技术提升了；

我开始学习 Java, springboot + mysql + mybatisPlus 做了一些简单的 crud，貌似并不是很难，我又有了些自信，以后前端干不了了，还可以搞后端；

我相信 如果一种思想不能拿出来给公众思辨，那么它和不存在没什么两样，所以我开始写博客，我认为这是最好的学习方式，但是我还不太擅长，22年一年才写了20+篇；

然后 chatGPT 出来了，我注册体验了一番，它真的可以在很多场景下协助我提升效率，这点资本也看得到，所以直接后果就是市场可能不需要那么多 开发者了, 这不局限在前端，甚至 chatGPT 更擅长写后端代码；

最后，互联网市场已进入红海之争了，存量市场下，开源节流是正常的操作，去年就经常看到外国各大大厂裁员的消息，国内就更不可能独善其身了；

总结

若没有开源文化，会不会互联网开发，也是一个越老越吃香的职业呢 [微笑]？我不知道，我是开源的受益者，我也愿意为开源做贡献，但是我不会期待它能给我带来多大的商业收益了，开源和商业付费之间，是两种文化之争；

最近core-js 作者对开源社区的“控诉”更是印证了我的看法： core-js 作者快被缺钱“拖垮”了：全职做开源维护 9 年，月均收入从 2500 美元锐减到 400 美元

前端已死 更多的是一种焦虑情绪的表达，市场确实不太好，但这并不是针对前端，整个互联网行业衰败的表现而已，对此持不同意见的怕是只剩培训机构了吧；

前端老鸟，市场还是需要和欠缺的，只是对于初中级前端太卷了，我建议应届生不要继续入门前端了，搞搞嵌入式开发，或者芯片之类的，门槛高一些。

总之，不用过于悲观，互联网风口过去了，还会有下一个风口，比如 web3, 人工智能，都可能带来新的市场机会，作为时代前沿的参与者，程序员因该更容易抓住这样的机会吧。

作者：Ethan_Zhou
来源：juejin.cn/post/7201047960826052667

动机

为什么程序员要学习英语？

• 工作：我们每天接触的代码都是英文的、包括很多技术文档也是英文的

• 学习：最新最前沿的技术最开始都是只有English版本

• 就业：学好英语让你的就业范围扩大到全球，而不只限于国内

目标

读： 流畅的阅读英文文档、英文论坛。

写： 可以简单的写一些英文的Issue、Readme等。

借助 APP

多邻国

多邻国是一个免费的多语言学习网站，界面清爽友好，对零基础非常友好，更有游戏般通关的体验。

不止可以学习英语更支持40+种语言的学习。

安卓、IOS都支持。

墨墨背单词

墨墨背单词是根据艾宾浩斯遗忘曲线的算法打造的高效抗遗忘，精准规划海量记忆的一款APP.

可以将不会的单词记录下到墨墨里就可以做到反复练习，强化记忆了。

安卓、IOS都支持。

借助影视剧

• 老友记

• 摩登家庭

• 绝望主妇

• ...（根据自己爱好选择）

浏览器插件

• 沙拉翻译

• DeepL

• immersive-translate

阅读提升

技术类

Vue、React、Node官方文档都可以，除此之外可以看看其他的技术网站：

• Github

• stackoverflow

• Dev

• Medium

• thehackernews

新闻类

如果你比较关注实时新闻的话，不妨多看看这些。

• foxNews

• Google News

• Yahoo! News

总结

没事刷刷美剧、看看英文论坛、新闻，然后将不会的单词在墨墨中反复练习。

然后经常逛逛Dev、StackOverflow等论坛，即可增加技术能力也可以熟悉学习英文。

再比如写中文文章写出来后尝试用英语也写一遍等等。

也可以和同学、朋友、网友一起尝试用英文沟通，如果有认识外国人(最近很火的chatGPT也可以)沟通就更好了。

总结一下，大概的方法：

1. 多看英文文档、论坛

2. 多使用英语交流、写作

3. 观看英语电影，电视和新闻

4. 使用英语学习软件和网站，比如多邻国这种

5. 加入英语学习小组或找英语学习伙伴一起学习

6. 并将不会的单词记录下到墨墨反复练习

最后，关键在于持之以恒。

作者：九旬
来源：juejin.cn/post/7199882882139373625

团队的技术方案设计模板

不管我们是做业务开发，还是做基础建设，虽然产品诉求千差万别，但是我们必然需要做好方案设计，然后还需要进行方案设计评审。

之前我们团队的一些成员，甚至有些 T9 级别的同学，竟然都写不好一个技术方案设计文档。究其根本，主要还是没有形成自己的方法论，从我个人工作这么多年的经验来看，技术方案设计是可以总结出一套方法论或者说框架套路来的。为此，我总结出了一套通用的技术方案设计模板（提纲），然后在我们团队内部进行了统一，后面还推广到了整个中心，大家按照这个模板来写方案设计，绝对让你的领导满意。

大家参考我这个方案设计模板(提纲)和相关介绍来做自己的方案设计的时候，可以根据自己的实际业务情况和背景做相关目录的删减，最后得出自己最终的方案设计，然后再去进行方案评审。

精简版-技术方案设计模板（提纲）

精简版的模板如下，一般的方案设计，大家都可以参考这个提纲来写：

详细版-技术方案设计模板（提纲）

相对详细和复杂的版本如下：

下面是技术方案设计模板在每一章节的简单说明，用来帮助你理清每个章节大概要写什么内容

一，现状

现状，主要是用来描述当前这个业务(项目)的一些基本情况介绍和相关的背景。你的方案设计出来之后，是需要给你的 leader 或者团队其他成员进行评审或者查看，甚至是要给更高级别的人来评审。但是别人不可能都和你一样清楚你的项目，因此首先，你要把你项目的基本情况和背景都说清楚，让大家达成一个共识，站在同一个起点上，才能进行后面的方案评审和讨论。

业务背景

业务背景就是你这个业务（项目）的基本介绍，包括但不限于：

• 项目名称

• 业务描述

技术背景

技术背景就是你这个业务是基于什么样的技术背景下来构建的，我们的技术方案可能是从 0 到 1 来构建，也能是基于现有的方案来优化，但是不管是什么场景，一定都会存在相关的技术背景，因此包括但不限于：

• 现有技术积淀

• 现有架构描述

• 现有系统的整体容量

二，需求

需求，很重要！技术人员千万不要忽略需求，因为不管你的技术有多牛逼，都一定为需求服务的，不管这个需求是技术需求，还是业务需求，一定都是要为需求服务。而需求，就是你这个技术方案的起点，技术方案一切都是围绕需求来设计，当然，这个需求可以是当下的需求，也可以包含未来潜在的需求。

只有把需求介绍清楚之后，大家才能知道你方案设计里面的所有设计和对应的折中点是否可行，也才能比较好的去评审你的方案。

业务需求

业务需求就是你这个业务具体要做的事情，包括但不限于：

• 要改造的内容

• 要实现的新需求

业务痛点

• 涉及到的业务痛点有哪些

性能需求

我们做需求的时候，对于技术人员，不能只看业务需求，业务需求可能是项目管理人员，也可能是产品人员提出来的，他们只会重点关注业务的可行性，只会关注业务的逻辑。但是技术人员，要从这个业务需求里面考虑清楚我们满足这个业务之下的性能需求点，比如我做一个秒杀活动，如果你不考虑性能，可能活动一上来，服务就挂掉了。性能需求包括但不限于：

• 预估系统平均容量

• 预估系统峰值容量

• 可伸缩性

• 其他的一些性能要求点，比如安全性等

三，方案描述

前面把现状和需求说清楚后，终于到了我们的重头戏，方案描述这里了。一般我们做方案，可能会有几个可选的方案，但是你不清楚哪个方案最合适，因此你需要把相关可能的方案都描述清楚，然后给出你认为的最合适的方案，然后让大家来评审和决策，看是否同意你的意见或者有其他更好的意见。

如果没有方案对比，那么可以省略掉这一章节

方案1

概述

一句话概括方案的亮点，比如说：高性能、可扩展、双写、主从分离、分库分表、扩容等。

详细说明

详细说明这里需要图文结合，包括但不限于架构图、流程图 等。把你整个方案的架构和模块、细节流程都描述清楚

性能目标

性能一般来说可能包含以下部分：

• 日平均请求：一般来自产品人员的评估；

• 平均QPS：日平均请求 除以 4w秒得出，为什么是4w秒呢，24小时化为86400秒，取用户活跃时间为白天算，除2得4w秒；

• 峰值QPS：一般可以以QPS的2~4倍计算；

性能评估

给出方案的基准数据，并按性能需求评估需要使用的资源数量。

• 单机并发量

• 单机容量

• 按照预估性能需求，预估资源数量(应用服务器、缓存、存储、队列等)

• 伸缩方式

方案优缺点

列出方案的优缺点，优缺点要具有确定性，最好是通过量化的指标来说明

方案2

可选的另外一种方案，模板和上面一样。

方案对比

前面给出了多种可选的方案，那么这里就是进行一个简单的对比，然后给出你觉得最优的方案和原因，这就是你的决策。

有了你自己的决策（倾向）的方案后，接下来的设计就应该更多的偏向你倾向的方案去做设计和描述

四，线上方案

线上方案是对上面你更倾向的方案的更为细致的描述。

架构图

整体架构是如何，把架构图画上

关键设计点 和 设计折衷

把几个关键、重点的点的设计思想表述出来，用来确保你的方案的大体方向是 OK 的。

因为没有一个方案设计是最完美，方案设计都是逐步演进和优化的，方案设计是要最符合当前的背景的。因此，一定会有你设计的关键点和折衷点，这也就是前面为何要把项目的各种业务背景和技术背景都说清楚的原因。

业务流程

整体流程是如何，弄一个整体流程图、核心流程图出来，然后分业务场景把各个业务场景的流程图也画出来，并且做好相关介绍

模块划分

有了业务流程，那么必然要针对这个业务流程的各个环节来划分模块，模块的划分需要考虑我们架构设计的一些原则，比如：架构分层、业务分模块、微服务化、高内聚低耦合 等。然后把每个模块的功能点都说清楚

异常边界【重要】

异常边界是比较重要的，一般情况下，大部分人都能考虑到正常的处理流程，对于异常的边界考虑的比较少，但是线上出问题，大部分都是异常情况导致，因此这里非常重要！！！

我们可以通过一个 xmind 格式去整理相关的异常边界，这样有助于自己在实现的时候有足够的把控度，也便于别人去 review 你的方案和具体实现（如 coding）

异常边界需要考虑:

• 涉及到了哪些模块

• 涉及到了哪些流程

• 每个模块、流程出现了各种可能情况的处理是？

• 系统底层原因导致的异常的处理是 ？

统计、监控

线上运行的项目，一定需要有各种监控，除了公司内部的基建的监控外，我们可能还需要从业务内部实现自定义的一些业务监控和相关技术统计

灰度、回滚策略

• 如何灰度？

• 如何回滚？

容灾方案

容灾就是当出现 IDC 异常的情况下，怎么容灾，这个可以根据实际情况去考虑。

五，部署拓扑

线上部署拓扑如何，上下游是如何

六，风险评估

标识所选方案的风险，提出解决此风险发生时候的应对策略，比如：上线失败时的回滚策略。

潜在风险

• 相关的改动有哪些风险点

• 不兼容点？

• 当前设计方案目前存在哪些问题？

• 潜在有哪些问题

七，阶段规划【架构演进规划】

架构怎么演进

阶段如何规划

每个阶段该达成什么目标

第一阶段

第二阶段

第三阶段

八，工作量评估

工作量评估也是一个重要的环节，这里需要细化到每个模块、每个接口的设计分别需要多长时间，一定要同时包括开发时间、联调时间、测试时间。

来源： 后端系统和架构

TCP 长连接接入层的连接管理

TCP 长连接的管理思路

实现思路

IM 架构中的 TCP 长连接接入层的 NET 连接一般会很多，比如单台服务器至少会有几十万，有的甚至会到百万连接；这个长连接的维持，也就代表中会有这么多客户端（用户）的接入。那么我们怎么去管理这些连接？当有数据需要下发的时候，怎么能够快速根据连接信息找到用户、或者根据用户快速定位到网络连接？这就需要我们能够有一个合适的数据结构去维护，并且我们需要考虑一些其他的点比如快速定位、机器内存大小等。

最容易想到的一个思路是通过 map 数据结构来管理，比如 map<conn，user>，因为每个用户的 uid（user）是唯一，因此，这样做，初期来看，并不会有太大的影响；但是试想一下，这个只能单向定位，只能根据 Conn 网络连接查找用户，那么我想根据用户信息快速查找到对应的 Conn 然后下发数据怎么办呢？

为此，一个更为合适的做法就是将用户和网络连接进行一一对应，这样，不仅是可以相互查找，并且查找定位的时间复杂度总是 O(1)。具体实现的 Golang 代码如下，只列出关键信息：

// Conn 与 User 一一映射，用来优化 map 查询方式

type Conn struct {
    conn        net.Conn  // TCP 网络 连接信息
     user        *User     // 客户端用户信息（一般包含 uid、name等）
}

type User struct {
    uid              int64
    Name             string
    conn             *Conn
}

这样的结构设计，就是 Conn 里面包含了 User、User 里面包含了 Conn，这样就是一一对应，不管多少数据量，查询定位的时间复杂度都是 O(1)。这里应用了一个思想就是空间换时间，因为我们当前的机器的内存是很大的，所以就可以利用这个空间换时间的思想，快速查询。

应用场景

IM 系统中，必然会有这么几个操作：

• • 用来连接（accept）

• • 用户登录（login）

TCP Socket 编程模型是：

socket -> bind -> listen -> accept -> recv -> send -> close

因此对 IM 接入层来说，首先会收到用户的 accept 请求，accept 成功之后，我们就有了 Conn 信息，然后我们开始填充 Conn 结构 和 User 结构，这里算是初步建立起了对应关系，但是 User 中的信息还不够，还需要用户登录之后才有更多的数据。

连接成功之后，用户就会发起登录请求，登录成功之后，就会有了足够的 User 信息，这样就可以根据相关信息相互定位了。登录成功之后，长连接接入层还需要给用户回应 ACK ，因此在登录包之后，长连接接入层就可以从 User 结构中取出 Conn 进行回包给用户（客户端）。

随后的操作中，我们可以根据业务场景的需要，从 User（uid）中快速定位到 Conn，然后发送消息给客户端；也可以根据 Conn 快速定位到 User，更新 User 信息，或者获取 User 信息。

TCP 长连接心跳超时的处理

再来看看另外一个场景，首先，我们要清楚，长连接接入层一定是有多个的，一台机器肯定扛不住，也无法做到高可用。因此在每个接入层节点中的处理上，还有一点非常重要的就是，维持着大量长连接后，如果客户端一直没有请求，或者客户端以为异常导致关闭了连接但是服务端并不知晓，那么这些无用的长连接，服务端肯定是需要清理的，避免占用大量资源。

怎么实现？当然需要通过心跳来保持连接，如果心跳超时则踢出连接。心跳这里多说一句，一般固定心跳设置为 4.5 分钟，还有更为合适的智能心跳策略。我们现在重点在于管理 TCP 长连接，不讨论心跳策略的实现。

上面的 TCP 长连接的管理思路是需要一一对应，方便相互查找，那么针对心跳是否超时，这个和用户没有关系，因此只需 Conn 的处理。通过一个红黑树可以搞定，通过递归地从根节点向左遍历节点，直到左节点为空，可以查找树中的所有 Conn 的超时情况。

Golang 的代码片段如下：

var timeoutTree *rbtree.Rbtree  //红黑树


type TimeoutInfo struct {
    conn    *Conn         // 连接信息
    latestTime time.Time  //心跳的最新时间
}


每次收到心跳包都重新更新时间
func AddTimeoutCheckInfo(conn *Conn) {
    timeoutTree.Insert(&TimeoutInfo{conn: conn, latestTime: time.Now()})
}

独立协程来遍历扫描并清除超时的连接：

    for {
        // 遍历
        item := timeoutTree.Min()

        // 取连接、取最新时间
        latestTime := item.(*TimeoutInfo).latestTime
        conn := item.(*TimeoutInfo).conn

        // 计算连接的最新时间是否超时，超时则关闭连接和清理
        if timeout { 
            timeoutTree.Delete(item)
            conn.Close()
        } 
    }

TCP 长连接层的负载均衡策略

既然长连接接入层节点有多个，并且可以随时根据需要扩缩容，然而客户端并不清楚你服务端到底部署了多少台节点，那么客户端该怎么发起连接呢？怎么做才能保证合理的负载均衡呢？

一般的负载均衡策略如 RR 轮询，是否能够满足 IM 的诉求呢？试想这么一个真实的场景，当前线上有 5 台机器，每台机器负载都很高了，此时连接会很不稳定，客户端出现频繁重连。此时肯定需要扩容，OK，那么扩容了 2 台，然后 client 建连如果还是轮询，那么新扩容的机器，还是不能马上分散其他机器上的压力，压力还是会往老的机器上面去打，显然不合理。

因此，针对 IM 场景，最合理的负载均衡策略，就是根据连接数来负载均衡，客户端新发起连接需要接入的接入层节点一定是连接数最少的，因为每台节点会需要控制最大连接数的限制才能保证最优性能，并且能够及时给压力大的节点减压。

怎么实现呢？这里就需要有一个服务注册发现的组件（如 Etcd）来帮助我们达到诉求。首先，接入层启动后，往 Etcd 里面注册信息，并且再在后续的生命周期中，定期更新当前节点已有的连接数到 Etcd 中；然后我们需要有一个 Router Server，这个服务去 watch Etcd 中的接入层节点信息，Etcd 的使用可以参考etcd/clientv3；然后实时计算，得到一个列表排序，这个排序是按照节点数最少的节点排序的。

然后 Router Server 提供一个 HTTP 服务的 API 接口，用来返回所有节点中连接数最少的节点的一批 IP 列表（一般可以 3 个）给到客户端。为何不是返回一个呢？因为我们返回的节点，可能因为其他原因导致连接不上，或者连接不稳定，那么此时 客户端就可以有备选方案，选择返回的下一个节点建连。

涉及点包括：

• • 接入层注册信息（节点 IP 和 port、节点连接数）

• • 路由层 watch 接入层的信息

• • 路由层计算路由算法

• • 路由层提供 HTTP 接口返回合适的节点 IP 列表

TCP 长连接接入层服务的优雅重启和缩容

对于通用的长连接接入层而言

长连接接入层是和用户客户端直接相连的，客户端通过 TCP 长连接连接到接入层，因此接入层如果需要重启，那么必然会导致客户端连接断开，发生重连。如果此时用户正在发送消息，那么必然会导致发送异常，从而影响用户体验。

那么我们需要怎么实现接入层，才能保证重启或者缩容的时候，不影响用户、对用户无感知呢？有这么几个思路：

1. \1. 接入层做的足够轻量，尽量只是维持 TCP 长连接和数据包的转发，所有其他业务逻辑，尽量转发到业务层去处理，接入层与业务逻辑层严格分离；因为业务层逻辑是需要频繁变动，而接入层的长连接维持可以做到尽量不变，这样就会尽可能的减少重启。

2. \2. 接入层尽可能的做到无状态化，方便随时的扩缩容；这样就需要有一个叫用户中心的服务来保存用户的各种状态和信息，如在线状态、离线状态、用户是通过哪个接入层节点连接的；通过这个方式，用户就可以随意接入到任何接入层节点，并且接入层节点也可随时扩缩容；这样的话，业务逻辑层就可以和用户中心通过 RPC 通信获取用户的各种连接信息和是否在线的状态，然后精准下发消息到指定接入层，然后接入层将消息下发给客户端用户。

3. \3. 主动迁移信令。增加一条信令和客户端进行交互，服务端如果要重启/缩容，那么主动告知连接在此接入层节点上的所有客户端，服务端主动发送迁移信令，比如 publish(迁移信令,100%)，表示发送给所有此接入层节点上的客户端，客户端收到此迁移信令后，就主动进行重新连接其他节点。因为是客户端主动断开重连其他节点的，虽然还是会有重连，但是客户端是主动发起的，因此可以通过代码逻辑来保证从业务逻辑上不会影响用户的体验，这样的话，用户在操作上就会无感知，从而提升用户体验。同时，接入层节点要发送主动迁移信令之前，需要先从服务发现与注册中心（Etcd）中下线自己，避免重连的时候还继续连接到此节点。然后当重启之前，也需要判断一下是否当前节点上所有的用户连接都已经迁移到其他节点上了。

长连接接入层的优雅扩容方案

扩容方案是指在线用户越来越多，当前已有的接入层节点已经扛不住了，需要扩容接入层节点来分摊在线用户的连接和请求。这里分两种情况考虑：

• • 其他节点的压力还相对较小，但是事先预知到需要扩容，也就是提前扩容。此时按照路由层的最小连接数优先接入请求的策略并无不妥，新扩容的可以均摊流量，原有的节点也不会因为压力过大而导致性能问题。

• • 其他节点压力已经扛不住了，需要紧急扩容并且快速给老的节点减压。这个时候，如果还仅仅只是新增节点，然后根据原有的负载均衡路由策略来减压是达不到减压效果的，因为只有新的连接才会接入到新扩容的节点；原有老的节点上的连接如果没有断连那么还是继续维持在原有节点上，因此根本不能给老的节点减压。

• • 所以，就需要服务端有更好的机制，通过服务端的机制来促使客户端重新连接到新的节点上，从而进行减压。这里，还是需要一个迁移信令，但是这个信令服务端只是需要随机发送给部分比例的用户，比如 publish(迁移信令,30%)，表示发送迁移信令给 30% 比例的用户，让这 30%的用户重连到新的节点上。

TCP 长连接层节点怎么防止攻击

基本的防火墙策略

公司内常规的防火墙策略，通过 iptable 设置 iptables 的防火墙策略。比如限制只能接收指定 IP 和 Port 的包，避免攻击者通过节点上其他端口的漏洞登录机器；比如只接收某些协议（TCP）的包。

SYN 攻击

SYN 攻击是一个典型的 DDOS 攻击，具体就是攻击客户端在短时间内伪造大量不存在的 IP 地址，然后向服务端发送 TCP 握手连接的 SYN 请求包，服务端收到 SYN 包后会回复 ACK 确认包，并等待客户端的 ACK 确认。但是，由于源 IP 地址不是真实有效的，因此服务端需要不断的重发直至 63s 超时后才会断开连接。这些伪造的 SYN 包将长时间占用未连接队列，引起网络堵塞甚至系统瘫痪，让正常的 TCP 握手连接请求不能处理。通过 netstat -n -p TCP | grep SYN_RECV 可以查看是否有大量 SYN_RECV 状态，如果有则可能存在 SYN 攻击。

Linux 在系统层面上，提供了三个选项来应对相关攻击：

• • tcp_max_syn_backlog，增大 SYN 连接数

• • tcp_synack_retries，减少重试次数

• • tcp_abort_on_overflow，过载直接丢弃，拒绝连接

另外，还有一个 tcp_syncookies 参数可以缓解，当 SYN 队列满了后，TCP 会通过相关信息（源 IP、源 port）制造出一个 SYN Cookie 返回，如果是攻击者则不会有响应，如果是正常连接，则会把这个 SYN Cookie 发回来，然后服务端可以通过 SYN Cookie 建连接。

TCP 长连接层面上

黑名单机制

可以静态或者动态配置黑名单列表，处于黑名单中的 IP 列表则直接拒绝 accept 建连；服务端执行 accept 之后，首先先判断 remote IP 是否存在于黑名单中，如果是则直接 close 连接；如果不是则继续下一步。

限制建连速度

IM 系统为了防止恶意攻击，需要防止单个 IP 大量频繁建连，避免异常 socket 连接数爆满；因此需要限制每个 IP 每秒建立速度，如果单个 IP 在单位时间内建连的连接数超过一定阈值（如 100）该值，则将 IP 列入黑名单并且同时关闭此连接

怎么实现呢？分如下几步。

\1. 定义一个合理的防攻击的数据结构，里面包含 connRates 字段、startTime 字段。

• • startTime 表示此连接接入的初始时间

• • connRates 用来对统计时间内的接入 IP 做累加

\2. 服务端每次 accept 之后，针对这个 Conn 连接，先判断当前时间和此连接的 startTime 的差值是否已经超过一个统计周期，如果超过则清零重置；如果没有超过，则对此连接的 IP 做累加。

\3. 然后判断 IP 累加的结果是否超过阈值，如果超过则加入黑名单并且 close 连接；如果没有超过则进行下一步的请求。

限制发包速度

IM 系统要能够发送消息包，必然需要先进行登录操作，登录主要是为了鉴权，从而获取得到正确的 token，才能正常登录。为了避免 token 等被窃取，为了更为安全，登录之后发送消息的频率也需要进行控制；控制的机制就是针对单个连接限制每秒处理包的上限，在单位时间内收到的包的请求数量超过一定阈值（如 100p/s）则直接丢弃。

怎么实现呢？需要几个步骤：

• • 针对每个 Conn 的数据结构，增加一个 packetsNum 字段；

• • 当前 Conn 每收到一个包，先计算统计时间内 packetsNum 的次数是否超过阈值，然后 packetsNum++；如果超过阈值则丢包并返回错误；

• • 开一个定时器，每隔一个统计时间周期，清零 packetsNum。

TLS 加密传输

TLS 安全传输层协议用于在两个通信应用程序之间提供保密性和数据完整性，是我们 IM 系统中保证消息传输过程中不被截获、篡改、伪造的常用手段。

TLS 过程使用到了对称加密、非对称加密、CA 认证等，安全性非常高；但是相比于 TCP 传输会多了几个秘钥相关的环节，从而导致整个握手阶段会多出 1~2 个 RTT 的耗时；不过只是握手阶段的耗时对我们 IM 的应用场景并不影响。为此，为了安全性，尽可能的使用 TLS 来建立 TCP 连接。

来源： 后端系统和架构

高性能架构和系统设计经验

高性能和高并发，听着就有点类似，并且他们还经常一起提及，比如提高我们的并发性能，显然，高性能可以提高我们的并发，但是细化来看，他们是有区别的，他们的考量点的维度不同。高性能需要我们从单机维度到整体维度去考虑，更多的是先从编码角度、架构使用角度去让我们的单机（单实例）有更好的性能，然后再从整个系统层面来拥有更好的性能；高并发则直接是全局角度来让我们的系统在全链路下都能够抗住更多的并发请求。

一、高性能架构和系统设计的几个层面

高性能架构设计主要集中在单机优化、服务集群优化、编码优化三方面。但架构层面的设计是高性能的基础，如果架构层面的设计没有做到高性能，仅依靠优化编码，对整体系统的提升是有限的。我们从一个全局角度来看高性能的系统设计，需要整体考虑的包括如下几个层面：

• 前端层面。 后端优化的再好，如果前端（客户端）的性能不 ok，那么对用户而言，他们的体感还是很差的，因此前端层也是有必要考虑的，只是不在我们本文的设计范围之内，在实际工作中是需要进行探讨的。

• 编码实现层面：代码逻辑的分层、分模块、协程、资源复用（对象池，线程池等）、异步、IO 多路复用（异步非阻塞）、并发、无锁设计、设计模式等。

• 单机架构设计层面： IO 多路复用、Reactor 和 Proactor 架构模式

• 系统架构设计层面：架构分层、业务分模块、集群（集中式、分布式）、缓存（多级缓存、本地缓存）、消息队列（异步、削峰）

• 基础建设层面：机房、机器、资源分配

• 运维部署层面：容器化部署、弹性伸缩

• 性能测试优化层面： 性能压测、性能分析、性能优化

二、前端层面

后端优化的再好，如果前端（客户端）的性能不 ok，那么对用户而言，他们的体感还是很差的，因此前端层也是有必要考虑的，只是不在我们本文的设计范围之内，在实际工作中是需要进行探讨的。

这里简单说明下，从我个人工作的经历来看，前端（客户端）这里可以优化的点包括但不限于：数据预加载、数据本地缓存、业务逻辑前置处理、CDN 加速、请求压缩、异步处理、合并请求、长连接、静态资源等

三、编码实现层面

编码实现层面：代码逻辑的分层、分模块、协程、资源复用（对象池，线程池等）、异步、IO 多路复用（异步非阻塞）、并发、无锁设计、设计模式等。

多线程、多协程

大多数情况下，多进程、多线程、多协程都可以大大提高我们的并发性能，尤其是是多协程。

在网络框架层面，现在一般成熟的后端系统框架（服务化框架）都是支持多线程、多协程的，因此对于网络框架这点，我们只要是引用相对成熟的服务化框架来实现我们的业务，基本上可以不用过多考虑和设计。

在业务层面，如果是 Go 语言，天然支持大量并发，并且创建 Go 的协程非常容易，一个 go 关键字就搞定，因此多协程那就非常容易了，Go 里面可以创建大量协程来提高我们的并发性能。如果是其他语言，我们尽可能的使用多协程、多线程去执行我们的业务逻辑。

无锁设计（lock free）

在多线程、多协程的框架下，如果我们并发的线程（协程）之间访问共享资源，那么需要特别注意，要么通过加锁、要么通过无锁化设计，否则没有任何处理的访问共享资源会产生意想不到的结果。而加锁的设计，在并发较大的时候，如果锁的力度不合适，或者频繁的加锁解锁，又会使我们的性能严重下降。

为此，在追求高性能的时候，大家就比较推崇无锁化的设计。目前很多后台底层设计，为了避免共享资源的竞争，都采用了无锁化设计，特别是在底层框架上。无锁化主要有两种实现，无锁队列和原子操作。

• 无锁队列。可以通过 链表或者 RingBuffer（循环数组）来实现无锁队列。

• 原子操作。利用硬件同步原语 CAS 来实现各种无锁的数据结构。比如 Go 语言中的 atomic 包、C++11 语言中的 atomic 库。

数据序列化

为什么要说 数据序列化协议？因为我们的系统，要么就是各个后端微服务之间通过 RPC 做交互，要么就是通过 HTTP/TCP 协议和前端(终端)做交互，因此不可避免的需要我们进行网络数据传输。而数据，只有序列化后，才方便进行网络传输。

序列化就是将数据结构或对象转换成二进制串的过程，也就是编码的过程，序列化后，会把数据转换为二进制串，然后可以进行网络传输；反序列化就是在序列化过程中所生成的二进制串转换成数据结构或者对象的过程，将二进制转换为对象后业务才好进行后续的逻辑处理。

常见的序列化协议如下

• Protocol Buffer（PB）

• JSON

• XML

• 内置类型（如 java 语言就有 java.io.Serializable）

常见的序列化协议的对比在网上有各种性能的对比，这里就不在贴相关截图了，只说结论：从性能上和使用广泛度上来看，后端服务之间现在一般推荐使用 PB。如果和前端交互，由于 HTTP 协议只能支持 JSON，因此一般只能 JSON。

池化技术（资源复用）

池化技术是非常常见的一个提高性能的技术，池化的核心思想就是对资源进行复用，减少重复创建销毁所带来的开销。复用就是创建一个池子，然后再在这个池子里面对各种资源进行统一分配和调度，不是创建后就释放，而是统一放到池子里面来复用，这样可以减少重复创建和销毁，从而提高性能。而这个资源就包括我们编程中常见到如 线程资源、网络连接资源、内存资源，具体到对应的池化技术层面就是 线程池（协程池）、连接池、内存池等。

• 线程池（协程池）。本质都是进程、线程、协程这些维度的一个池子，先创建合适数量的线程（协程）并且初始处于休眠状态，然后当需要用到的时候，从池子里面唤醒一个，然后执行业务逻辑，处理完业务逻辑后，资源并不释放，而是直接放回池子里面休眠，等待后续的请求被唤醒，这样重复利用。

  • 创建线程的开销是很大的，因此如果来一个请求就频创建一个线程、进程，那么请求的性能肯定不会太高。

• 连接池。这个是最常用的，一般我们都要操作 MySQL、Redis 等存储资源，同样的，我们并不是每次请求 MySQL、Redis 等存储的时候就新创建一个连接去访问数据，而是初始化的时候就创建合适数量的连接放到池子里面，当需要连接去访问数据的时候，从池子里面获取一个空闲的连接去访问数据，访问完了之后不释放连接，而是放回池子里面。

  • 连接池需要保证连接的可用性，就是这个连接和 MySQL、Redis 等存储是必须要定期发送数据来保证连接的，要不然会被断开。同时我们要针对已经失效（断开）的连接进行检测和摘除。

• 内存池。常规的情况下，我们都是直接调用 new、malloc 等 Linux 操作系统的 API 来申请分配内存，而每次申请的内存块的大小不定，所以，当我们频繁 分配内存、回收内存的时候，会造成大量的内存碎片，同时每次使用内存都要重新分配也会降低性能。内存池就是先预先分配足够大的一块内存，当做我们的内存池，然后每次用户请求分配内存的时候，就会返回内存池中的一块空闲的内存，并将这块内存的标志置为已使用，当内存使用完毕释放内存的时候，也不是真正地调用 free 或 delete 来释放内存，而是把这块内存直接放回内存池内并且同时把标志置为空闲。一般业内都有相关的套件来帮我们来做这个事情，比如在 C/C++ 语言里面，都有相关库去封装原生的 malloc，glibc 实现了一个 ptmalloc 库，Google 实现了一个 tcmalloc 库。

• 对象池。其实前面几种类型的池化技术，其实都可以作为对象池的各种应用，因为各种资源都可以当做一个对象。对象池就是避免大量创建同一个类型的对象，从而进行池化，保证对象的可复用性。

异步IO 和 异步流程

异步有两个层面的意思：

• IO 层面的异步调用

• 业务逻辑层面的异步流程

异步是相对同步而言的，同步就是要等待前面一个事情执行完毕才能继续执行，异步就是可以不用等待，可想而知，异步的性能要比同步好很多。

IO 层面的异步调用

针对 IO 层面的异步调用，就是我们常说的 I/O 模型，有 阻塞、非阻塞、同步、异步这几种类型。在 Linux 操作系统内核中，内置了 5 种不同的 IO 交互模式，分别是阻塞 IO、非阻塞 IO、多路复用 IO、信号驱动 IO、异步 IO。

针对网络 IO 模型而言，Linux 下，使用最多性能较好的是同步非阻塞模型，具体代表是 AIO，而 Windows 下的代表作 IOCP 则实现了真正的异步非阻塞 I/O。

业务逻辑层面的异步流程

业务逻辑层面的异步流程，就是指让我们的应用程序在业务逻辑上可以异步的执行。通常比较复杂的业务，都会有很多步骤流程，如果所有步骤都是同步的话，那么当这些步骤中有一步卡住，那么整个流程都会卡住，这样的流程显然性能不会很高。为此，在业内，我们如果想要提高性能，提高并发，那么基本上都会采用异步流程的方式。

举个实际的应用案例，针对 IM 系统的发送消息的这个场景，比如微信发送消息，那么当客户端发送的消息，服务端收到后，这个消息肯定要落地存储，这个发送的流程才能算完毕，但是，如果每条消息，服务端都真正存储到 DB 后再返回给客户端说已经正确收到，那么这个性能显然会很低，因为我们知道，写 DB 的性能是很低的，尤其是像微信这种每天有大量消息的 APP。那么这个流程就可以异步化，服务端收到消息后，先把消息写入消息队列，写入队列成功就返回给客户端，然后异步流程去从消息队列里面消费数据然后落地存储到 DB 里面，这样性能就非常高了，因为消息队列的性能会很高。而比较低性能的操作都是异步处理。

并发流程

并发流程，同样是针对我们上层的应用程序而言的，我们在处理业务逻辑的时候，尤其是相对负责的业务逻辑，一般下游都可能会有多个请求，或者说多个流程，如果依赖的下游多个请求之间没有强依赖关系，那么我们可以将这些请求的流程并发处理，这个是后端系统设计里面非常常见的优化手段。

通过并发的处理流程，可以将串行的叠加处理耗时优化为单个处理耗时，这样就大大的降低了整体耗时，举个例子，一个商品活动页面，渲染的数据包括 用户基本信息、用户活动积分、用户推荐商品列表。那么当收到这个用户的请求的时候，我们需要 查询用户的基本信息、用户的活动积分，还有用户的商品推荐，而这 3 个步骤完全是没有相互依赖关系的，因此，我们可以并发去分别查询，这样可以极大的减少耗时，从而提高我们的性能。

四、单机架构设计层面

单机优化的关键点

单机优化层面就是要尽量提升单机的性能，将单机的性能发挥到极致的其中一个关键点就是我们服务器采取的并发模型，然后在这个模型下，去设计好我们的服务器对连接的管理、对请求的处理流程。而这些就涉及到我们的多协程、多线程的进程模型和异步非阻塞、同步非阻塞的 IO 模型。

在具体实现细节上，针对连接的管理，要想提高性能，那么就要采用 IO 多路复用技术，可以参考I/O Multiplexing查看，I/O 多路复用技术的两个关键点在于：

• 当多条连接共用一个阻塞对象后，进程只需要在一个阻塞对象上等待，而无须再轮询所有连接，常见的实现方式有 select、epoll、kqueue 等。

• 当某条连接有新的数据可以处理时，操作系统会通知进程，进程从阻塞状态返回，开始进行业务处理。

IO 多路复用（epoll 模型）

基本上来说，异步 I/O 模型的发展技术是： select -> poll -> epoll -> aio -> libevent -> libuv。

而且现在大家比较熟悉和使用的最多的恐怕就是 epoll 和 aio ，尤其是 epoll 模型，基本是 Linux 后端系统下的大部分框架和软件都是采用 epoll 模型。

但是，需要特别强调的是，仅仅依靠 epoll 不是万能的，连接数太多的时候单进程的 epoll 也是不行的。

Reactor 和 Proactor 架构模式

epoll 只是一个 IO 多路复用的模型，在后端系统设计里面，要想实现单机的高性能，那在 IO 多路复用基础之上，我们的整个网络框架，还需要配合池化技术来提高我们的性能。因此，业界一般都是采用 I/O 多路复用 + 线程池（协程池、进程池）的方式来提高性能。与之对应的，在业界常用的两个单机高性能的架构模式就是Reactor 和 Proactor 模式。Reactor 模式属于非阻塞同步网络模型，Proactor 模式属于非阻塞异步网络模型。

在业内开源软件里面，Redis 采用的是 单 Reactor 单进程的方式，Memcache 采用的是 多 Reactor 多线程的方式，Nginx 采用的是多 Reactor 多进程的方式。关于 的详细介绍，可以查看The Design and Implementation of the Reactor。

Redis 可以用单进程 Reactor 模式的是因为 Redis 的应用场景是内部访问，并发数一般不会超过 1w，而 Nginx 必须用多进程 Reactor 模式是因为 Nginx 是外网访问，并发数很容易超过 1w，因此我们的网络架构模式，必须要通过 I/O 多路复用 + 线程池（协程池、进程池）来配合。

可以看到，单机优化层面其实和编码层面上的多协程、异步 IO、 池化技术都是有强关联的。这里也是一个知识相通的典型，我们所学的一些基础层面的知识点，在架构层面、模型层面都是有用武之地的。

五、系统架构设计层面

架构设计层面：架构分层、业务分模块、集群（集中式、分布式）、缓存（多级缓存、本地缓存）、消息队列（异步、削峰）

架构和模块划分的设计

整个系统想要有一个高性能，那么首先就需要有个合理的架构设计，这里需要根据一些架构设计原则，比如高内聚低耦合，职责单一等来去构建我们的架构。最有效的方式包括架构分层设计、业务分模块设计。

这么设计之后，在整体的系统性能优化上，后面就会有比较大的优化空间，从而不至于后面想要优化就根本无从下手，只能重构系统。

服务化框架的设计

目前的互联网时代，我们基本上都是采用微服务来搭建我们的系统，而微服务化的必要条件就是要有一套服务化框架，这个服务化框架最核心的功能包括 RPC 请求和最基础的服务治理策略（服务注册和发现、负载均衡等）。

为此，这里服务化框架的性能就尤为重要，这里主要包括这个服务化框架里面实现：

• 数据处理。

  • 数据序列化协议，一般有些采用 PB 协议，不管是从性能还是维护都是最优的。

  • 数据压缩，一般采用 gzip 压缩，压缩后可以减少网络上的数据传输。

• 网络模型。

  • 同步还是异步流程，如果是 Go 语言，那么可以来一个请求 go 一个协程来处理。

  • 是否有相关连接池的能力。

  • 其他的一些优化。

负载均衡

负载均衡系统是水平扩展的关键技术，通过负载均衡，相当于可以把流量分散到不同的机器的不同的服务实例里面，这样每个服务实例都可以承担一部分请求，从而可以提高我们的整体系统的性能。

对于负载均衡的方式，大都是在客户端发现模式(client-side) 来实现服务路和负载均衡，一般也都会支持常见的负载均衡策略，如随机，轮训，hash，权重，连接数【连接数越少，优先级越高】。

合理采用各种队列

在后端系统设计里面，很多流程和请求并不要求实时处理，更不需要做到强一致，大部分情况下，我们只需要实现最终一致性就可以了。故而，我们通过队列，就可以使我们的系统能够实现异步处理逻辑、流程削峰、业务模块解耦、柔性事务等多种效果，从而可以完成最终一致性，并且能够极大的提高我们系统的性能。

我们常见的队列包括

• 消息队列：使用的最为广泛的队列之一，代表作有 RabbitMQ、RocketMQ、Kafka 等。可以用来实现异步逻辑、削峰、解耦等多种效果。从而可以极大的提高我们的性能

• 延迟队列：延时队列相比于普通队列最大的区别就体现在其延时的属性上，普通队列的元素是先进先出，按入队顺序进行处理，而延时队列中的元素在入队时会指定一个延迟时间，表示其希望能够在经过该指定时间后处理。延迟队列的目的是为了异步处理。延迟队列的应用场景其实也非常的广泛，比如说以下的场景：

  • 到期后自动执行指定操作。

  • 在指定时间之前自动执行某些动作

  • 查询某个任务是否完成，未完成等待一定时间再次查询

  • 回调通知，当回调失败时，等待后重试

• 任务队列：将任务提交到队列中异步执行，最常见的就是线程池的任务队列。

各级缓存的设计

分布式缓存

分布式缓存的代表作有 Redis、Memcache。通过分布式缓存，我们可以不直接读数据库，而是读取缓存来获取数据，可以极大的提高我们读数据的性能。而一般的业务都是读多写少，因此，对我们的整体性能的提高是非常有效的手段，而且是必须的手段。

本地缓存

本地缓存可以从几个维度来看：

• 客户端的本地缓存：针对一些不常改变的数据，客户端也可以缓存，这样就可以避免请求后端，从而可以改善性能

• 后端服务的本地缓存：后端服务中，一般都会采用分布式缓存，但是，有些场景下，如果我们的数据量比较小，那么可以直接将这些数据缓存到进程里面，这样直接通过内存读取，而不用网络耗时，性能会更高。但是本地缓存一般只会缓存少量数据。数据量太大就不合适。

多级缓存

多级缓存是一个更为高级的缓存架构设计，比如最简单的模式可以是 本地缓存 + 分布式缓存这样形成一个多级缓存架构。

我们把全量要缓存的数据都放到分布式缓存里面，然后把一些热点的少量缓存放到本地缓存里面，这样大部分热点数据都能够从本地直接读取，而其他非热点的数据还是通过分布式缓存读取，这样可以极大的提高我们的性能，提高并发能力。

举个例子，电商系统里面，我们做一个活动页，活动页的前面 10 个商品是特卖商品，然后后面的其他商品就是常规商品，因为是活动页面，那么这个页面的访问肯定就会非常大。而活动页面的前 10 个商品，必然是用户首先进来页面就一定会看到的，而用户想要继续看其他商品，那么就需要在手机上手动上滑刷新一下。这个场景下，前面 10 个商品的访问量无疑是最大的，而用户手动上滑刷新后的请求就会少很多。为此，我们可以把全量商品都缓存在分布式缓存如 redis 里面，然后再在这个基础之上，把前面 10 个商品的信息缓存到本地，这样，当活动开始后，拉取的第一页 10 个商品数据，都是从本地缓存拉取的，本地读取性能会非常高，因为内存读取就行，完全不需要网络交互。

其他的模式，可以 本地缓存 + 二级分布式缓存 + 一级分布式缓存，也就是针对分布式缓存再做一层分级，这样每一级的缓存都能抗一部分的量，因此整体来看，能够对外提供的性能就足够高。

缓存预热

通过异步任务提前将接下来要大量访问的数据预热到我们缓存里面。这样当有请求的突峰的时候，可以从容应对。

其他高性能的 NoSQL

除了 Redis、本地缓存这些，其他的一些 NoSQL 中，MongoDB、Elasticserach 也是常见的性能很高的组件，我们可以根据适用场景，合理选用。

比如我们在电商系统里面，我们针对商品的搜索、推荐都是采用 Elasticserach 来实现。

存储的设计

数据分区

数据分区是把数据按一定的方式分成多个区（比如通过地理位置），不同的数据区来分担不同区的流量，这需要一个数据路由的中间件，但会导致跨库的 Join 和跨库的事务非常复杂。

将数据分布到多个分区有两种比较典型的方案：

• 根据键做哈希，根据哈希值选择对应的数据节点。

• 根据范围分区，某一段连续的键都保存在一个数据节点上。

分库分表

一般来说，影响数据库最大的性能问题有两个，一个是对数据库的操作，一个是数据库中数据的大小。对于前者，我们需要从业务上来优化。一方面，简化业务，不要在数据库上做太多的关联查询，而对于一些更为复杂的用于做报表或是搜索的数据库操作，应该把其移到更适合的地方。比如，用 ElasticSearch 来做查询，用 Hadoop 或别的数据分析软件来做报表分析。对于后者，一般就是拆分。分库分表技术，有些地方也称为 Sharding、分片，通过分库分表可以提高我们的读写性能，

分库分表有垂直切分和水平切分两种：

• 垂直切分（分库），一般按照业务功能模块来划分，分库后分表部署到不同的库上。分库是为了提高并发能力，比如读写请求量大就需要分库。

• 水平切分（分表），当一个表中的数据量过大时，我们可以把该表的数据通过各种 ID 的 hash 散列来划分，比如 用户 ID、订单 ID 的 hash。分表更多的是应对性能问题，比如查询慢的问题。单表一般情况下，千万级别后各种性能就开始下降了，就要考虑开始分表了。

分表包括垂直切分和水平切分，而分区只能起到水平切分的作用。

读写分离

互联网系统大多数都是读多写少，因此读写分离可以帮助主库抗量，读写分离就是将读的请求量改为从库承担，写还是主库来承担。一般我们都是一主多从的架构，既可以抗量，又可以保证数据不丢。

冷热分离

针对业务场景而言，如果数据有冷热之分的话，可以将历史冷数据与当前热数据分开存储，这样可以减轻当前热数据的存储量，可以提高性能。

我们常见的存储系统比如 MySQL、Elasticserach 等都可以支持。

分布式数据库

分布式数据库的基本思想是将原来集中式数据库中的数据分散存储到多个通过网络连接的数据存储节点上，以获取更大的存储容量和更高的并发访问量，从而提高我们的性能。现在传统的关系型数据库已经开始从集中式模型向分布式架构发展了。一般云服务厂商，都会提供分布式数据库的解决方案，比如腾讯云的 TDSQL MySQL 版，TDSQL for MySQL 是腾讯打造的一款分布式数据库产品，具备强一致高可用、全球部署架构、分布式水平扩展、高性能、企业级安全等特性，同时提供智能 DBA、自动化运营、监控告警等配套设施，为客户提供完整的分布式数据库解决方案。

六、基础建设层面

基础建设层面，大体分为 3 大块：

• 机房层面，主要关注机房的网络出口带宽、入口带宽。一般这个对我们业务开发来说，都接触不到，但是这里还是需要注意，如果机房带宽不够，那么我们的服务就支撑不了大的并发，从而也没法让我们的系统有一个好的性能。

• 机器配置层面，服务器本身的性能要足够好，包括 CPU、内存、磁盘（SSD）等资源。同理，一般这个对我们业务开发来说，都接触不到，但是如果机器配置较差，那么我们的服务部署在这样的机器上面，也无法充分发挥，从而使得我们的业系统也无法拥有一个好的性能。

• 资源使用层面，我们要合理的分配 CPU 和内存等相关资源，一般 CPU 的使用率不要超过 70%-80%，超过这个阈值后，我们服务的性能就会开始下降，因此一般我们在 70% 的时候就要开始执行扩容。如果是 K8s 容器部署的话，我们可以设置 CPU 使用率超过指定阈值后就自动扩容。当然，如果是物理机部署，或者其他方式，可以同样的进行监控和及时扩容。也就是说，要保证我们所需的各种资源（CPU、内存、磁盘、带宽）都在一个合理的范围。

七、运维部署层面

在运维部署层面做好相关建设，是有助于提高我们系统的整体性能的。比如，我们可以通过容器化部署做到弹性伸缩，通过弹性伸缩的能力，可以使得我们的服务，在资源分配使用上，一直保持合理的 CPU、内存等资源的使用率。

八、性能测试优化层面

我们从架构设计层面、编码实现层面按照高性能的解决方案和思路实现了我们系统之后，理论上，我们的系统性能不会太差，但是，具体我们的系统性能如何？是否存在可优化点？代码的实现是否有性能问题？我们的依赖服务是否存在性能问题？等等，这些对我们大部分人来说，如果没有一个合理的性能压测和分析，那么可能还是黑盒的。

因此，针对我们研发人员而言，在高性能架构设计方面的最后一个环节，就是进行性能测试优化，具体包括三个环节：

• 性能压测。针对系统的各个环节先分别做压测，然后有条件的情况下，最好能够做全链路压测。

• 性能分析。压测后，最优的分析方式是结合火焰图去分析，看看性能最差的是哪里，是否有可优化的点。一定是先找到性能最差的进行优化，这样事半功倍。

• 性能优化。找到可优化点后，进行优化。然后反复这三个步骤，直到你认为性能已经完全符合预期。

作者：AllenWu
来源：juejin.cn/post/7198476152633163831

接：关于我加了一行日志搞崩了服务这件小事（上）

// 方案一 - 这里会根据当前属性名和clazz来判断是否被忽略了，详见@JsonType注解
           boolean ignore = isJSONTypeIgnore(clazz, propertyName);
// 如果忽略了，就不再往下走了
           if (ignore) {
               continue;
          }
//此时根据属性和类获取对应的值对象。
           Field field = ParserConfig.getField(clazz, propertyName);
           JSONField fieldAnnotation = null;
           if (field != null) {
               //方案二 - 会获取属性对应的JSONField注解
               // 如果该注解的serialize属性是false，那么也不会继续往下去加载逻辑
               fieldAnnotation = field.getAnnotation(JSONField.class);
               if (fieldAnnotation != null) {
                   if (!fieldAnnotation.serialize()) {
                       continue;
                  }
//获取顺序
                   ordinal = fieldAnnotation.ordinal();
                   serialzeFeatures = SerializerFeature.of(fieldAnnotation.serialzeFeatures());
                   if (fieldAnnotation.name().length() != 0) {
                       //获取名字
                       propertyName = fieldAnnotation.name();
                       if (aliasMap != null) {
                           propertyName = aliasMap.get(propertyName);
                           if (propertyName == null) {
                               continue;
                          }
                      }
                  }
                   if (fieldAnnotation.label().length() != 0) {
                       label = fieldAnnotation.label();
                  }
              }
          }
           if (aliasMap != null) {
               propertyName = aliasMap.get(propertyName);
               if (propertyName == null) {
                   continue;
              }
          }
           //这里会新构建一个fieldInfo对象，并存放到fieldInfoMap中进行保存
           FieldInfo fieldInfo = new FieldInfo(propertyName, method, field, clazz, null, ordinal, serialzeFeatures,
                                               annotation, fieldAnnotation, label);
           fieldInfoMap.put(propertyName, fieldInfo);
      }
       //紧接着第二部分是关于isXXX的方法
       if (methodName.startsWith("is")) {
           if (methodName.length() < 3) {
               continue;
          }
           char c2 = methodName.charAt(2);
           String propertyName;
           if (Character.isUpperCase(c2)) {
               if (compatibleWithJavaBean) {
                   propertyName = decapitalize(methodName.substring(2));
              } else {
                   propertyName = Character.toLowerCase(methodName.charAt(2)) + methodName.substring(3);
              }
          } else if (...) {
          //同上面几乎一样，也是针对is_x这类特殊写法做了处理。
          }else {
               continue;
          }
           Field field = ParserConfig.getField(clazz, propertyName);
           if (field == null) {
               field = ParserConfig.getField(clazz, methodName);
          }
           JSONField fieldAnnotation = null;
           if (field != null) {
               //同样是对JSONField注解做处理。
               fieldAnnotation = field.getAnnotation(JSONField.class);
               if (fieldAnnotation != null) {
                   if (!fieldAnnotation.serialize()) {
                       continue;
                  }
                   ordinal = fieldAnnotation.ordinal();
                   serialzeFeatures = SerializerFeature.of(fieldAnnotation.serialzeFeatures());
                   if (fieldAnnotation.name().length() != 0) {
                       propertyName = fieldAnnotation.name();
                       if (aliasMap != null) {
                           propertyName = aliasMap.get(propertyName);
                           if (propertyName == null) {
                               continue;
                          }
                      }
                  }
                   if (fieldAnnotation.label().length() != 0) {
                       label = fieldAnnotation.label();
                  }
              }
          }
           if (aliasMap != null) {
               propertyName = aliasMap.get(propertyName);
               if (propertyName == null) {
                   continue;
              }
          }
           FieldInfo fieldInfo = new FieldInfo(propertyName, method, field, clazz, null, ordinal, serialzeFeatures,
                                               annotation, fieldAnnotation, label);
           fieldInfoMap.put(propertyName, fieldInfo);
      }
  }
//最后，又是对所有的常规属性做相应的处理，避免因为某个属性没写getX()方法而得不到序列化。整体的加载逻辑同上。
   for (Field field : clazz.getFields()) {
       if (Modifier.isStatic(field.getModifiers())) {
           continue;
      }
       JSONField fieldAnnotation = field.getAnnotation(JSONField.class);
       int ordinal = 0, serialzeFeatures = 0;
       String propertyName = field.getName();
       String label = null;
       if (fieldAnnotation != null) {
           if (!fieldAnnotation.serialize()) {
               continue;
          }
           ordinal = fieldAnnotation.ordinal();
           serialzeFeatures = SerializerFeature.of(fieldAnnotation.serialzeFeatures());
           if (fieldAnnotation.name().length() != 0) {
               propertyName = fieldAnnotation.name();
          }
           if (fieldAnnotation.label().length() != 0) {
               label = fieldAnnotation.label();
          }
      }
       if (aliasMap != null) {
           propertyName = aliasMap.get(propertyName);
           if (propertyName == null) {
               continue;
          }
      }

       if (!fieldInfoMap.containsKey(propertyName)) {
           FieldInfo fieldInfo = new FieldInfo(propertyName, null, field, clazz, null, ordinal, serialzeFeatures,
                                               null, fieldAnnotation, label);
           fieldInfoMap.put(propertyName, fieldInfo);
      }
  }

   List<FieldInfo> fieldInfoList = new ArrayList<FieldInfo>();

   boolean containsAll = false;
   String[] orders = null;

   JSONType annotation = clazz.getAnnotation(JSONType.class);
   if (annotation != null) {
       orders = annotation.orders();

       if (orders != null && orders.length == fieldInfoMap.size()) {
           containsAll = true;
           for (String item : orders) {
               if (!fieldInfoMap.containsKey(item)) {
                   containsAll = false;
                   break;
              }
          }
      } else {
           containsAll = false;
      }
  }

   if (containsAll) {
       for (String item : orders) {
           FieldInfo fieldInfo = fieldInfoMap.get(item);
           fieldInfoList.add(fieldInfo);
      }
  } else {
       for (FieldInfo fieldInfo : fieldInfoMap.values()) {
           fieldInfoList.add(fieldInfo);
      }
       if (sorted) {
           Collections.sort(fieldInfoList);
      }
  }
   return fieldInfoList;
}

代码有点长，听我一点点地慢慢解释。整个代码其实比较容易理解，我尝试从我们常规角度来理解下。fastJson组件的发明者认为，类中常见需要序列化的类型有三种：

1、getX()方法；

2、isX()方法;

3、没有写getX()方法的固有变量。

围绕这三种类型他做的事都是类似的。这里我们先以getX()方法为例子展开说明，要获取到所有的getX()方法，并对他们解析，主要分为以下四个步骤：

1、获取到所有的类下的方法信息

这个可以通过class<?>.getMethods()方法获得，如下是我coreData类的所有方法。

2、判断符合规范的getXXX方法

在获取到了所有的method以后，我们自然需要判断哪些是符合规范的getXX方法。在组件中是这么判断的：

if (methodName.startsWith("get")) {
   //此时做相应的处理逻辑  
}

没错，就是这么粗暴简单。

3、根据JSONType判断是否需要加载

那么获取到这些方法就一定要加载了吗？当然不是！对于getter方法，fastJson会首先判断当前的属性，是否已被包含在了类的@JSONType(ignores = "xxx")下，如果包含在了其中，那么此时就不会去将该方法保存到待序列化的列表中。局限点在于该种写法只会对get方法生效，对于isXXX和普通属性是不会生效的。

// 方案一 - 这里会根据当前属性名和clazz来判断是否被忽略了，详见@JsonType注解
boolean ignore = isJSONTypeIgnore(clazz, propertyName);
// 如果忽略了，就不再往下走了
if (ignore) {
   continue;
}

4、根据JSONField判断是否需要加载

什么？你说采用JSONType写一大堆不方便？fastJson自然也是想到了，那么此时就可以采用@JSONField(serialize = false)的方式在对单独的属性或方法进行标注。也能起到忽略的作用。

到此，以getXX()方法的解析判断就完成了，当然其中还有一些更为细致的判断逻辑，如跳过getMetaClass、返回值为空的跳过等等逻辑。但大体上已经不影响我们的分析了。isXXX和固有变亮的解析几乎相似。至此，我们已经大致了解了整个解析的原理。当然为了验证我们的逻辑的正确性，我对原本coreData的代码做了一下改造并进行了试验，具体内容如下所示：

@Data
@JSONType(ignores = "funcProperties")
public class CoreData {

   //正常的属性
   public String normalProperties = "normalProperties";

   /**
    * 以get开头的方法
    * @return
    */
   public String getFuncProperties(){
       double a = 2/0;
       return "getFuncProperties";
  }

   /**
    * 以is开头的方法
    * @return
    */
   @JSONField(serialize = false)
   public Boolean isType(){
       return true;
  }

   /**
    * 用于跳过，检查方法是否判断
    * @return
    */
   public String skipFuncProperties(){
       double a = 2/0;
       return "getFuncProperties";
  }
}

简要来说，这里对getFuncProperties方法，我才用了@JSONType(ignores = "funcProperties")将其进行忽略，而对于isType方法，我则用单个的@JSONField(serialize = false)对其进行忽略，如果我们的结论成立，那么此时应该只会保存一个normalProperties属性的输出，且不存在出现报错的情况。

事实证明，我们是对的。

案件总结与反思：

在经历了这次惨痛的教训之后，有哪些是值得我们深入关注去思考和反思的呢？

1、在编写方法的时候尽量避免才用getXXX、isXXX的方法进行书写，这会导致部分框架的解析出现问题。（这个点也是我曾经在JAVA开发手册中看到的，想必也是前人被坑过了。）

2、如果非要这样写，那么此时需要评估好当前这个方法是否需要被一些框架进行解析，如果不需要，尝试对这些类型属性添加基本的忽略操作。类似@JSONField(seralize = false)、@Trasient等注解。

3、避免在对象中参杂进复杂的业务逻辑。（当然这条并不一定正常，对于DDD的充血模型，有时候是需要一定的业务逻辑的混合的。）

吃一堑长一智，如此一来才能避免在未来犯下相同的错误呀～

作者：DrLauPen
来源：juejin.cn/post/7134513215890784293

前言

周三的时候，组内出现了一个线上问题，影响到了若干个用户的下单、支付等操作。然而实际查询到问题的原因时，发现只是由于一行小小的日志打印导致的错误。

以下的文章内容分为主要分为三部分：

1、对案件的发生进行回顾；

2、分析案件发生的原因；

3、对案件总结与反思

以三章内容来回顾出现的问题，以及提供未来的预防策略。

案件回顾

周三的时候，服务频繁收到报警，系统频繁爆出空指针异常。值班同学根据报错的错误栈，快速定位到了错误的代码行。

at com.alibaba.fastjson.serializer.JSONSerializer.write(JSONSerializer.java:285)
at com.alibaba.fastjson.JSON.toJSONString(JSON.java:696)

找到代码行后却让值班同学感到疑惑：“这个明显是fastjson的日志打印呀，这也会有什么错误么？”。旁边的同事看完却惊呼一声：“fastJson打印日志会调用对象内的其余的get方法的呀！”。

（PS：该对象是一个DDD的核心域对象，其中包含一些业务场景方法被命名为getXXX方法的，因此执行Json序列化打印也就可能因为部分数据为空而出现空指针。）

定位到了问题原因，本着优先止损的原则，值班同事快速上线代码删除了这行日志打印。系统暂时的恢复了正常，没有再出现新增的报错信息了。然而后续还有漫长的数据修复、更正的过程。

案件分析：

案件复原：

本质上来说，这起线上事故出现的原因主要是因为fastJson序列化时，会将手工编写的一些方法认为是待输出属性对象，那么如果这些方法包含一些业务逻辑代码的时候，就会存在出现异常的风险。这里我们简单复现一下场景：

@Data
public class CoreData {
   //正常的属性
   public String normalProperties = "normalProperties";

   /**
    * 以get开头的方法 不是期望输出的属性
    * @return
    */
   public String getFuncProperties(){
       return "getFuncProperties";
  }

   /**
    * 以is开头的方法 不是期望输出的属性
    * @return
    */
   public Boolean isType(){
       return true;
  }
}

如上代码是我们编写的一个纯代码类，可以看到，我们实际期望设置的属性应该只有一个normalPropertites。

public static void main(String[] args) {
   CoreData data = new CoreData();
   String dataString = JSONObject.toJSONString(data);
   System.out.println(dataString); // 对应正常的业务逻辑
}

进而我还写了一段针对当前对象进行打印的代码，从上可以看到，就是简单的对对象进行JSON序列化后打印输出。按照我们的期望来说，只是期望输出normalProperties这一个固有的字符串属性。随后我运行了代码，得到了如下的结果：

可以看到，一个类型+两个方法，都被JSON序列化后输出了。那么如果此时我们在getFuncProperties()这样的方法中如果出现了异常，就会影响整个业务的运行。例如我们把方法改成如下的例子：

public String getFuncProperties(){
   double a = 2/0;
   return "getFuncProperties";
}

可以看到，我们原本的逻辑可能只是想输出normalProperties属性，但是因为getFuncProperties2/0是无法进行运算的，导致了系统直接报错了。那么此时，main函数中的输出方法（对应于我们正常业务逻辑），也就无法再继续执行了，而这在生产环境上无疑是致命的。

背后原理：

(PS: 以下讨论内容均基于1.2.9版本的fastJson。)

根据报错的问题点，结合debug，很快找到了问题所在：

在com.alibaba.fastjson.serializer.JSONSerializer#write(java.lang.Object)这个方法中，Fastjson所创建的ObjectSerializer对象中，nature下所包含的getters对象有三个。这明显不符合我们的预期。那么我们就需要找到他是如何获取到这三个方法的。紧跟着我们进行追入，在com.alibaba.fastjson.serializer.SerializeConfig#getObjectWriter方法下找到了这行代码：

put(clazz, createJavaBeanSerializer(clazz));

很明显，这里的createJavaBeanSerializer(clazz)创建了javaBean的序列化器。对于该方法，其主要的逻辑流程就是判断当前的对象类型是否符合使用ASM的序列化器。这里一通判断下来，是符合采用ASM序列化的要求的，因此，我们又进一步定位到了如下代码：

ObjectSerializer asmSerializer = createASMSerializer(clazz);

在createASMSerializer对应的方法中，最关键的代码莫过于下面这行了：

List<FieldInfo> unsortedGetters = TypeUtils.computeGetters(clazz, jsonType, aliasMap, false);

这力的代码会生成对应的fieldInfo对象，也正好对应了前面我们涉及到的那三个方法，这里让我们仔细看一下com.alibaba.fastjson.util.TypeUtils#computeGetters所对应的代码：

public static List<FieldInfo> computeGetters(Class clazz, JSONType jsonType, Map<String, String> aliasMap, boolean sorted) {
   Map<String, FieldInfo> fieldInfoMap = new LinkedHashMap<String, FieldInfo>();
   for (Method method : clazz.getMethods()) {
       String methodName = method.getName();
       int ordinal = 0, serialzeFeatures = 0;
       String label = null;
//判读当前方法是否为静态的
       if (Modifier.isStatic(method.getModifiers())) {
           continue;
      }
//若返回值为void则此时不需要处理
       if (method.getReturnType().equals(Void.TYPE)) {
           continue;
      }
//若此时入参不为空则跳过
       if (method.getParameterTypes().length != 0) {
           continue;
      }
//若返回类型是类加载器也进行跳过。
       if (method.getReturnType() == ClassLoader.class) {
           continue;
      }
//若方法名是getMetaClass也跳过
       if (method.getName().equals("getMetaClass")
           && method.getReturnType().getName().equals("groovy.lang.MetaClass")) {
           continue;
      }
//获取方法的有关JSONField的注释
       JSONField annotation = method.getAnnotation(JSONField.class);
       if (annotation == null) {
           //若当前类为空，则再获取父类的。
           annotation = getSupperMethodAnnotation(clazz, method);
      }
       if (annotation != null) {
           //若父类不为空则进行序列化的判断，我们使用的例子无继承，这部分先忽略不看。
          ......
      }
       //重点来了，判断当前是否以get开头
       if (methodName.startsWith("get")) {
           //长度小于4，即不满足getXX的格式的，直接跳过。
           if (methodName.length() < 4) {
               continue;
          }
           //getClass的进行跳过
           if (methodName.equals("getClass")) {
               continue;
          }
//获取第四个位置的字符
           char c3 = methodName.charAt(3);
           String propertyName;
           if (Character.isUpperCase(c3) || c3 > 512 ) {
               //若方法遵循驼峰的写法：则依次取出对应的名称信息
               if (compatibleWithJavaBean) {
                   propertyName = decapitalize(methodName.substring(3));
              } else {
                   propertyName = Character.toLowerCase(methodName.charAt(3)) + methodName.substring(4);
              }
          } else if (...) {
               //这里针对部分特殊的写法：如get_X、getfX做了特殊的判断处理。
          } else {
               continue;
          }

续：关于我加了一行日志搞崩了服务这件小事（下）

作者：DrLauPen
来源：juejin.cn/post/7134513215890784293

功能原型图

其实就是微信发送语音的功能。没有转文字的功能。

拆解需求

根据原型图可以很容易的得出我们需要做的内容包括下面三个部分：

1. 接入微信的语音SDK

2. 调用微信SDK的API逻辑

3. 界面和交互的实现

其中第一点和第二点属于业务逻辑部分，第三点属于交互逻辑部分。对于业务逻辑和交互逻辑的关系在我的另外一篇文章描述过，我在vue中是这样拆分组件的 - 掘金 (juejin.cn)

从原型图可以分析出如下的流程图：

评估时间

第三事情是评估时间。在接到这个需求的时候，我们需要假设我们在此之前没有接入过微信相关的SDK，并以此为前提进行工期的评估。

可以将该用户故事拆分为如下任务：

• 微信语音SDK的技术调研（0.5天）

• 输出开发设计文档（0.5天）

• 接入微信语音SDK（0.5天）

• 编码（1天）

• 自测（0.5天）

随后将上面的时间都乘以2！ 自此才可以将估算的工期上报给产品。多年的经验告诉自己，自己一开始估算的工期从来没够过。自行估算的时候，幻想的是在工作的时候能够一直保持专注。

就我自己而言，做不到，上班不可能不摸鱼！也是必须要摸鱼的。乘以2才是刚够而已。

代码实现

都说在实现代码之前要先设计，谋定而后动。我是这样做的，先想好文件夹创建，然后到文件的创建，再到具体文件中写出大体的框架。

需求并不复杂，只是一个界面中的一个模块。所以我只需要一个Record.vue来承载界面，一个use-record-layout.js来承载业务逻辑，以及一个use-record-interact.js来承接交互逻辑。

|__im-record
    |__Record.vue
    |__use-record-layout.js
    |__use-record-interact.js

为了便于说明，将这个聊天的界面简化如下：

<script setup>
import { useNamespace } from "@/use-namespace";
const ns = useNamespace('chat')
</script>
<template>
  <header :class="ns.b('header')"></header>
  <main :class="ns.b('main')">
    <section :class="[ns.b('record'), ns.w('record', 'toast')]">
      <div :class="ns.w('record', 'speak')"></div>
      <div :class="ns.w('record', 'pause')"></div>
    </section>
  </main>
  <footer :class="ns.w('button', 'wrap')">
    <button :class="ns.b('button')">
      <span>
        按住 说话
      </span>
    </button>
  </footer>
</template>

通过上面的代码片段可知，我们的主要的界面在section标签的record部分。

use-record-layout.js的主题代码如下：

  const recordStyle = {
    default: { }, // 默认样式/确定发送录音
    recording: { }, // 录音中
    pause: { }, // 暂停录音
    cancel: { } // 取消录音
  }

  const init = () => {
    initEvent()
    initStyle()
  }

  const initStyle = () => {
    recordStyle.default.is = true
  }

  const initEvent = () => {
    el.addEventListener('touchstart', handleTouchstart)
    el.addEventListener('touchmove', handleTouchmove)
    el.addEventListener('touchend', handleTouchend)
  }

  const axis = {
    posStart: 0, // 初始化起点坐标
    posMove: 0 // 初始化滑动坐标
  }
  const handleTouchstart = (event) => {
    event.preventDefault()
    axis.posStart = event.touches[0].pageY
    recordStyle.recording.is = true
  }
  const handleTouchmove = (event) => {
    event.preventDefault()
    axis.posMove = event.targetTouches[0].pageY
    const diffMove = axis.posMove - axis.posStart
    if (diffMove > DEFAULT_AXIS) {
      recordStyle.recording.is = true
    }
  }
  const handleTouchend = (event) => {
    event.preventDefault()
    recordStyle.default.is = true
  }

  init()

其中recordStyle是交互的结果，在这个需求当中，我们的界面的四种变化都对应其中一个的样式。

use-record-interact.js也很简单，注册微信录音功能 ➡️

const wx = 'wx'
const useRecordInteract = () => {
  const isAuth = localStorage.getItem('allowWxRecord')
  // 获取录音权限
  const authRecord = () => {
    if (!isAuth) {
      wx.startRecord()
      return
    }

    return isAuth
  }
  // 停止录音
  const stopRecord = () => {}
  // 上传录音
  const uploadRecord = () => {}
  
}

交互逻辑和业务逻辑的联动通过recordStyle对象的存取属性来实现,代码片段如下：

const interact = useRecordInteract()
const recordStyle = {
    default: {
      _is: false,
      get is() {
        return this._is
      },
      set is(value) {
        this._is = value
        if (value) {
          this.recording.is = false
          this.pause.is = false
          this.cancel.is = false
          
          interact.uploadRecord()
        }
      }
    },
    //...
}

实现了业务逻辑和交互逻辑的分离。

作者：砂糖橘加盐
来源：juejin.cn/post/7201491839815745597

相信大家在刷 某博 / 某书 / 某音 的时候，最能体会什么叫做 条条大路通 tao bao。经常是你打开一个 App，不小心点了下屏幕，就又打开了另一个 App 了。

那么这种自动打开一个 App 到底是怎么实现的呢？

URL Scheme

首先是最原始的方式 URL Scheme。

URL Scheme 是一种特殊的 URL，用于定位到某个应用以及应用的某个功能。

它的格式一般是： [scheme:][//authority][path][?query]

scheme 代表要打开的应用，每个上架应用商店的 App 所注册的 scheme 都是唯一的；后面的参数代表应用下的某个功能及其参数。

在 IOS 上配置 URL Scheme

在 XCode 里可以轻松配置

在 Android 上配置 URL Scheme

Android 的配置也很简单，在 AndroidManifest.xml 文件下添加以下配置即可

通过访问链接自动打开 App

配置完成后，只要访问 URL Scheme 链接，系统便会自动打开对应 scheme 的 App。

因此，我们可以实现一个简单的 H5 页面来承载这个跳转逻辑，然后在页面中通过调用 location.href=schemeUrl 或者 <a href='schemeUrl' /> 等方式来触发访问链接，从而自动打开 App

优缺点分析

优点： 这个是最原始的方案，因此最大的优点就是兼容性好

缺点：

1. 通过 scheme url 这种方式唤起 App，对于 H5 中间页面是无法感知的，并不知道是否已经成功打开 App

2. 部分浏览器有安全限制，自动跳转会被拦截，必须用户手动触发跳转（即 location.href 行不通，必须 a 标签）

3. 一些 App 会限制可访问的 scheme，你必须要在白名单内，否则也会被拦截跳转

4. 通过 scheme url 唤起 App 时，浏览器会提示你是否确定要打开该 App，会影响用户体验

DeepLink

通过上述缺点我们可以看出，传统的 URL Scheme 在用户体验上是存在一定缺陷的。

因此，DeepLink 诞生了。

DeepLink 的宗旨就是通过传统的 HTT P链接就可以唤醒app，而如果用户没有安装APP，则会跳转到该链接对应的页面。

IOS Universal Link

在 IOS 上一般称之为 Universal Link。

【配置你的 Universal Link 域名】

首先要去 Apple 的开发者平台上配置你的 domains，假设是： mysite.com

【配置 apple-app-site-association 文件】

在该域名根目录下创建一个 .well-known 路径，并在该路径下放置 apple-app-site-association 文件。

文件内容包含 appID 以及 path，path如果配置 /app 则表示访问该域名下的 /app 路径均能唤起App

该文件内容大致如下：

{
    "applinks": {
        "apps": [],
        "details": [
            {
                "appID": "xxx", // 你的应用的 appID
                "paths": [ "/app/*"]
            }
        ]
    }
}
复制代码

【系统获取配置文件】

上面两步配置成功后，当用户 首次安装App 或者后续每次 覆盖安装App 时，系统都会主动去拉取域名下的配置文件。

即系统会主动去拉取 https://mysite.com/.well-known/apple-app-site-association 这个文件

然后根据返回的 appID 以及 path 判断访问哪些路径是需要唤起哪个App

【自动唤起 App】

当系统成功获取配置文件后，只要用户访问 mysite.com/app/xxx 链接，系统便会自动唤起你的 App。

同时，客户端还可以进行一些自定义逻辑处理：

客户端会接收到 NSUserActivity 对象，其 actionType 为 NSUserActivityTypeBrowsingWeb，因此客户端可以在接收到该对象后做一些跳转逻辑处理。

Android DeepLink

与 IOS Universal Link 原理相似，Android系统也能够直接通过网站地址打开应用程序对应的内容页面，而不需要用户选择使用哪个应用来处理网站地址

【配置 AndroidManifest.xml】 在 AndroidManifest 配置文件中添加对应域名的 intent-filter：

scheme 为 https / http；

host 则是你的域名，假设是： mysite.com

【生成 assetlinks.json 文件】

首先要去 Google developers.google.com/digital-ass… 生成你的 assetlinks json 文件。

【配置 assetlinks.json 文件】

生成文件后，同样的需要在该域名根目录下创建一个 .well-known 路径，并在该路径下放置 assetlinks.json 配置文件，文件内容包含应用的package name 和对应签名的sha哈希

【系统获取配置文件】

配置成功后，当用户 首次安装App 或者后续每次 覆盖安装App 时，系统会进行以下校验：

1. 如果 intent-filter 的 autoVerify 设置为 true，那么系统会验证其

• Action 是否为 android.intent.action.VIEW

• Category 是否为android.intent.category.BROWSABLE 和 android.intent.category.DEFAULT

• Data scheme 是否为 http 或 https

1. 如果上述条件都满足，那么系统将会拉取该域名下的 json 配置文件，同时将 App 设置为该域名链接的默认处理App

【自动唤起 App】

当系统成功获取配置文件后，只要用户访问 mysite.com/app/xxx 链接，系统便会自动唤起你的 App。

优缺点分析

【优点】

1. 用户体验好：可以直接打开 App，没有弹窗提示

2. 唤起App失败则会跳转链接对应的页面

【缺点】

1. iOS 9 以后才支持 Universal Link，

2. Android 6.0 以后才支持 DeepLink

3. DeepLink 需要依赖远程配置文件，无法保证每次都能成功拉取到配置文件

推荐方案： DeepLink + H5 兜底

基于前面两种方案的优缺点，我推荐的解决方案是配置 DeepLink，同时再加上一个 H5 页面作为兜底。

首先按照前面 DeepLink 的教程先配置好 DeepLink，其中访问路径配置为 https://mysite.com/app

接着，我们就可以在 https://mysite.com/app 路径下做文章了。在该路径下放置一个 H5 页面，内容可以是引导用户打开你的 App。

当用户访问 DeepLink 没有自动打开你的 App 时，此时用户会进入浏览器，并访问 https://mysite.com/app 这个 H5 页面。

在 H5 页面中，你可以通过浏览器 ua 获取当前的系统以及版本：

1. 如果是 Android 6.0 以下，那么可以尝试用 URL Scheme 去唤起 App

2. 如果是 IOS / Android 6.0 及以上，那么此时可以判断用户未安装 App。这种情况下可以做些额外的逻辑，比如重定向到应用商店引导用户去下载之类的

作者：龙飞_longfe
来源：juejin.cn/post/7201521440612974649