在公司做过搭建自己的微信红包服务和话费服务，这两样东西都有一同共同点，就是利用第三方服务来搭建属于自己的第三方服务。这让我思考着一个简单的第三方服务的搭建应该思考些什么，以便少踩坑。
调用第三方服务
失败重试机制
- 什么怎样的失败是需要重试的
- 重试次数以及重试间隔
- 调用失败，订单号要记录，以便返查
- 严重错误消息通知
调用第三方服务失败的可能性是必然存在的，而重试的意义在于确保那些不是必然失败的能调用成功， 对于那些重试后任然100%失败的，就无需重试了。例如，调用微信商户平台的红包发放接口，对于那些openid错误，发放的微信用户账户异常等错误，即便重试也必然错误，故不需要重试。但是对于，商户账户余额不足，超过红包发送接口请求频率等错误，就必须要重试。
注意第三方服务接口限制
- 频率
- 次数
第三方服务的接口调用一般来说，都会有所限制，一定一定要了解清楚，避免踩没有必要的坑。例如，微信商户平台红包发送接口的限制有: 金额限制，频率限制，个数限制，写代码时需要添加上这些限制，避免大规模的调用失败。
考虑会更改第三方服务的情况
- 确定自己的错误码以及状态码，与第三方服务的错误码和状态码解耦
- 利用接口和多态来进行第三方服务SDK的编写
若第三方服务商是可选的，在做数据模型以及代码的编写时就要考虑更换第三方服务商的情况。这时需要分析与第三方服务耦合的内容有哪些。例如，每个第三方服务都会有自己的错误码和状态码，此时就需要建立将第三方的错误码和状态映射到自己系统的错误码和状态码。当然对于像微信红包发送这样的不可替换的第三方服务，可以不用考虑这些问题，降低复杂度。
自己提供给客户接口
权限,安全与限制
- 接口调用需要签名校验
- 回调给客户的需要做签名, 给客户做签名校验
- 频率，次数的限制
既然是提供给客户调用，必然涉及到身份校验。调用者身份的校验，一般来说是通过key,secret来做签名，必要可以IP，甚至是证书。校验是双向，若提供接口调用的回调，需要提供本服务的身份信息，以便客户进行校验。
结果通知机制
- 提供API查询
- 回调（注意，回调也有重试）
一般来说，提供给客户调用的服务接口的处理是异步的，这意味着结果是延迟才能知道。此时就需要有，结果通知机制。总的来说机制就两种，1. 作为服务提供者主动返回（回调） 2. 服务使用者主动查询(提供结果查询API)
订单号
- 客户提供的订单号
- 自己系统的订单
订单号需要考虑：
唯一性，订单号的最主要的作用是为了查询，故不能重复。
安全性，不要把重要的运营信息（例如交易量）添加到订单号上，以免别人猜到的重要运营信息。
防并发，确保高并发时不会产生一样的订单号（编码中有时间的话，添加上随机数即可）
位数，位数多有助于提高唯一性，安全性，并发性，但稍微订单查询场景难度，比较位数多复制起来比较麻烦
性能，检索性能和生成性能。检索性能的提高可以采用纯数字，数据库的索引和检索效率比文本高。生成性能的提高可以采用预先生成订单，即建立订单池。
常见的订单号生成规则:
- 年月日时分秒微秒+随机码
- 用户标识+年月日+一天内不能重复的数字
