小团队中微服务的可怕之处

微服务听起来很棒，每一个团队可以彼此独立工作而不影响其他团队。你可以轻松地维护和扩展微服务。你也可以在同一项目中使用不同的技术。它们如此稳定，所以，你的产品会有极好的扩展。在 2021 年，不应该把任何应用作为单体来构建，对吧？

很遗憾，微服务并非在每一种环境下都可以发挥作用，在盲目使用之前，你必须确定它们提供了你所需要的价值。我见过几个典型的项目，有 4~6 名开发者，基本上是一个团队。客户想要构建微服务的应用程序，因为它们非常棒。IT 经理同意了，于是团队开始设计应用程序。

用户管理？是的，这是一个微服务。访问权限管理？也是微服务。管理和预约？同样是微服务！通过连接到几个第三方 API 来管理和发送订单？这绝对是一个微服务。不错，现在每个人都可以得到一个微服务了！有时候你可能会违反物理学法则，每个人都有多个微服务。

恐怖开始

当你开始这个伟大的旅程时，你的团队需要确保每一个微服务都可以独立开发。每一个微服务都有它自己的 CI/CD 管道，自己的数据库和自己的版本化 API。

现在，在启动一个新项目时，你可能只有一个团队。将在同一个团队中构建所有这些微服务。这种情况经常发生：一个人为了实现一个新功能而承担多个微服务。让我们就叫她 Ellie 吧。Ellie 需要在任何地方进行一些调整，同时进行测试。当她遇到问题时，她可以开始对两个微服务进行并行调试，以尝试了解它们之间的通信。如果它实际上是应用程序的一部分，那么 Ellie 就拥有一个更简单的工作环境，并且可以直接在应用程序中进行调试。此外，她还不需要为这些微服务之间的分布式、可能是异步通信编写大量定义和代码。

之后，你的应用程序的第一个版本将提供给你的客户。当你更新应用程序并尝试开始滚动更新时，你将面临在某一时间内运行微服务的多个版本。要么它们都与其他版本兼容（这也需要在开发过程中进行一些工作），要么你需要以某种方式优雅地更新它们。

在最坏的情况下，你正在构建一个分布式的单体应用。而且，在你的小团队里，你会发现微服务的所有缺点，但是很可能并没有从这些中获益。

微服务的亮点在哪里？

亚马逊和 Netflix 是最早提到他们使用微服务的大公司之一，他们解释了微服务为何如此有用。亚马逊提出了两个披萨原则，并表示：“如果两个披萨不足以喂饱一个项目团队，那么这个团队可能就显得太大了”。每个团队都应该有自己的微服务，它绝不应该在两个团队之间分割。要获得完全的所有权，团队必须对其组件及其相关的所有东西拥有完全的控制权。

在单体应用中管理代码和依赖项，面对庞大的软件和数百人的工作，是相当麻烦的。因为微服务与其他所有东西解耦，这是一个完美的方法，可以扩展开发团队的数量。他们可以在自己的微服务上工作，使用已经构建的 API，并扩展现有产品。他们无须与其他 80 个团队中的每个决策保持一致，而且他们可能不必选择相同的技术或保持版本一致。

微服务对于管理大型软件来说并不是必需的，而是管理大量使用这些软件的人。

我现在该怎么办？

但这并不意味着微服务就会陷入混乱。但是，我要你真正思考微服务对你的意义，以及你是否能从中获益。当然，它们可以为你提供许多好处，但同时也增加了许多复杂性。假如这些好处对你无关紧要，你就可以跳过它们。

一个很好的软件开发范式是保持简单。既然可以简单地实现相同的结果，为什么还要选择更复杂的方式呢？你只会让它变得更难理解，以后也更难改变。

微服务同样如此。既然你的团队必须处理所有微服务，并完全控制应用程序，为何还要增加微服务的复杂性？你的产品可能会增长，但是两周内它并不会成为下一个 Netflix。就像俗话所说的：“过早的优化是万恶之源”，所以不要急着优化！

相反，享受一个相当单一的应用程序的好处。尽情享用更快的开发速度，因为你不需要担心改进微服务间的通信，不需要花费更多时间调试和测试微服务间共享通用代码的意义，不需要尝试协调复杂的分阶段微服务发布，甚至不需要在每个微服务上处理巨大的 docker 映像大小和内存需求，因为你正在使用 Spring Boot。

你也不需要全心致力于单体或微服务。你仍可以将应用程序划分为有意义的部分 —— 甚至遵循领域驱动设计的指导原则。有了合适的架构，你的代码和模块仍然可以被恰当地解耦，并且你的应用程序符合 12 要素原则。可以在相同的应用程序中运行这些模块，可以共享相同的构建管道，只需部署一个版本即可进行部署。

但我如何扩大规模呢？

你发布了你的产品，而且非常成功。你希望构建更多功能并适当地扩展。你雇佣并组建了多个开发团队，你是否真的从微服务中获益？现在正是将你的应用拆分到微服务的绝佳时机。

若你的应用程序构建正确，且不同模块已经解耦并易于理解，则拆分它们应该不会太困难。是啊，得费点功工夫。当然，你可以从一开始就直接使用微服务来避免这个问题。但是在这种情况下，你也必须从一开始就直接处理复杂的事情，并且拖拖拉拉。

保证在适当的时候选择合适的架构并且保持简单。关注代码架构和质量。

原文链接： https://mp.weixin.qq.com/s/DXsAdZOc76ycCAkiF-yN8Q