在实际的程序开发过程中，难免会接入一些三方服务，比如用户注册的时候，调用三方的短信服务，又或者是使用微信的账户体系简化注册流程。针对不同的服务，可能注意点会不一样，但是大致都差不多

按照接口的提供者，是否收费我们通常会需要不同的策略去接入这些三方服务

云服务商

通常基础类接口服务，一般各大云服务器都会作为自己的产品去维护，因为这个量大，且有很大的利润空间，比如

• 短消息服务
• 一键登录
• 存储服务
• 消息队列
• 推送服务
• OAuth 服务
• 多媒体服务
• 支付/分账服务
• 直播服务
• …

三方服务商

一般第三方服务通常是一些特定业务情况下的，业务需求没有稳定使用情况，但公司不愿意去对接原始数据，或者原始接入投入太大，所以就会这种负责数据的公司，针对各种业务需求，去接对应的原始数据源，或者是自己研发工具类接口，比如

• 实名信息验证（两 / 三要素）
• 短连接服务
• 银行信息
• 地图服务
• 敏感词过滤
• 二维码识别
• 手机号码归属地信息
• 人脸识别
• …

通常接入的三方服务，大部分都是按量付费使用的，基本没有免费的，因为提供额外的服务通常都是成本，所以及时免费也是要自己折腾，或者是自己去搭建相应的服务，耗时耗力，且不能保证稳定，比如：转码服务，自己是可以搭建，但是如果使用量低，可能覆盖不了服务器本身的成本，且自建很难保证可用性

关于选择云服务的服务还是三方服务的问题，主要考虑三点，稳定性，价格，执行效率

如果是基础服务，比如短信验证码这种属于核心服务，我们应该优先考虑，稳定和执行效率，其次考虑成本问题。
对于要求实时性要求不高，可以考虑价格低的，但是稳定的，就可以不追求执行效率，只用保障在使用的时候能保障出结果的，比如转码服务
对于第三方服务提供的，应该根据实际情况，选择合适服务商，也可以考虑接入多个服务商的同类型的服务，来提高服务的可用性

账单问题

通常基本都是按量收费，不过也 分预付费和后付费额，针对这两张类型的账单，都应该留意购买的额度和账户余额，避免因为欠费或者额度不足导致的服务不可用

巡查账单

• 有些购买的服务有可能存在有效期，比如从购买日起1年内有效
• 业务量激增，导致额度使用过快

留意云服务商的通知 短信 / 电话 / 邮件

• 一般都会提前发送短信，通常收到相关的通知后，就及时处理账单问题

自己加入备忘录，主动处理

• 通过手机系统的待办事项
• 办公软件的备忘录，比如 钉钉/企业微信 的提醒
• 自建 server bot，比如 Server酱 这种

服务质量

执行效率，服务可用性，服务的准确性，基本这三个维度就能衡量这个服务的质量，一般这个问题发生在三方服务商的服务里面，通常云服务商都会针对自己的服务提供 SLA 的方案，或者监控系统，且通常使用量大，一般不存在太差的质量问题，不过针对三方服务，在接入后，应该观察这个服务上面提到3个维度。

执行效率

较为简单，只用按照接入的方式来监控就行了，如果是 Http 接入的，这种较为简单，记录服务调用用的时间就可以了，如果是 SDK 接入的也差不多，都可以直接记录执行时间，只是要注意一点，如果能按照标准 Http 接入的，可以优先使用 Http 接入，因为 Http 协议相对完善，且可以全局记录，监控。

可用性（准确性）

这个就比较难评估了，通常是需要人为去观察数据结果是否准确，比如一个地图服务，这个在上线前和上线后都应该留意，否则可能因为第三方服务的质量不行，导致应用服务的可用性不行

缓存的时机

在接入了三方服务后，我们加入适当的缓存可以有效的提高我们自身服务的服务质量，但是考虑到缓存存在结果的不准确性，我们应该考虑到缓存的有效期和是否缓存异常结果

有效期

针对不同的场景，需要使用不同的有效期，比如已经是一个确定的结果，我们可以考虑使用一个较长的有效期，比如 姓名和身份信息，提取的二维码的结果

是否缓存异常结果

有些情况下，比如三方服务已经提供一个结果后，及时是一个错误的结果，我们也应该将起缓存下来，避免重复执行导致的不必要的花费，或者导致额度被快速使用完后，导致其他用户也无法正常使用了

审计

一般云服务商的提供服务，都提供了完善的调用记录得，主要用于对账和异常处理，所以我们更多关心的是第三方服务的，如果有完善的审计我们可以大致知道一段时间内的使用量，又或者是这个三方服务是否稳定

自建数据聚合平台

这个针对服务较多，且使用大情况下，搭建一套自己的数据平台的确更好，不过应该考虑实际的维护成本和程序的稳定性，因为多了一个中间件了

异常处理

通常第三方接口对外提供服务都会使用 HTTP 的，我们按照对应的接口的规则接入就可以了，但是要注意一点，我们需要考虑接口异常是使用 http 状态码，还是都返回 200，在消息体里面使用 error 的方式，无论使用哪种方式，我们都应该异常的情况捕捉清楚，避免一旦走上了异常后，出现一些未预期的情况，比如没有给客户一个相对准确的提示

是否考虑备用服务，我们可以针对一些高频接口，我们可以考虑接入多个服务商的服务，出现异常的情况，可以考虑使用另外一个服务商提供的服务来顶替。或者在实际工作情况下，就是多个同类型的服务（不同服务商的）可以随机选择，且一个服务异常了就自动切换到另外一个的，来尽可能的提高基础服务的稳定性

总结

本文简单梳理了下，接入三方服务的常见问题，和一些注意点，希望能帮助大家，在接入三方服务的时候，能选择最合适的当前环境下的业务需求