architecture - 微服务:优点和缺点是什么？

Question

与替代架构相比，使用微服务的优缺点是什么？
使用微服务时是否有经验法则？

Answer 1

优点

Building Microservices中的Sam Newman列举了微服务的主要优点，如下所示:
技术异质性
通过包含多个协作服务的系统，我们可以决定使用不同的
每个内部都有技术。这使我们能够为每个工作选择合适的工具，而不是
必须选择一种更加标准化，一刀切的全能方法
最低公分母。
flex
flex 工程中的一个关键概念是隔板。如果系统的一个组成部分
失败，但是这种失败并没有解决，您可以将问题与其余
系统可以继续工作。服务边界成为您显而易见的隔壁。在一个
整体服务，如果服务失败，一切都会停止。与单片
系统，我们可以在多台机器上运行以减少发生故障的机会，但是
微服务，我们可以构建处理服务全部失败并降级的系统
功能相应。
缩放比例
借助庞大的整体服务，我们必须将所有内容一起扩展。一小部分
我们整个系统的性能都受到限制，但是如果该行为被锁定在
巨大的整体应用程序，我们必须将所有内容按比例缩放。用
较小的服务，我们可以扩展那些需要扩展的服务，从而使我们能够运行
在较小，功能较弱的硬件上使用系统的其他部分。
易于部署
将单行更改为一百万行长的整体应用程序需要整体
为了发布更改而部署的应用程序。这可能会产生很大的影响，
高风险部署。在实践中，最终会发生影响重大的高风险部署
很少是由于可以理解的恐惧。
借助微服务，我们可以更改单个服务并独立部署
该系统的其余部分。这使我们可以更快地部署代码。如果有问题
发生时，可以快速将其隔离到单个服务，从而使快速回滚易于实现
实现。
组织一致性
微服务使我们能够更好地将架构与组织保持一致，从而帮助我们
最小化在任何一个代码库上工作的人员数量，以达到团队的最佳位置
规模和生产力。我们还可以在团队之间转移服务所有权，以保持
在一项服务上工作的人们在同一地点。
可组合性
分布式系统和面向服务的体系结构的主要 promise 之一是
我们为功能复用提供了机会。通过微服务，我们允许
为不同目的而以不同方式使用的功能。这可以是
当我们考虑消费者如何使用我们的软件时，这一点尤其重要。
优化可替换性
如果您在中型或大型组织中工作，那么您很可能知道一些
坐在角落的庞大，令人讨厌的旧系统。一个没人想碰的人。那一个
对您的公司的运营至关重要，但这恰好是用一些奇怪的Fortran编写的
变体，并且只能在25年前使用寿命终止的硬件上运行。为什么没有
被替换了吗？你知道为什么:它太大而且工作风险很大。
由于我们的单个服务规模较小，因此以更好的价格替换它们的成本
实现，甚至完全删除它们，都更易于管理。
缺点

微服务的最重要缺点是它们具有以下所有相关的复杂性:
分布式系统，虽然我们已经学到了很多有关如何管理分布式系统的知识
系统还不错。如果你要来
从整体系统的 Angular 来看，您必须在处理方面做得更好
部署，测试和监视以释放 yield 。你会
还需要对您如何扩展系统并确保它们
有 flex 。如果发生分布式交易或CAP定理之类的事情，也不要感到惊讶
要么开始让您头痛!
闭幕致辞

只是引用Martin Fowler:

One reasonable argument we've heard is that you shouldn't start with amicroservices architecture. Instead begin with a monolith, keep itmodular, and split it into microservices once the monolith becomes aproblem.