话题来源于和某同学的交流，他说自己的系统 A 需要调用 B 系统中的数据，然后开发给的方案是直接连接 B 系统的数据库。我也不知道是哪位高人想出的方案，以为只是临时的方案。结果他和我说，他们线上也是这么做的。
01
随着业务复杂性的增加和微服务的流行，越来越多的应用系统开始进行分布式的设计和部署。系统由原来单一的技术架构变成面向服务的多系统架构。原来在一个系统之间可以完成的业务流程，通过多系统之间多次交互来实现。如果是上下游依赖的数据，直连其他业务的数据库，会有什么不妥的地方呢？笔者认为会有以下 4 点缺陷：
表结构变更带来的问题：由于是对方的业务系统，当因为业务需要，对方变更表结构时，不太可能及时通知到己方，那么自己的系统就有可能在没有升级的情况下，出现错误，导致业务上的失败。如果通知了，己方还要被动升级，也是很麻烦的，造成了强依赖。
数据库的性能问题：原则上，自己的数据库只有本方应用可以调用。这样可以很方清晰地控制调用频率，但是现在数据库有第三方在调用，而我们又无法从系统上控制别人的使用频率，如果对方调用的频率太高，引发数据库连接数不够用，会影响到自身的业务。同时，还可能造成数据库锁表的问题，当你发现有锁表现象出现，然后根据 SQL 的 ID 在己方的系统中又查不到相关记录，是不是会很崩溃？
留痕问题：在系统中的操作，我们都应该做到有据可查（可以设置日志级别，但不能没有），以便在发现问题时，可以及时定位。但是对方是直连数据库的，如果对数据做了修改，自己都不知道，也无从查证（自己的日志里没有，但数据又被改了，你崩溃不）。虽然我们可能只会提供只读的权限，但也是存在风险的。
安全问题：安全性应该是第一位被考虑到的，但是现在数据库一般都是在内网，配置基本上也做了分离，所以危害性也没那么重要了。但也不能不考虑。
基于上以原因，笔者认为，一个成熟的开发，就不应该采用这类方式来获取上下游的数据。
02
那么，在实际的应用场景中，服务或者系统之间，应该采用什么方式来解决数据交互的问题呢？常见的一般有三类：接口、文件和消息队列。
接口交互：这是最常见的交互方式，现在的微服务，基本上都是基于 RPC 协议和 Rest 协议，双方定义好数据交互的格式，就可以了相互通信了。从业务层面来讲，通过接口，可以更好地描述业务诉求是什么，为了解决什么问题。同时，接口也屏蔽了系统内部的实现细节，调用方只关系自己需要的内容，只要出入参数不变，内部如何重构，都是可以的。
文件共享：在传输大量的数据内容时，接口就会有问题，比如连接超时、网络占用过高等。这种情况下，我们就需要用到文件共享。A 系统把数据处理好，按照规定的格式生成文件，然后放到中间的文件服务器上，B 系统在另一个时间段根据规则从文件服务器上获取这份数据，并解析处理。笔者在之前处理医院系统的数据时，就是这么做的。医院在晚上 11 点把当天的数据处理好，并上传的文件服务器上，我们的系统 12 点再从服务器上获取文件，并做数据的处理（大约是 2G 左右的数量，如果走接口，不合适）。
消息队列：这个也是现在被大量使用的交互方式。对于可异步处理的业务，通过 MQ 来理最合适不过了。即可以做到业务的解耦，也可以在高峰期起到削峰填谷的作用。现在常用的 MQ 中间件有 Kafka、RabbitMQ 等。
03
不同的数据交互都有自己的优缺点和适应场景，直连数据库当然也是一种处理方式，但是在明显有其他更好的选择下，直连的缺点就会被放大，现在基本上也不建议这么做了。从测试的角度来看，直连可能是最简单的测试方式了，直接改数据库多直接。其他的几种方式，需要有额外的手段去保障，同时，对于测试数据的构造，也提出了更多的要求。对于这种依赖数据，如何处理，之前也讨论过，可参考：模拟数据在实际场景中的应用（ https://testerhome.com/topics/33341）
真的会有人这么搞么.....表怀疑...
不会是标题党吧
个人觉得，这么说太笼统了，也有一些想当然，以下是一些想法：
- 怎么叫别人的数据库？ 数据库都是公司的，还能是别人的？
- 微服务是可能是按照领域划分，这个是逻辑概念，一个数据库，比如 postgresql，可以有很多 schema 的，共用一个数据库，但是使用不同 schema，这样数据库是别人的也是自己的，那开发肯定要直连数据库的
- 数据库性能问题可能也只是猜想，性能问题都是相对的，你有多少访问量数据之后才好说性能问题
- 访问日志的问题，最可靠的访问日志不是写到日志，是在数据库里记录，自己数据的变化没有记录，不能怪数据库不行，日志级别修改这个也不能说服人，一旦你发现数据改了，然后再把日志级别调整，这有用吗？改都改过了，日志没记录，还查什么东西？再试一次看日志？那再试一次看数据库不是也行吗？
- 文件一般都不用数据库存储的，文件很大，实际上传输会不可靠，未必会比数据库好用；医院这个例子很明显这个文件方式本身就不好，数据实时性很差，万一晚上数据处理出错，那可能得拖延 1-2 天，用文件传输，是异步处理，异步处理方法多的很
- 消息队列，添加新的组件，会增加开发成本，这都是衡量出来的，另外使用消息队列了，那谁是消息的发起方，谁是消费方呢？ 你要完成自己的需求，却要别人组帮你完成原来不需要做的事情，别人也未必为答应
我感觉可能有点太喜欢吐槽别人的方案了，但是自己其实也没想清楚，为什么不行？有什么好处，有什么坏处？这个方案需要再多久内解决？这些都是采用方案的变量，可能还有更多，脱离了实际情况的变量，存粹讨论方案，很难说就是别人的方案不好。
感谢回复，欢迎讨论。
“别人的数据库”：这个指的是不同系统间的数据库。比如统一认证系统与商城系统，只有业务上的关联，程序上是相互独立的。直链的场景是：商城系统的登录不走统一认证接口，而是直接访问认证系统的用户信息。
关于第 4 点日志的问题：如果是别的系统直连数据库，数据的修改只能从 Binglog 日志中去看。比如，商城系统修改用户信息，直接连接认证系统的库 update，那么对于认证系统来说，就是不可控的。日志级别是系统发布的时候就统一规定好的。这个也是基本的规范。如果页面有操作而在日志里找不到，那是日志的问题。
3.
关于文件存储，有自身的应用场景，这个不做过多讨论，它有你说的缺点，也有自身的优点，对于时效性不强的场景，完全可以这么做。
4.消息队列的使用，如果这个都会增加太多的开发成本。那只能说明团队能力的问题。这已经是业内非常成熟的方案了。谁发起谁消费？这个还需要讨论么？建议你学习下 MQ 相关的内容。
5.不是吐槽对方的方案，不论是从业务角度，还是技术角度，直连别的系统的数据库，就是个非常不成熟的方案。如果你觉的这个方案好，也可以采用。从我自身的观点来看，这个是架构师没做好。
我感觉我们公司的开发就是这样设计的，不同项目之间是直连的，确实也出现了很多的问题 。但是貌似就没人动手修改
可以，公司能赚到钱怎么搞都是对的，赚不到连呼吸都是犯罪