Zabbix 5.2由浅入深系列之Proxy篇

优点

• 安全的迁移单体应用程序到微服务
• 可以并行地迁移已有功能和开发新功能
• 迁移过程可以更好把控节奏

缺点

• 在现有的单体应用服务和新的微服务之间共享数据存储变得具有挑战性
• 添加 Facade （API 网关）将增加系统延迟
• 端到端测试变得困难

何时使用 Strangler

• 将大型后端单体应用程序的增量迁移到微服务
• 何时不宜使用 Strangler
• 如果后端单体应用很小，那么全量替换会更好。
• 如果无法拦截客户端对遗留的单体应用程序的请求。

可用技术示例

API 网关后端应用框架。

断路器

在微服务架构中，微服务通过同步调用其他服务来满足业务需求。服务调用会由于瞬时故障（网络连接缓慢、超时或暂时不可用） 导致失败，这种情况重试可以解决问题。然而，如果出现了严重问题（微服务完全失败），那么微服务将长时间不可用，这时重试没有意义且浪费宝贵的资源（线程被阻塞，CPU 周期被浪费）。此外，一个服务的故障还会引发整个应用系统的级联故障。这时快速失败是一种更好的方法。

在这种情况，可以使用断路器模式挽救。一个微服务通过代理请求另一个微服务，其工作原理类似于电气断路器，代理通过统计最近发生的故障数量，并使用它来决定是继续请求还是简单的直接返回异常。
 

Amazon API 网关， Azure API 管理， Apigee， Kong， WSO2 API 管理器

Strangler

如果想在运行中的项目中使用微服务架构，我们需要将遗留的或现有的单体应用迁移到微服务。将现有的大型在线单体应用程序迁移到微服务是相当有挑战性的，因为这可能破坏应用程序的可用性。

一个解决方案是使用 Strangler 模式。Strangler 模式意味着通过使用新的微服务逐步替换特定功能，将单体应用程序增量地迁移到微服务架构。此外，新功能只在微服务中添加，而不再添加到遗留的单体应用中。然后配置一个 Facade （API 网关）来路由遗留单体应用和微服务间的请求。当某个功能从单体应用迁移到微服务，Facade 就会拦截客户端请求并路由到新的微服务。一旦迁移了所有的功能，遗留单体应用程序就会被“扼杀（Strangler）”，即退役。

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!