场景设计
场景一（法催）
需要开发一个系统 A，A 系统所需要的数据比较庞杂，需要从 B，C，D，E 系统分别获取不同的数据组装成自己需要的格式，在使用接口的情况下，BCDE 系统的更新，或对接口的修改会导致 A 系统可用性极差，针对这种场景，A 系统如何设计？
BCDE 系统已经开发完成
回答 1:
这个问题应该更多改为 BCDE 应该如何设计。BCDE 作为服务者。应该更多考虑如何让消费者更方便地使用, 而不是让消费者来为服务者的随意设计变更。
BCDE 需要做好：
- 在设计 API 时就尽量考虑好接口签名，尽量避免以后频繁变动。
- 接口传输数据的 DTO 要单独设计，而不是使用持久层的实体类。
- 接口实现变动的，尽量要向后兼容。
- 如果对接口改动较大，为了向后兼容，会让代码可读性和可维护性变差，那么新增一个接口。
- 版本化，如过大量接口，或者整个业务逻辑变动极大，那么新开类似于 v2 这样的版本号。
版本化常见方式有：
- 虚拟路径：api.domain.com/v1, api.domain.com/v2, …
- 域名：v1.api.domain.com, v2.api.domain.com, …
问题：
在 BCDE 已经开发完成，或者旧的系统的情况下，对 BCDE 重新设计并不简单。
场景二（CRM）
A:呼叫中心，B:大数据，C:贷后其他系统
现有公司 A 系统对接第三方公司，BC 系统也对接第三方，但是第三方将所有处理结果统一回调到了 B 系统，且 B 系统只建立手机号与结果的对应关系且保存落库，这种情况下，A 系统如何获取第三方处理结果？
B 系统目前仅支持 dubbo 接口，kafka 推送两种模式，在解决时暂不考虑。
方案 1：
B 系统提供接口，A 系统定时通过接口拉取自己需要的数据。
问题：
通过接口拉取数据，无法保证实时性。本场景对实时要求较高。
方案 2:
通过 kafka，B 主动向 A 系统推送数据，推送 A 系统需要的数据。
问题：
B 系统仅仅只做了，手机号与第三方结果的保存，无法主动识别该数据是否是 A 系统所需要，或 C 系统的需要。加区别字段，对 B 系统改造较大，且由另外对开发人员维护。