一 背景

   来自一个用户匹配的需求。用户的不同信息分布于两个系统，且客观上无法直接打通（不必纠结具体是什么场景，这是真实存在，且非技术上能解决的），所以就涉及到两个系统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，在一个周期内不再重新计算的限制。因为绑定率/匹配率看中的是最终数据，所以能够接受一定的时间延迟。策略上线后进行了一周观察，确定在没有降低匹配率的前提下，计算量大大减少，而减少下来的这些计算资源，就是实实在在的真金白银。

七 未来优化方向

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