什么應用可以用在微服務上
1、應用希望使用在云場景下。
首先這個應用是想用在云的場景上的。這個是前提，我個人認為。在云場景上應用會更靈活、更快上線。云上有它自身的特點，比如云上系統運行環境是容器或虛機，并不像傳統場景下是物理服務器。這些要求導致應用是不是要用微服務.
2、應用本身很重很復雜，可以考慮使用微服務。
對于應用本身來說，如果特別簡單，也很靈活，在容器或者虛機場景下就很快使用，那就不需要使用微服務了，如果說容器本身就很重很復雜，有至少幾十個節點，曾經在一個服務器搭建出來，可以考慮下用微服務。
微服務幫用戶實現故障機制：熔斷、容錯、隔離。達到故障迅速恢復。
微服務上過云環境，在云環境體系下就是放在容器下跟另一個容器中你的另一個組件去交互，你會發現不知道這個虛機或者這個容器的地址在哪里，這樣就需要自己去實現訪問機制，但你在原來傳統的應用服務器的場景下是固定的IP，在云上容器IP會根據實際的情況變化。就比如你的節點或者虛機出現故障，它會掛掉，有自己的保護機制能夠拉起來，但是IP就會變。如果IP變掉，你的業務怎么樣才能不出問題，這樣還是要結合我們的云場景說。
在云上用了微服務會碰到在云上才會發生的故障，比如云上的容器出了問題，這種場景下我們在傳統應用服務器上出現的故障情況不同，比如有的時候是網絡故障，有的時候是容器遷移了等其他原因。不否認云上出故障的頻率比傳統物理機上要高，這里就必須要有個故障保護機制，這個故障機制就需要這個應用自己去做，如果沒有用微服務的話。用了微服務，就會幫你實現故障機制：容錯、熔斷、隔離。微服務幫你做了你需要做的事情，不需要你再考慮，統一幫你解決這些問題。
在云上可能會面臨如何去運維和定位問題這樣的一個場景。有的應用可能做了很強大的運維手段和系統，有的應用并沒有這么強大，也有可能做了運維系統，但是在云上有些不符合的東西。比如說在物理機環境下運維系統基于每個IP是固定，然后再構建你的運維系統，但在云場景下這個場景就不成立了，你的系統就不成立或者不適合。這就涉及到在云上是如何運維，其中一種手段就是calling tracker業務調用鏈跟蹤，還有很多微服務的運維手段。Calling tracker 會記錄你的每一個組件，用了微服務之后，你的消息都是經過微服務發的，能做到消息跟蹤，并不需要你關注，只要你需要的時候打開。它能幫你跟蹤每個應用的消息鏈，幫你繪制拓撲圖：比如你組件相互的關系，幫你描繪每個相互關系的時間，比如XX毫秒在這個模塊發出，進入這個模塊，到另一個模塊出來耗時多久，這些信息都可以用Calling tracker繪制。經過這個拓撲關系繪制之后，你會發現你原來發現不了的問題，比如這個模塊消費的時間最大，可能就是你性能消耗點在這里；
還有就是故障發生的時候，原來能走到的一個過程，現在走不到了，比如這條鏈，因為在訪問關系中這條鏈路的調用關系中斷了，這個就可以從微服務運維的界面上清晰地看到業務的交互過程，這個就是微服務里面幫應用解決的一些問題。