微服务与单片架构转换

作者: 时间
发布时间: 2024-04-18 04:30:43 (1月前)
转自：

3 条回复

0#
回复此人
不浪漫罪名 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <BLOCKQUOTE> 单片架构的一个缺点是，一个错误的功能将导致整个系统崩溃。如果其中一个功能停止按预期工作，它将如何降低整个系统？ </BLOCKQUOTE> 不，不一定。你可以拥有一个非常有弹性的巨石，低耦合的 模块 </强> 例如，异步通信。如果一个模块发生故障，那么其他模块将不会停机，而是等待它变为可用或重试和/或使用断路器或您使用的任何机制来避免级联故障。 或者，您可以使用微服务架构，其中单个微服务降低整个应用程序（即级联故障）。 <BLOCKQUOTE> 如果确实如此，那么在微服务架构中如何解决这个问题呢？微服务转换意味着将单个文件拆分为多个文件，每个文件执行一个特定的操作。请求是针对这些许多不同的模型文件。由于该特定服务与其他服务之间的依赖关系仍然存在，它是否也不会使系统在微服务架构中失效？ </BLOCKQUOTE> 它没有。微服务无法解决您的不良（如非弹性）架构。 使用微服务的主要优点是，您可以独立于其他微服务部署和发展一个微服务，因为它们就像其他观点的黑盒子一样。只要微服务公开相同的API（或兼容的API），您就可以在任何给定时刻替换它或回滚另一个实现。 </DIV>

编辑
1#
回复此人
十二* | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 好吧，单片应用程序将所有内容都放在一个文件结构中，作为一个应用程序。不一定在一个文件中。 运行微服务有许多优点。但你是对的，他们仍然需要工作。 微服务通常包含一组可以一起交谈的api，如果你采用有限范围的Facebook，他们可能有一个api用于帖子，另一个用于喜欢，另一个用于存储，如果图片，身份验证等等。并且一个巨大的优势是能够根据负载进行放大和缩小。 开发时，您的范围有限，因此如果一个模块不稳定，您不会丢弃整个代码库。您可以部署新版本，而不依赖于成千上万的人（在facebook的情况下）。你可以拥有不同技能的开发人员，如果你在java，php，python等中做这件事并不重要。您还可以为任务选择最佳技术。重新编写代码片段更容易，因为通常很容易指定微服务应该做什么。 借助云，我非常确定微服务将成为可以部署在云中的所有服务的标准。因为优势如此之大，以至于企业必须睁开眼睛。 </DIV>

编辑

登录后才能参与评论