不要再说微服务可以解决一切问题了！

Posted 2022-07-14 优维科技EasyOps

受到 Netflix 和亚马逊等科技巨头的喜爱，微服务已经成为现代软件开发的新宠，尽管它们已有十多年的历史。但是，尽管有好处，但这种范式很容易出错。那么，让我们来探讨一下微服务是什么，更重要的是，它们不是什么。

01

什么是微服务？

微服务架构是一种软件设计方法，它将应用程序分解为通过定义明确的 API 进行通信的小型独立服务。由于每个服务都可以由自治团队开发和维护，因此它是最具可扩展性的软件开发方法。

02

微服务与单体架构

微服务设计与单体开发截然相反。单体是一个实现所有功能的大型代码库（“厨房水槽”）。一切都在一个地方，没有一个组件可以孤立地工作。这意味着应用程序必须作为一个整体进行测试。

从好的方面来说，单体应用很容易启动和运行。举个例子，Airbnb 是从“The Monorail”开始的，它是一个 Ruby on Rails 单体应用程序。虽然公司还很小，但开发人员可以快速迭代。由于单体架构不同部分之间的关系是透明的，因此进行广泛的更改很容易。

然而，随着公司的发展和团队规模的扩大，单体开发变得更加困难。很快，系统就不能再装在一个头上了——移动部件太多了，所以事情变慢了。

微服务使公司能够保持团队规模小而敏捷。这个想法是将应用程序分解为可以由紧密结合的团队自主开发和部署的小型服务。

03

微服务的好处

​可扩展性

公司采用微服务的主要原因是可扩展性。服务可以独立开发和发布，无需在组织内安排大规模的协调工作。

​误隔离

拥有分布式系统的一个好处是能够避免单个故障点。您可以使用支持云的技术在不同的可用区部署微服务，确保您的用户永远不会遇到中断。

​较小的团队

使用微服务，开发团队可以保持小而有凝聚力。小组越小，沟通开销越少，协作越好。

亚马逊通过他们的两个披萨团队将团队规模发挥到了极致。这意味着一个团队应该足够小，可以吃两个比萨饼。

选择技术堆栈的自由

对于单体应用，语言和技术堆栈选项几乎从一开始就设置好了。新开发人员必须适应过去做出的任何选择。

相比之下，每个微服务都可以使用最适合解决手头任务的技术堆栈。因此，团队可以为工作和他们的技能选择最佳工具。例如，您可以使用 Go 或 C 实现高性能服务，并使用 Erlang 或 Elixir 实现高容错微服务。

​更频繁的发布

随着小团队迭代速度更快，开发和测试周期更短。而且，由于他们还可以随时部署更新，微服务的部署频率比单体应用要高得多。

04

微服务架构设计挑战

有这么多好处，似乎为新项目选择微服务是一件轻而易举的事。但是微服务设计也带来了一些严峻的挑战：

• Small：适用于团队规模和代码库。微服务必须小到足以被一个人完全理解。如果从头开始重写它需要超过 sprint 的时间，那么你的微服务就太大了。
• 专注于一件事：服务必须专注于问题的一个方面或只执行一项任务。
• 自治：自治允许团队选择最合适的语言堆栈和数据模型。这通常意味着每个微服务都有自己的数据库或持久层，不与其他服务共享。
• 与有界上下文一致：在软件中，我们创建模型来表示我们想要解决的问题。有界上下文表示给定模型的限制。上下文是服务的自然边界，因此找到它们是设计良好微服务架构的一部分。
• 松耦合：虽然微服务可以依赖于其他微服务，但我们必须注意它们的通信方式。每次跨越有界上下文时，都需要某种程度的抽象和翻译，以防止一个服务中的行为更改影响其他服务。
• 可独立部署：由于是自治且松耦合的，团队可以在几乎没有外部协调或集成测试的情况下部署他们的微服务。微服务应该通过定义明确的 API 进行通信，并使用翻译层来防止一项服务中的行为更改影响其他服务。

05

当微服务不是微服务时

你怎么知道你是否在做正确的微服务设计？如果您的团队可以在不与其他团队协调的情况下随时部署更新，并且如果其他团队可以类似地部署他们的更改而不影响您，那么恭喜您，您掌握了微服务的诀窍。

失去微服务提供的好处的最可靠方法是不遵守解耦规则。如果我们仔细观察，我们会发现微服务都是关于自治的。当这种自主权丧失时，团队必须在开发和部署期间进行协调。需要完美的集成测试来确保所有微服务协同工作。

即便如此，详尽的测试也无法捕捉到所有问题。当出现问题时，耦合服务是很难调试的。当问题被发现时，修复它并不总是像回滚更新那么容易。

这些都是分布式计算带来的问题。如果您曾经使用过云服务，您就会知道将服务或机器分布在多个地理位置与在同一站点上运行所有内容不同。分布式系统具有更高的延迟，可能存在同步问题，并且更难管理和调试。这种高度耦合的服务架构实际上是一个分布式单体架构，具有两全其美的优点，也没有微服务应该带来的任何好处。

如果您在不与其他团队协调或依赖其他微服务的特定版本来部署您的微服务的情况下无法进行部署，那么您只是在分发您的单体应用。

06

当微服务不是最佳选择时

微服务并没有取代单体。两者都是有效的方法。事实上，当团队仍在探索他们正在构建的东西时，单体应用可能是最佳选择。

单体应用就像是项目的自然起点，因为它易于开发、快速迭代、快速部署、易于调试，并且更能容忍设计错误。在可扩展性成为问题之前，单体应用可以让您走得更远。

07

微服务架构适合您吗？

微服务是我们开发软件的最具可扩展性的方式。但它们不是免费的午餐。如果您不小心，它们会带来一些很容易发生冲突的风险。当团队正在成长并且您需要保持快速和敏捷时，它们非常有用。但是你需要对要解决的问题有一个很好的理解，否则你最终会得到一个分布式的单体。