04 系统面临的现实问题：第三方客户系统的对接耦合性太高，经常出问题

1. 第三方：客户物流系统

明确一点，下订单之后，大部分核心步骤，都是在本公司的系统内完成，如订单状态更新、库存扣减、优惠券派发等。

而其中下单并支付成功后的发货是交由第三方仓储系统负责的。具体流程如下：

调度流程：下单后，选择去找一个距离你用户最近的一个仓库，然后从里面调度一些商品进行发货，在发货的时候还需要调用第三方物流公司的系统，通知物流公司去仓库里取货发货。

2.系统间的耦合

什么是耦合？

以上图中圈红的部分为例，负责订单系统的工程师下单成功后，调用促销系统的接口来发放优惠券。负责促销系统的工程师对接口定下接收5个参数就能调用这个接口。此时我订单系统的工程师就把需要的5个参数传过去了，成功调用了发放优惠券等的接口功能。有一天，促销系统的工程师修改了接口参数为7个，而我依旧用原来的5个参数去调，然后调度失败，也无法派发优惠券了。这时候，订单系统的工程师就必须修改对应调度的代码按照对方要的7个参数去调用接口。这种场景就说明了订单系统和仓储系统是强耦合的。促销系统接口的一点更改，就会让我订单系统跟着去改，去配合。这便是系统间的耦合。

订单系统与第三方物流系统的耦合：

订单系统通知仓储系统发货，而仓储系统则生成物流单通知第三方物流系统取货，而订单系统必须等待物流系统返回确认信息之后，仓储系统返回结果后，才能结束对仓储系统的调用。这一过程中，仓储系统直接与物流系统耦合，而订单系统与物流系统间接耦合了。

耦合带来的问题

第三方是不能完全信任的，它随时有可能出现意料之外的性能变差、接口失败的问题。

比如：假如你调用它的接口，结果它的接口有时候很快只要20ms，有时候很慢要200ms，或者有时候会调用失败几次，那么会怎么样？

这种时候，它的性能降低了，我们的系统性能也随之降低了，它耗费200ms甚至更多，那我们是不是要耗费1s以上，用户体验能好吗？再者，它的接口调用失败会直接导致我们的这次操作也失败，为此还要添加重试机制或者服务降级等，不然客户看到页面报了500，会很懵的。

总结： 第三方接口的固化是一种严重耦合。实际案例：朋友做营销类项目，有一个下单对外api接口（post,入参是json），给多方用，但是有一方的请求方式固定，也不肯改，他们发起的post请求传参是form-data。我朋友表示，这很淦。^_^

解决方案：电商小程序项目给出的解决方案是：第三方调用接口变化，采用v1、v2、v3接口版本，每次更改都保留旧版。