直连别人的数据库，靠谱吗

话题来源于和某同学的交流，他说自己的系统A需要调用B系统中的数据，然后开发给的方案是直接连接B系统的数据库。我也不知道是哪位高人想出的方案，以为只是临时的方案。结果他和我说，他们线上也是这么做的。

01

随着业务复杂性的增加和微服务的流行，越来越多的应用系统开始进行分布式的设计和部署。系统由原来单一的技术架构变成面向服务的多系统架构。原来在一个系统之间可以完成的业务流程，通过多系统之间多次交互来实现。如果是上下游依赖的数据，直连其他业务的数据库，会有什么不妥的地方呢？笔者认为会有以下4点缺陷：

表结构变更带来的问题：由于是对方的业务系统，当因为业务需要，对方变更表结构时，不太可能及时通知到己方，那么自己的系统就有可能在没有升级的情况下，出现错误，导致业务上的失败。如果通知了，己方还要被动升级，也是很麻烦的，造成了强依赖。

数据库的性能问题：原则上，自己的数据库只有本方应用可以调用。这样可以很方清晰地控制调用频率，但是现在数据库有第三方在调用，而我们又无法从系统上控制别人的使用频率，如果对方调用的频率太高，引发数据库连接数不够用，会影响到自身的业务。同时，还可能造成数据库锁表的问题，当你发现有锁表现象出现，然后根据SQL的ID在己方的系统中又查不到相关记录，是不是会很崩溃？

留痕问题：在系统中的操作，我们都应该做到有据可查（可以设置日志级别，但不能没有），以便在发现问题时，可以及时定位。但是对方是直连数据库的，如果对数据做了修改，自己都不知道，也无从查证（自己的日志里没有，但数据又被改了，你崩溃不）。虽然我们可能只会提供只读的权限，但也是存在风险的。

安全问题：安全性应该是第一位被考虑到的，但是现在数据库一般都是在内网，配置基本上也做了分离，所以危害性也没那么重要了。但也不能不考虑。

基于上以原因，笔者认为，一个成熟的开发，就不应该采用这类方式来获取上下游的数据。

02

那么，在实际的应用场景中，服务或者系统之间，应该采用什么方式来解决数据交互的问题呢？常见的一般有三类：接口、文件和消息队列。

接口交互：这是最常见的交互方式，现在的微服务，基本上都是基于RPC协议和Rest协议，双方定义好数据交互的格式，就可以了相互通信了。从业务层面来讲，通过接口，可以更好地描述业务诉求是什么，为了解决什么问题。同时，接口也屏蔽了系统内部的实现细节，调用方只关系自己需要的内容，只要出入参数不变，内部如何重构，都是可以的。

文件共享：在传输大量的数据内容时，接口就会有问题，比如连接超时、网络占用过高等。这种情况下，我们就需要用到文件共享。A系统把数据处理好，按照规定的格式生成文件，然后放到中间的文件服务器上，B系统在另一个时间段根据规则从文件服务器上获取这份数据，并解析处理。笔者在之前处理医院系统的数据时，就是这么做的。医院在晚上11点把当天的数据处理好，并上传的文件服务器上，我们的系统12点再从服务器上获取文件，并做数据的处理（大约是2G左右的数量，如果走接口，不合适）。

消息队列：这个也是现在被大量使用的交互方式。对于可异步处理的业务，通过MQ来理最合适不过了。即可以做到业务的解耦，也可以在高峰期起到削峰填谷的作用。现在常用的MQ中间件有Kafka、RabbitMQ等。

03

不同的数据交互都有自己的优缺点和适应场景，直连数据库当然也是一种处理方式，但是在明显有其他更好的选择下，直连的缺点就会被放大，现在基本上也不建议这么做了。从测试的角度来看，直连可能是最简单的测试方式了，直接改数据库多直接。其他的几种方式，需要有额外的手段去保障，同时，对于测试数据的构造，也提出了更多的要求。对于这种依赖数据，如何处理，之前也讨论过，可参考：模拟数据在实际场景中的应用