面试夺命三问之《为何微服务不能共享数据库？》

引子：今天面试一位候选人，候选人描述他作的项目，使用了微服务化的设计理念，业务差分红多个微服务，可是服务之间共享一个数据库，因而就有了这样的一个问题探讨。

所谓多个服务共享数据库，其实有两种类型：共享数据库结构和共享数据库实例，下面分别进行探讨。

关注公众号：Java架构师联盟，每日更新技术好文

共享数据库结构——全部的表，在一个数据库中。

共享数据库结构

在实际的工做中，不少同窗对这种模型比较推崇，理由就是写代码简单，能够用数据库的链接查询，完成复杂的业务逻辑。由企业级应用开发经验的同窗，对此模型的推崇更甚，这是为何呢？我尝试分析企业应用和互联网应用的不一样特色，进行解答。

企业应用的特色是：业务复杂，并发小，研发投入有限。在这种状况下，就要求以较少的代价完成业务功能，经过复杂SQL作业务操做是不错的选择。数据库虽然执行了复杂的查询，由于并发小，并无太大的压力。企业级应用的开发者，倾向于写复杂的查询，不太用考虑复杂的应用架构和程序运行效率。

互联网应用的特色是：大并发，业务复杂，通常研发投入较大。一方面，数据库若是是性能瓶颈，扩容机制复杂，虽然有一些扩容方案，例如读写分离、缓存、分表分库等等，都须要程序配合，同时很难作到热扩容。另外一方面，执行效率和并发能力成反比，只有尽量的缩短单操做的执行时间，才能作大大并发。因此，互联网应用的开发者，倾向于写简单的查询，经过应用架构优化和程序优化，提高应用的并发能力。

架构的不少理念，没有对错，只有合适不合适。对于小规模的企业应用开发，采用这种模式是合适的。可是对于比较大规模的应用和互联网应用就不合适了，主要的理由以下：

1. 服务边界不清晰，有些代码写在服务A能够，写在服务B也能够，总之是一种很混乱的状态。
2. 难以维护。因为服务边界不清晰，代码混乱，代码的维护成为难题。
3. 难以优化。主要业务在SQL里，不能经过优化代码提高性能。SQL的优化很是复杂，大量的关联查询，牵一发而动全身。
4. 性能瓶颈。数据库是业务的性能瓶颈，不容易扩容。

共享数据库实例——表按照业务分红多个库，这些库存储在一台实例上

共享数据库实例

经过上面的分析，对设计作了优化，服务之间没有了数据库表依赖，也不写复杂的查询。为了节省成本，把这些数据库建在同一个实例上，就进化成了如今这种模式。探讨这个模式的不足，就要聊聊雪崩效应。

假设订单服务有一个复杂的查询，正常查询须要200ms，有一天由于某个错误，致使频繁查询，数据库的CUP被占用到100%。这时候数据库的查询都会变慢，100ms返回的查询，可能耗时超过10秒，甚至更夸张。用户服务和库存服务，很快就不能对外提供服务了。这种现象就是雪崩效应，共享的资源，一旦被耗尽，就会传播给其余共享方。共享数据库实例的风险很高，这种风险不是增长数据库的实例配置就能解决的。既然采用了服务化的设计理念，就要考虑资源隔离。

总结：我当时问他的问题是共享有什么缺点吗？候选人只是从设计的角度进行了解答，没有从性能、并发能力方面解答，也没有提到雪崩效应。也就很明显的看出，候选人大规模、大并发应用的设计能力是有待提升的。