微服务与单片架构
我做了一些关于微服务的阅读，而且我有点兴趣。看起来像是一个有趣的概念。 但是我想知道，在单片架构上使用微服务有哪些优缺点，反之亦然。
当微服务适合更好，哪里更好的单片架构。
虽然我对微服务世界比较陌生，但我会尽可能地回答你的问题。
当你使用微服务体系结构时，你会增加解耦和关注的分离。 既然你正在分裂你的申请。
这导致您的代码库更容易pipe理 （每个应用程序独立于其他应用程序以保持运行）。 因此， 如果你这样做 ，将来可以更容易地为你的应用程序添加新的function 。 而对于单一的体系结构，如果你的应用程序很大，你可能会认为它会变成一件非常困难的事情。
部署应用程序也更容易 ，因为您正在独立构build独立的微服务并将其部署在不同的服务器上。 这意味着您可以随时构build和部署服务，而无需重新构build应用程序的其余部分。
由于不同的服务是小型的，而且是单独部署的，因此扩展它们显然更容易 ，其优点是可以扩展应用程序的特定服务（用单一的方式扩展整个“事物”，即使它只是一个特定的部分应用程序正在获得过多的负载）。
但是，对于那些不打算变得太大而不能pipe理的应用程序。 把它放在单一的体系结构上更好。 由于微服务架构涉及一些严重的困难。 我曾经说过部署微服务比较容易，但是与大的巨集相比，这只是真实的。 使用微服务，将服务分布到不同位置的不同服务器上增加了复杂性，您需要find一种方法来pipe理所有这些服务。 如果您的应用程序变得庞大，构build微服务将从长远来看帮助您，但对于较小的应用程序来说，保持单一性更容易。
这是一个非常重要的问题，因为很less有人被微服务引起的轰动，并且有权衡考虑。 那么，微服务（与单一模型相比）有什么优点和缺点呢？
优点：
- 可部署性 ：由于构build+testing+部署周期更短，因此可以更灵活地部署新版本的服务。 此外，灵活地使用特定于服务的安全性，复制，持久性和监视configuration。
- 可靠性 ：微服务故障影响单独的微服务及其消费者，而在单片模型中，服务故障可能会导致整个巨型服务器失效。
- 可用性 ：推出新版本的微服务需要很less的停机时间，而在整体服务器中推出新版本的服务需要整个整体的重启速度通常较慢。
- 可扩展性 ：每个微服务可以使用池，集群，网格独立扩展 。 部署特性使得微服务与云的弹性非常匹配。
- 可修改性 ：更灵活地使用新的框架，库，数据源和其他资源。 另外，微服务是松耦合的，模块化的组件只能通过契约来访问，因此不太容易变成大泥球。 通过registry（例如Apache ZooKeeper，Netflix Eureka）dynamic发现和绑定有时用于位置透明。
- pipe理 ：应用程序开发工作分为小型团队和独立工作团队。
- devise自主性 ：团队可以自由地使用不同的技术，框架和模式来devise和实现每个微服务，并且可以独立地更改和重新部署每个微服务
缺点：
- 可部署性 ：部署的许多作业，脚本，传输区域和configuration文件的部署变得更加复杂。
- 性能 ：服务更可能需要通过networking进行通信，而整体服务内部的服务可能会从本地通话中受益。 此外，如果微服务使用dynamic发现，registry查找是一个性能开销。
- 可用性 ：如果您使用registry进行dynamic发现，registry的不可用性可能会影响消费者与服务的交互。
- 可修改性 ：对合同的更改更有可能影响到其他地方的消费者，而在单一模式中，消费者更有可能处于巨无霸之中，并将与服务同步推出。 此外，改进自治的机制（如最终一致性和asynchronous调用）也增加了微服务的复杂性。
- 可testing性 ：自动化testing更难以设置和运行，因为它们可能在不同的运行时环境中跨越不同的微服务。
- pipe理 ：应用程序操作的成本增加，因为有更多的运行时组件，日志文件和点对点交互来监督。
- 内存使用 ：经常会在每个微服务包中复制几个类和库，并增加整个内存占用量。
- 运行时自治 ：整体业务逻辑是并列的。 通过微服务，逻辑分布在微服务中。 所以，在其他条件相同的情况下，微服务更有可能与networking上的其他微服务交互 – 这种交互会降低自治性。 如果微服务之间的交互涉及到数据的更改，那么对事务边界的需求会进一步影响自治。 好消息是，为了避免运行时自治问题，我们可以采用诸如最终一致性，事件驱动架构，CQRS，caching（数据复制）以及将微服务与DDD有界上下文alignment等技术。 这些技术并不是微服务所固有的，但几乎每个我读过的作者都已经提出过。
一旦我们理解了这些权衡之后 ，还有一件事我们需要知道回答另一个问题：哪个更好，微服务或巨石？ 我们需要知道应用程序的非function需求（质量属性需求）。 一旦您了解了性能与可伸缩性之间的重要性，例如，您可以权衡权衡，并做出有教育意义的devise决策。
@卢克索是现货。 我只想提供一些细微的变化，并带来组织的视angular。 微服务不仅允许应用程序分离，还可以在组织级别上提供帮助。 例如，组织可以分成多个小组，每个小组可以在小组可能提供的一组微服务上开发。
例如，在像亚马逊这样的大型商店里，你可能会有一个个性化的团队，电子商务团队，基础设施服务团队等。如果你想进入微服务，亚马逊就是一个很好的例子。 杰夫·贝佐斯（Jeff Bezos）认为，如果团队需要访问共享function，团队可以与其他团队的服务进行沟通。 在这里看到一个简要的描述。
此外，来自Etsy和Netflix的工程师也在Twitter上的微服务与庞然大物之间进行了一场小型辩论。 这场辩论有点less技术性，但也可以提供一些见解。
