一 背景 

来自一个用户匹配的需求。用户的不同信息分布于两个系统，且客观上无法直接打通（不必纠结具体是什么场景，这是真实存在，且非技术上能解决的），所以就涉及到两个系统 id 匹配的问题。

先抽象问题：系统 A，系统 B；系统 A 中存在一个用户 a（字段：a_id, a_img, a_name）， 系统 B 中可能有 a 的补充信息（字段：ab_id, ab_img,ab_name），

目标：如果 B 中存在用户 a 的信息，那么希望能找到并进行匹配，并把匹配结果返回系统 A，结果格式：a_id, a_img, a_name,ab_id。

一些前提：首先由于必要信息从外部服务进入系统 B 不是实时的，这里就存在一些延迟，所以上述的匹配率数据，允许有一定的时间延迟，预期是最终的匹配率/绑定率达到预期水平。

二 问题详细描述

字段说明：

1）a_id 用户 a 在系统 A 的 id；

2）a_img 用户 a 在系统 A 的属性图片链接，注： a_img 和 ab_img 虽然都是用户 a 的图片链接，但可能链接并不相同。例如 a_img: http://sysa/a1.jpg，ab_img：http://sysb/b2.jpg

3）a_name 用户 a 在系统 A 的属性昵称；

4）ab_id 用户 a 在系统 B 中的 id。

两个系统中的图片，正常情况下，img 内容是相同的（链接可能不同）；或者是缩略图关系； name 通常不会修改，但存在多个用户昵称相同的情况。

这两个属性是判定两个系统中的用户是否是同一个的主要依据。

三 匹配策略

注：以下只是项目初期的简化匹配策略。因为数据特性，经过统计和特征分析，验证准确率可以达到预期，所以初期不会为百分之几的优化投入过多资源和精力。所以不必纠结策略的准确率

1、首先通过昵称匹配

    当系统 A 的用户昵称，与系统 B 的有且只有一条记录昵称相同时，将这两个记录匹配 【根据真实数据经验，用户进入两个系统记录的时间规律，并允许较低的错误率；支持人工修复】；

2、当系统 A 的输入记录，与系统 B 的多条记录昵称相同时，继续判断图片内容。这里的判断步骤设计如下：

2-1 分别拉取 a_img 和 ab_img 的图片内容（字符串），如果内容相同，那么确定是同一条记录，记录匹配关系；

2-2 如果内容不同，计算两张图片的相似度（汉明距离）。当相似度大于指定阈值时，认为二者匹配，记录匹配关系

四 系统交互流程

系统 A 与 B 的交互设计如下图所示，注：系统 B 下又分为任务服务、web 服务、api 服务三个子服务。

五 计算资源管理

可以看到，这里可能会有一个比较耗费资源的动作，就是需要匹配图片内容时。我们要拉取图片内容、字符串直接比对、简化特征、计算汉明距离，而当这个计算逻辑被并发调用的频率很高时，所需的带宽、计算能力都有可能成为瓶颈。自运维就需要解决峰值问题，或强制限制调用频率。所以采用函数计算来做弹性支持。

另外，为了减少重复的图片拉取动作，降低流量消耗，且绑定数据存储在系统 B 中。那么我们先完成系统 B 内 img 的内容拉取，和特征提取工作，对于一个新的匹配请求，我们只需要拉取 a_img 的内容并特征提取就可以了，减少了近一半的工作。

六 上线后出现的问题及优化

项目上线后，我们持续观察了一段时间，发现函数计算调用次数过高。官方的计价标准，每月全地域免费资源使用量：40 万 GB-S。正常情况下，可以控制本业务的调用量在预算范围之内。但实际线上的调用发现，短短几天就快到达收费门槛，这显然是不符合预期的。

为什么会造成这个问题？是真实的调用需要，还是有重复调用导致额外开销？这点需要先排查清楚。

首先查看匹配结果数据，发现线上 A、B 两个系统用户匹配率低于预期，这就导致有一些用户在系统 B 内找不到可以绑定的 ab_id；而执行中发现，系统 A 触发绑定计算的时机是在用户进行微信登陆的时候，而且有会多次调用；预期借此提高最终匹配率（因为有些信息可能会更新，或延迟获取到，当信息补全时，是有可能匹配上之前计算时没能匹配的用户的。这也是一个客观前提）。但这带来的问题就是，会导致多次不必要的重复计算，至少在信息更新前的一段时间内是。

为了解决上述问题，补加了一个输入用户 id，在一个周期内不再重新计算的限制。因为绑定率/匹配率看中的是最终数据，所以能够接受一定的时间延迟。策略上线后进行了一周观察，确定在没有降低匹配率的前提下，计算量大大减少，而减少下来的这些计算资源，就是实实在在的真金白银。

七 未来优化方向

目前，项目已经上线运营一个月的时间，观察服务正常，未来继续在调用量优化、匹配准确率、召回率提升几个方面进行深入优化。