什么应用可以用在微服务上

1、应用希望使用在云场景下。

首先这个应用是想用在云的场景上的。这个是前提，我个人认为。在云场景上应用会更灵活、更快上线。云上有它自身的特点，比如云上系统运行环境是容器或虚机，并不像传统场景下是物理服务器。这些要求导致应用是不是要用微服务.

2、应用本身很重很复杂，可以考虑使用微服务。

对于应用本身来说，如果特别简单，也很灵活，在容器或者虚机场景下就很快使用，那就不需要使用微服务了，如果说容器本身就很重很复杂，有至少几十个节点，曾经在一个服务器搭建出来，可以考虑下用微服务。

微服务帮用户实现故障机制：熔断、容错、隔离。达到故障迅速恢复。

微服务上过云环境，在云环境体系下就是放在容器下跟另一个容器中你的另一个组件去交互，你会发现不知道这个虚机或者这个容器的地址在哪里，这样就需要自己去实现访问机制，但你在原来传统的应用服务器的场景下是固定的IP，在云上容器IP会根据实际的情况变化。就比如你的节点或者虚机出现故障，它会挂掉，有自己的保护机制能够拉起来，但是IP就会变。如果IP变掉，你的业务怎么样才能不出问题，这样还是要结合我们的云场景说。

在云上用了微服务会碰到在云上才会发生的故障，比如云上的容器出了问题，这种场景下我们在传统应用服务器上出现的故障情况不同，比如有的时候是网络故障，有的时候是容器迁移了等其他原因。不否认云上出故障的频率比传统物理机上要高，这里就必须要有个故障保护机制，这个故障机制就需要这个应用自己去做，如果没有用微服务的话。用了微服务，就会帮你实现故障机制：容错、熔断、隔离。微服务帮你做了你需要做的事情，不需要你再考虑，统一帮你解决这些问题。

在云上可能会面临如何去运维和定位问题这样的一个场景。有的应用可能做了很强大的运维手段和系统，有的应用并没有这么强大，也有可能做了运维系统，但是在云上有些不符合的东西。比如说在物理机环境下运维系统基于每个IP是固定，然后再构建你的运维系统，但在云场景下这个场景就不成立了，你的系统就不成立或者不适合。这就涉及到在云上是如何运维，其中一种手段就是calling tracker业务调用链跟踪，还有很多微服务的运维手段。Calling tracker 会记录你的每一个组件，用了微服务之后，你的消息都是经过微服务发的，能做到消息跟踪，并不需要你关注，只要你需要的时候打开。它能帮你跟踪每个应用的消息链，帮你绘制拓扑图：比如你组件相互的关系，帮你描绘每个相互关系的时间，比如XX毫秒在这个模块发出，进入这个模块，到另一个模块出来耗时多久，这些信息都可以用Calling tracker绘制。经过这个拓扑关系绘制之后，你会发现你原来发现不了的问题，比如这个模块消费的时间最大，可能就是你性能消耗点在这里；

还有就是故障发生的时候，原来能走到的一个过程，现在走不到了，比如这条链，因为在访问关系中这条链路的调用关系中断了，这个就可以从微服务运维的界面上清晰地看到业务的交互过程，这个就是微服务里面帮应用解决的一些问题。