每当在面试过程中觉得枯燥乏味的时候，我总是会问候选人“说下微服务的优点”这个问题。
因为，我特别喜欢看候选人在那一本正经地胡说八道的样子。
在这些候选人眼中，系统架构中的”微服务“，似乎等于服务行业中的”微笑服务“，永远都是最优解一样。
下面我来截取一些场景，看看他们是如何胡说八道的。
胡说八道场景一：微服务更易于开发维护
我：“说下微服务的优点吧。”
候选人：“我认为微服务更易于开发维护，研发人员只需要关心自己负责的这个模块的逻辑即可，这样代码量和逻辑复杂度都会降低。”
我：“可以展开说说吗？”
候选人：“
比如：
如果我负责上游某服务，那下游服务的业务逻辑和存储数据结构，我们是不需要关心的；
如果我负责下游服务，那上游服务在什么业务场景下调用了我们，又是如何和其他数据进行聚合展示的，我们也是不需要关心的；
还有就是，一个庞大的整体系统，比如：淘天电商或抖音电商，还有多少个跟我们一样的微服务，他们的运转机制是什么样的，我们同样不需要全盘了解。”
我说：“如果你负责电商中的商品中心，由于业务需求迭代的原因，商品中心中改了一个被用户端、商家端、客服系统、订单中心、促销平台都会调用的核心接口，且代码逻辑改动量很大，不是加一行日志那种。
你真的完全不关心你的上游调用方会不会出错吗？这种情况下，你敢跑个单元测试，不惊动任何调用方，直接部署上线吗？”
候选人：“这。。。。这种情况也得关心吧。”
我说：“另外，你可以只关心你这一个服务，但总需要有个技术负责人站出来做整体的方案吧。那么对于他来讲，技术挑战永远都在，甚至还增加了分布式系统所带来的复杂度。”
候选人：“嗯嗯，是的。”
嘿嘿，聊到这里，我感觉身体上的每个毛孔都是舒展的。
胡说八道场景二：微服务能够解决系统性能瓶颈
我：“请问，如何解决系统中的性能瓶颈？”
候选人：“我们公司当时的解决方案是微服务拆分，这样就从一个单体服务处理所有系统请求，变成被多个微服务共同分摊这些请求，且微服务所对应的各个数据库也都进行拆分了，性能瓶颈自然没有了。”
我：“那拆分前共用了多少台服务器，拆分后又用了多少台服务器，这个你知道吗？”
候选人：“拆分前用了5台应用服务器，3台Redis服务器和1台数据库服务器，拆分后是20台应用服务器，12台Redis服务器和4台数据库服务器。”
我：“那为什么你不认为性能瓶颈是通过服务器扩容解决的，而是通过微服务拆分解决的？”
候选人：“这。。。。”
胡说八道场景三：微服务可以简化部署
我：“说下微服务的优点吧。”
候选人：“微服务间每个服务的部署都是独立的，所以可以简化部署。”
我：“可以展开说说吗？”
候选人：“因为在单体应用中，即使修改一行代码，也需要重新部署整个应用系统。这种部署方式的影响大且风险高，因此不敢轻易地进行部署。而微服务架构中，每个服务可进行独立部署，这样可以更快地对特定部分的代码进行部署。”
我：“单体应用，如果想减少部署风险的话，也可以进行灰度部署啊。”
我接着说：“另外，你这说的是改一行代码的情况，如果整个项目改动特别大的话，单体应用只需要部署一个服务，微服务得部署多少个服务啊，而且还需要有上下游依赖的部署顺序。
最可怕的是，如果部署不成功，还得把这些服务全部回滚了。 ”
候选人：“这。。。呵呵呵。”
胡说八道场景四：微服务具备更好的复用性和组合性
我：“说下微服务的优点吧。”
候选人：“微服务很小，具备更好的复用性和组合性。”
我：“可以展开说说吗？”
候选人：“在微服务架构中，各个服务会提供很多细粒度的接口供上游调用。当业务发生变更时，细粒度的接口更复用性更高，且通过组合多个接口，即可提供新的业务功能。
但单体应用只能提供一个非常粗粒度的接口供上游调用。”
我：“为什么单体应用不能提供细粒度的接口呢？接口的代码实现不是工程师自己写的吗？“
候选人：”但一般情况下，都习惯于在单体服务中写粗粒度接口，一站式实现业务逻辑。“
我说：”粗粒度接口相当于直接买品牌电脑，一站式服务，省时省力；
细粒度接口相当于是自己买硬件组装电脑，可根据个人需要进行任意搭配，灵活度高。
你不能希望其同时具备林黛玉般的我见犹怜。还需要像潘金莲一样性感妩媚啊，毕竟两者的目标用户不一样。”
候选人：“。。。。。。”
胡说八道场景五：微服务可以与组织结构相匹配
我：“说下微服务的优点吧。”
候选人：“微服务可以将技术架构与组织结构相匹配，避免出现过大的代码库，从而获得理想的团队大小及生产力。”
我：“我没太听明白，可以详细解释一下吗？”
候选人眉宇间略带不屑：“研发团队越大越难以管理，同时团队越大也代表系统规模越大，其对应的代码库也就越大，这样容易引起一系列的问题。且团队存在异地办公的情况下，问题更严重。
微服务架构就能很好地解决这个问题，微服务架构可以将架构与组织结构相匹配，避免出现过大的代码库，从而获得理想的团队大小及生产力。服务的所有权也可以在团队之间交接，从而避免异地团队的出现。”
我：“微服务架构是Martin Fowler(马丁 福勒)在2014年提出来的，难道在此之前研发团队一旦庞大了，所带来的一系列问题就没法解决了吗？”
我接着说：“不在异地成立分公司和招人，不就可以避免异地团队出现吗？”
两个无可争议的优点
《微服务架构设计模式》中写到的两个优点，我是深度认同的。
（1）使大型的复杂应用程序可以持续交付和持续部署
这句话我的理解是，通过微服务架构的方式，将大团队开发复杂应用程序所带来的代码冲突、业务逻辑冲突和部署冲突降至可控范围，使其具备持续交付和部署能力。
（2）更好的容错性
当一个非核心链路中的服务或其对应的数据库，由于硬件资源耗尽导致故障的时候，通过合理的降级、限流、熔断策略，配合上微服务天然的进程隔离特性，具备更好的容错性。
一句话总结
微服务在各服务内部可区域自治的场景上，降低了复杂度，但在需要各服务联动配合才能解决的场景中，又引入了新的复杂度。
