搭建与外部交互的业务系统，我们会发现将许多无法捉摸的状况，例如事务特性无法维护，远距离系统的响应时间相对比较长，对方系统的处理效率可能无法得到保证，等等。
相对于内部交互的系统来说，很多东西无法由内部的协调方案（例如一个专用的分布式事务协调器来解决分布式事务的问题）来解决。
把与外部接合的点抽出来单独形成一套体系，做成所谓的“网关”，负责整体的接入业务，隔离内部系统与外部系统之间复杂性。
对于事务特性的问题，我们考虑本地单库事务处理的时候是最简单的，直接可以依赖于DBMS，如果业务的量达到一定级别出现了分库的情况，我们必须考虑使用独立的事务协调者来保证分布式事务的能力，事务的特性以及出现错误之后的容错能力就封装在事务协调器中；但当业务的完整性必须依赖外部系统时，我们的协调器如果不能协调外部系统的提交或者回滚操作，它就不能升任维护事务最基本的原子性的责任，那么我们可能通过细分业务状态的形式来尝试解决这个问题。把一个请求拆分成多个阶段，每个阶段给以一个表示，做之前、做完后，甚至是正在处理中都可以打上不同的状态标记。
容错机制使用任务调度系统不停地对业务系统发起轮询，检索出需要恢复的异常业务，并根据对方系统不同（是否能保证业务处理的幂等性等），来决定重复发起交易请求还是查询请求。由于执行恢复过程中调度线程必须对正在操作的记录执行锁定操作，而且必须保证容错恢复机制不能影响正常业务数据的流转，因此并发和死锁的问题必须慎重考虑。
与外部系统接口之间的沟通方式我们可能没有太多的选择，保证非长连接应该是最基本的，在这种情况下同步还是异步都可以选择。初期实现以同步的方式进行会比较简单，但对于耗时较长的情况下仍应该提供异步通知的机制，否则系统会对用户体验和系统吞吐量都造成太大的影响。根据实际监测到的情况看，对于某一业务，从杭州到深圳的物理距离下作一次请求，建立相对复杂的https连接，包括双方网关和业务各级系统的处理时间，耗时能达到2秒以上，恶劣的情况下的某些业务平均调用事件甚至达到了5秒。对于一个业务必须多次请求的情况，要么采用异步通知的形式进行（当然会增加系统复杂性），提供通知接口，外部客户系统完成处理之后通知我们的应用处理结果；要么可以在业务设计时把这种耗时操作分发到用户操作流程的各个点上去，这样拆分之后也可以在系统维持简单的同步模型的情况下减少用户在单一操作过程中的等待时间，也能够提升用户体验。