前言：之前写过为什么微服务不能共享数据库，有朋友跟我留言，在他面试的时候，被问到：微服务是独立的db，在做跨服务器查询的时候，要做跨库跨表查询非常慢，比原来单体服务的时候，几个表之间只要join一下就能够快速出结果，要慢多了，你怎么解决这个问题？针对在这个问题，我尝试做一下解答，如有不完整的，请指正。

设计理念

无论是微服务，还是模块，甚至是类、函数，“高内聚，低耦合”是通用的设计要求。微服务的划分，不是简单的功能的切分，而是根据业务实践，创建相互独立、低依赖的服务，服务之间通过有限的接口进行交互。如果服务之间的表，需要通过join连接进行查询，只能说明微服务的划分是有问题的，服务之间的耦合度过高。

面试官提出此疑问，一种可能是面试官深刻理解微服务的设计理念，只是给候选人提一个相对开放的问题；另一种可能是，面试官也不太了解微服务，甚至有排斥的态度。以我的亲身体验为例，在新项目开始时，决定采用微服务架构，不少同事习惯了单体服务的开发模式，对此有排斥的态度，重要的理由就是不能联查。随着项目推进，大家慢慢熟悉了微服务的开发模式，就接受了微服务理念。

开发效率 VS 执行效率

即使微服务是低耦合的，也会存在通过调用接口组装数据的场景。那就探讨一下，这种情况下，是否真的”低效“呢？所谓低效，虽然常常说运行效率，但我认为还隐藏着开发效率的问题。

微服务，增加了系统的复杂度，原来可以用一个sql联查多张表，现在只能通过调用多个接口组装数据。程序员对“复杂性”有天然的拒绝态度，虽然很多时候使用了其他的理由，但究其原因，就是“太复杂了，不好做”。不可否认，使用微服务化后，程序员需要更多的精力处理系统间的依赖，程序开发效率降低。程序员应该抱有开放、学习的态度，不断接受挑战，才能有所进步吧。

执行效率方面，几张表联查，真的比调用几个接口快吗？在数据量较小，并发较小的情况下，可能确实如此，但是在此种情况下，何必折腾微服务呢？

在数据量比较大的时候，多表联查效率较低，并且难以优化；当并发上来后，受制于物理机器性能，数据库的扩容比较困难，这种模式对性能扩展并不友好。微服务提供的接口，可通过缓存等策略，提升接口调用的效率。另外，在实际的微服务开发中，我是不建议使用多表联查的，通过冗余满足联查码表需求。还可以通过增加服务的实例个数，提升服务能力。总之，把业务逻辑通过代码而不是sql实现，我们可以有更多的优化策略，满足大并发的应用场景 。

综上，既然使用微服务，就是业务足够复杂，有可观的并发需求，就要对这种复杂性，有足够的认识。微服务不是被用来炫耀的，而是要根据业务实际，选择是否应用微服务。

看到这里，请关注我吧。