当我们发布新功能时，需要尽可能降低因新功能发布所导致的线上风险，通常会采取灰度放量的方式将新功能逐步发布给用户。在具体实施灰度放量时，我们可以根据业务需求选择相应的放量规则，常见如按白名单放量（如仅 QA 可见）、按特定人群属性放量（如仅某个城市的用户可见）亦或是按用户百分比放量。

当我们选择将功能以用户百分比放量时，如下图所示，会先将功发布给10% 内部用户，此时即便出现问题影响也相对可控，如观察没有问题后逐步扩大需要放量的用户百分比，实现从少量到全量平滑过渡的上线。

那么在 FeatureProbe 上要如何实现百分比放量？

下面将通过一个实际的例子介绍如何通过 FeatureProbe 实现按百分比放量发布一个新功能。

步骤一：创建一个特性开关

接着，配置开关百分比信息。以收藏功能百分比发布为例，设置 10%  的用户可用收藏功能，而另外 90% 的用户无法使用收藏功能。

步骤二：将 SDK 接入应用程序

接下来，将 FeatureProbe SDK 接入应用程序。FeatureProbe 提供完整清晰的接入引导，只需按照步骤即可快速完成 SDK 接入。

1、选择所使用的 SDK

2、按步骤设置应用程序

3、测试应用程序 SDK接入情况

步骤三：按百分比放量发布开关

开关信息配置和 SDK 接入都完成后，点击发布按钮并确认发布。这将会将收藏功能发布给用户，但只有10%的用户可以使用收藏功能。

如果希望逐步扩大灰度范围，可以在开关规则中配置百分比比例。

大部分情况下，我们希望在一个功能的灰度放量过程中，某个特定用户一旦进入了灰度放量组，在灰度比例不减少的情况下，总是进入灰度组。不希望用户因为刷新页面、重新打开APP、请求被分配到另一个服务端实例等原因，一会看到新功能，一会看不到新功能，从而感到迷惑。要达到用户稳定进入灰度组，只需要在上述代码第三步创建 User 时指定stableRollout 即可，具体使用详情见：docs.featureprobe.io/zh-CN/tutor…

总结

灰度按百分比放量是一种软件开发中常用的功能发布方法，它可以帮助提高软件可靠性，提高用户体验，在实施时也需要注意几个方面：

1、确定放量目标：首先需要确定放量的目标，例如增加多少百分比的数据量。这个目标需要根据实际情况进行制定，例如需要考虑数据量的大小、计算资源的限制等因素。

2、确定放量规则：你需要确定在放量过程中，哪些功能会被启用，哪些功能会被禁用。你可以根据开发进度、测试结果和市场需求等因素来确定放量规则。

3、监控放量过程：在实施放量操作时，需要监控放量过程，以确保放量结果的稳定性和可靠性。如果出现异常情况，需要及时采取措施进行调整。

若要了解有关FeatureProbe 灰度发布的更多信息，请查看其官方文档中的教程。该教程可以提供关于如何进行灰度发布的详细说明。文档中还包括其他相关主题的信息，例如如何进行服务降级和指标分析等。请访问以下链接以查看该文档：docs.featureprobe.io/zh-CN/tutor…

关于我们

FeatureProbe 是国内首家功能开关管理开源平台，它包含了灰度放量、AB实验、实时配置变更等针对『功能粒度』的一系列管理操作，完全开源，可以放心直接使用。

当前 FeatureProbe 作为一个功能开关管理平台已经使用 Apache 2.0 License 协议完全开源，你可以在 GitHub 和 Gitee 上访问源码，你也可以在上面给提 issue 和 feature 等。

GitHub: github.com/FeatureProb…

Gitee: gitee.com/featureprob…

体验环境: featureprobe.io/

1.缘起：

为啥想学习es，主要是在工作中会用到，但是因为不了解原理，所以用起来畏手畏脚的，就想了解下es是怎么存储数据，以及es是怎么搜索数据的，我们平时应该如 何使用es，以及使用时候需要注意的方面。
es:github.com/elastic/ela…
lucene:github.com/apache/luce…

2.es的一些基础概念

es是一个基于lucence的分布式的搜索引擎，它使用java编写，并提供了一套RESTful api，是一款流行的企业级搜索引擎

2.1 es的特点

1. 横向可扩展性: 作为大型分布式集群, 很容易就能扩展新的服务器到ES集群中; 也可运行在单机上作为轻量级搜索引擎使用.


2. 更丰富的功能: 与传统关系型数据库相比, ES提供了全文检索、同义词处理、相关度排名、复杂数据分析、海量数据的近实时处理等功能.


3. 分片机制提供更好地分布性: 同一个索引被分为多个分片(Shard), 利用分而治之的思想提升处理效率.


4. 高可用: 提供副本(Replica)机制, 一个分片可以设置多个副本, 即使在某些服务器宕机后, 集群仍能正常工作.


5. 开箱即用: 提供简单易用的API, 服务的搭建、部署和使用都很容易操作.

2.2 es的重要概念

1.cluster(集群)
可以通过为多个节点配置同一个集群名来创建集群，通过elasticsearch.yml文件配置。
2.node(节点)
运行了单个es实例的主机被成为节点，一个集群里会包含一个或者多个节点。可以用来存储数据，搜索数据，操作数据。有三个主节点，三个数据节点。

3.shard(分片)
一个索引会分成多个分片，并存储在不同的节点中。每个shard都是一个最小工作单元，承载部分数据，对应一个lucene实例，具有完整的建立索引和处理请求的能力。shard分为primary shard和replica shard，其中replica shard 负责容错，以及承担读请求负载。一个document只会存在一个primary shard及其replica shard中，而不会存在于多个primary shard中。shards:5*2，表示有五个primary shard 以及五个replica shard。一旦创建完成，其primary shard的数量将不可更改。

4.index（索引）
一堆类型数据结构相同的document的集合。类似于数据库中的表
5.document( 文档)
es中的最小数据单元。比如一条纠纷单的数据，存在es中就是一个document。但是存储格式为json。类似于数据库中的一行数据。
6.type
类型，一个索引会存在一个或者多个 type，一个type下的document有相同的field。7.x后废弃
7.field
一个field就是一个数据字段
8.term
field的内容在经过analyze后，会被分词为term，是数据中最小的存储单位
9.数据库和es概念类比Elasticsearch 关系型数据库

3.es是如何存储数据的

3.1 es写入数据过程

1. 用户发送的请求会随机打到某一node，此时这个node为coordinate node


2. coordinate node通过路由策略找到对应的主分片 shard = hash(routing) % number_of_primary_shards，其中routing为docId，如果docId不存在，es会生成一个id来实现路由。主分片也会把请求转发到副本分片，实现数据备份。索引的primary shards在索引创建后不可更改也是因为路由策略，举个例子，对于同一个docId，原本存在primary shard 0 中，但是primary shard num修改后，就被路由到primary shard 3，这样就出现数据查不到的情况了。


3. 主分片&副本分片会构建索引以及将索引落盘

3.2 es近实时特性的原理

1. 写请求将数据写入buffer中，此时数据是不能被搜索到的，此时会同时将写操作记录在translog中，translog的落盘如果配置成同步，此时就会落盘，如果配置成异步，会在配置间隔时间进行落盘。


2. 默认1s一次的refresh操作，es会将buffer里的数据存入os cache中，并把buffer中的数据转化成segment，此时document便可以被搜索到了。每次refresh都会生成一个segment，es会定期进行segment合并。refresh数据到os cache后，buffer会被清空。


3. 每隔30min或者segment达到512M 后，会把os cache中的segment写入到磁盘中，这个过程叫做flush。此时会生成一个commit point文件，用来唯一标识该segment。执行flush操作时，会把buffer和os cache里的数据清空，此时translog也会被落盘。原有的translog会被删除，会在内存中创建一个新的translog。

3.3 segment的数据结构以及索引的原理

segment是lucene的概念，也是实现搜索的关键。名称 扩展名 简要描述
Term Dictionary .tim term词典，存储term信息
Term Index .tip 指向term词典的索引
Frequencies .doc 包含了有term的频率的文档列表
Positions .pos 存储了每个出现在索引中的term的位置信息
Payloads .pay 存储了额外的每一个位置的元数据信息如一个字符偏移和用户的负载
Field Index .fdx 包含field data的指针
Field Data .fdt 存储docs里的field表1 segment文件

其中和倒排索引相关的是.tim、.tip、.doc、.pos、.pay文件，而和正向索引相关的是.fdx、.fdt文件。下面先讲下倒排索引

3.3.1 lucene的倒排索引结构

倒排索引，其实从字面意义上很容易理解错，但是看英文就会好理解一些，inverted index，反向的索引。为什么称之为反向的索引，那应该有正向索引，正向索引指的是文档id和文档内容的映射关系，mysql的主键索引就是一个正向索引，而倒排索引，就是把这种对应关系颠倒，指的是，索引词（关键词）和文档之间的对应关系，即通过一个关键词，可以得到包含这个关键词的所有文档的文档id。

1. 通过对查询语句的解析，得到需要查找的term，找到该term对应的.tip文件和.tim文件。lucene会默认为每一个term都创建对应的索引


2. term index主要由FSTIndex和indexStartFP组成，FST(Finite State Transducer)有限状态转移机。我觉得可以理解为一个词语前缀索引。通过对前缀索引的搜索，就可以缩小搜索的范围，提高搜索的效率。


3. indexStartFPn里存的是FSTIndexn的地址， 为啥要存indexStartFPn，是因为每个FSTIndexn的大小不一样，为了节省存储空间，密集存储FSTIndexn，但是这样就没办法快速查找FSTIndexn。因此使用空间换时间，存下每个FSTIndexn的起始地址，而indexStartFP的大小都一样，这样就可以通过indexStartFPn进行二分查找了。


4. 通过term的前缀匹配定位到该term可能存在的block，此时就需要到.tim文件里去查找。可以看到.tim文件我们比较关注的是三部分。一是suffix；二是TermStats；三是TermsMetaData。其中suffix里存放的就是该term的后缀长度和suffix的内容。TermStats里包含的是该Term在文档中的频率以及所有 Term的频率，这部分是为了计算相关性。


5. 第三部分TermsMetaData里存放的是该Term在.doc、.pos、.pay中的地址。.doc文件中存放的是docId信息，包括这个term所在的docId、频率等信息。.pos文件里包含该term在每个文档里的位置。通过.tim文件里存放的这些地址，就可以去对应的文件里得出该term所在的文档id、位置、频率这些重要的信息了。

3.3.2 lucene的正向索引结构

通过倒排索引拿到的docId后，如何去拿到文档的其他字段信息，这时候就需要用到正向索引了

● fdt文件里每个chunk里包含压缩后的doc信息。fdx文件里存放的是每组chunk的起始地址
● fdx文件较小，直接加载到内存
● 通过fdx文件拿到对应的docid所在chunk的地址，再加载doc的数据信息。
● 通过正向索引拿到doc的数据类似于mysql里的回表操作

3.3.3 和mysql索引的对比

● 默认设置情况下 lucene会为doc里的每个term都创建对应的倒排、正向索引，而mysql只会为你指定的列创建索引，因此对于复杂查询场景，使用es来查询更合适，mysql无法构建索引覆盖所有的查询情况
● mysql的索引是存放在磁盘里的，检索时需要分页加载到内存再检索；lucene的.tip文件很小，可以直接放入内存，在检索时候，通过term index来快速定位到term可能存在的block。相当于给索引（词典表.tim文件）又建立了一层索引，查询效率更高

4.es是如何搜索数据的

1. 用户发送的搜索请求会随机达到任意一个node上，该node即为coordinate node。


2. coordinate node会将请求转发到该索引对应的所有的primary shard或者replica shard中


3. 每个shard处理query请求，通过lucene的搜索能力，将搜索结果返回给coordinate node


4. coordinate node将所有的结果处理后，根据排序要求取topk，再返回给client。

每一个分片中发生的搜索过程

1. 对用户的请求语句进行词法、语法分析，生成查询语法树，把文本请求转换为Lucene理解的请求对象


2. 按照查询语法树，搜索索引获取最终匹配的文档id集合


3. 对查询结果进行相关性排序，获取Top N的文档id集合，获取文档原始数据后返回用户
   5.一些关于es的使用思考


4. 对于复杂的查询场景，es查询优于mysql，对于实时性要求高，或需要实现事务操作的场景，需要使用mysql。


5. 由于es是通过查询所有分片，合并后再给出最终查询结果，所以也和mysql一样，需要注意深分页的问题，不过这块es已经做了限制，默认只返回前1w条的查询结果


6. 索引过大也会导致查询慢，可以从上面讲的索引结构看出，虽然term index是可以加载到内存的，但是最终的term dict也是存在磁盘里的，对于具体term的查询需要花费很多时间。此时可以考虑重建索引，使用更多的分片来存储/查询数据。


7. 尽可能地使用filter来代替query，query需要对查询结果进行相关性排序，而filter则不需要。

前言

在实际工作中，我们经常需要在项目中调用第三方API接口，获取数据，或者上报数据，进行数据交换和通信。

那么，调用第三方API接口会遇到哪些问题？如何解决这些问题呢？

这篇文章就跟大家一起聊聊第三方API接口的话题，希望对你会有所帮助。

1 域名访问不到

一般我们在第一次对接第三方平台的API接口时，可能会先通过浏览器或者postman调用一下，该接口是否可以访问。

有些人可能觉得多次一举。

其实不然。

有可能你调用第三方平台的API接口时，他们的接口真的挂了，他们还不知道。

还有一种最重要的情况，就是你的工作网络，是否可以访问这个外网的接口。

有些公司为了安全考虑，对内网的开发环境，是设置了防火墙的，或者有一些其他的限制，有些ip白名单，只能访问一些指定的外网接口。

如果你发现你访问的域名，在开发环境访问不通，就要到运维同学给你添加ip白名单了。

2 签名错误

很多第三方API接口为了防止别人篡改数据，通常会增加数字签名(sign)的验证。

sign = md5(多个参数拼接 + 密钥)

在刚开始对接第三方平台接口时，会遇到参数错误，签名错误等问题。

其中参数错误比较好解决，重点是签名错误这个问题。

签名是由一些算法生成的。

比如：将参数名和参数值用冒号拼接，如果有多个参数，则按首字母排序，然后再将多个参数一起拼接。然后加盐（即：密钥），再通过md5，生成一个签名。

如果有多个参数，你是按首字母倒序的，则最后生成的签名会出问题。

如果你开发环境的密钥，用的生产环境的，也可能会导致生产的签名出现问题。

如果第三方平台要求最后3次md5生成签名，而你只用了1次，也可能会导致生产的签名出现问题。

因此，接口签名在接口联调时是比较麻烦的事情。

如果第三方平台有提供sdk生成签名是最好的，如果没有，就只能根据他们文档手写签名算法了。

3 签名过期

通过上面一步，我们将签名调通了，可以正常访问第三方平台获取数据了。

但你可能会发现，同一个请求，15分钟之后，再获取数据，却返回失败了。

第三方平台在设计接口时，在签名中增加了时间戳校验，同一个请求在15分钟之内，允许返回数据。如果超过了15分钟，则直接返回失败。

这种设计是为了安全考虑。

防止有人利用工具进行暴力破解，不停伪造签名，不停调用接口校验，如果一直穷举下去的话，总有一天可以校验通过的。

sign = md5(多个参数拼接 + 密钥 + 时间戳)

因此，有必要增加时间戳的校验。

如果出现这种情况，不要慌，重新发起一次新的请求即可。

4 接口突然没返回数据

如果你调用第三方平台的某个API接口查询数据，刚开始一直都有数据返回。

但突然某一天没返回数据了。

但是该API接口能够正常响应。

不要感到意外，有可能是第三方平台将数据删除了。

我对接完第三方平台的API接口后，部署到了测试环境，发现他们接口竟然没有返回数据，原因是他们有一天将测试环境的数据删完了。

因此，在部署测试环境之前，要先跟对方沟通，要用哪些数据测试，不能删除。

5 token失效

有些平台的API接口在请求之前，先要调用另外一个API接口获取token，然后再header中携带该token信息才能访问其他的业务API接口。

在获取token的API接口中，我们需要传入账号、密码和密钥等信息。每个接口对接方，这些信息都不一样。

我们在请求其他的API接口之前，每次都实时调用一次获取token的接口获取token？还是请求一次token，将其缓存到redis中，后面直接从redis获取数据呢？

很显然我们更倾向于后者，因为如果每次请求其他的API接口之前，都实时调用一次获取token的接口获取token，这样每次都会请求两次接口，性能上会有一些影响。

如果将请求的token，保存到redis，又会出现另外一个问题：token失效的问题。

我们调用第三方平台获取token的接口获取到的token，一般都有个有效期，比如：1天，1个月等。

在有效期内，该API接口能够正常访问。如果超过了token的有效期，则该API接口不允许访问。

好办，我们把redis的失效时间设置成跟token的有效期一样不就OK了？

想法是不错，但是有问题。

你咋保证，你们系统的服务器时间，跟第三方平台的服务器时间一模一样？

我之前遇到过某大厂，提供了获取token接口，在30天内发起请求，每次都返回相同的token值。如果超过了30天，则返回一个新的。

有可能出现这种情况，你们系统的服务器时间要快一些，第三方平台的时间要慢一些。结果到了30天，你们系统调用第三方平台的获取token接口获取到了token还是老的token，更新到redis中了。

过一段时间，token失效了，你们系统还是用老的token访问第三方平台的其他API接口，一直都返回失败。但获取新的token却要等30天，这个时间太漫长了。

为了解决这个问题，需要捕获token失效的异常。如果在调用其他的API接口是发现token失效了，马上请求一次获取token接口，将新的token立刻更新到redis中。

这样基本可以解决token失效问题，也能尽可能保证访问其他接口的稳定性和性能。

6 接口超时

系统上线之后，调用第三方API接口，最容易出现的问题，应该是接口超时问题了。

系统到外部系统之间，有一条很复杂的链路，中间有很多环节出现问题，都可能影响API接口的相应时间。

作为API接口的调用方，面对第三方API接口超时问题，除了给他们反馈问题，优化接口性能之外，我们更有效的方式，可能是增加接口调用的失败重试机制。

例如：

int retryCount=0;

do {

   try {

      doPost();

      break;

   } catch(Exception e) {

     log.warn("接口调用失败")

     retryCount++;

   }

} where (retryCount <= 3)

如果接口调用失败，则程序会立刻自动重试3次。

如果重试之后成功了，则该API接口调用成功。

如果重试3次之后还是失败，则该API接口调用失败。

7 接口返回500

调用第三方API接口，偶尔因为参数的不同，可能会出现500的问题。

比如：有些API接口对于参数校验不到位，少部分必填字段，没有校验不能为空。

刚好系统的有些请求，通过某个参数去调用该API接口时，没有传入那个参数，对方可能会出现NPE问题。而该接口的返回code，很可能是500。

还有一种情况，就是该API接口的内部bug，传入不同的参数，走了不同的条件分支逻辑，在走某个分支时，接口逻辑出现异常，可能会导致接口返回500。

这种情况做接口重试也没用，只能联系第三方API接口提供者，反馈相关问题，让他们排查具体原因。

他们可能会通过修复bug，或者修复数据，来解决这个问题。

8 接口返回404

如果你在系统日志中发现调用的第三方API接口返回了404，这就非常坑了。

如果第三方的API接口没有上线，很可能是他们把接口名改了，没有及时通知你。

这种情况，可以锤他们了。

还有一种情况是，如果第三方的API接口已经上线了，刚开始接口是能正常调用的。

第三方也没有改过接口地址。

后来，突然有一天发现调用第三方的API接口还是出现了404问题。

这种情况很可能是他们网关出问题了，最新的配置没有生效，或者改了网关配置导致的问题。

总之一个字：坑。

9 接口返回少数据了

之前我调过一个第三方的API接口分页查询数据，接入非常顺利，但后来上线之后，发现他们的接口少数据了。

一查原因发现是该分页查询接口，返回的总页数不对，比实际情况少了。

有些小伙伴可能会好奇，这么诡异的问题我是怎么发现？

之前调用第三方API接口分页查询分类数据，保存到我们的第三方分类表中。

突然有一天，产品反馈说，第三方有个分类在分类树中找不到。

我确认之后，发现竟然是真的没有。

从调用第三方API接口的响应日志中，也没有查到该分类的数据。

这个API接口是分页查询接口，目前已经分了十几页查询数据，但还是没有查到我们想要的分类。

之前的做法是先调用一次API接口查询第一页的数据，同时查出总页数。然后再根据总页数循环调用，查询其他页的数据。

我当时猜测，可能是他们接口返回的总页数有问题。

于是，可以将接口调用逻辑改成这样的：

• 从第一页开始，后面每调用一次API接口查数据，页数就加1。然后判断接口返回的数据是否小于pageSize，


• 如果不小于，则进行下一次调用。


• 如果小于，则说明已经是最后一页了，可以停止后续调用了。

验证之后发现这样果然可以获取那个分类的数据，只能说明第三方的分页查询接口返回的总页数比实际情况小了。

10 偷偷改参数了

我之前调用过某平台的API接口获取指标的状态，之前根据双方约定的状态有：正常和禁用 两种。

然后将状态更新到我们的指标表中。

后来，双方系统上线运行了好几个月。

突然有一天，用户反馈说某一条数据明明删除了，为什么在页面上还是可以查到。

此时，我查我们这边的指标表，发现状态是正常的。

然后查看调用该平台的API接口日志，发现返回的该指标的状态是：下架。

what？

这是什么状态？

跟该平台的开发人员沟通后，发现他们改了状态的枚举，增加了：上架、下架等多个值，而且没有通知我们。

这就坑了。

我们这边的代码中判断，如果状态非禁用状态，都认为是正常状态。

而下架状态，自动被判断为正常状态。

经过跟对方沟通后，他们确认下架状态，是非正常状态，不应该显示指标。他们改了数据，临时解决了该指标的问题。

后来，他们按接口文档又改回了之前的状态枚举值。

11 接口时好时坏

不知道你在调用第三方接口时，有没有遇到过接口时好时坏的情况。

5分钟前，该接口还能正常返回数据。

5分钟后，该接口返回503不可用。

又过了几分钟，该接口又能正常返回数据了。

这种情况大概率是第三方平台在重启服务，在重启的过程中，可能会出现服务暂时不可用的情况。

还有另外一种情况：第三方接口部署了多个服务节点，有一部分服务节点挂了。也会导致请求第三方接口时，返回值时好时坏的情况。

此外还有一种情况：网关的配置没有及时更新，没有把已经下线的服务剔除掉。

这样用户请求经过网关时，网关转发到了已经下线的服务，导致服务不可用。网关转发请求到正常的服务，该服务能够正常返回。

如果遇到该问题，要尽快将问题反馈给第三方平台，然后增加接口失败重试机制。

12 文档和接口逻辑不一致

之前还遇到一个第三方平台提供的API查询接口，接口文档中明确写明了有个dr字段表示删除状态。

有了这个字段，我们在同步第三方平台的分类数据时，就能够知道有哪些数据是被删除的，后面可以及时调整我们这边的数据，将相关的数据也做删除处理。

后来发现有些分类，他们那边已经删除了，但是我们这边却没删除。

这是啥情况呢？

代码逻辑很简单，我review了一下代码，也没有bug，为什么会出现这种情况呢？

追查日志之后发现，调用第三方平台获取分类接口时，对方并没有把已删除的分类数据返回给我们。

也就是说接口文档中的那个dr字段没有什么用，接口文档和接口逻辑不一致。

这个问题估计好多小伙伴都遇到过。

如果要解决这个问题，主要的方案有两种：

1. 第三方平台按文档修改接口逻辑，返回删除状态。


2. 我们系统在调用分类查询接口之后，根据分类code判断，如果数据库中有些分类的code不在接口返回值中，则删除这些分类。

13 欠费了

我们调用过百度的票据识别接口，可以自动识别发票信息，获取发票编号和金额等信息。

之前是另外一个同事对接的接口，后来他离职了。

发票识别功能上线，使用了很长一段时间，一直都没有出问题。

后来，某一天，生产环境用户反馈发票识别不了了。

我查询了相关服务的日志，没有发现异常，这就奇怪了。

打开代码仔细看了一下，发现那位同事的代码中调用第三方的API接口，接收响应数据时，直接转换成了对象，没有打印当时返回的字符串。

莫非，接口返回值有问题？

后来，我增加了日志，打印出了该接口真正的返回内容值。

原因一下查到了，原来是欠费了。

如果出现该了异常，百度的API接口返回的数据结构，用之前那位同事的实体有些参数没法获取到。

这是一个不小的坑。

我们在接收第三方API接口返回数据时，尽可能先用字符串接收返回值，然后将字符串转换成相应实体类，一定要将该返回值在日志中打印出来，方便后面定位问题。

不要直接用实体对象接收返回值，有些API接口，如果出现不同的异常，返回的数据结构差异比较大。

有些异常结果可能是他们网关系统直接返回的，有些异常是他们业务系统返回的。

其实，我们之前还遇到过其他坑，比如：调用分类树查询接口，但第三方返回的数据有重复的id，我们这边该如何处理这种异常数据呢？

我们在job中循环调用第三方API接口获取数据，如果其中某一次调用失败了，是try/catch捕获异常呢？继续执行后面的调用，还是直接终止当前的程序？如果try/catch如何保证数据一致性？终止当前程序，该如何处理后续的流程？

最后说一句(求关注，别白嫖我)

如果这篇文章对您有所帮助，或者有所启发的话，帮忙扫描下发二维码关注一下，您的支持是我坚持写作最大的动力。

1. 起因

这一切还得从前段时间接到的一个需求讲起。

业务方需要离线计算一批A附近5公里内的B，并统计聚合B的相关指标，进行展示。

嗯，听起来很合理。🤔

2. 问题

虽然在进行前期评估时，就已经预料到计算量会很大（当时的计算方案十分简陋）。

但在实际运行过程中，还是发现附近5km的逻辑，计算效率过于低下（按照城市编码将数据拆分为3个任务进行并行计算，但平均耗时还是会达到7-10个小时，无法接受）😦

3. 一些尝试

3.1 第一版：

最开始的计算逻辑很粗暴：把每个城市内的A和B进行full join，然后根据经纬度逐个计算距离，排除掉超出距离限制的集合。肉眼可见的低效。。。

3.2 第二版：

由于全量计算十分耗时，并且大部分B的坐标也不会经常变更，因此开始考虑使用增量计算进行优化，减少重复计算。

但在实际任务运行过程中发现，大量耗时用在了历史数据和新增数据的合并写入，并没有有效的效率提升。

3.3 第三版：

这个时候，已经没有什么优化的头绪了。只是一次偶然的搜索，让我发现了一个全新的实现逻辑。（没错，面向google编程）

一个周五的晚上，脑袋里思索着通过经纬度计算距离的逻辑，突然一个想法出现：既然经纬度可以进行距离计算，是否意味着经纬度的数字也是和距离有着一定的转换关系，比如经度小数点后1位，代表距离xx公里？

带着这个疑问，我发现了这两篇文章。

其中 高效的多维空间点索引算法 — Geohash 和 Google S2介绍的案例，与我的需求十分相似。（大神的文章值得好好阅读）

里面提到的geohash算法，则是1966年就有人提出的一种将经纬度坐标点进行一维化编码的解决思路。而后续的google的s2、uber的h3，均是在此设计理念的基础上优化而来的。

这种算法的本质就是对地球的每一块区域都进行编码（精度可调），也就是一个编码代表着一段经纬度范围内的区域。

那么接下来问题就简单了，找到合适的编码方案以及精度参数，测试验证即可。

具体的方案选择就不重复了。可以参考这个帖子：geohash、google s2、uber h3三种格网系统比较

我这边最终选择的是h3(h3-pyspark)。

4. 最终解决

第一步：将A的经纬度按照需要的精度进行编码，再获取该编码附近x公里的区域编码集合。

第二步：将B的经纬度按照同样的精度进行编码。

第三步：将两个数据集inner join，即可获得符合要求的集合。

是的，就是这么简单。（摊手）

5. 总结

通过这次的问题解决，学习到了这类场景的通用解决方案，受益匪浅。

6. 参考文章

高效的多维空间点索引算法 — Geohash 和 Google S2

彩云天气地理查询优化(2): 行政区划查询

geohash算法

geohash、google s2、uber h3三种格网系统比较

h3-pyspark

Uber H3使用

  Donald Knuth（高德纳）是一位计算机科学界的著名学者和计算机程序设计的先驱之一。他被誉为计算机科学的“圣经”《计算机程序设计艺术》的作者，提出了著名的“大O符号”来描述算法的时间复杂度和空间复杂度，开发了TeX系统用于排版科技文献，获得过图灵奖、冯·诺伊曼奖、美国国家科学奖章等多项荣誉。今天要说的就是他所提出的一条软件设计重要原则 Premature optimization is the root of all evil 过早优化是万恶之源。


为什么说“过早优化是万恶之源”？ 我认为过早优化代码会让人陷入到错误的目标中去，从而忽视掉了最重要的目标。举个很简单的例子，你需要快速构建一个产品来抢占用户，你当下最重要的目标是让这个产品快速上线，而不是把这个产品打造的好用(在中国互联网下，这样的事数不胜数)，如果你只关注到后者体验、性能问题而忽视了速度，在当下高度竞争的市场之下，你根本毫无机会。

  当然上面这个例子是从感性的层面说的，对很多程序猿来说也可能涉及不到产品层面的内容。我们从软件设计的层面，理性的来说，过早优化可能会导致以下的一些问题：

1. 
   

   增加代码的复杂性：过度优化可能会导致代码的复杂性增加，从而降低代码的可读性和可维护性。如果代码过于复杂，可能会导致开发人员难以理解和维护代码，从而增加开发成本和时间。

   
   


2. 
   

   耗费开发时间和资源：过度优化可能会导致开发人员花费大量时间和资源在代码的性能优化上，而忽略了其他重要的开发任务。这可能会导致项目进度延误和开发成本增加。

   
   


3. 
   

   降低代码的可移植性：过度优化可能会导致代码的可移植性降低。如果代码过于依赖于特定的硬件或操作系统，可能会导致代码无法在其他环境中运行。

   
   


4. 
   

   降低代码的可扩展性：过度优化可能会降低代码的可扩展性。如果代码过于依赖于特定的算法或数据结构，可能会导致代码无法适应未来的需求变化。

   
   

过早优化的典型案例

  在软件工程史上由于过度关注软件性能导致项目最终失败的案例比比皆是，比如我下面要说的一些项目，在软件工程史上都是非常知名的项目（当然可能有些新生代程序员已经不知道了）。

1. 
   

   IBM OS/360操作系统：在20世纪60年代，IBM公司开发了OS/360操作系统，这是当时最大的软件工程项目之一。在开发过程中，IBM公司过于关注代码的性能问题，导致代码的复杂性增加，开发时间延误，最终导致项目的失败。我知晓这个项目还是在我最近在阅读的一本软件工程经典书籍《人月神话》中，也推荐大家阅读下，这个项目虽然最终失败了，但也给整个软件工程领域留下了宝贵的经验。

   
   


2. 
   

   Netscape Navigator浏览器：在20世纪90年代，Netscape公司开发了Navigator浏览器，这是当时最流行的浏览器之一。在开发过程中，Netscape公司过于关注代码的性能问题，导致代码的复杂性增加，开发时间延误，最终导致浏览器市场份额严重下降。

   
   


3. 
   

   Windows Vista操作系统：在21世纪初，微软公司开发了Windows Vista操作系统，这是当时最大的软件工程项目之一。在开发过程中，微软公司过于关注代码的性能问题，导致代码的复杂性增加，开发时间延误，最终导致操作系统的用户体验不佳，市场反响不佳。话说这个操作系统我还用过呢，用户界面还是很漂亮的，很多UI设计也被沿用到了Window7中。

   
   

如何识别过早优化

  在软件开发过程中，如何判断是否过早优化呢？这里有一些概括性的判断标准，可以简单参考下：

1. 
   

   是否存在性能问题：如果代码还没有性能问题，那么过早优化就是不必要的。因此，在进行优化之前，应该先测试代码的性能，确定是否存在性能问题。

   
   


2. 
   

   是否优化了未来可能发生的问题：如果优化的是未来可能发生的问题，而不是当前存在的问题，那么就可能是过早优化。在进行优化之前，应该优先考虑当前存在的问题，而不是未来可能发生的问题。

   
   


3. 
   

   是否牺牲了代码的可读性和可维护性：如果优化代码会导致代码的复杂性增加，降低代码的可读性和可维护性，那么就可能是过早优化。在进行优化之前，应该优先考虑代码的可读性、可维护性和可扩展性。

   
   


4. 
   

   是否浪费了大量的开发时间和资源：如果优化代码会浪费大量的开发时间和资源，而不是提高代码的性能和效率，那么就可能是过早优化。在进行优化之前，应该评估优化的成本和收益，确定是否值得进行优化。

   
   

  判断是否过早优化需要根据具体情况进行评估。在进行优化之前，应该先测试代码的性能，确定是否存在性能问题。同时，也应该优先考虑代码的可读性、可维护性和可扩展性，避免过度优化。

总结

  作为一名在IT领域摸爬滚打多年的工程师，我深有体会地认识到过早优化是软件开发中的一大陷阱。在软件开发的初期，我们可能会过于关注代码的性能问题，而忽略了代码的可读性、可维护性和可扩展性。这种做法可能会导致代码的复杂性增加，降低代码的可读性和可维护性，甚至可能会浪费大量的开发时间和资源。

  在软件开发过程中，我们应该避免过早优化，而是优先考虑代码的可读性、可维护性和可扩展性。当需要进行性能优化时，应该在代码的基础上进行优化，通过分析性能瓶颈、优化算法和数据结构等方法来提高代码的性能和效率。同时，我们也应该意识到，性能优化并不是软件开发的唯一目标，我们还应该注重代码的可读性、可维护性和可扩展性，以便保证代码的质量和可靠性。

一、设计思路

对于一些登录之后才能访问的接口（例如：查询我的账号资料），我们通常的做法是增加一层接口校验：

• 如果校验通过，则：正常返回数据。


• 如果校验未通过，则：抛出异常，告知其需要先进行登录。

那么，判断会话是否登录的依据是什么？我们先来简单分析一下登录访问流程：

1. 用户提交 name + password 参数，调用登录接口。


2. 登录成功，返回这个用户的 Token 会话凭证。


3. 用户后续的每次请求，都携带上这个 Token。


4. 服务器根据 Token 判断此会话是否登录成功。

所谓登录认证，指的就是服务器校验账号密码，为用户颁发 Token 会话凭证的过程，这个 Token 也是我们后续判断会话是否登录的关键所在。

动态图演示：

接下来，我们将介绍在 SpringBoot 中如何使用 Sa-Token 完成登录认证操作。

Sa-Token 是一个 java 权限认证框架，主要解决登录认证、权限认证、单点登录、OAuth2、微服务网关鉴权 等一系列权限相关问题。
Gitee 开源地址：gitee.com/dromara/sa-…

首先在项目中引入 Sa-Token 依赖：

<!-- Sa-Token 权限认证 -->

<dependency>

    <groupId>cn.dev33</groupId>

    <artifactId>sa-token-spring-boot-starter</artifactId>

    <version>1.34.0</version>

</dependency>

注：如果你使用的是 SpringBoot 3.x，只需要将 sa-token-spring-boot-starter 修改为 sa-token-spring-boot3-starter 即可。

二、登录与注销

根据以上思路，我们需要一个会话登录的函数：

// 会话登录：参数填写要登录的账号id，建议的数据类型：long | int | String， 不可以传入复杂类型，如：User、Admin 等等

StpUtil.login(Object id);	 

只此一句代码，便可以使会话登录成功，实际上，Sa-Token 在背后做了大量的工作，包括但不限于：

1. 检查此账号是否之前已有登录


2. 为账号生成 Token 凭证与 Session 会话


3. 通知全局侦听器，xx 账号登录成功


4. 将 Token 注入到请求上下文


5. 等等其它工作……

你暂时不需要完整的了解整个登录过程，你只需要记住关键一点：Sa-Token 为这个账号创建了一个Token凭证，且通过 Cookie 上下文返回给了前端。

所以一般情况下，我们的登录接口代码，会大致类似如下：

// 会话登录接口 

@RequestMapping("doLogin")

public SaResult doLogin(String name, String pwd) {

	// 第一步：比对前端提交的账号名称、密码

	if("zhang".equals(name) && "123456".equals(pwd)) {

		// 第二步：根据账号id，进行登录 

		StpUtil.login(10001);

		return SaResult.ok("登录成功");

	}

	return SaResult.error("登录失败");

}

如果你对以上代码阅读没有压力，你可能会注意到略显奇怪的一点：此处仅仅做了会话登录，但并没有主动向前端返回 Token 信息。
是因为不需要吗？严格来讲是需要的，只不过 StpUtil.login(id) 方法利用了 Cookie 自动注入的特性，省略了你手写返回 Token 的代码。

如果你对 Cookie 功能还不太了解，也不用担心，我们会在之后的 [ 前后端分离 ] 章节中详细的阐述 Cookie 功能，现在你只需要了解最基本的两点：

• Cookie 可以从后端控制往浏览器中写入 Token 值。


• Cookie 会在前端每次发起请求时自动提交 Token 值。

因此，在 Cookie 功能的加持下，我们可以仅靠 StpUtil.login(id) 一句代码就完成登录认证。

除了登录方法，我们还需要：

// 当前会话注销登录

StpUtil.logout();



// 获取当前会话是否已经登录，返回true=已登录，false=未登录

StpUtil.isLogin();



// 检验当前会话是否已经登录, 如果未登录，则抛出异常：`NotLoginException`

StpUtil.checkLogin();

异常 NotLoginException 代表当前会话暂未登录，可能的原因有很多：
前端没有提交 Token、前端提交的 Token 是无效的、前端提交的 Token 已经过期 …… 等等。

Sa-Token 未登录场景值参照表：

那么，如何获取场景值呢？废话少说直接上代码：

// 全局异常拦截（拦截项目中的NotLoginException异常）

@ExceptionHandler(NotLoginException.class)

public SaResult handlerNotLoginException(NotLoginException nle)

		throws Exception {



	// 打印堆栈，以供调试

	nle.printStackTrace(); 

	

	// 判断场景值，定制化异常信息 

	String message = "";

	if(nle.getType().equals(NotLoginException.NOT_TOKEN)) {

		message = "未提供token";

	}

	else if(nle.getType().equals(NotLoginException.INVALID_TOKEN)) {

		message = "token无效";

	}

	else if(nle.getType().equals(NotLoginException.TOKEN_TIMEOUT)) {

		message = "token已过期";

	}

	else if(nle.getType().equals(NotLoginException.BE_REPLACED)) {

		message = "token已被顶下线";

	}

	else if(nle.getType().equals(NotLoginException.KICK_OUT)) {

		message = "token已被踢下线";

	}

	else {

		message = "当前会话未登录";

	}

	

	// 返回给前端

	return SaResult.error(message);

}

三、会话查询

// 获取当前会话账号id, 如果未登录，则抛出异常：`NotLoginException`

StpUtil.getLoginId();



// 类似查询API还有：

StpUtil.getLoginIdAsString();    // 获取当前会话账号id, 并转化为`String`类型

StpUtil.getLoginIdAsInt();       // 获取当前会话账号id, 并转化为`int`类型

StpUtil.getLoginIdAsLong();      // 获取当前会话账号id, 并转化为`long`类型



// ---------- 指定未登录情形下返回的默认值 ----------



// 获取当前会话账号id, 如果未登录，则返回null 

StpUtil.getLoginIdDefaultNull();



// 获取当前会话账号id, 如果未登录，则返回默认值 （`defaultValue`可以为任意类型）

StpUtil.getLoginId(T defaultValue);

四、Token 查询

// 获取当前会话的token值

StpUtil.getTokenValue();



// 获取当前`StpLogic`的token名称

StpUtil.getTokenName();



// 获取指定token对应的账号id，如果未登录，则返回 null

StpUtil.getLoginIdByToken(String tokenValue);



// 获取当前会话剩余有效期（单位：s，返回-1代表永久有效）

StpUtil.getTokenTimeout();



// 获取当前会话的token信息参数

StpUtil.getTokenInfo();

TokenInfo 是 Token 信息 Model，用来描述一个 Token 的常用参数：

{

	"tokenName": "satoken",           // token名称

	"tokenValue": "e67b99f1-3d7a-4a8d-bb2f-e888a0805633",      // token值

	"isLogin": true,                  // 此token是否已经登录

	"loginId": "10001",               // 此token对应的LoginId，未登录时为null

	"loginType": "login",              // 账号类型标识

	"tokenTimeout": 2591977,          // token剩余有效期 (单位: 秒)

	"sessionTimeout": 2591977,        // User-Session剩余有效时间 (单位: 秒)

	"tokenSessionTimeout": -2,        // Token-Session剩余有效时间 (单位: 秒) (-2表示系统中不存在这个缓存)

	"tokenActivityTimeout": -1,       // token剩余无操作有效时间 (单位: 秒)

	"loginDevice": "default-device"   // 登录设备类型 

}

五、来个小测试，加深一下理解

新建 LoginAuthController，复制以下代码

package com.pj.cases.use;



import org.springframework.web.bind.annotation.RequestMapping;

import org.springframework.web.bind.annotation.RestController;



import cn.dev33.satoken.stp.SaTokenInfo;

import cn.dev33.satoken.stp.StpUtil;

import cn.dev33.satoken.util.SaResult;



/**

 * Sa-Token 登录认证示例 

 * 

 * @author kong

 * @since 2022-10-13

 */

@RestController

@RequestMapping("/acc/")

public class LoginAuthController {



	// 会话登录接口  ---- http://localhost:8081/acc/doLogin?name=zhang&pwd=123456

	@RequestMapping("doLogin")

	public SaResult doLogin(String name, String pwd) {

		

		// 第一步：比对前端提交的 账号名称 & 密码 是否正确，比对成功后开始登录 

		// 		此处仅作模拟示例，真实项目需要从数据库中查询数据进行比对 

		if("zhang".equals(name) && "123456".equals(pwd)) {

			

			// 第二步：根据账号id，进行登录 

			// 		此处填入的参数应该保持用户表唯一，比如用户id，不可以直接填入整个 User 对象 

			StpUtil.login(10001);

			

			// SaResult 是 Sa-Token 中对返回结果的简单封装，下面的示例将不再赘述 

			return SaResult.ok("登录成功");

		}

		

		return SaResult.error("登录失败");

	}



	// 查询当前登录状态  ---- http://localhost:8081/acc/isLogin

	@RequestMapping("isLogin")

	public SaResult isLogin() {

		// StpUtil.isLogin() 查询当前客户端是否登录，返回 true 或 false 

		boolean isLogin = StpUtil.isLogin();

		return SaResult.ok("当前客户端是否登录：" + isLogin);

	}



	// 校验当前登录状态  ---- http://localhost:8081/acc/checkLogin

	@RequestMapping("checkLogin")

	public SaResult checkLogin() {

		// 检验当前会话是否已经登录, 如果未登录，则抛出异常：`NotLoginException`

		StpUtil.checkLogin();



		// 抛出异常后，代码将走入全局异常处理（GlobalException.java），如果没有抛出异常，则代表通过了登录校验，返回下面信息 

		return SaResult.ok("校验登录成功，这行字符串是只有登录后才会返回的信息");

	}



	// 获取当前登录的账号是谁  ---- http://localhost:8081/acc/getLoginId

	@RequestMapping("getLoginId")

	public SaResult getLoginId() {

		// 需要注意的是，StpUtil.getLoginId() 自带登录校验效果

		// 也就是说如果在未登录的情况下调用这句代码，框架就会抛出 `NotLoginException` 异常，效果和 StpUtil.checkLogin() 是一样的 

		Object userId = StpUtil.getLoginId();

		System.out.println("当前登录的账号id是：" + userId);

		

		// 如果不希望 StpUtil.getLoginId() 触发登录校验效果，可以填入一个默认值

		// 如果会话未登录，则返回这个默认值，如果会话已登录，将正常返回登录的账号id 

		Object userId2 = StpUtil.getLoginId(0);

		System.out.println("当前登录的账号id是：" + userId2);

		

		// 或者使其在未登录的时候返回 null 

		Object userId3 = StpUtil.getLoginIdDefaultNull();

		System.out.println("当前登录的账号id是：" + userId3);

		

		// 类型转换：

		// StpUtil.getLoginId() 返回的是 Object 类型，你可以使用以下方法指定其返回的类型 

		int userId4 = StpUtil.getLoginIdAsInt();  // 将返回值转换为 int 类型 

		long userId5 = StpUtil.getLoginIdAsLong();  // 将返回值转换为 long 类型 

		String userId6 = StpUtil.getLoginIdAsString();  // 将返回值转换为 String 类型 

		

		// 疑问：数据基本类型不是有八个吗，为什么只封装以上三种类型的转换？

		// 因为大多数项目都是拿 int、long 或 String 声明 UserId 的类型的，实在没见过哪个项目用 double、float、boolean 之类来声明 UserId 

		System.out.println("当前登录的账号id是：" + userId4 + " --- " + userId5 + " --- " + userId6);

		

		// 返回给前端 

		return SaResult.ok("当前客户端登录的账号id是：" + userId);

	}



	// 查询 Token 信息  ---- http://localhost:8081/acc/tokenInfo

	@RequestMapping("tokenInfo")

	public SaResult tokenInfo() {

		// TokenName 是 Token 名称的意思，此值也决定了前端提交 Token 时应该使用的参数名称 

		String tokenName = StpUtil.getTokenName();

		System.out.println("前端提交 Token 时应该使用的参数名称：" + tokenName);

		

		// 使用 StpUtil.getTokenValue() 获取前端提交的 Token 值 

		// 框架默认前端可以从以下三个途径中提交 Token：

		// 		Cookie 		（浏览器自动提交）

		// 		Header头	（代码手动提交）

		// 		Query 参数	（代码手动提交） 例如： /user/getInfo?satoken=xxxx-xxxx-xxxx-xxxx 

		// 读取顺序为： Query 参数 --> Header头 -- > Cookie 

		// 以上三个地方都读取不到 Token 信息的话，则视为前端没有提交 Token 

		String tokenValue = StpUtil.getTokenValue();

		System.out.println("前端提交的Token值为：" + tokenValue);

		

		// TokenInfo 包含了此 Token 的大多数信息 

		SaTokenInfo info = StpUtil.getTokenInfo();

		System.out.println("Token 名称：" + info.getTokenName());

		System.out.println("Token 值：" + info.getTokenValue());

		System.out.println("当前是否登录：" + info.getIsLogin());

		System.out.println("当前登录的账号id：" + info.getLoginId());

		System.out.println("当前登录账号的类型：" + info.getLoginType());

		System.out.println("当前登录客户端的设备类型：" + info.getLoginDevice());

		System.out.println("当前 Token 的剩余有效期：" + info.getTokenTimeout()); // 单位：秒，-1代表永久有效，-2代表值不存在

		System.out.println("当前 Token 的剩余临时有效期：" + info.getTokenActivityTimeout()); // 单位：秒，-1代表永久有效，-2代表值不存在

		System.out.println("当前 User-Session 的剩余有效期" + info.getSessionTimeout()); // 单位：秒，-1代表永久有效，-2代表值不存在

		System.out.println("当前 Token-Session 的剩余有效期" + info.getTokenSessionTimeout()); // 单位：秒，-1代表永久有效，-2代表值不存在

		

		// 返回给前端 

		return SaResult.data(StpUtil.getTokenInfo());

	}

	

	// 会话注销  ---- http://localhost:8081/acc/logout

	@RequestMapping("logout")

	public SaResult logout() {

		// 退出登录会清除三个地方的数据：

		// 		1、Redis中保存的 Token 信息

		// 		2、当前请求上下文中保存的 Token 信息 

		// 		3、Cookie 中保存的 Token 信息（如果未使用Cookie模式则不会清除）

		StpUtil.logout();

		

		// StpUtil.logout() 在未登录时也是可以调用成功的，

		// 也就是说，无论客户端有没有登录，执行完 StpUtil.logout() 后，都会处于未登录状态 

		System.out.println("当前是否处于登录状态：" + StpUtil.isLogin());

		

		// 返回给前端 

		return SaResult.ok("退出登录成功");

	}

	

}

代码注释已针对每一步操作做出详细解释，大家可根据可参照注释中的访问链接进行逐步测试。

本示例代码已上传至 Gitee，可参考：
Sa-Token 登录认证示例

参考资料

• Gitee 仓库地址：gitee.com/dromara/sa-…


• GitHub 仓库地址：github.com/dromara/sa-…


• Sa-Token 在线文档：sa-token.dev33.cn/

之前线上发生了一个很诡异的异常，网上各种搜索、排查，都没有找到问题，给大家分享一下。

大概在 2 月份的时候，我们的某个应用整合了中间件的 kafka 客户端，发布到灰度和蓝节点进行观察，然后就发现线上某个 Topic 发生了大量的RetriableCommitException，并且集中在灰度机器上。

E20:21:59.770 RuntimeException  org.apache.kafka.clients.consumer.RetriableCommitFailedException  ERROR [Consumer clientId=xx-xx.4-0， groupId=xx-xx-consumer_[gray]] Offset commit with offsets {xx-xx-xx-callback-1=OffsetAndMetadata{offset=181894918， leaderEpoch=4， metadata=''}， xx-xx-xx-callback-0=OffsetAndMetadata{offset=181909228， leaderEpoch=5， metadata=''}} failed org.apache.kafka.clients.consumer.RetriableCommitFailedException: Offset commit failed with a retriable exception. You should retry committing the latest consumed offsets.

Caused by: org.apache.kafka.common.errors.TimeoutException: Failed to send request after 30000 ms.

排查

检查了这个 Topic 的流量流入、流出情况，发现并不是很高，至少和 QA 环境的压测流量对比，连零头都没有达到。

但是从发生异常的这个 Topic 的历史流量来看的话，发生问题的那几个时间点的流量又确实比平时高出了很多。

同时我们检查 Broker 集群的负载情况，发现那几个时间点的 CPU 负载也比平时也高出很多（也只是比平时高，整体并不算高)。

对Broker集群的日志排查，也没发现什么特殊的地方。

然后我们对这个应用在QA上进行了模拟，尝试复现，遗憾的是，尽管我们在QA上把生产流量放大到很多倍并尝试了多次，问题还是没能出现。

此时，我们把问题归于当时的网络环境，这个结论在当时其实是站不住脚的，如果那个时刻网络环境发生了抖动的话，其它应用为什么没有这类异常？

可能其它的服务实例网络情况是好的，只是发生问题的这个灰实例网络发生了问题。

那问题又来了，为什么这个实例的其它 Topic 没有报出异常，偏偏问题只出现在这个 Topic 呢？。。。。。。。。。

至此，陷入了僵局，无从下手的感觉。

从这个客户端的开发、测试到压测，如果有 bug 的话，不可能躲过前面那么多环节，偏偏爆发在了生产环境。

没办法了，我们再次进行了一次灰度发布，如果过了一夜没有事情发生，我们就把问题划分到环境问题，如果再次出现问题的话，那就只能把问题划分到我们实现的 Kafka 客户端的问题了。

果不其然，发布后的第二天凌晨1点多，又出现了大量的 RetriableCommitFailedException，只是这次换了个 Topic，并且异常的原因又多出了其它Caused by 。

org.apache.kafka.clients.consumer.RetriableCommitFailedException: Offset commit failed with a retriable exception. You should retry committing the latest consumed offsets.

Caused by: org.apache.kafka.common.errors.DisconnectException

...

...

E16:23:31.640 RuntimeException  org.apache.kafka.clients.consumer.RetriableCommitFailedException  ERROR 

...

...

org.apache.kafka.clients.consumer.RetriableCommitFailedException: Offset commit failed with a retriable exception. You should retry committing the latest consumed offsets.

Caused by: org.apache.kafka.common.errors.TimeoutException: The request timed out.

分析

这次出现的异常与之前异常的不同之处在于：

1. 1. Topic 变了


2. 2. 异常Cause变了

而与之前异常又有相同之处：

1. 1. 只发生在灰度消费者组


2. 2. 都是RetriableCommitFailedException

RetriableCommitFailedException 意思很明确了，可以重试提交的异常，网上搜了一圈后仅发现StackOverFlow上有一问题描述和我们的现象相似度很高，遗憾的是没人回复这个问题：StackOverFlow。

我们看下 RetriableCommitFailedException 这个异常和产生这个异常的调用层级关系。

除了产生异常的具体 Cause 不同，剩下的都是让我们再 retry，You should retry Commiting the lastest consumed offsets。

从调用层级上来看，我们可以得到几个关键的信息，commit 、 async。

再结合异常发生的实例，我们可以得到有用关键信息： 灰度、commit 、async。

在灰度消息的实现上，我们确实存在着管理位移和手动提交的实现。

看代码的第 62 行，如果当前批次消息经过 filter 的过滤后一条消息都不符合当前实例消费，那么我们就把当前批次进行手动异步提交位移。结合我们在生产的实际情况，在灰度实例上我们确实会把所有的消息都过滤掉，并异步提交位移。

为什么我们封装的客户端提交就会报大量的报错，而使用 spring-kafka 的没有呢？

我们看下Spring对提交位移这块的核心实现逻辑。

可以同步，也可以异步提交，具体那种提交方式就要看 this.containerProperties.isSyncCommits() 这个属性的配置了，然而我们一般也不会去配置这个东西，大部分都是在使用默认配置。

人家默认使用的是同步提交方式，而我们使用的是异步方式。

同步提交和异步提交有什么区别么？

先看下同步提交的实现：

只要遇到了不是不可恢复的异常外，在 timer 参数过期时间范围内重试到成功（这个方法的描述感觉不是很严谨的样子）。

我们在看下异步提交方式的核心实现：

我们不要被第 645 行的 RequestFuture future = sendOffsetCommitRequest(offsets) 所迷惑，它其实并不是发送位移提交的请求，它内部只是把当前请求包装好，放到 private final UnsentRequests unsent = new UnsentRequests(); 这个属性中，同时唤醒真正的发送线程来发送的。

这里不是重点，重点是如果我们的异步提交发生了异常，它只是简单的使用 RetriableCommitFailedException 给我们包装了一层。

重试呢？为什么异步发送产生了可重试异常它不给我们自动重试？

如果我们对多个异步提交进行重试的话，很大可能会导致位移覆盖，从而引发重复消费的问题。

正好，我们遇到的所有异常都是 RetriableCommitException 类型的，也就是说，我们把灰度位移提交的方式修改成同步可重试的提交方式，就可以解决我们遇到的问题了。

1：项目背景

一个项目往往会有小程序，APP，PC等多端访问，比如淘宝，京东等。这时候就会有一些踢人下线的需求，比如你在一台电脑登录了PC端，这时候你再另外一台电脑也登录PC端，这时候之前在另外一台电脑上就会被强制下线。

或者你登录了PC端，这时候你登陆了APP或者小程序，这时候PC端的账号也会被强制下线

2：项目只有PC端

假设我们现在的项目只有PC端，没有小程序或者APP，那么这时候就是很简单了，用户的sessin(也就是所谓的Token)一般都是存储在redis中，session中包括用户ID等一些信息，当然还有一个最重要的就是登录的ip地址。

1：用户在登录的时候，从redis中获取用户session，如果没有就可以直接登录了

2：用户在另外一台电脑登录，从redis中获取到用户session，这时候用户session是有的，说明用户之前已经登录过了

3：这时候从用户session中获取IP，判断二者的ip是不是相同，如果不同，这时候就要发送一个通知给客户端，让另外一台设备登录的账号强制下线即可

3：项目有PC端和APP端和小程序端

当你的应用有PC端和APP端的时候，我们用户的session如果还是只存一个ip地址，那明显就是不够的，因为很多情况下，我们PC端和APP端是可以同时登录的，比如淘宝，京东等都是，也就是所谓的双端登录

这时候就会有多种情况

单端登录：PC端，APP端，小程序只能有一端登录

双端登录：允许其中二个端登录

三端登录：三个端都可以同时登录

对于三端可以同时登录就很简单，但是现在有个限制，就是app端只能登录一次，不能同时登录，也就是我一个手机登录了APP，另外一个手机登录的话，之前登录的APP端就要强制下线

所以我们的用户session存储的格式如下

{

   userId：用户的id

   clientType：PC端，小程序端，APP端

   imei：就是设备的唯一编号(对于PC端这个值就是ip地址，其余的就是手机设备的一个唯一编号)

}

单端登录

首先我们要知道，用户登录不同的设备那么用户session是不一样的。对于单端登录，那么我们可以拿到用户的所有的session，然后根据clientType和imei号来强制将其它端的用户session删除掉，然后通知客户端强制下线

双端登录

同样拿到所有用户的session，然后根据自己的业务需求来判定哪一端需要强制下线，比如我们现在已经登录了PC端和APP端，这时候登录小程序，现在要让APP端的强制下线。

这时候登录之后获取用户所有的session，这时候会有二个用户session，首先拿到clientType = APP的session，然后来通知客户端这个端需要强制下线。

如果这时候我登录了PC端和一个APP端，这时候我用另外一台手机登录APP端，那么之前那台手机上登录的APP端就要被强制下线，这个时候仅通过clientType是不行的，因为我二个手机登录的clientType都是APP端。所以这时候就要根据imei号来判断了。因为不同的手机imei号是不一样的。

这时候我拿到用户所有的session

  PC端的session

  sessionA{

      userId: 1,

      clientType: PC,

      imei: "123"

  }

  

  APP端的session

  sessionA{

      userId: 1,

      clientType: APP,

      imei: "12345"

  }

这时候我从另外一台手机登录的时候，生成的session应该是这样的

 APP端的session

  sessionA{

      userId: 1,

      clientType: APP,

      imei: "1234567"

  }

我发现同一个clientType的session已经有了，这时候我要判断imei号是否一样，imei一样说明是同一台设备，不同说明不是同一台设备，我们只需要把对应设备的账号强制下线即可了

总结

不管是单端登录，双端登录还是多端登录，我们都是根据用户session来判断。只要根据clientType和imei号来就可以满足我们大部分的踢人下线需求了。

1.前言

大家好，我是王老狮，近期OpenAI开放了chatGPT的最新gpt-3.5-turbo模型，据介绍该模型是和当前官网使用的相同的模型，如果你还没体验过ChatGPT，那么今天就教大家如何打破网络壁垒，打造一个属于自己的智能助手把。本文包括API Key的申请以及网络代理的搭建,那么事不宜迟，我们现在开始。

2.对接流程

2.1.API-Key的获取

首先第一步要获取OpenAI接口的API Key，该Key是你用来调用接口的token，主要用于接口鉴权。获取该key首先要注册OpenAi的账号，具体可以见我的另外一篇文章，ChatGPT保姆级注册教程。

1. 打开platform.openai.com/网站，点击view API Key，

2. 点击创建key

3. 弹窗显示生成的key，记得把key复制，不然等会就找不到这个key了，只能重新创建。

将API Key保存好以备用

2.2.API用量的查看

这里可以查看API的使用情况，新账号注册默认有5美元的试用额度，之前都是18美元，API成本降了之后试用额度也狠狠地砍了一刀啊，哈哈。

2.3.核心代码实现

2.3.1.pom依赖

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

    <modelVersion>4.0.0modelVersion>

    <groupId>com.webtapgroupId>

    <artifactId>webtapartifactId>

    <version>0.0.1version>

    <packaging>jarpackaging>



    <parent>

        <groupId>org.springframework.bootgroupId>

        <artifactId>spring-boot-starter-parentartifactId>

        <version>2.1.2.RELEASEversion>

    parent>



    <dependencies>

        <dependency>

            <groupId>org.springframework.bootgroupId>

            <artifactId>spring-boot-starter-webartifactId>

        dependency>

        <dependency>

            <groupId>org.springframework.bootgroupId>

            <artifactId>spring-boot-starter-thymeleafartifactId>

        dependency>

        <dependency>

            <groupId>nz.net.ultraq.thymeleafgroupId>

            <artifactId>thymeleaf-layout-dialectartifactId>

        dependency>

        <dependency>

            <groupId>org.springframework.bootgroupId>

            <artifactId>spring-boot-starter-data-jpaartifactId>

        dependency>

        <dependency>

            <groupId>org.springframework.bootgroupId>

            <artifactId>spring-boot-devtoolsartifactId>

        dependency>

        <dependency>

            <groupId>org.springframework.bootgroupId>

            <artifactId>spring-boot-starter-testartifactId>

        dependency>

        <dependency>

            <groupId>org.springframework.bootgroupId>

            <artifactId>spring-boot-starter-mailartifactId>

        dependency>



        <dependency>

            <groupId>mysqlgroupId>

            <artifactId>mysql-connector-javaartifactId>

        dependency>

        <dependency>

            <groupId>org.apache.commonsgroupId>

            <artifactId>commons-lang3artifactId>

            <version>3.4version>

        dependency>

        <dependency>

            <groupId>commons-codecgroupId>

            <artifactId>commons-codecartifactId>

        dependency>

        <dependency>

            <groupId>org.jsoupgroupId>

            <artifactId>jsoupartifactId>

            <version>1.9.2version>

        dependency>

        

        <dependency>

            <groupId>com.alibabagroupId>

            <artifactId>fastjsonartifactId>

            <version>1.2.56version>

        dependency>

        <dependency>

            <groupId>net.sourceforge.nekohtmlgroupId>

            <artifactId>nekohtmlartifactId>

            <version>1.9.22version>

        dependency>

        <dependency>

            <groupId>com.github.pagehelpergroupId>

            <artifactId>pagehelper-spring-boot-starterartifactId>

            <version>1.4.1version>

        dependency>

        <dependency>

            <groupId>org.projectlombokgroupId>

            <artifactId>lombokartifactId>

        dependency>

        <dependency>

            <groupId>org.apache.httpcomponentsgroupId>

            <artifactId>httpasyncclientartifactId>

            <version>4.0.2version>

        dependency>

        <dependency>

            <groupId>org.apache.httpcomponentsgroupId>

            <artifactId>httpcore-nioartifactId>

            <version>4.3.2version>

        dependency>



        <dependency>

            <groupId>org.apache.httpcomponentsgroupId>

            <artifactId>httpclientartifactId>

            <version>4.3.5version>

            <exclusions>

                <exclusion>

                    <artifactId>commons-codecartifactId>

                    <groupId>commons-codecgroupId>

                exclusion>

            exclusions>

        dependency>

        <dependency>

            <groupId>commons-httpclientgroupId>

            <artifactId>commons-httpclientartifactId>

            <version>3.1version>

            <exclusions>

                <exclusion>

                    <artifactId>commons-codecartifactId>

                    <groupId>commons-codecgroupId>

                exclusion>

            exclusions>

        dependency>

        <dependency>

            <groupId>org.mybatis.spring.bootgroupId>

            <artifactId>mybatis-spring-boot-starterartifactId>

            <version>1.3.1version>

        dependency>

        <dependency>

            <groupId>com.github.ulisesbocchiogroupId>

            <artifactId>jasypt-spring-boot-starterartifactId>

            <version>2.0.0version>

        dependency>



    dependencies>



    <build>

        <plugins>

            <plugin>

                <groupId>org.springframework.bootgroupId>

                <artifactId>spring-boot-maven-pluginartifactId>

            plugin>

        plugins>

    build>



project>

2.3.2.实体类ChatMessage.java

用于存放发送的消息信息，注解使用了lombok，如果没有使用lombok可以自动生成构造方法以及get和set方法

@Data

@NoArgsConstructor

@AllArgsConstructor

public class ChatMessage {

    //消息角色

    String role;

    //消息内容

    String content;

}

2.3.3.实体类ChatCompletionRequest.java

用于发送的请求的参数实体类，参数释义如下：

model：选择使用的模型，如gpt-3.5-turbo

messages ：发送的消息列表

temperature ：温度，参数从0-2，越低表示越精准，越高表示越广发，回答的内容重复率越低

n :回复条数，一次对话回复的条数

stream :是否流式处理，就像ChatGPT一样的处理方式，会增量的发送信息。

max_tokens ：生成的答案允许的最大token数

user ：对话用户

@Data

@Builder

public class ChatCompletionRequest {



    String model;



    List<ChatMessage> messages;



    Double temperature;



    Integer n;



    Boolean stream;



    List<String> stop;



    Integer max_tokens;



    String user;

}

2.3.4.实体类ExecuteRet .java

用于接收请求返回的信息以及执行结果

/**

 * 调用返回

 */

public class ExecuteRet {



    /**

     * 操作是否成功

     */

    private final boolean success;



    /**

     * 返回的内容

     */

    private final String respStr;



    /**

     * 请求的地址

     */

    private final HttpMethod method;



    /**

     * statusCode

     */

    private final int statusCode;



    public ExecuteRet(booleansuccess, StringrespStr, HttpMethodmethod, intstatusCode) {

        this.success =success;

        this.respStr =respStr;

        this.method =method;

        this.statusCode =statusCode;

    }



    @Override

    public String toString() {

        return String.format("[success:%s,respStr:%s,statusCode:%s]", success, respStr, statusCode);

    }



    /**

     *@returnthe isSuccess

     */

    public boolean isSuccess() {

        return success;

    }



    /**

     *@returnthe !isSuccess

     */

    public boolean isNotSuccess() {

        return !success;

    }



    /**

     *@returnthe respStr

     */

    public String getRespStr() {

        return respStr;

    }



    /**

     *@returnthe statusCode

     */

    public int getStatusCode() {

        return statusCode;

    }



    /**

     *@returnthe method

     */

    public HttpMethod getMethod() {

        return method;

    }

}

2.3.5.实体类ChatCompletionChoice .java

用于接收ChatGPT返回的数据

@Data

public class ChatCompletionChoice {



    Integer index;



    ChatMessage message;



    String finishReason;

}

2.3.6.接口调用核心类OpenAiApi .java

使用httpclient用于进行api接口的调用，支持post和get方法请求。

url为配置文件open.ai.url的值，表示调用api的地址：https://api.openai.com/ ，token为获取的api-key。
执行post或者get方法时增加头部信息headers.put("Authorization", "Bearer " + token); 用于通过接口鉴权。

@Slf4j

@Component

public class OpenAiApi {



    @Value("${open.ai.url}")

    private String url;

    @Value("${open.ai.token}")

    private String token;



    private static final MultiThreadedHttpConnectionManagerCONNECTION_MANAGER= new MultiThreadedHttpConnectionManager();



    static {

        // 默认单个host最大链接数

CONNECTION_MANAGER.getParams().setDefaultMaxConnectionsPerHost(

                Integer.valueOf(20));

        // 最大总连接数，默认20

CONNECTION_MANAGER.getParams()

                .setMaxTotalConnections(20);

        // 连接超时时间

CONNECTION_MANAGER.getParams()

                .setConnectionTimeout(60000);

        // 读取超时时间

CONNECTION_MANAGER.getParams().setSoTimeout(60000);

    }



    public ExecuteRet get(Stringpath, Map headers) {

        GetMethod method = new GetMethod(url +path);

        if (headers== null) {

            headers = new HashMap<>();

        }

        headers.put("Authorization", "Bearer " + token);

        for (Map.Entry h : headers.entrySet()) {

            method.setRequestHeader(h.getKey(), h.getValue());

        }

        return execute(method);

    }



    public ExecuteRet post(Stringpath, Stringjson, Map headers) {

        try {

            PostMethod method = new PostMethod(url +path);

            //log.info("POST Url is {} ", url + path);

            // 输出传入参数

log.info(String.format("POST JSON HttpMethod's Params = %s",json));

            StringRequestEntity entity = new StringRequestEntity(json, "application/json", "UTF-8");

            method.setRequestEntity(entity);

            if (headers== null) {

                headers = new HashMap<>();

            }

            headers.put("Authorization", "Bearer " + token);

            for (Map.Entry h : headers.entrySet()) {

                method.setRequestHeader(h.getKey(), h.getValue());

            }

            return execute(method);

        } catch (UnsupportedEncodingExceptionex) {

log.error(ex.getMessage(),ex);

        }

        return new ExecuteRet(false, "", null, -1);

    }



    public ExecuteRet execute(HttpMethodmethod) {

        HttpClient client = new HttpClient(CONNECTION_MANAGER);

        int statusCode = -1;

        String respStr = null;

        boolean isSuccess = false;

        try {

            client.getParams().setParameter(HttpMethodParams.HTTP_CONTENT_CHARSET, "UTF8");

            statusCode = client.executeMethod(method);

method.getRequestHeaders();



            // log.info("执行结果statusCode = " + statusCode);

            InputStreamReader inputStreamReader = new InputStreamReader(method.getResponseBodyAsStream(), "UTF-8");

            BufferedReader reader = new BufferedReader(inputStreamReader);

            StringBuilder stringBuffer = new StringBuilder(100);

            String str;

            while ((str = reader.readLine()) != null) {

log.debug("逐行读取String = " + str);

                stringBuffer.append(str.trim());

            }

            respStr = stringBuffer.toString();

            if (respStr != null) {

             log.info(String.format("执行结果String = %s, Length = %d", respStr, respStr.length()));

                          } 

            inputStreamReader.close();

            reader.close();

            // 返回200，接口调用成功

            isSuccess = (statusCode == HttpStatus.SC_OK);

        } catch (IOExceptionex) {

        } finally {

method.releaseConnection();

        }

        return new ExecuteRet(isSuccess, respStr,method, statusCode);

    }



}

2.3.7.定义接口常量类PathConstant.class

用于维护支持的api接口列表

public class PathConstant {

    public static class MODEL {

				//获取模型列表

        public static String MODEL_LIST = "/v1/models";

    }



    public static class COMPLETIONS {

        public static String CREATE_COMPLETION = "/v1/completions";

				//创建对话

        public static String CREATE_CHAT_COMPLETION = "/v1/chat/completions";

      

    }

}

2.3.8.接口调用调试单元测试类OpenAiApplicationTests.class

核心代码都已经准备完毕，接下来写个单元测试测试下接口调用情况。

@SpringBootTest

@RunWith(SpringRunner.class)

public class OpenAiApplicationTests {



    @Autowired

    private OpenAiApi openAiApi;

    @Test

    public void createChatCompletion2() {

        Scanner in = new Scanner(System.in);

        String input = in.next();

        ChatMessage systemMessage = new ChatMessage('user', input);

        messages.add(systemMessage);

        ChatCompletionRequest chatCompletionRequest = ChatCompletionRequest.builder()

                .model("gpt-3.5-turbo-0301")

                .messages(messages)

                .user("testing")

                .max_tokens(500)

                .temperature(1.0)

                .build();

        ExecuteRet executeRet = openAiApi.post(PathConstant.COMPLETIONS.CREATE_CHAT_COMPLETION, JSONObject.toJSONString(chatCompletionRequest),

                null);

        JSONObject result = JSONObject.parseObject(executeRet.getRespStr());

        List choices = result.getJSONArray("choices").toJavaList(ChatCompletionChoice.class);

        System.out.println(choices.get(0).getMessage().getContent());

        ChatMessage context = new ChatMessage(choices.get(0).getMessage().getRole(), choices.get(0).getMessage().getContent());

        System.out.println(context.getContent());

    }



}

• 使用Scanner 用于控制台输入信息，如果单元测试时控制台不能输入，那么进入IDEA的安装目录，修改以下文件。增加最后一行增加-Deditable.java.test.console=true即可。

• 
  

  创建ChatMessage对象，用于存放参数,role有user,system,assistant,一般接口返回的响应为assistant角色，我们一般使用user就好。

  
  


• 
  

  定义请求参数ChatCompletionRequest，这里我们使用3.1日发布的最新模型gpt-3.5-turbo-0301。具体都有哪些模型大家可以调用v1/model接口查看支持的模型。

  
  


• 
  

  之后调用openAiApi.post进行接口的请求，并将请求结果转为JSON对象。取其中的choices字段转为ChatCompletionChoice对象，该对象是存放api返回的具体信息。

  
  

  接口返回信息格式如下：

  
  

  {
  
      "id": "chatcmpl-6rNPw1hqm5xMVMsyf6PXClRHtNQAI",
  
      "object": "chat.completion",
  
      "created": 1678179420,
  
      "model": "gpt-3.5-turbo-0301",
  
      "usage": {
  
          "prompt_tokens": 16,
  
          "completion_tokens": 339,
  
          "total_tokens": 355
  
      },
  
      "choices": [{
  
          "message": {
  
              "role": "assistant",
  
              "content": "\n\nI. 介绍数字孪生的概念和背景\n    A. 数字孪生的定义和意义\n    B. 数字孪生的发展历程\n    C. 数字孪生在现代工业的应用\n\nII. 数字孪生的构建方法\n    A. 数字孪生的数据采集和处理\n    B. 数字孪生的建模和仿真\n    C. 数字孪生的验证和测试\n\nIII. 数字孪生的应用领域和案例分析\n    A. 制造业领域中的数字孪生应用\n    B. 建筑和城市领域中的数字孪生应用\n    C. 医疗和健康领域中的数字孪生应用\n\nIV. 数字孪生的挑战和发展趋势\n    A. 数字孪生的技术挑战\n    B. 数字孪生的实践难点\n    C. 数字孪生的未来发展趋势\n\nV. 结论和展望\n    A. 总结数字孪生的意义和价值\n    B. 展望数字孪生的未来发展趋势和研究方向"
  
          },
  
          "finish_reason": "stop",
  
          "index": 0
  
      }]
  
  }
  
  

  
  


• 
  

  输出对应的信息。

  
  

2.3.9.结果演示

2.4.连续对话实现

2.4.1连续对话的功能实现

基本接口调通之后，发现一次会话之后，没有返回完，输入继续又重新发起了新的会话。那么那么我们该如何实现联系上下文呢？其实只要做一些简单地改动，将每次对话的信息都保存到一个消息列表中，这样问答就支持上下文了，代码如下：

List messages = new ArrayList<>();

@Test

public void createChatCompletion() {

    Scanner in = new Scanner(System.in);

    String input = in.next();

    while (!"exit".equals(input)) {

        ChatMessage systemMessage = new ChatMessage(ChatMessageRole.USER.value(), input);

        messages.add(systemMessage);

        ChatCompletionRequest chatCompletionRequest = ChatCompletionRequest.builder()

                .model("gpt-3.5-turbo-0301")

                .messages(messages)

                .user("testing")

                .max_tokens(500)

                .temperature(1.0)

                .build();

        ExecuteRet executeRet = openAiApi.post(PathConstant.COMPLETIONS.CREATE_CHAT_COMPLETION, JSONObject.toJSONString(chatCompletionRequest),

                null);

        JSONObject result = JSONObject.parseObject(executeRet.getRespStr());

        List choices = result.getJSONArray("choices").toJavaList(ChatCompletionChoice.class);

        System.out.println(choices.get(0).getMessage().getContent());

        ChatMessage context = new ChatMessage(choices.get(0).getMessage().getRole(), choices.get(0).getMessage().getContent());

        messages.add(context);

        in = new Scanner(System.in);

        input = in.next();

    }

}

因为OpenAi的/v1/chat/completions接口消息参数是个list，这个是用来保存我们的上下文的，因此我们只要将每次对话的内容用list进行保存即可。

2.4.2结果如下：

4.常见问题

4.1.OpenAi接口调用不通

因为https://api.openai.com/地址也被限制了，但是接口没有对地区做校验，因此可以自己搭建一个香港代理，也可以走科学上网。

我采用的是香港代理的模式，一劳永逸，具体代理配置流程如下：

1. 购买一台香港的虚拟机，反正以后都会用得到，作为开发者建议搞一个。搞活动的时候新人很便宜，基本3年的才200块钱。


2. 访问nginx.org/download/ng… 下载最新版nginx


3. 部署nginx并修改/nginx/config/nginx.conf文件，配置接口代理路径如下

server {

        listen       19999;

        server_name  ai;



         ssl_certificate      /usr/local/nginx/ssl/server.crt;

        ssl_certificate_key  /usr/local/nginx/ssl/server.key;



        ssl_session_cache    shared:SSL:1m;

        ssl_session_timeout  5m;



        ssl_ciphers  HIGH:!aNULL:!MD5;

        ssl_prefer_server_ciphers  on;



        #charset koi8-r;



        location /v1/ {

                proxy_pass ;

        }

    }

4. 启动nginx


5. 将接口访问地址改为nginx的机器出口IP+端口即可

如果代理配置大家还不了解，可以留下评论我单独出一期教程。

4.2.接口返回401

检查请求方法是否增加token字段以及key是否正确

5.总结

至此JAVA对OpenAI对接就已经完成了，并且也支持连续对话，大家可以在此基础上不断地完善和桥接到web服务，定制自己的ChatGPT助手了。我自己也搭建了个平台，不断地在完善中，具体可见下图，后续会开源出来，想要体验的可以私信我获取地址和账号哈

数据库是公司重要资产，在此类重要资产平台上，尤其是重要操作，应该保持敬畏心。

数据库被删了？可怎么证明是某某某删了数据库？或者根本都不知道谁删除了数据库，又没抓现行，该怎么办？

正文

第一步 证据先行，有录屏有真相

删库动作的录制回放

录制回放让团队能清楚了解和学习用户路径和行为，其中对于关键页面诸如删除等高价值的动作，可以开启录制回放功能，比如下图，就是某一用户某一行为的屏幕录制情况。

删库成功的页面截图

针对录制回放的内容，可以看到用户点击删除按钮这一高风险行为。

第二步 录屏背后是详细的用户访问数据

在rum中查看用户会话

在用户使用产品的那一刻，用户体验就开始了。用户体验数据洞见很多，加购物车、下单、视频播放等高价值按钮背后的性能等相关数据和业务息息相关：比如下图展示了成功删除数据库的提示弹窗。

发现用户登录并浏览数据库平台的详细信息

每一次用户会话中，记录着用户的来源、访问时长，以及用户行为，这里面就包含对页面的加载（切换）和按钮点击。下图便是一个用户登录数据库管理平台后，0-20分钟以内的用户旅程：

发现用户点击删除库的按钮的详细信息

链接或者按钮背后隐藏着逻辑和用户动机，充分利用能转化良好化学反应。反之，在用户旅程中，也能看到用户点击删除数据库的按钮的行为，如下图所示：

点击按钮成功触发删除数据库的接口请求

为了明白请求或行为在系统中的'前世今生'，链路追踪已经成了必备，在下图中，用户行为触发的请求的完整上下文就被“追踪”到了：

后台处理接口请求

在产品使用流畅度中，丝滑不一定是卖点，但“慢”肯定是用户卡点，通过全链路链路追踪综合分析，可以得到请求耗时占比，进一步定位卡在哪里（前端、后端、网络），详情见下图：

第三步 成功删库的链路详情

前后端加上数据库形成可视化闭环，构成的业务链路，能够高效定位业务情况，下图能完整看出一次删库的效率：

第四步 自动关联删库日志

让全链路追踪能锦上添花的要数自动关联日志的功能了，下图能清晰看到链路所产生的日志：

以上我们便通过用户删库的录屏，用户行为、链路信息、操作日志等，还原了删库现场。当然，其中涉及了很多技术内容，下面整理了其中一些常见问题

相关技术点的FAQ ：

1. 如何针对关键步骤开启录制回放功能

以 删除按钮 为例 ，用户点击删除按钮后 可以开启 录制回放功能

  function deleteDB(){

        showConfirm(deleteDB).then((yes,no)=>{

            if(yes)=>[             datafluxRum.startSessionReplayRecording();]

        })

       

    }

2. 录制回放是否涉及密码等用户私密信息

出于数据安全考虑，任何情况下，以下元素都会被屏蔽：

• password、email 和 tel 类型的输入


• 具有 autocomplete 属性的元素，例如信用卡号、到期日期和安全代码

3 . 如何将 用户行为与 后端 进行关联

前后端关联通过http请求头的traceID进行关联，开启rum和apm简单设置即可实现关联。
在rum中仅仅需要在启动时注明后端地址。以本文的后台管理系统为例，需要在启动rum时开启allowTracingOrigin这个字段，配置见下图

可以参照如下代码

 window.DATAFLUX_RUM &&

    window.DATAFLUX_RUM.init({

        applicationId: "node_mongo_admin_express",

        datakitOrigin: "http://mongodb_admin:9529", // 协议（包括：//），域名（或IP地址）[和端口号]

        env: "production",

        service:"node_mongo_admin_express",

        version: "1.0.0",

        trackInteractions: true,

        allowedTracingOrigins: ["http://mongodb_admin:1234"], // 非必填，允许注入trace采集器所需header头部的所有请求列表。可以是请求的origin，也可以是是正则

        sessionSampleRate: 100,

        sessionReplaySampleRate: 100,

        defaultPrivacyLevel:  'allow',      

      });

      window.DATAFLUX_RUM && window.DATAFLUX_RUM.startSessionReplayRecording()

4. 如何自动将采集的日志和链路信息进行关联

需要将traceID注入日志，进行切分，就可以实现链路和日志的关联。本文仅用一行进行了关联，代码见下图。

5. 如何从后端下钻到数据库

仅需要接入追踪工具即可实现下图全链路追踪,本文后端使用node的express框架，链路追踪展示图如下：

其中服务调用拓扑关系如下，也就是web端访问后端（node技术栈）的，后端调用数据库（mongo）

6. 后端支持java吗？

支持java、python、go以及.net等，接入的学习成本是有的，整体对于开发而言，接入配置问题不大。

7. 前端的技术架构或技术栈有兼容性吗？

目前不论是mpa还是spa，不论是ssr、还是csr，亦或是vue、react、jQuery等，都支持，但针对不同架构，需要选择接入的场景。

8. 还支持哪些场景？

支持的场景很多，比如：

• 线上告警的故障定位


• 开发、测试环境的bug调试


• 用户行为的追踪与回放


• 性能瓶颈的查找与性能提升

9.有关请求耗时占比，能更详细的举个例子吗？

我们以后端为例，看到db_create这个接口：

这些数据是如何统计得出的呢？感兴趣的同学可以查看下图：

其中每个部分的计算原理如下：

Queueing（队列）耗时 = Duration - First Byte - Download  

First Byte（首包）耗时 = responseStart - domainLookupStart  

Download（下载）耗时 =  responseEnd - responseStart

更深入的技术内容，我将在今后的文章继续为大家整理。

综上所述

可观测性切入点很多，聪明的团队会观测；可观测性是研发质量的试金石，是企业城墙的基石，用好可观测性，能更多的了解系统，扩宽业务。

本文由观测云高级产品技术专家刘刚和交付工程师 苏桐桐共同撰写，其中所有截图及数据，均来自模拟数据，此外也欢迎一起探讨技术和业务。

参考词汇

• adminMongo：mongo数据库管理平台


• rum: 真实用户体验


• apm: 应用性能管理


• metrics:指标


• logs：日志


• trace：链路

1. 前言

微信小程序开发平台，提供有一类 API，可以让开发者获取到微信登录用户的个人数据。这类 API 统称为开放接口。

Tip：微信小程序开发平台，会把微信登录用户的个人信息分为明文数据和敏感数据。

明文数据也称为公开数据，开发者可以直接获取到，如登录者的昵称、头像……

敏感数据如电话号码、唯一标识符……等数据，只有高级认证开发者和经过登录者授权后才能解密获取到。

这一类 API较多，且 API之间功能有重叠之处，相互之间的区别较微小。有的适用于低版本，有的适用于高版本。

为了避免在使用时出现选择混乱，本文将通过具体应用案例介绍几个常用 API的使用。

2. 开放接口

开放接口是对一类 API的统称，开发者可以通过调用这类接口得到微信登录用户的授权或获取登录者的个人数据。
开放接口又分成几个子类 API ：

• 登录接口： 包括 wx.pluginLogin(Object args)、wx.login(Object object)、wx.checkSession(Object object) 几 个 API。


• 账号信息： 包括Object wx.getAccountInfoSync()此接口用来获取开发者的账号信息。


• 用户信息： 包括 wx.getUserProfile(Object object)、wx.getUserInfo(Object object)、UserInfo。使用频率非常高的接口，常用于小程序中获取登录者个人公开数据。


• 授权接口：wx.authorizeForMiniProgram(Object object)、wx.authorize(Object object)

除上述列出的子类接口，还有收货地址、生物认证……等诸多子类 API，有兴趣者可以自行了解。

2.1 登录接口

登录接口中有 3 个 API，对于开发者来说，使用频率较高的是 login接口，此环节将重点介绍此接口。

非本文特别关注的接口，会简略带过。

wx.pluginLogin(Object args)：此接口只能在插件中可以调用，调用此接口获得插件用户的标志凭证code，插件可使用此凭证换取用于识别用户的唯一标识 OpenpId。

用户不同、宿主小程序不同或插件不同的情况下，该标识均不相同，即当且仅当同一个用户在同一个宿主小程序中使用同一个插件时，OpenpId 才会相同。

对于一般开发者，此 接口用的不是很多，具体使用细节在此处也不做过多复述。

什么是 OpenId?

当微信用户登录公众号或小程序时，微信平台为每一个微信登录者分配的一个唯一标识符号。

2.1.1 wx.login(Object object)

功能描述：

• 
  

  开发者使用此接口可以获取到微信登录者的登录凭证（code）。

  
  

  
  

  登录凭证具有临时性，也就是每次调用时都会不一样，所以code 只能使用一次。

  
  

  
  


• 
  

  开发者可以通过临时code，再向微信接口服务器索取登录者的唯一标识符 OpenId、微信开发平台账号的唯一标识 UnionID(需要当前小程序已绑定到微信开放平台帐号）、以及会话密钥 session_key。

  
  

那么，获取到的openId和session_key对于开发者而言，有什么实质性的意义？

• 
  

  根据 OpenId的唯一性特点，可以在微信用户第一次登录时，把OpenID保存在数据库或缓存中，在后续登录时，只需要检查用户的 OpenId是否存在于数据库或缓存中，便能实现自动登录功能。

  
  


• 
  

  session_key 也称会话密钥，用来解密微信登录者的敏感数据。

  
  

  
  

  后文将详细介绍。

  
  

  
  

如何获取OpenId？

现通过一个简单案例，实现微信小程序端与开发者服务器之间的数据交互。以此了解开发者服务器如何通过微信小程序传递过来的用户临时 code换取到登录者的更多信息。

实现之前，先通过一个简易演示图了解其过程。

简单描述整个请求过程：

• 微信用户打开微信小程序后，开发者在微信小程序中通过调用wx.login接口获取到临时登录凭证 code。


• 在微信小程序中调用 wx.request 接口向开发者服务器发送 http 请求，需要把登录凭证 code一并发送过去。


• 开发者服务器使用发送过来的 code 以及开发者凭证信息向微信接口服务器索取微信登录者的 openId和session_key。

简而言之，就是 3 者(微信小程序、开发者服务器、微信接口服务器)之间的一个击鼓传花游戏。

开发流程：

第一步：项目结构分析

完整的系统由 2 个部分组成：

• 
  

  微信小程序端 APP。

  
  

  
  

  如对微信小程序开发不是很了解，请先阅读官方提供的相关文档。

  
  

  
  


• 
  

  服务器端应用程序。

  
  

  
  

  本文的服务器端应用程序基于 Spring Boot开发平台。

  
  

  
  

本项目结构是标准的前后端分离模式，微信小程序是前端应用，服务器端应用程序为后台应用。

第二步：新建微信小程序(前端应用)

打开微信开发工具，新建一个名为 guokeai 的小程序项目 ，项目会初始化一个index 页面。在 index.js中编写如下代码。

//index.js

const app = getApp()

const httpRequest = require("../../utils/request.js")



Page({

  data: {

    isHasUserInfo: null,

    userInfo: null

  },

  //启动时

  onLoad: function () {

    let this_ = this

    /***

     * 检查微信用户是否已经登录到后台服务器

     * 已经登录的标志，数据库中存在 OPENID

     */

    let code = null

    //调用 login 接口

    wx.login({

      success: (res) => {

        //得到登录用户的临时 code

        code = res.code

        //向开发者服务器发送请求

        let api = "wx/getLoginCertificate"

        let config = {

          url: api,

          method: "GET",

          data: {

            code: code

          }

        }

        let promise = httpRequest.wxRequest(config)

        promise.then(res => {

          let isHas = null

          // 有没有完整的微信登录者信息

          isHas = res.data == 0 ? false : true

          app.globalData.isHasUserInfo = isHas

          this_.setData({

            isHasUserInfo: isHas

          })

        }).catch(res => {

          console.log("fail", res)

        });

      }

    })

  }

})

代码解释：

• 一般会在微信小程序启动时，也就是在页面onload 函数中调用 wx.login接口，检查用户是否登录过。


• http://127.0.0.1:8080/wx/getLoginCertificate 是开发者服务器提供的对外处理微信用户信息的接口。


• 最后只是简单地输出开发者服务器端返回的数据。


• httpRequest.wxRequest(config)是自定义的封装wx.request接口的请求组件。

function wxRequest(config) {

  //返回的数据类型

  let dataType = config.dataType == null ? "json" : config.dataType;

  let responseType = config.responseType == null ? "text" : config.responseType;

  //服务器基地址

  let serverUrl = "http://127.0.0.1:8080/"

  //超时

  let timeout = config.timeout == null ? 50000 : config.timeout;

  //目标地址，基地址+接口

  let url = serverUrl + config.url;

  //数据提交方式

  let method = config.method == null ? "GET" : config.method;

  //提交数据

  let data = config.data == null ? null : config.data

  //头信息

  let header = {

    // 默认值

    'content-type': 'application/json',

    'x-requested-with': 'XMLHttpRequest'

  }

  let sessionId = wx.getStorageSync('sessionId')

  if (sessionId) {

    header["cookie"] = sessionId

  }

  return new Promise(function (resolve, reject) {

    wx.request({

      url: url,

      data: data,

      //返回的数据类型（json）

      dataType: dataType,

      enableCache: false,

      enableHttp2: false,

      enableQuic: false,

      method: method,

      header: header,

      responseType: responseType,

      timeout: timeout,

      success: (res) => {

        console.log("requestData", res)

        if (res.cookies != null && res.cookies.length != 0)

          wx.setStorageSync('sessionId', res.cookies[0])

        resolve(res)

      },

      fail: (res) => {

        console.log("requestException", res)

        reject(res)

      }

    })

  })

}

第三步：创建开发者服务器程序（后台应用）

本文使用 spring boot快速搭建后台应用程序。在项目的 pom.xml文件中除了必要的依赖包外，还需要添加以下 的依赖包。

<dependency>

    <groupId>com.alibaba</groupId>

    <artifactId>fastjson</artifactId>

    <version>1.2.73</version>

</dependency>

<dependency>

    <groupId>org.apache.httpcomponents</groupId>

    <artifactId>httpclient</artifactId>

    <version>4.5.13</version>

</dependency>

<dependency>

     <groupId>mysql</groupId>

     <artifactId>mysql-connector-java</artifactId>

     <scope>runtime</scope>

</dependency>

<dependency>

     <groupId>org.projectlombok</groupId>

     <artifactId>lombok</artifactId>

     <optional>true</optional>

</dependency>

<dependency>

     <groupId>com.baomidou</groupId>

     <artifactId>mybatis-plus-boot-starter</artifactId>

     <version>3.5.1</version>

 </dependency>

• 
  

  fastjson 是阿里云提供的开源 JSON解析框架。

  
  

  
  

  微信小程序和开发者服务器构建的项目结构，是标准的前后端分离模式。

  
  

  请求与响应时，数据交互常使用JSON格式。这时使用 fastjson 作为json解析器，当然，也可以选择其它的类似解析器。

  
  

  
  


• 
  

  httpclient 是一个http请求组件。

  
  


• 
  

  mysql-connector-java 本文案例使用 MySQL数据库，需要加载相应的驱动包。

  
  


• 
  

  mybatis-plus-boot-starter，mybatis-plus 依赖包。

  
  

在后台应用中编写处理器（响应）组件：

@RestController

@RequestMapping("/wx")

public class WxAction {

    @Autowired

    private IWxService wxService;

    /***

     * 获取到微信用户的 OPENID

     */

    @GetMapping("/getLoginCertificate")

    public String getLoginCertificate(@RequestParam("code") String code) throws Exception {

        WxUserInfo wxInfo = this.wxService.getLoginCertificate(code);

        //用户不存在，或者用户的信息不全

        return wxInfo==null || wxInfo.getNickName()==null?"0":"1";

    }

代码解释：

• IWxService是处理器依赖的业务组件，提供有 getLoginCertificate()方法用来实现通过code向微信接口服务器换取微信登录者的 openId和session_key。

编写业务组件：

@Service

public class WxService implements IWxService {

    @Override

    public WxUserInfo getLoginCertificate(String code) throws Exception {

        //请求地址

        String requestUrl = WxUtil.getWxServerUrl(code);

        // 发送请求

        String response = HttpClientUtils.getRequest(requestUrl);

        //格式化JSON数据

        WxUserInfo wxUserInfo = JSONObject.parseObject(response, WxUserInfo.class);

        //检查数据库中是否存在 OPENID

        WxUserInfo wxUserInfo_ = this.wxUserMapper.selectById(wxUserInfo.getOpenId());

        if (wxUserInfo_ == null) {

            //数据库中没有用户的 OPENID，添加到数据库中

            this.wxUserMapper.insert(wxUserInfo);

        } else {

            if (!wxUserInfo.getSessionKey().equals(wxUserInfo_.getSessionKey())) {

                //如果数据库保存的session_key和最新的session_key 不相同，则更新

                wxUserInfo_.setSessionKey(wxUserInfo.getSessionKey());

                this.wxUserMapper.updateById(wxUserInfo_);

            }

        }

        return wxUserInfo_;

    }

}

代码解释：

• 
  

  WxUtil 是自定义的一个工具组件，用来构建请求微信接口服务器的 url。

  
  

  https://api.weixin.qq.com/sns/jscode2session是微信接口服务器对外提供的接口，请求此接口时，需要提供 4 个请求数据。

  
  

  appid：小程序 appId。

  
  

  secret：小程序 appSecret。

  
  

  js_code：获取到的微信登录者的临时 code。

  
  

  grant_type：授权类型，此处只需填写 authorization_code。

  
  

public class WxUtil {

    private final static String APP_ID = "微信小程序开发者申请的 appid";

    private final static String APP_SECRET = "微信小程序开发者申请的 APP_SECRET";

    //

    private final static String WX_LOGIN_SERVER_URL = "https://api.weixin.qq.com/sns/jscode2session?appid={0}&secret={1}&js_code={2}&grant_type=authorization_code";

    public static String getWxServerUrl(String code) throws IOException {

        String url = MessageFormat.format(WX_LOGIN_SERVER_URL, new String[]{APP_ID, APP_SECRET, code});

        return url;

    }

}

• HttpClientUtils也是一个自定义组件，用来向指定的服务器发送 http请求。

public class HttpClientUtils {

	/**

     * GET请求

     */

    public static String getRequest(String url) throws Exception {

        //HttpClient对象

        CloseableHttpClient httpClient = HttpClients.createDefault();

        CloseableHttpResponse response = null;

        try {

            HttpGet httpGet = new HttpGet(url);

            response = httpClient.execute(httpGet);

            //响应体

            HttpEntity entity = response.getEntity();

            if (entity != null) {

                //格式化响应体

                return EntityUtils.toString(entity);

            }

        } catch (ClientProtocolException e) {

           throw  e;

        } catch (IOException e) {

            throw  e;

        } finally {

            response.close();

            httpClient.close();

        }

        return null;

    }

}

• WxUserInfo 是自定义的数据封装类。微信接口服务器返回的数据是以JSON格式组装的，这里需要格式成对象数据，便于在 java中处理。本文使用 MyBatisPlus操作数据库，此类也对应数据库中的gk_wx_user表。

@Data

@AllArgsConstructor

@NoArgsConstructor

@TableName("gk_wx_user")

public class WxUserInfo {

    //OPEN_id

    @TableId(type = IdType.ASSIGN_ID, value = "open_id")

    private String openId;

    //会话密钥

    @TableField(value = "session_key")

    private String sessionKey;

    //头像路径

    @TableField("avatar_url")

    private String avatarUrl;

    //城市

    private String city;

    //国家

    private String country;

    //性别

    private String gender;

    //语言

    private String language;

    //昵称

    @TableField("nick_name")

    private String nickName;

    //备注名或真实名

    @TableField("real_name")

    private String realName;

    //省份

    private String province;

    //学生ID

    @TableField("stu_id")

    private Integer stuId;

}

MyBatis 数据库映射组件：

@Repository

public interface WxUserMapper extends BaseMapper<WxUserInfo> {



}

第四步：测试。

先启动后台应用程序，再启动微信小程序，可以在数据库表中查看到如下信息。

微信用户的openid和session_key已经保存到后台的数据库表中。

2.1.2 wx.checkSession(Object object)

官方文档中，有一段对 session_key的生命周期的描述。

• session_key的生命周期有不确定性，可以使用 wx.login接口刷新 session_key。为了避免频繁调用 wx.login 接口，可以通过调用 wx.checkSession(Object object)接口判断session_key是否已经过期。


• 当开发者在实现自定义登录态时，可以考虑以 session_key 有效期作为自身登录态有效期，也可以实现自定义的时效性策略。

wx.checkSession 的功能，可以使用此接口判断session_key是否过期。

• 调用成功说明当前 session_key 未过期。


• 调用失败说明 session_key 已过期。

2.2 用户信息接口

wx.login接口仅能获取到微信登录者的有限数据，如果想要获取到登录者的更多个人信息，可以使用用户信息接口中的相关API。

• wx.getUserProfile(Object object)。获取用户信息，页面产生点击事件（例如 button 上 bindtap 的回调中）后才可调用，每次请求都会弹出授权窗口，用户同意后返回 userInfo。


• wx.getUserInfo(Object object) 。和 wx.getUserProfile的功能一样，在基础库 2.10 的后续版本中，其功能已经被削弱。


• UserInfo是用户信息封装类。

getUserProfile是从 基础库2.10.4版本开始支持的接口，该接口用来替换 wx.getUserInfo，意味着官方不建议再使用getUserInfo接口获取用户的个人信息。

下图是官方提供的 2 个接口的功能对比图。

为了避免频繁弹窗，可以在第一次获取到用户信息后保存在数据库中以备以后所用。为了获取到用户的敏感数据，在后台要通过getUserProfile接口所获取的数据进行解密操作。

2.2.2 wx.getUserProfile

下面通过具体代码讲解如何保存微信登录者的个人数据。先了解一下整个数据获取的流程，这里直接截取官方提供的一张流程图。

获取微信登录者的个人信息，需要经过 2 个步骤。

签名效验：

• 通过调用wx.getUserProfile接口获取数据时，接口会同时返回 rawData、signature，其中 signature = sha1( rawData + session_key )。


• 开发者将 signature、rawData 发送到开发者服务器进行校验。服务器利用用户对应的 session_key 使用相同的算法计算出签名 signature2 ，比对signature 与 signature2 即可校验数据的完整性。

解密加密数据：

• 对称解密使用的算法为 AES-128-CBC，数据采用PKCS#7填充。


• 对称解密的目标密文为 Base64_Decode(encryptedData)。


• 对称解密秘钥 aeskey = Base64_Decode(session_key), aeskey 是16字节。


• 对称解密算法初始向量 为Base64_Decode(iv)，其中iv由数据接口返回。

具体编写实现。

**第一步：**在微信小程序端编码。

在index.wxml页面中添加一个按钮，并注册bindtap事件。

<view>

  <button bindtap="getUserProfile">获取用户数据</button>

</view>

在index.js中添加一个名为getUserProfile的事件回调函数。为了避免不必要的弹窗，只有当后台没有获取到个人数据时，才调用wx.getUserProfile接口。

getUserProfile: function (e) {

    let this_ = this

    if (!this.data.isHasUserInfo) {

      //如果服务器端没有保存完整的微信登录者信息

      wx.getUserProfile({

        desc: '需要完善您的资料！',

        success: (res) => {

          this_.setData({

            //小程序中用来显示个人信息  

            userInfo: res.userInfo,

            isHasUserInfo: true

          })

          //再次登录，因为 session_key 有生命中周期

          wx.login({

            success(res_) {

              //保存到服务器端

              let config = {

                url: "wx/wxLogin",

                method: "GET",

                data: {

                  code: res_.code,

                  //明文数据

                  rawData: res.rawData,

                  //加密数据

                  encryptedData: res.encryptedData,

                  iv: res.iv,

                  //数字签名

                  signature: res.signature

                }

              }

              let promise = httpRequest.wxRequest(config)

              promise.then(res => {

                //返回

                console.log("wxLogin", res)

              }).catch(res => {

                console.log("fail", res)

              });

            }

          })

        }

      })

    }

  }

服务器端代码：

在pom.xml文件中添加如下依赖包，用来解密数据。

<dependency>

   <groupId>org.bouncycastle</groupId>

   <artifactId>bcprov-jdk16</artifactId>

   <version>1.46</version>

</dependency>

<dependency>

    <groupId>commons-codec</groupId>

    <artifactId>commons-codec</artifactId>

    <version>1.15</version>

</dependency>

在处理器类WxAction中添加wxLogin响应方法。

@RestController

@RequestMapping("/wx")

public class WxAction {

    @Autowired

    private IWxService wxService;

    /***

     *

     * @param code

     * @param rawData

     * @param encryptedData

     * @param iv

     * @param signature

     * @return

     * @throws Exception

     */

    @GetMapping("/wxLogin")

    public WxUserInfo wxLogin(@RequestParam("code") String code, @RequestParam("rawData") String rawData,

                              @RequestParam("encryptedData") String encryptedData, @RequestParam("iv") String iv,

                              @RequestParam("signature") String signature) throws Exception {

        WxUserInfo wxInfo = this.wxService.getWxUserInfo(code, rawData, encryptedData, iv, signature);

        return wxInfo;

    }

}

业务代码：

小程序中传递过来的数据是经过base64编码以及加密的数据，需要使用 Base64解码字符串，再使用解密算法解密数据。先提供一个解密方法。

public String decrypt(String session_key, String iv, String encryptData) {

   

    String decryptString = "";

    //解码经过 base64 编码的字符串    

    byte[] sessionKeyByte = Base64.getDecoder().decode(session_key);

    byte[] ivByte = Base64.getDecoder().decode(iv);

    byte[] encryptDataByte = Base64.getDecoder().decode(encryptData);



    try {

        Security.addProvider(new BouncyCastleProvider());    

        Cipher cipher = Cipher.getInstance("AES/CBC/PKCS7Padding");

        //得到密钥

        Key key = new SecretKeySpec(sessionKeyByte, "AES");

        //AES 加密算法

        AlgorithmParameters algorithmParameters = AlgorithmParameters.getInstance("AES");

        algorithmParameters.init(new IvParameterSpec(ivByte));

        cipher.init(Cipher.DECRYPT_MODE, key, algorithmParameters);

        byte[] bytes = cipher.doFinal(encryptDataByte);

        decryptString = new String(bytes);

    } catch (Exception e) {

            e.printStackTrace();

    }

    return decryptString;

}

具体获取数据的业务实现：

@Override

public WxUserInfo getWxUserInfo(@NotNull String code, @NotNull String rawData, @NotNull String encryptedData, @NotNull String iv, @NotNull String signature) throws Exception {

        //会话密钥

        WxUserInfo wxUserInfo = this.getLoginCertificate(code);

        String signature2 = DigestUtils.sha1Hex(rawData + wxUserInfo.getSessionKey());

        if (!signature.equals(signature2)) {

            throw new Exception("数字签名验证失败");

        }

        //数字签名验证成功,解密

        String infos = this.decrypt(wxUserInfo.getSessionKey(), iv, encryptedData);

    	//反序列化 JSON 数据	

        WxUserInfo wxUserInfo_ = JSONObject.parseObject(infos, WxUserInfo.class);

        wxUserInfo_.setSessionKey(wxUserInfo.getSessionKey());

        wxUserInfo_.setOpenId(wxUserInfo.getOpenId());

        //更新数据库

        this.wxUserMapper.updateById(wxUserInfo_);

        return wxUserInfo_;

}

测试，启动微信小程序和后台应用，在小程序中触发按钮事件。

在弹出的对话框中，选择允许。

查看后台数据库表中的数据。

能够获取到的微信登录者个人信息都保存到了数据库表中。至于怎么使用这些数据，可以根据自己的业务需要定制。

3.总结

微信开发平台，提供有诸多接口，可以帮助开发者获取到有用的数据。本文主要介绍 wx.login和wx.getProfile接口，因篇幅所限，不能对其它接口做详细介绍 ，有兴趣者可以查阅官方文档。

官方文档只会对接口功能做些介绍 ，如要灵活运用这些接口，还需要结合实际需要演练一下，如此方能有切身体会。

序列化隐秘的吭，你踩过了没？

序列化和反序列化

Java序列化的目的主要有2个：

• 网络传输


• 对象持久化

当2个相对独立的进程，需要进行跨进程服务调用时，就需要把被传输的Java对象编码为字节数组或者ByteBuffer对象。

接收方只需要把这些字节数组或者Bytebuf对象重新解码成内存对象即可实现通信、调用的作用。

那么在我们使用序列化的时候有哪些需要注意的，避免的坑呢？

成员变量不能以is开头

阿里的《Java开发手册》明文规定了：成员变量禁止使用类似 isXxxx 的命名方式，也不要有isXxx命名的方法

大概的意思就是：不要加is前缀，因为部分框架序列化的时候，会以为对应的字段名是isXxxx后面的Xxxx

• 比如：isSucceed序列化成Succeed，前端读取isSucceed的时候就会发现没有这个字段，然后出错了。

这里面的序列化框架其实就是fastjson，我们可以直接去看他的源码

fastjson源码分析：computeGetters

去找get前缀的方法，然后进行字符串切割找到get后面的

去找is前缀的方法，然后进行字符串切割

• 这里还进行了驼峰命名的判断：ixXxx，第三个字符是否是大写等判断

所以isSucceed字段会被fastjson框架认为Succeed字段。

默认值

成员变量的默认值同样会带来坑

同样是阿里的《Java开发手册》里面也是规定了：POJO类、RPC方法必须使用包装类型。

关于包装类型和基本类型的区别，如果还有不清楚的，赶紧去看，这是最基础的面试知识点..

POJO类必须使用包装类型

尽量让错误暴露在编译期，不要拖到运行期

基本类型具有初始值，比如：

• Int：0


• float：0.0f


• boolean：false

一个统计点赞的接口里面的返回值包含一个表示点赞数变化的字段，当发生错误的时候，这个字段没有进行赋初始值，就会出现以下情况：

• 基本类型：读默认值，0，表达的意思就是没有点赞数变化，程序上并不知道是服务器那边出了错。


• 包装类型：读到了个null，程序上是知道服务器那边出错了，可以进行对应的显示，比如显示 - ，表示读取不到等操作。

总的来说就是：如果字段设置为基础类型并且基础类型的默认值具有业务意义，那么就会出错，并且无法感知错误

RPC方法的返回值和参数必须使用包装类型

RPC调用常常具有超时导致调用失败的情况

如果用包装类型，那么在接收方，就能感知到，这次RPC调用是成功，还是失败。

包装数据类型的null值具有表示额外的信息功能。

彦祖来都来了，点个赞👍再走吧，这对我来说真的非常重要

“yes，你看着这鬼代码，竟然在 for 循环里面搞了个 try-catch，不知道try-catch有性能损耗吗？”老陈煞有其事地指着屏幕里的代码：

 for (int i = 0; i < 5000; i++) {

     try {

         dosth

     } catch (Exception e) {

         e.printStackTrace();

     }

 }

我探过头去看了眼代码，“那老陈你觉得该怎么改？”

“当然是把 try-catch 提到外面啊！”老陈脑子都不转一下，脱口而出。

“你是不是傻？且不说性能，这代码的目的明显是让循环内部单次调用出错不影响循环的运行，你其到外面业务逻辑不就变了吗！”

老陈挠了挠他的地中海，“好像也是啊！”

“回过头来，catch 整个 for 循环和在循环内部 catch，在不出错的情况下，其实性能差不多。” 我喝一口咖啡不经意地提到，准备在老陈前面秀一下。

“啥意思？”老陈有点懵地看着我，“try-catch是有性能损耗的，我可是看过网上资料的！”

果然，老陈上钩了，我二话不说直接打开 idea，一顿操作敲了以下代码：

public class TryCatchTest {



    @Benchmark

    public void tryfor(Blackhole blackhole) {

        try {

            for (int i = 0; i < 5000; i++) {

                blackhole.consume(i);

            }

        } catch (Exception e) {

            e.printStackTrace();

        }

    }



    @Benchmark

    public void fortry(Blackhole blackhole) {

        for (int i = 0; i < 5000; i++) {

            try {

                blackhole.consume(i);

            } catch (Exception e) {

                e.printStackTrace();

            }

        }

    }



}

“BB 不如 show code，看到没，老陈，我把 try-catch 从 for 循环里面提出来跟在for循环里面做个对比跑一下，你猜猜两个差多少？”

“切，肯定 tryfor 性能好，想都不用想，不是的话我倒立洗头！”老陈信誓旦旦道。

我懒得跟他BB，直接开始了 benchmark，跑的结果如下：

可以看到，两者的性能（数字越大越好）其实差不多：

• fortry: 86,261(100359-14098) ~ 114,457(100359+14098)


• tryfor: 95,961(103216-7255) ~ 110,471(103216+7255)

我再调小(一般业务场景 for 循环次数都不会很多)下 for 循环的次数为 1000 ，结果也是差不多：

老陈一看傻了：“说好的性能影响呢？怎么没了？”

我直接一个javap，让老陈看看，其实两个实现在字节码层面没啥区别：

tryfor 的字节码

异常表记录的是 0 - 20 行，如果这些行里面的代码出现问题，直接跳到 23 行处理。

fortry 的字节码

差别也就是异常表的范围小点，包的是 9-14 行，其它跟 tryfor 都差不多。

所以从字节码层面来看，没抛错两者的执行效率其实没啥差别。

“那为什么网上流传着try-catch会有性能问题的说法啊？”老陈觉得非常奇怪。

这个说法确实有，在《Effective Java》这本书里就提到了 try-catch 性能问题：

并且还有下面一段话：

正所谓听话不能听一半，以前读书时候最怕的就是一知半解，因为完全理解选择题能选对，完全不懂蒙可能蒙对，一知半解必定选到错误的选项！

《Effective Java》书中说的其实是不要用 try-catch 来代替正常的代码，书中的举例了正常的 for 循环肯定这样实现：

但有个卧龙偏偏不这样实现，要通过 try-catch 拐着弯来实现循环：

这操作我只能说有点逆天，这两个实现的对比就有性能损耗了。

我们直接再跑下有try-catch 的代码和没 try-catch的 for 循环区别，代码如下：

结果如下：

+-差不多，直接看前面的分数对比，没有 ry-catch 的性能确实好些，这也和书中说的 try-catch 会影响 JVM 一些特定的优化说法吻合，但是具体没有说影响哪些优化，我猜测可能是指令重排之类的。

好了，我再总结下有关 try-catch 性能问题说法：

1. try-catch 相比较没 try-catch，确实有一定的性能影响，但是旨在不推荐我们用 try-catch 来代替正常能不用 try-catch 的实现，而不是不让用 try-catch。


2. for循环内用 try-catch 和用 try-catch 包裹整个 for 循环性能差不多，但是其实两者本质上是业务处理方式的不同，跟性能扯不上关系，关键看你的业务流程处理。


3. 虽然知道try-catch会有性能影响，但是业务上不需要避讳其使用，业务实现优先（只要不是书中举例的那种逆天代码就行），非特殊情况下性能都是其次，有意识地避免大范围的try-catch，只 catch 需要的部分即可（没把握全 catch 也行，代码安全执行第一）。

“好了，老陈你懂了没？”

“行啊yes，BB是一套一套的，走请你喝燕麦拿铁！” 老陈一把拉起我，我直接一个挣脱，“少来，我刚喝过咖啡，你那个倒立洗头，赶紧的！”我立马意识到老陈想岔开话题。

“洗洗洗，我们先喝个咖啡，晚上回去给你洗！”

晚上22点，老陈发来一张图片：

你别说，这头发至少比三毛多。

我是yes，我们下篇见~

我们平时在写代码的时候经常会遇到这样的一种情况

提示说没有处理xxx异常

然后解决办法可以在外面加上try-catch，就像这样

所以我之前经常这样处理

//重新抛出 RuntimeException

public class ThrowsDemo {



    public void demo4throws() {

        try {

            new ThrowsSample().sample4throws();

        } catch (IOException e) {

            throw new RuntimeException(e);

        }

    }

}



//打印日志

@Slf4j

public class ThrowsDemo {



    public void demo4throws() {

        try {

            new ThrowsSample().sample4throws();

        } catch (IOException e) {

            log.error("sample4throws", e);

        }

    }

}



//继续往外抛，但是需要每个方法都添加 throws

public class ThrowsDemo {



    public void demo4throws() throws IOException {

        new ThrowsSample().sample4throws();

    }

}

但是我一直不明白

这个方法为什么不直接帮我做

反而要让我很多余的加上一步

我处理和它处理有什么区别吗？

而且变的好不美观

本来缩进就多，现在加个try-catch更是火上浇油

public class ThrowsDemo {



    public void demo4throws() {

        try {

            if (xxx) {

                try {

                    if (yyy) {

                        

                    } else {

                        

                    }

                } catch (Throwable e) {

                }

            } else {



            }

        } catch (IOException e) {

            

        }

    }

}

上面的代码，就算里面没有业务，看起来也已经比较乱了，分不清哪个括号和哪个括号是一对

还有就是对Lambda很不友好

没有办法直接用::来优化代码，所以就变成了下面这样

本来看起来很简单很舒服的Lambda，现在又变得又臭又长

为什么会强制 try-catch

为什么我们平时写的方法不需要强制try-catch，而很多jdk中的方法却要呢

那是因为那些方法在方法的定义上添加了throws关键字，并且后面跟的异常不是RuntimeException

一旦你显式的添加了这个关键字在方法上，同时后面跟的异常不是RuntimeException，那么使用这个方法的时候就必须要显示的处理

比如使用try-catch或者是给调用这个方法的方法也添加throws以及对应的异常

throws 是用来干什么的

那么为什么要给方法添加throws关键字呢？

给方法添加throws关键字是为了表明这个方法可能会抛出哪些异常

就像一个风险告知

这样你在看到这个方法的定义的时候就一目了然了：这个方法可能会出现什么异常

为什么 RuntimeException 不强制 try-catch

那为什么RuntimeException不强制try-catch呢？

因为很多的RuntimeException都是因为程序的BUG而产生的

比如我们调用Integer.parseInt("A")会抛出NumberFormatException

当我们的代码中出现了这个异常，那么我们就需要修复这个异常

当我们修复了这个异常之后，就不会再抛出这个异常了，所以try-catch就没有必要了

当然像下面这种代码除外

public boolean isInteger(String s) {

    try {

        Integer.parseInt(s);

        return true;

    } catch (NumberFormatException e) {

        return false;

    }

}

这是我们利用这个异常来达成我们的需求，是有意为之的

而另外一些异常是属于没办法用代码解决的异常，比如IOException

我们在进行网络请求的时候就有可能抛出这类异常

因为网络可能会出现不稳定的情况，而我们对这个情况是无法干预的

所以我们需要提前考虑各种突发情况

强制try-catch相当于间接的保证了程序的健壮性

毕竟我们平时写代码，如果IDE没有提示异常处理，我们完全不会认为这个方法会抛出异常

我的代码怎么可能有问题！

看来Java之父完全预判到了程序员的脑回路

throws 和 throw 的区别

java中还有一个关键词throw，和throws只有一个s的差别

throw是用来主动抛出一个异常

public class ThrowsDemo {



    public void demo4throws() throws RuntimeException {

        throw new RuntimeException();

    }

}

两者完全是不同的功能，大家不要弄错了

什么场景用 throws

我们可以发现我们平时写代码的时候其实很少使用throws

因为当我们在开发业务的时候，所有的分支都已经确定了

比如网络请求出现异常的时候，我们常用的方式可能是打印日志，或是进行重试，把异常往外抛等等

所以我们没有那么有必要去使用throws这个关键字来说明异常信息

但是当我们没有办法确定异常要怎么处理的时候呢？

比如我在GitHub上维护了一个功能库，本身没有什么业务属性，主要就是对于一些复杂的功能做了相应的封装，提供给自己或别人使用（如果有兴趣可以看看我的库，顺便给Star，嘿嘿）

对我来说，当我的方法中出现异常时，我是不清楚调用这个方法的人是想要怎么处理的

可能有的想要重试，有的想要打印日志，那么我干脆就往外抛，让调用方法的人自己去考虑，自己去处理

所以简单来说，如果方法主要是给别人用的最好用throws把异常往外抛，反之就是可加可不加

结束

很多时候你的不理解只是因为你还不够了解

一，前言

1,什么是动态化？

目前移动端应用的版本更新， 最常见的方式是定期发版，无论是安卓还是iOS，都需要提交新的安装包到应用市场进行审核。审核通过后，用户在应用市场进行App的下载更新。

而动态化， 就是不依赖更新程序安装包， 就能动态实时更新页面的技术。

2,动态化的必要性

为什么需要动态化技术呢？ 因为上述定期发版更新应用的方式存在一些问题，比如:

1. 审核周期长， 且可能审核不通过。 周期长导致发版本不够灵活， 紧急的业务需求不能及时上线。


2. 线上出现急需修复的bug时，需要较长修复周期，影响用户体验。


3. 安装包过大， 动辄几十兆几百兆的应用升级可能会让用户比较抗拒。


4. 即使上线了，也无法达到全部用户升级， 服务端存在兼容多版本App的问题。

面对这些问题，如果能实现app增量、无感知更新，实现功能同步。无论是对公司还是用户都是非常重要的需求，能实现app动态化更新就显得非常重要，能很好的解决以上问题:

1. 随时实现功能升级，不存在应用市场长时间审核和拒绝上线问题，达到业务需求快速上线的目的。


2. 线上bug可以实时修复，提高用户体验。


3. 可以减小发版功能包体积，只需要替换新增功能即可。


4. 功能保持一致，类似网页一样，发版后用户同步更新，不存在旧版本兼容问题。

接下来，我们就来分析一下，目前业内主要的Flutter动态化更新方式。

二，动态化方案调研

在Flutter实践层面，简单来说分为三个流派：

• 
  

  方案一：JavaScript是最好的语言（🤣碰瓷PHP）
  主要思路：利用Flutter做渲染，开发使用js，逻辑层通过v8/jscore解释运行。代表框架是腾讯的MXFlutter。这个框架是开源的，大写的👍。

  
  


• 
  

  方案三：布局，逻辑，一把梭

  
  

  主要思路：与方案一最主要的区别是，逻辑层也是使用dart，增加了一层语法解析和运行时。有一个代表，美团的MTFlutter，然而没有开源动向，无从考察更多。

  
  


• 
  

  方案二：DSL + JS

  
  

  主要思路：基于模板实现动态化，主要布局层采用Dart转DSL的方式，逻辑层使用JS。代表框架是58同城开源的Fair。

  
  

MXFlutter

项目简介

MXFlutter 是一套基于 JavaScript 的 Flutter 框架，可以用极其类似 Dart 的开发方式，通过编写 JavaScript 代码，来开发 Flutter 应用，或者使用 mxjsbuilder 编译器，把现有Flutter 工程编译为JS，运行在 mxflutter 之上。

核心思想

核心思路是把 Flutter 的渲染逻辑中的三棵树中的第一棵，放到 JavaScript 中生成。用 JavaScript 完整实现了 Flutter 控件层封装，可以使用 JavaScript，用极其类似 Dart 的开发方式，开发Flutter应用，利用JavaScript版的轻量级Flutter Runtime，生成UI描述，传递给Dart层的UI引擎，UI引擎把UI描述生产真正的 Flutter 控件。

MxFlutter 目前已经停止维护，具体请看MXFlutter。
MxFlutter通过JavaScript编写Dart，加载线上js文件，通过引擎在运行时转化并显示，从而达到动态化效果。 官方在0.7.0版本开始接入TypeScript，引入npm生态，优化了js开发的成本，向前端生态进一步靠拢。
很遗憾，在对比各大厂的方案时，发现MxFlutter的性价比极低，学习成本也高，而且又抛弃Dart生态。开发及维护成本都很高。

MTFlutter

项目简介

美团的MTFlutter团队flap项目采用的静态生产DSL方案，通过对Dart语言注解，保证平台一致性。实现了动态下发与解释的逻辑页面一体化的 Flutter 动态化方案。Flap 的出现让 Flutter 动态化和包大小这两个短板得到了一定程度的弥补，促进了 Flutter 生态的发展。

核心思想

通过静态生产 DSL+Runtime 解释运行的思路，实现了动态下发与解释的逻辑页面一体化的 Flutter 动态化方案，建设了一套 Flap 生态体系，涵盖了开发、发布、测试、运维各阶段。

布局和逻辑层都使用Dart, 增加了一层语法解析和运行时。然而没有开源动向，无从考察更多。

Fair

项目简介

Fair是为Flutter设计的动态化框架，通过Fair Compiler工具对原生Dart源文件的自动转化，使项目获得动态更新Widget Tree和State的能力。

创建Fair的目标是支持不发版（Android、iOS、Web）的情况下，通过业务bundle和JS下发实现更新，方式类似于React Native。与Flutter Fair集成后，您可以快速发布新的页面，而无需等待应用的下一个发布日期。Fair提供了标准的Widget，它可以被用作一个新的动态页面或作为现有Flutter页面的一部分，诸如运营位的排版/样式修改，整页面替换，局部替换等都可以使用。

核心思想

Fair是58自研的的动态化框架，通过Fair Compiler工具对原生Dart源文件的自动转化，使项目获得动态更新Widget Tree和State的能力。

三，方案对比

经过上述三个方案的调研，我们来大概对比一下上述框架

可以看到， MXFlutter需要使用js写Dart, 官方已经停止更新，而这种方式我们不能接受， MTFlutter目前未开源，无从继续研究。 接下来着重看一下 Fair。

四，Fair接入过程

1,添加依赖

推荐使用pub形式引入

# add Fair dependency

dependencies:

  fair: 2.7.0



# add compiler dependency

dev_dependencies:

  build_runner: ^2.0.0

  fair_compiler: ^1.2.0

 

# switch "fair_version" according to the local Flutter SDK version

dependency_overrides:

  fair_version: 3.0.0

Flutter版本切换

通过切换 flutter_version 版本进行版本兼容。例如，将本机切换为 flutter 2.0.6 后，Fair 需要同步切换

# switch to another stable flutter version

dependency_overrides:

  fair_version: 2.0.6

2,使用 Fair

在App中接入Fair步骤如下：

将 FairApp 添加为需要动态化部分的顶级节点

常见做法是作为 App 的根节点，如果不是全局采用也可以作为子页面的根节点

void main() {

  WidgetsFlutterBinding.ensureInitialized();



  FairApp.runApplication(

    _getApp(),

    plugins: {

    },

  );

}



dynamic _getApp() => FairApp(

  modules: {

  },

  delegate: {

  },

  child: MaterialApp(

    home: FairWidget(

            name: 'DynamicWidget',

            path: 'assets/bundle/lib_src_page_dynamic_widget.fair.json',

            data: {"fairProps": json.encode({})}),

  ),

);

添加动态组件

每一个动态组件由一个FairWidget表示。

FairWidget(

  name: 'DynamicWidget',

  path: 'assets/bundle/lib_src_page_dynamic_widget.fair.json',

  data: {"fairProps": json.encode({})}),

根据不同场景诉求，FairWidget可以混合和使用

1. 可以作为不同组件混合使用


2. 一般作为一个全屏页面


3. 支持嵌套使用，即可以局部嵌套在普通Widget下，也可以嵌套在另一个FairWidget下

五，Fair接入体验

1，fork,下载工程

将官方Github工程fork到自己仓库后， 下载工程。使用官方提供的 test_case/best_ui_templates工程体验fair的体验。

2, 执行 pub get

在 best_ui_templates工程中，执行 pub get命令获取依赖。

3，开发业务

接下来正式开始开发流程。 把一个页面改写为 用Fair 编写:

1. 创建需要动态化的 componnet, 并添加 @FairPatch() 注解。添加上注解后，在Fair生成产物时，会把此Component build生成 FairWidget加载的产物。

2, 执行 Fair工具链插件的命令生成产物， 如图:

3, 最终生成的产物，拷贝到 assets/bundle目录下(配置config.json后，会自动拷贝)

4, 看效果， 下图为使用 Fair 改造后的页面：

六，Fair优势

1，社区活跃度高

官方对Fair维护力度大，版本更新较快，问题修复及时，活跃的开发者社区氛围。

使得开发者在开发Fair过程中遇到的问题， 能够及时反馈给官方， 并能得到快速的帮助和解决。

2, 一份代码，灵活使用

Fair的区别于MTFlutter和MXFlutter这2种动态化方案，Fair能让同一份代码在Flutter原生和动态之间随意切换。在开发跟版本需求时，使用原生代码发布，以此持续保持Flutter的性能优势；而在热更新场景可以通过下发动态文件来达到动态更新Widget的目的。使用方式更加灵活。

3，配套开发工具丰富

Faircli配套工具链

官方为了让开发者快速上手，降低接入门槛， 解决在接入过程中的痛点。 Fair团队开发了Faircli配套工具链，主要包含三个部分:

• 工程创建：快速搭建Fair载体工程及动态化工程。


• 模板代码：提供页面及组件模板。


• 本地热更新：线下开发使用，实现开发阶段快速预览Fair动态化功能。

在安装了工具链提供的dart命令行工具及AS插件后， 通过创建模板， 构建产物， 本地启服务，体验热更新功能，开发者可以轻松接入并体验Fair。

Fair语法检测插件

官方为了让开发者在Fair开发过程中，出现不正确或者不支持的语法问题。 开发了配套插件去提示用户使用Fair语法糖。

查看以下示例:

1,build方法下if的代码检测，及提示引导信息

2,点击more action 或者 AS代码提示快捷键

3,根据提示点击替换

通过插件，在编写fair过程中，可以快速识别并解决不支持的语法问题。 提高开发Fair效率。

Fair Web代码编辑器

Fair其中一个方向是在线动态化平台，即在网页中编辑dart代码，在线预览Flutter效果和Fair动态化效果，并且发布Fair动态化产物。

通过在Fair Web代码编辑器，开发者可以在没有复杂的IDE配置的情况下，在网页端开发Fair并预览。 这无疑是降低了接入成本， 为开发者可以快速体验Fair提供了非常便捷的方式。

七，总结

通过近期对各大互联网公司在Flutter动态化方向上的探究方案。 发现这些方案都还没有达到成熟阶段，想在实际业务上落地， 还得看各团队后期的维护力度和开发投入程度。

MXFlutter使用js编写Dart的方式， 抛弃了原本Flutter的开发模式， 导致开发成本大，以及后续维护成本也大，官方已停止维护。

MTFlutter采用布局,逻辑都是使用Dart, 通过静态生产 DSL+Runtime 解释运行的思路，解决布局和逻辑的动态化，然而并没有开源计划，无从深入研究。

Fair通过Fair Compiler工具对原生Dart源文件的自动转化，使项目获得动态更新Widget Tree和State的能力。目前官方维护力度较大， 社区活跃，并且有比较全面的Fair生态工具。 期待 Fair 团队可以解决在开发Fair过程中一些体验问题，如语法支持不全等， 让Fair成为真正能够让开发者可以快速接入，能够达到和正常开发Flutter接近的体验。 为广大Flutter开发人员解决动态化的痛点。

支持我们

欢迎大家使用 Fair，也欢迎大家为我们点亮star

Github地址：github.com/wuba/fair

Fair官网：fair.58.com/

欢迎贡献

通过Issue提交问题，贡献代码请提交Pull Request，管理员将对代码进行审核。

引子

view.setOnClickListener { // 当控件被点击时触发的逻辑 }

正是因为 View 对控件点击采用了策略模式，才使得监听任何控件的点击事件变得易如反掌。

我有一个愿望。。。

如果 View 能有一个可见性监听该多好啊！

view.setOnVisibilityChangeListener { isVisible: Boolean ->   }

系统并未提供这个方法。。。

但业务上有可见性监听的需要，比如曝光埋点。当某控件可见时，上报XXX。

数据分析同学经常抱怨曝光数据不准确，有的场景曝光多报了，有的场景曝光少报了。。。

开发同学看到曝光埋点也很头痛，不同场景的曝光检测有不同的方法，缺乏统一的可见性检测入口，存在一定重复开发。

本文就试图为单个控件以及列表项的可见性提供统一的检测入口。

控件的可见性受到诸多因素的影响，下面是影响控件可见性的十大因素：

1. 手机电源开关


2. Home 键


3. 动态替换的 Fragment 遮挡了原有控件


4. ScrollView, NestedScrollView 的滚动


5. ViewPager, ViewPager2 的滚动


6. RecyclerView 的滚动


7. 被 Dialog 遮挡


8. Activity 切换


9. 同一 Activity 中 Fragment 的切换


10. 手动调用 View.setVisibility(View.GONE)


11. 被输入法遮盖

能否把这所有的情况都通过一个回调方法表达？目标是通过一个 View 的扩展方法完成上述所有情况的检测，并将可见性回调给上层，形如：

fun View.onVisibilityChange(block: (view: View, isVisible: Boolean) -> Unit) {}

若能实现就极大化简了上层可见性检测的复杂度，只需要如下代码就能实现任意控件的曝光上报埋点：

view.onVisibilityChange { view, isVisible ->

    if(isVisible) { // 曝光埋点 }

    else {}

}

控件全局可见性检测

可见性检测分为两步：

1. 捕获时机：调用检测算法检测控件可见性的时机。


2. 检测算法：描述如何检测控件是否对用户可见。

拿“手动调用 View.setVisibility(View.GONE)”举例，得先捕获 View Visibility 发生变化的时机，并在此刻检测控件的可见性。

下面是View.setVisibility()的源码：

// android.view.View.java

public void setVisibility(@Visibility int visibility) {

    setFlags(visibility, VISIBILITY_MASK);

}

系统并未在该方法中提供类似于回调的接口，即一个 View 的实例无法通过回调的方式捕获到 visibility 变化的时机。

难道通过自定义 View，然后重写 setVisibility() 方法？

这个做法接入成本太高且不具备通用性。

除了“手动调用 View.setVisibility(View.GONE)”，剩下的影响可见性的因素大多都可找到对应回调。难道得在fun View.onVisibilityChange()中对每个因素逐个添加回调吗？

这样实现太过复杂了，而且也不具备通用性，假设有例外情况，fun View.onVisibilityChange()的实现就得修改。

上面列出的十种影响控件可见性的因素都是现象，不同的现象背后可能对应相同的本质。

经过深挖，上述现象的本质可被收敛为下面四个：

1. 控件全局重绘


2. 控件全局滚动


3. 控件全局焦点变化


4. 容器控件新增子控件

下面就针对这四个本质编程。

捕获全局重绘时机

系统提供了ViewTreeObserver：

public final class ViewTreeObserver {

    public void addOnGlobalLayoutListener(OnGlobalLayoutListener listener) {

        checkIsAlive();

        if (mOnGlobalLayoutListeners == null) {

            mOnGlobalLayoutListeners = new CopyOnWriteArray();

        }

        mOnGlobalLayoutListeners.add(listener);

    }

}

ViewTreeObserver 是一个全局的 View 树变更观察者，它提供了一系列全局的监听器，全局重绘即是其中OnGlobalLayoutListener：

public interface OnGlobalLayoutListener {

    public void onGlobalLayout();

}

当 View 树发生变化需要重绘的时候，就会触发该回调。

调用 View.setVisibility(View.GONE) 之所以能将控件隐藏，正是因为整个 View 树触发了一次重绘。（任何一次微小的重绘都是从 View 树的树根自顶向下的遍历并触发每一个控件的重绘，不需要重绘的控件会跳过，关于 Adroid 绘制机制的分析可以点击Android自定义控件 | View绘制原理（画多大？））

在可见性检测扩展方法中捕获第一个时机：

fun View.onVisibilityChange(block: (view: View, isVisible: Boolean) -> Unit) {

    viewTreeObserver.addOnGlobalLayoutListener {}  

}

其中viewTreeObserver是 View 的方法：

// android.view.View.java

public ViewTreeObserver getViewTreeObserver() {

    if (mAttachInfo != null) {

        return mAttachInfo.mTreeObserver;

    }

    if (mFloatingTreeObserver == null) {

        mFloatingTreeObserver = new ViewTreeObserver(mContext);

    }

    return mFloatingTreeObserver;

}

getViewTreeObserver() 用于返回当前 View 所在 View 树的观察者。

全局重绘其实覆盖了上述的两个场景：

1. 同一 Activity 中 Fragment 的切换


2. 手动调用 View.setVisibility(View.GONE)


3. 被输入法覆盖

这两个场景都会发生 View 树的重绘。

捕获全局滚动时机

1. ScrollView, NestedScrollView 的滚动


2. ViewPager, ViewPager2 的滚动


3. RecyclerView 的滚动

上述三个时机的共同特点是“发生了滚动”。

每个可滚动的容器控件都提供了各自滚动的监听

// android.view.ScrollView.java

public interface OnScrollChangeListener {

    void onScrollChange(View v, int scrollX, int scrollY, int oldScrollX, int oldScrollY);

}



// androidx.viewpager2.widget.ViewPager2.java

public abstract static class OnPageChangeCallback {

    public void onPageScrolled(int position, float positionOffset, @Px int positionOffsetPixels) {}

    public void onPageSelected(int position) {}

    public void onPageScrollStateChanged(@ScrollState int state) {}

}



// androidx.recyclerview.widget.RecyclerView.java

public abstract static class OnScrollListener {

    public void onScrollStateChanged(@NonNull RecyclerView recyclerView, int newState) {}

    public void onScrolled(@NonNull RecyclerView recyclerView, int dx, int dy) {}

}

难道要针对不同的滚动控件设置不同的滚动监听器？

这样可见性检测就和控件耦合了，不具有通用性，也愧对View.onVisibilityChange()这个名字。

还好又在ViewTreeObserver中找到了全局的滚动监听：

public final class ViewTreeObserver {

    public void addOnScrollChangedListener(OnScrollChangedListener listener) {

        checkIsAlive();



        if (mOnScrollChangedListeners == null) {

            mOnScrollChangedListeners = new CopyOnWriteArray();

        }



        mOnScrollChangedListeners.add(listener);

    }

}



public interface OnScrollChangedListener {

    public void onScrollChanged();

}

在可见性检测扩展方法中捕获第二个时机：

fun View.onVisibilityChange(block: (view: View, isVisible: Boolean) -> Unit) {

    viewTreeObserver.addOnGlobalLayoutListener {} 

    viewTreeObserver.addOnScrollChangedListener {}

}

捕获全局焦点变化时机

下面这些 case 都是焦点发生了变化：

1. 手机电源开关


2. Home 键


3. 被 Dialog 遮挡


4. Activity 切换

同样借助于 ViewTreeObserver 可以捕获到焦点变化的时机。

到目前为止，全局可见性扩展方法中已经监听了三种时机，分别是全局重绘、全局滚动、全局焦点变化：

fun View.onVisibilityChange(block: (view: View, isVisible: Boolean) -> Unit) {

    viewTreeObserver.addOnGlobalLayoutListener {} 

    viewTreeObserver.addOnScrollChangedListener {}

    viewTreeObserver.addOnWindowFocusChangeListener {}

}

捕获新增子控件时机

最后一个 case 是最复杂的：动态替换的 Fragment 遮挡了原有控件。

该场景如下图所示：

界面中有一个底边栏，其中包含各种 tab 标签，点击其中的标签会以 Fragment 的形式从底部弹出。此时，底边栏各 tab 从可见变为不可见，当点击返回时，又从不可见变为可见。

一开始的思路是“从被遮挡的 View 本身出发”，看看某个 View 被遮挡后，其本身的属性是否会发生变化？

View 内部以is开头的方法如下所示：

我把其中名字看上去可能和被遮挡有关联的方法值全都打印出来了，然后触发 gif 中的场景，观察这些值在触发前后是否会发生变化。

几十个属性，一一比对，在看花眼之前，log 告诉我，被遮挡之后，这些都没有发生任何变化。。。。

绝望。。。但还不死心，继续寻找其他方法：

我又找了 View 内部所有has开头的方法，也把其中看上去和被遮挡有关的方法全打印出来了。。。你猜结果怎么着？依然是徒劳。。。。

我开始质疑出发点是否正确。。。此时一声雷鸣劈醒了我。

视图只可能了解其自身以及其下层视图的情况，它无法得知它的平级甚至是父亲的绘制情况。而 gif 中的场景，即是在底边栏的同级有一个 Fragment 的容器。而且当视图被其他层级的控件遮挡时，整个绘制体系也不必通知那个被遮挡的视图，否则多低效啊（我yy的，若有大佬知道内情，欢迎留言指点一二。）

经过这层思考之后，我跳出了被遮挡的那个视图，转而去 Fragment 的容器哪里寻求解决方案。

Fragment 要被添加到 Activity 必须提供一个容器控件，容器控件提供了一个回调用于监听子控件被添加：

// android.view.ViewGroup.java

public void setOnHierarchyChangeListener(OnHierarchyChangeListener listener) {

    mOnHierarchyChangeListener = listener;

}



public interface OnHierarchyChangeListener {

    void onChildViewAdded(View parent, View child);

    void onChildViewRemoved(View parent, View child);

}

为了监听 Fragment 被添加的这个瞬间，得为可见性检测扩展方法添加一个参数：

fun View.onVisibilityChange(

    viewGroup: ViewGroup? = null, // 容器

    block: (view: View, isVisible: Boolean) -> Unit

) { }