共享数据库不行了，大家还是得靠应用程序自己的数据库才靠谱

“共享数据库不行了，大家还是得靠应用程序自己的数据库才靠谱”这个说法，其实在软件开发领域，尤其是在经历了多年微服务架构实践之后，已经成为了很多技术团队的共识，这背后不是空穴来风，而是用无数次的“踩坑”和教训换来的。

回想一下早期的系统设计，很多公司都喜欢用一个巨大的、中心化的数据库来支撑所有的业务，比如一个电商网站，用户信息、商品数据、订单记录全都塞进同一个Oracle或者MySQL数据库里，当时觉得这样多好管理啊，数据都在一起，查询起来也方便，还能保证所谓的“强一致性”，这种做法，在刘超的《趣谈网络协议》专栏里提到早期系统架构时，虽然没有直接命名，但描述了那种“大一统”的设计思想，即把所有功能模块都紧密耦合在一起，这种数据库就是典型的“共享数据库”。

但这种好日子很快就到头了，随着业务越来越复杂，团队规模越来越大，共享数据库的弊端就暴露无遗了，马丁·福勒在他那篇著名的关于微服务的文章中就尖锐地指出，使用共享数据库是微服务架构中最常见的集成反模式之一,为什么这么说呢？

最头疼的就是“耦合”问题，所有应用程序都像章鱼一样把触手伸向同一个数据库，这就意味着数据库的任何一点小改动都可能成为一场灾难，订单团队为了优化性能，想给某个表加个索引，或者修改一个字段的长度，他们必须小心翼翼地通知到用户团队、支付团队、物流团队，因为谁也不知道哪个程序里的哪段SQL语句会因此崩溃，这就导致了团队之间极高的沟通成本和协调成本，敏捷开发根本无从谈起，任何一个改动都像是“牵一发而动全身”。

是技术选型的枷锁，一旦选择了某个数据库（比如Oracle），它就成了整个系统的“基石”，如果后来某个新业务更适合用MongoDB这样的文档数据库，或者需要Elasticsearch来做全文检索，你会非常为难，把数据从共享数据库里同步过去？延迟和一致性是大问题，直接让新业务也连Oracle？性能可能跟不上，也无法发挥新技术的优势，共享数据库就像给所有应用穿上了一双尺码固定的鞋,谁也别想跑得更快。

是稳定性的“风暴眼”，共享数据库是整个系统的单点，一旦这个数据库因为某个应用的蹩脚SQL查询而性能骤降，或者直接宕机，那么所有依赖它的应用会像多米诺骨牌一样全部崩溃，整个网站或服务可能瞬间瘫痪，这在强调高可用的今天是完全不可接受的，这正如在《企业IT架构转型之道》中，阿里巴巴中间件团队所反思的，传统的烟囱式系统（虽然主要指应用，但底层共享DB问题类似）导致系统间依赖复杂,故障难以隔离。

还有团队职责边界模糊的问题，当数据库是共享的时候，到底谁来负责数据库的优化、维护和监控？是DBA团队？还是每个业务团队？很容易出现“三个和尚没水吃”的局面，出了问题，大家互相推诿,很难快速定位和解决。

正是因为共享数据库有这么多难以解决的问题，应用程序自己的数据库才靠谱”的理念就兴起了，这个理念是微服务架构的核心原则之一，简单说就是：每个微服务都应该拥有自己的数据库，并且只能通过这个服务公开的API来访问其数据,其他服务不能直接来操作我的数据库表。

这样做的好处几乎是直接针对了共享数据库的痛点：

1. 解耦与独立：每个服务团队可以完全掌控自己的数据库，他们可以自由选择最适合自己业务的数据存储技术（SQL、NoSQL都行），可以独立地对数据库 schema 进行修改和优化，而无需担心会“误伤”其他服务，用户服务用MySQL存用户信息，商品服务用MongoDB存商品详情，订单服务再用一个MySQL实例存订单，它们之间通过清晰的API（比如RESTful接口或RPC调用）进行通信，这样一来，团队才能真正做到独立开发、独立部署、独立扩展,这才是敏捷的本质。

2. 故障隔离：如果商品服务的数据库因为一个复杂查询变慢了，那最多是商品浏览功能受影响，用户登录、下单支付这些功能依然可以正常服务,系统的整体韧性大大增强。

3. 清晰的所有权：数据库的维护责任非常清晰，商品数据库挂了，那就是商品团队的责任，他们需要立刻去修复，职责分明,效率自然提高。

这种“私有的”数据库模式也带来了新的挑战，比如如何保证跨服务的数据一致性（需要通过分布式事务如Saga模式，或者最终一致性方案来替代传统的ACID事务），以及如何管理分散的数据查询（可能需要通过API组合或命令查询职责分离CQRS模式），但业界普遍认为，相比于共享数据库带来的强耦合和僵化，处理这些新挑战是更值得的,也是更有成效的。

说“共享数据库不行了”，并不是说这种技术本身被淘汰了，而是指它作为一种系统架构模式，在应对现代复杂、快变的业务需求时，已经显得力不从心，甚至成为了阻碍，而“靠应用程序自己的数据库”所代表的是一种更灵活、更健壮、更易于扩展的架构哲学，它让系统能够更好地适应变化，让开发团队能够更高效地协作,这才是当前更靠谱的选择。