最近在很多场合都听到探探这样一款App：云栖大会、微服务案例分享、脱口秀大会等等，老司机们一定知道我在说啥，作为国内版的Tinder，它在系统设计上还是借鉴了许多老大哥的想法。
探探的功能可以简单概述为四个部分：用户配置文件管理、个性化推荐匹配、配对服务和实时消息服务。简单地说个人配置文件就是每个用户的介绍，主要存储的是用户照片或视频，毕竟人类是视觉动物，尤其是对于第一印象，照片的上限是9张；推荐服务根据筛选条件（性别，年龄，距离，爱好等）从活跃用户中推荐匹配者；配对服务即双方都有意向，对方将进入自己的匹配用户名单，即服务端的通讯录列表，男性的匹配成功率在0.1%，即每一千次右划能配对成功一次，当然这也看头像和区域哈（当然女性玩家会高出几百倍）；最后是实时通讯服务，即点到点即时聊天，不能添加第三方更不能组群^.^
好了，先说第一项功能，探探的客群还是以大陆地区为主，即便如此，图片和小视频的存储量也是相当惊人的，如何确定这些对象在服务端的存储方式，究竟是用文件还是块存储呢？相对于文件存储，块存储的优势在于以下三点：
- 易编辑：块存储的表结构可以方便用户提取任意数据块进行编辑；
- Transaction保证：变更需要commit并确认操作成功；
- 索引功能：可以提升搜索效率。
- 便于做访问控制
平心而论，照片一般作为一个整体文件被添加或替换，所以前两个特点的应用场景并不多，而且在实际操作中，很少有用户会给照片添加各种元数据（拍摄时间，地点，圈头像等等），甚至连照片名字都是一串数字，常规搜索都词不达意，更别说特征搜索了。因此看起来唯一有用的功能只剩访问控制了。我们再来看看文件存储的优势：
- 便宜
- 访问迅速：不需要遍历表把所有数据块拼起来，一般只需要建立用户--图片--存储位置的单表就可以了。
- 可通过CDN进一步提升访问速度，CDN可以很好地缓存多媒体文件。
下面进入我们的正题，首先我们该如何对用户的配置文件进行微服务拆分？主要考虑有以下几点。
- 用户访问配置文件（记录用户的基本信息，昵称、地区、爱好等等）需要提供秘钥（为提高安全级别可以将密码替换成令牌），如果我们直接将配置文件与用户对接，那势必别的服务都需要与配置文件建立连接以获取验证信息。但很多情况是不必要的，例如即时通讯跟用户的配置文件毫无关系。基于此我们需要建立一个应用网关服务，专门用来核实用户身份。
- 配置文件是否要和用户的照片库关联，目前看来似乎只有进入用户账号才能看到该用户的照片，但是从长远来看，不排除会将所有照片进行AI分析，以开发更多客群服务，所以这部分在实际操作中，探探还是将其拆分了。
因此配置文件拆分后的微服务就如下图所示。
配对服务的业务逻辑是，如果你喜欢我，我也喜欢你，双方就加入到各自的通讯录里，不然你就再也不会浏览到该用户。用户的配置文件跟配对服务没有关系，配对数据库只记录任意通过验证的两个ID之间的双向选择关系，一旦双向选择了，就配对成功，当然如果一方取消配对也会实时地删除双方通讯录。因此可以简单理解为下面的微服务架构。
关于即时聊天服务，小编已经在微信的微服务中介绍过了，这里需要注意的是HTTP是客户端到服务端的单向通信服务，作为即时通讯来说，不可能让用户每次登陆才能查看到未读消息，因此这里需要建立XMPP通讯协议来使服务端可以主动发消息给客户。
综上所述：探探的微服务从前至后包括了：网关服务、配置文件、图片库、配对服务、全网配对数据库（由于数据量的关系，这部分很可能对数据进行了切片，将不同地域的用户放在不同地区的数据库里）、会话服务、会话数据库、消息数据库。
各位观众如果有想了解的互联网公司的架构，可私信小编，我们可以一起探讨一下。
