调用三方的注意事项

三方包括什么

狭义上的三方：外部提供的rpc、http接口。
广义上的三方：sdk、存储、消息队列、配置中心等外部团队维护的组件。

为什么要格外注意对三方依赖的处理

归属于外部团队甚至外部公司，相比自身更加不可控，容易出现：
1. 排查问题效率低。需要外部协助排查，效率较低，甚至可能会造成双方互相推卸责任，更加低效。
2. 稳定性不可预知。不清楚具体实现，可能非常脆弱。

注意事项有哪些

编码注意点

必然导致业务功能无法正常使用

仔细阅读三方接口的文档，思考下面4个问题，如有疑问立刻询问对方接口人，不能去猜测应该怎样：
1. 自己的项目能否使用三方提供的调用方式，如http、rpc、sdk。如果无法通过上述方法接入，考虑其他接口或者自行适配。
2. 请求和响应的参数含义是什么，怎么和自己项目中的字段映射上。
3. 调用三方前，需要对哪些参数做校验，确保接口调用的有效性。如根据id查询xx这种场景，id必然不能为空。
4. 三方响应后，如何处理异常。
  1. 需要处理哪些错误码和怎么处理。如确认参数异常的错误码，识别该错误码包装成三方BizException抛出，无须多次重试。
  2. 如果抛超时或者其他未识别的错误，怎么处理。如读接口包装成三方SysException抛出，写接口重试、调用回滚接口、卡住人工介入。
  3. 必填字段没有返回，或者返回预期之外的值怎么处理。如查单据类型没有返回，或者返回了未知的单据类型，包装成三方BizException抛出。

设计注意点

无法处理极端场景，给后续迭代埋坑

扩展性
1. 抽象业务对象，而不是直接使用三方交互的DTO做业务逻辑，避免三方接口切换使用新的DTO对象，整个项目需要大改。如使用DDD设计领域对象和防腐层。
可用性
1. 合理设置超时时间，避免三方接口经常超时。如国内接口默认1s响应，但是调用海外服务，或者国内其他供应商的写接口，可以延长到10s以上。
2. 合理重试，避免网络偶尔抖动的影响。需要注意：
  1. 网络超时可以重试，业务异常单独分析，可能重试没有意义
  2. 下游需要保证幂等，或者能否处理成幂等。读接口天然幂等，写接口需要单独分析，可能需要识别幂等错误码。
  3. 重试次数需要限制，避免过多的重试会造成读写扩散，打挂下游。比如超过3次人工介入等。
3. 合理设置限流、熔断阈值，避免打挂三方。如大流量场景，和三方对齐是否需要限流，设置成多少qps，是否可以熔断，错误率超过多少可以熔断。
4. 制定降级方案，避免主流程被拖挂。梳理强弱依赖，强依赖读请求读容灾存储，写请求异步消息补偿；弱依赖缩短超时时间，如100ms两次重试，或者手动熔断。
5. 监控告警，避免线上故障无人处理。如校验入参异常、未知响应打error，error日志触发告警；除非流量较大或安全要求，打印请求和响应日志，方便排查问题。
安全
1. 敏感信息加密，避免泄露。如用户信息需要加密存储，对公司外部系统加密传输。
性能
1. 批量读写场景并行化。如每批x个配置化，分批请求三方。
2. 合理使用缓存。缓存命中率较高如读写比超过2，数据不经常变更且略微滞后影响不大时，使用本地缓存或者分布式缓存。
3. 异步化请求。无须关注结果，不影响主流程的三方请求，用线程池或者mq异步处理。
伸缩性
1. 原则上不请求具体的ip，避免Ip改动或者增减需要调用方调整。三方只能提供Ip直连的方式例外。