一、哪些应用适合用在微服务上?
没有太标准的说法,主要看应用的实际情况。
1、应用希望使用在云场景下。
首先这个应用是想用在云的场景上的。这个是前提。在云场景上应用会更灵活、更快上线。云上有它自身的特点,比如云上系统运行环境是容器或虚机,并不像传统场景下是物理服务器。这些要求导致应用是不是要用微服务。
2、应用本身很重很复杂,可以考虑使用微服务。
对于应用本身来说,如果特别简单,也很灵活,在容器或者虚机场景下就很快使用,那就不需要使用微服务了,如果说容器本身就很重很复杂,有至少几十个节点,曾经在一个服务器搭建出来,可以考虑下用微服务。
微服务帮用户实现故障机制:熔断、容错、隔离。达到故障迅速恢复。
微服务上过云环境,在云环境体系下就是放在容器下跟另一个容器中你的另一个组件去交互,你会发现不知道这个虚机或者这个容器的地址在哪里,这样就需要自己去实现访问机制,但你在原来传统的应用服务器的场景下是固定的IP,在云上容器IP会根据实际的情况变化。就比如你的节点或者虚机出现故障,它会挂掉,有自己的保护机制能够拉起来,但是IP就会变。如果IP变掉,你的业务怎么样才能不出问题,这样还是要结合具体的云场景说。
在云上用了微服务会碰到在云上才会发生的故障,比如云上的容器出了问题,这种场景下我们在传统应用服务器上出现的故障情况不同,比如有的时候是网络故障,有的时候是容器迁移了等其他原因。不否认云上出故障的频率比传统物理机上要高,这里就必须要有个故障保护机制,这个故障机制就需要这个应用自己去做,如果没有用微服务的话。用了微服务,就会帮你实现故障机制:容错、熔断、隔离。微服务帮你做了你需要做的事情,不需要你再考虑,统一帮你解决这些问题。
在云上可能会面临如何去运维和定位问题这样的一个场景。有的应用可能做了很强大的运维手段和系统,有的应用并没有这么强大,也有可能做了运维系统,但是

本文探讨了微服务在云环境中的适用性,强调了云场景下微服务的必要性,如故障隔离、容错和熔断机制。此外,介绍了FusionStage PaaS平台的微服务管理,包括服务注册发现、版本管理、配置管理和服务治理。重点阐述了Business Keeper在服务治理中的角色,如容错、熔断和隔离功能,以及IPC和Calling Tracker在消息跟踪和运维中的作用。
最低0.47元/天 解锁文章
1万+

被折叠的 条评论
为什么被折叠?



