微服务与单片架构

Question

我做了一些关于微服务的阅读，我有点兴趣。看起来像是有趣的概念。但我想知道，使用微服务而不是单片架构有什么优缺点，反之亦然。

当微服务更合适时，更好地采用单片架构。

Answer 1

这是一个非常重要的问题，因为有些人被微服务的所有嗡嗡声所吸引，需要考虑权衡。那么，微服务的好处和挑战是什么（与单片模型相比）？

优势

• 可部署性：由于更短的构建+测试+部署周期，更灵活地推出新版本的服务。此外，还可以灵活地使用特定于服务的安全性，复制，持久性和监视配置。
• 可靠性：微服务故障仅影响微服务及其消费者，而在整体模型中，服务故障可能会影响整个整体结构。
• 可用性：推出新版本的微服务需要很少的停机时间，而在整体中推出新版本的服务需要通常较慢的重启整个整体。
• 可伸缩性：每个微服务都可以使用池，群集，网格独立扩展。部署特性使微服务与云的弹性非常匹配。
• 可修改性：使用新框架，库，数据源和其他资源的灵活性更高。此外，微服务是松散耦合的，模块化组件只能通过他们的合同访问，因此不太容易变成泥球。
• 管理：应用程序开发工作分为更小，更独立工作的团队。
• 设计自治：团队可以自由地使用不同的技术，框架和模式来设计和实现每个微服务，并且可以独立地更改和重新部署每个微服务

挑战

• 可部署性：有更多的部署单元，因此需要更复杂的作业，脚本，传输区域和配置文件来监督部署。 （出于这个原因，持续交付和DevOps非常适合微服务项目。）
• 性能：服务更可能需要通过网络进行通信，而整体内部的服务可能会受益于本地呼叫。 （出于这个原因，设计应该避免“讨厌”的微服务。）
• 可修改性：对合同的更改更有可能影响部署在其他地方的消费者，而在整体模型中，消费者更有可能在整体中，并将​​与服务一起推出。此外，提高自治性的机制，例如最终的一致性和异步调用，增加了微服务的复杂性。
• 可测试性：集成测试更难设置和运行，因为它们可能跨越不同运行时环境中的不同微服务。
• 管理：管理操作的工作量增加，因为有更多的运行时组件，日志文件和点对点交互来监督。
• 内存使用：每个微服务包中经常会复制多个类和库，并且整体内存占用量也会增加。
• 运行时自治：在整体中，整体业务逻辑并置。使用微服务，逻辑分布在微服务上。因此，在其他条件相同的情况下，微服务更有可能通过网络与其他微服务进行交互 - 这种交互会降低自主性。如果微服务之间的交互涉及改变数据，则对事务边界的需求进一步损害了自治。好消息是，为了避免运行时自治问题，我们可以采用诸如最终一致性，事件驱动架构，CQRS，缓存（数据复制）以及将微服务与DDD有界上下文对齐等技术。这些技术并非微服务所固有的，但几乎每个我读过的作者都提出过这种技术。

一旦我们理解了these tradeoffs，我们还需要知道一件事来回答另一个问题：哪个更好，微服务还是整体？ 我们需要了解应用程序的非功能性需求（质量属性要求）。一旦您了解了性能与可扩展性的重要性，您就可以权衡权衡并做出有根据的设计决策。

Answer 2

虽然我对微服务世界相对较新，但我会尽量回答你的问题。

当您使用微服务架构时，您将增加解耦和关注点分离。因为你完全分开你的应用程序。

这导致代码库更易于管理（每个应用程序独立于其他应用程序以保持运行）。因此，如果您这样做，将来将更容易向您的应用添加新功能。如果使用单一体系结构，如果您的应用程序很大（并且您可以在某个时间点假设它），那么它可能会变得非常困难。

同样部署应用程序更容易，因为您要单独构建独立的微服务并将它们部署在不同的服务器上。这意味着您可以随时构建和部署服务，而无需重建应用程序的其余部分。

由于不同的服务很小并且单独部署，因此它们显然更容易扩展，因为您可以扩展应用程序的特定服务（使用单一服务扩展您的应用程序）完成＆＃34;事情＆＃34;，即使它只是应用程序中的特定部分，也会产生过多的负载。）

但是，对于不打算在将来管理太大的应用程序。最好将它保持在单片架构上。由于微服务架构存在一些严重的困难。我说部署微服务更容易，但这与大型单块相比只是如此。使用微服务会增加将服务分发到不同位置的不同服务器的复杂性，您需要找到一种方法来管理所有这些服务。如果您的应用程序变大，构建微服务将在长期帮助您，但对于较小的应用程序，它更容易保持整体。

Answer 3

@Luxo是现货。我只是想提供一个微小的变化，并带来它的组织视角。微服务不仅允许应用程序解耦，而且还可以在组织层面上提供帮助。例如，该组织可以分成多个团队，每个团队可以在团队可能提供的一组微服务上进行开发。

例如，在像亚马逊这样的大型商店中，您可能拥有个性化团队，电子商务团队，基础架构服务团队等。如果您想进入微服务，亚马逊就是一个非常好的例子。 Jeff Bezos要求团队在需要访问共享功能时与其他团队的服务进行通信。有关简要说明，请参阅here。

此外，来自Etsy and Netflix的工程师在微服务和Twitter上的monolith当天也进行了一场小辩论。辩论的技术性稍差，但也可以提供一些见解。