面试夺命三问之《为什么微服务不能共享数据库？》
引子：今天面试一位候选人，候选人描述他做的项目，使用了微服务化的设计理念，业务差分成多个微服务，但是服务之间共享一个数据库，于是就有了这样的一个问题探讨。
所谓多个服务共享数据库，其实有两种类型：共享数据库结构和共享数据库实例，下面分别进行探讨。
关注公众号：Java架构师联盟，每日更新技术好文
共享数据库结构——所有的表，在一个数据库中。
共享数据库结构
在实际的工作中，很多同学对这种模型比较推崇，理由就是写代码简单，可以用数据库的连接查询，完成复杂的业务逻辑。由企业级应用开发经验的同学，对此模型的推崇更甚，这是为什么呢？我尝试分析企业应用和互联网应用的不同特点，进行解答。
企业应用的特点是：业务复杂，并发小，研发投入有限。在这种情况下，就要求以较少的代价完成业务功能，通过复杂SQL做业务操作是不错的选择。数据库虽然执行了复杂的查询，因为并发小，并没有太大的压力。企业级应用的开发者，倾向于写复杂的查询，不太用考虑复杂的应用架构和程序运行效率。
互联网应用的特点是：大并发，业务复杂，一般研发投入较大。一方面，数据库如果是性能瓶颈，扩容机制复杂，虽然有一些扩容方案，例如读写分离、缓存、分表分库等等，都需要程序配合，同时很难做到热扩容。另一方面，执行效率和并发能力成反比，只有尽可能的缩短单操作的执行时间，才能做大大并发。所以，互联网应用的开发者，倾向于写简单的查询，通过应用架构优化和程序优化，提升应用的并发能力。
架构的很多理念，没有对错，只有合适不合适。对于小规模的企业应用开发，采用这种模式是合适的。但是对于比较大规模的应用和互联网应用就不合适了，主要的理由如下：
- 服务边界不清晰，有些代码写在服务A可以，写在服务B也可以，总之是一种很混乱的状态。
- 难以维护。由于服务边界不清晰，代码混乱，代码的维护成为难题。
- 难以优化。主要业务在SQL里，不能通过优化代码提升性能。SQL的优化非常复杂，大量的关联查询，牵一发而动全身。
- 性能瓶颈。数据库是业务的性能瓶颈，不容易扩容。
共享数据库实例——表按照业务分成多个库，这些库存储在一台实例上
共享数据库实例
通过上面的分析，对设计做了优化，服务之间没有了数据库表依赖，也不写复杂的查询。为了节省成本，把这些数据库建在同一个实例上，就进化成了现在这种模式。探讨这个模式的不足，就要聊聊雪崩效应。
假设订单服务有一个复杂的查询，正常查询需要200ms，有一天因为某个错误，导致频繁查询，数据库的CUP被占用到100%。这时候数据库的查询都会变慢，100ms返回的查询，可能耗时超过10秒，甚至更夸张。用户服务和库存服务，很快就不能对外提供服务了。这种现象就是雪崩效应，共享的资源，一旦被耗尽，就会传播给其他共享方。共享数据库实例的风险很高，这种风险不是增加数据库的实例配置就能解决的。既然采用了服务化的设计理念，就要考虑资源隔离。
总结：我当时问他的问题是共享有什么缺点吗？候选人只是从设计的角度进行了解答，没有从性能、并发能力方面解答，也没有提到雪崩效应。也就很明显的看出，候选人大规模、大并发应用的设计能力是有待提高的。