跨公网调用第三方接口的服务层的思考

跨公网调用第三方接口的服务层的思考

问题

前日有幸拜读了架构师之路的58沈剑所写的 跨公网调用的大坑与架构优化方案 一文。文中，作者提到了一个很值得思考的问题：

如何设计一个为内部系统提供跨公网第三方接口调用的服务层，才能避免因部分接口问题导致整体失效的问题？

问题的具体描述请参见原文。

在看到问题后，我先试着想了几个解决方案。

我的解决方案

1. 对于每次接口调用，都记录其响应时间，并对服务层内每个接口求出其平均响应时间。
2. 对于每个接口，根据其平均调用时间，设置其可用工作线程数的阈值，保证当接口出现异常时，不会影响到所有工作线程。
3. 当接口相应时间明显超过其历史平均响应时间时，动态降低此接口的可用线程数量。
4. 当接口的异常状态持续一段时间仍未恢复时，停止为该接口提供服务，改用对进行轮询的方式，来保证当其恢复可用后可以迅速恢复对该接口的服务。

文章中给出的解决方案

1. 增大工作线程数、降低超时时间、拆分接口和服务层（治标不治本）。
2. 对于可以接受非实时数据的内部系统调用方提供异步代理，对其屏蔽具体细节。即缓存外部接口调用的返回结果，对内部调用方直接提供对应的缓存结果，并定期调用外部接口来完成数据的更新。
3. 对于可以冗余的外部接口，保证其冗余性，在主接口调用失败后迅速将服务转移至备份接口。
4. 对于是向外部接口推（主动同步）数据而不是拉数据的业务场景，先同步写本地数据库，本地写成功后对内部调用方返回调用成功的消息，其后异步地向第三方接口推数据。

我对自己的反思

1. 解决方案局限在一个具体的技术实现思路上（限流、动态规划），考虑太窄，没有结合实际的业务需求分析可行性。目前还停留在解决具体技术问题的阶段，看山只是山，应该努力培养自己的宏观思维。
2. 我提出的解决方案需要直接操作服务容器的线程调度，难度大，技术可行性也未知。
3. 因为我的计算机网络相关从业背景，我在思考过程中受到各种网络协议的设计思路影响很大（比如IP SLA探针、GLBP中的各种权重判断等），这点我认为在我的程序设计思维中可能会让我持续受益。虽然现在已经不从事网络相关行业了，但是也应该保持住网络工程师对于系统稳定性、可用性、扩展性的不懈追求。