随着业务发展和规模不断增长，不可避免的，企业内部系统会不断增多。系统增多后，系统内部的交互肯定是不可少的。但是，如果系统间交互的接口设计不当，会使企业内部各个系统耦合紧密在一起，维护成本高，甚至，经常bug不断。鉴于此，我根据以往的一些经验，总结了一些系统间交互的原则，列在下面，供大家参考：
1.系统职责单一明确
2. 资源的状态转移（或服务提供和调用）使用同步接口，业务事件发布使用异步消息
3. 接口提供方或消息消费方保证接口幂等性；接口调用方需要根据具体情况考虑容错
4. 升级同步接口时，如果接口协议有变更，尽可能扩展接口，而不是改变原有接口
5. 异步接口应包含业务唯一编号，生产和消费消息记录日志
以下是对每条原则进行详细阐述：
1.系统职责单一明确
面向对象设计原则中有一条是职责单一原则（SRP：Single responsibility principle）。顾名思义，就是一个类或对象只能有一个职责，只能因为一个原因而改变。将这条面向对象的设计原则延伸一下，应用于系统设计，我认为也是非常必要的。职责单一的系统，在自己职责边界内是高内聚的，不会将自身业务扩散到边界之外（也就是其他系统内）；同时，对外暴露合适行为和粒度的接口，也更容易降低与其他系统的耦合性。
严格的说，这一项不算是系统交互的原则，属于系统设计原则。之所以第一条就列出，是为了彰显其重要性。只有这条原则遵循好了，系统间的交互才不会混乱，才有可能设计好系统之间的交互接口。如果系统职责不明确，各个系统定位模糊不清，或者且相互重复，系统之间的交互也会变得越来越复杂和混乱。
因此，这是系统设计中很重要的一条规则，虽然理解起来很简单，但要切实执行却非常难。一方面，前期系统的定位往往比较粗糙；另一方面，系统的定位会随着业务发展和系统的演化不断变化，因此，系统也要随着发展不断重构和调整。要做到这一点，一方面需要敏锐的洞察力，能够清晰准确的对系统定位和划定边界；另一方面，需要有坚定不移的执行力，不因为外界的压力而改变初衷；同时，也需要能随机应变，顺势调整，不断权衡利弊，及时调整系统的定位和目标。这一点，需要大家谨记在心，不断努力。
2.资源的状态转移（或服务提供和调用）使用同步接口，业务事件发布使用异步消息
关于使用同步接口，还是使用异步消息，往往仁者见仁智者见智，存在的争议比较大。不过也有一个普适性的原则可以遵循。以我个人的经验，总结了这一条原则。
一个系统从大的业务目标来说，一般就是维护某些资源或者提供某些服务。如果系统以restful风格提供资源，该系统的核心资源需要以rest接口方式暴露出来，这时，毫无置疑的，应该使用同步接口。其他系统要获取该系统的资源，自然需要同步调用rest接口。如果系统是SOA架构，对外提供某些业务服务。一般情况下，最简单直接的方式也是提供同步的服务接口。这两种情况都没什么疑问，也没有必要使用异步消息。
不过，异步消息有异步消息的优势，在很多业务场景非常合适。异步消息通信好处是能够实现系统解耦、提高系统吞吐量、系统的并发的削峰、系统的自治等目标。因此，在设计多个系统交互的业务需求方案时，最好能基于事件发布模式，尽可能使用MQ消息通信。当系统发生某个事件（如客户还款、资金方放款、用户注册了账号等）时，则发布一个MQ消息，消息中尽可能全面包含事件发生的主体、客体、时间等信息。这样，凡是关注该事件的系统都可以订阅该主题消息，并作出自己职责范围内的业务操作。
一种不太恰当的设计思路是将异步消息设计的针对性很强，比如一个消息只针对于特定的接收系统，完成具体的业务目标，类似于一个服务的异步调用。这样的接口设计，其实并没有最大地发挥出“用异步消息实现系统间解耦”的目标，反而增加了系统交互的复杂度。设计类似系统交互方式的时候，需要多斟酌斟酌，是否真的有必要这样做。
3.接口提供方或消息消费方保证接口幂等性；接口调用方需要根据具体情况考虑容错
在分布式系统的交互，不像单个系统内部的方法调用那么稳定。分布式系统通过网络进行交互，很容易遇到网络不稳定、系统发布、系统bug、宕机等情况。在遇到这些情况时，其他上游系统或网络重试调用是很常见的容错措施。因此，一个系统对外暴露接口时，一定要保证接口的幂等性。这里我们简单地补充一下幂等性概念，在http/1.1规范中定义如下：
Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.
从定义上看，HTTP方法的幂等性是指一次和多次请求某一个资源应该具有同样的副作用。即使我们提供的接口不是http协议的，幂等性的概念也是一样的。从这里我们可以看出，方法的幂等性主要是为了防止客户端重试对数据产生副作用，产生重复提交的问题。
调用方在调用一个接口时，也一定要了解清楚接口的幂等性、安全性等特性，根据业务需求制定容错方案，尤其是与外部系统交互时，一般的容错方案如下：
- 接口是幂等性接口，调用方可以重试3次，如果调用依然失败，要通知运维人员，人工干预
- 如果对方接口不支持幂性，千万不要重试，防止重复提交，可以将信息反馈给用户，同时通知运维人员，人工干预
而对于异步消息通信，道理也一样。作为消息消费方，也一定要注意消费消息的幂等性。如果稍不注意，当出现一些网络抖动的情况下，很多消息中间件会重发消息，必然会出现消息重复消费，业务错乱的情况。
至于实现接口的幂等性的方法，有很多种实现方式，比如token、乐观锁、悲观锁、分布式锁、状态机等等。大家可以在网上查查，根据不同的业务场景，选择合适方式，这里不再赘述。
4.升级同步接口时，如果接口协议有变更，尽可能扩展接口，而不是改变原有接口
只要业务不断发展，就存在业务需求变化；而只要需求变化，我们系统对外提供的接口就很可能会受影响。如果只是接口的实现发生变化，而接口对外的承诺也就是接口的规约没变，一般不会对调用方的代码和系统行为产生影响。而如果系统规约需要变化或升级调整，就不可避免对上游系统产生影响。为了降低对上游系统的影响，我们在升级接口规约的时候，最好是新增一个接口，而原有接口依然保留，这样可以避免使用该接口的上游系统报错或被迫升级。当然，维护多个版本的接口也是有很大成本的，我们可以给定一个接口的废弃截止日期，给使用老接口的系统一个过渡期来安排迭代升级。尽量平滑过渡，使影响降到最低。
5.异步消息应包含业务唯一编号，生产和消费消息记录日志
与同步接口的交互方式相比，异步消息一般需要引入第三方的消息中间件——MQ（比较流行的如RocketMQ、RabbitMQ、Kafka等），这样也会增加系统的复杂度，一旦出现问题，排查起来也会比较困难。为了能够快速排查和解决问题，我们在使用异步消息通信时，最好能遵循本条原则。发送的消息中至少保含一条业务唯标识信息，如订单编号、客户id等；与此同时，无论是消息生产者，还是消息消费者，一定要记录日志。这样，我们可以在日志中快速定位到指定的消息，便于快速定位和解决问题。
