微服务已经成为现代软件开发的新宠，尽管它们已有十多年的历史。但是，尽管有好处，但这种范式很容易出错。那么让我们来探讨一下微服务是什么，更重要的是，它们不是什么。

什么是微服务？

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

微服务与单体

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

从好的方面来说，单体应用很容易启动和运行。由于单体架构不同部分之间的关系是透明的，因此进行广泛的更改很容易。

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

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

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

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

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

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

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

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

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

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

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