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