资深架构师 Adam Drake 在他的博客上分享了他对微服务的看法，他从自己的经验出发，结合 Martin Fowler 对微服务的见解，帮助想要采用微服务的公司重新审视微服务。以下内容已获得作者翻译授权。

写在前面

关于微服务的优势和劣势已经有过太多的讨论，不过我仍然看到很多成长型初创公司对它进行着“盲目崇拜”。冒着“重复发明轮子”的风险（Martin Fowler 已经写过“Microservice Premium”的文章），我想把我的一些想法写下来，在必要的时候可以发给客户，也希望能够帮助人们避免犯下我之前见过的那些错误。在进行架构或技术选型时，将网络上找到的一些所谓的最佳实践文章作为指南，一旦做出了错误的决定，就要付出惨重的代价。如果能够帮助哪怕一个公司避免犯下这种错误，那么写这篇文章都是值得的。

如今微服务是个热门技术，微服务架构一直以来都存在（面向服务架构也算是吧？），但对于我所见过的大部分公司来说，微服务不仅浪费了他们的时间，分散了他们的注意力，而且让事情变得更糟糕。

这听起来似乎很奇怪，因为大部分关于微服务的文章都会肯定微服务的各种好处，比如解耦系统、更好的伸缩性、移除开发团队之间的依赖，等等。如果你的公司有 Uber、Airbnb、Facebook 或 Twitter 那样的规模，那么就不存在什么问题。我曾经帮助一些大型组织转型到微服务架构，包括搭建消息系统和采用一些能够提升伸缩性的技术。不过，对于成长型初创公司来说，很少需要这些技术和微服务。

Russ Miles 在他的《让微服务失效的八种方式》这篇文章中表达了他的首要观点，而在我看来，这些场景却到处可见。成长型初创公司总是想模仿那些大公司的最佳实践，用它们来弥补自身的不足。但是，最佳实践是要视情况而定的。有些东西对于 Facebook 来说是最佳实践，但对于只有不到百人的初创公司来说，它们就不一定也是最佳实践。

如果你的公司比那些大公司小一些，你仍然能够在一定程度上从微服务架构中获得好处。但是，对于成长型初创公司来说，大规模地迁移到微服务是一种过错，而且对技术人来说是不公平的。

为什么选择微服务？

一般来说，成长型初创公司采用微服务架构最主要的目的是要减少或者消除开发团队间的依赖，或者提升系统处理大流量负载的能力（比如伸缩性）。开发人员经常抱怨的问题和常见的症状包括合并冲突、由未完整实现的功能引起的部署错误以及伸缩性问题。接下来让我们逐个说明这些问题。

依赖

在初创公司的早期阶段，开发团队规模不大，使用的技术也很简单。人们在一起工作，不会出现混乱，要实现一些功能也比较快。一切看起来都很美好。

随着公司的不断发展，开发团队也在壮大，代码库也在增长，然后就出现了多个团队在同一个代码库上工作的情况。这些团队的大部分成员都是公司早期的员工。因为初创公司的早期员工一般都是初级开发人员，他们并没有意识到一个问题，那就是在团队规模增长和代码库增长的同时，沟通成本也会随之提升。对于缺乏经验的技术人员来说，他们倾向于通过技术问题来解决人的问题，并希望通过微服务来减少开发团队之间的依赖和耦合。

实际上，他们真正需要做的是通过有效的沟通来解决人的问题。当一个初创公司有多个开发团队时，团队之间需要协调，团队成员需要知道每个人都在做什么，他们需要协作。在这样规模的企业里，软件开发其实具有了社交的性质。如果团队之间缺乏沟通或者缺乏信息分享，不管用不用微服务，一样会存在依赖问题，而就算使用了微服务，也仍然存在负面的技术问题。

将代码模块化作为解决这个问题的技术方案，确实能够缓解软件开发固有的团队依赖问题，但团队间的沟通仍然要随着团队规模的增长而不断改进。

切记不要混淆了 解耦和分布式二者的含义。由模块和接口组成的单体可以帮助你达到解耦的目的，而且你也应该这么做。你没有必要把应用程序拆分成分布式的多个独立服务，在模块间定义清晰的接口也能达到解耦的目的。

部分功能实现

微服务里需要用到功能标志（feature flag），微服务开发人员需要熟悉这种技术。特别是在进行快速开发（下面会深入讨论）的时候，你可能需要部署一些功能，这些功能在某些平台上还没有实现，或者前端已经完全实现，但后端还没有，等等。随着公司的发展，部署和运维系统变得越来越自动化和复杂，功能标志变得越来越重要。

水平伸缩