微服务与Monolothic架构转换

Question

我最近在阅读有关微服务架构及其与单片架构的不同之处。我想知道它是以纯代码的形式实现的。

假设你有一个单一的架构。您的所有模型，即处理所有请求等的核心系统都在一个文件中。但是，对于每种不同类型的请求，这包含此文件中的不同函数定义。

单片架构的一个缺点是一个错误的功能会导致整个系统崩溃。如果其中一个功能停止按预期工作，它将如何降低整个系统？

如果确实如此，那么在微服务架构中如何解决这个问题呢？微服务转换意味着将单个文件拆分为多个文件，每个文件执行一个特定的操作。请求是针对这些许多不同的模型文件。由于该特定服务与其他服务之间的依赖关系仍然存在，它是否也不会使系统在微服务架构中失效？

Answer 1

好吧，单一应用程序将所有内容都放在一个文件结构中，作为一个应用程序。不一定在一个文件中。

运行微服务有许多优点。但你是对的，他们仍然需要工作。

微服务通常由一组api组成，如果你在Facebook的范围有限，他们可能有一个api用于帖子，另一个用于喜欢，另一个用于存储，如果图片，身份验证和等等。并且一个巨大的优势是能够根据负载进行放大和缩小。

开发时，您的范围有限，因此如果一个模块不稳定，您不会丢弃整个代码库。您可以部署新版本，而不依赖于成千上万的人（在facebook的情况下）。你可以拥有不同技能的开发人员，如果你在java，php，python等中做这件事并不重要。您还可以为任务选择最佳技术。重新编写代码片段更容易，因为通常很容易指定微服务应该做什么。

借助云，我非常肯定微服务将成为可以部署在云中的所有服务的标准。因为优势如此之大，以至于企业必须睁开眼睛。

Answer 2

  

单片架构的一个缺点是一个错误的功能会导致整个系统崩溃。如果其中一个功能停止按预期工作，它将如何使整个系统停止工作？

不，不一定。您可以拥有一个非常有弹性的整体，具有低耦合模块，例如可以进行异步通信。如果一个模块发生故障，那么其他模块将不会停机，而是等待它变为可用或重试和/或使用断路器或您使用的任何机制来避免级联故障。

或者，您可以使用微服务架构，其中单个微服务会导致整个应用程序崩溃（即级联故障）。

  

如果确实如此，那么在微服务架构中如何解决这个问题呢？微服务转换意味着将单个文件拆分为多个文件，每个文件执行一个特定的操作。请求是针对这些许多不同的模型文件。由于该特定服务与其他服务之间的依赖关系仍然存在，它是否也不会使系统在微服务架构中失效？

它没有。微服务无法解决您的不良（如非弹性）架构。

使用微服务的主要优点是，您可以独立于其他微服务部署和发展一个微服务，因为它们就像其他观点的黑盒子一样。只要微服务公开相同的API（或兼容的API），您就可以在任何给定时刻替换它或使用其他实现回滚。