一、哪些應用適合用在微服務上？

沒有太標準的說法，主要看應用的實際情況。

1、應用希望使用在雲場景下。

首先這個應用是想用在雲的場景上的。這個是前提。在雲場景上應用會更靈活、更快上線。雲上有它自身的特點，比如雲上系統執行環境是容器或虛機，並不像傳統場景下是物理伺服器。這些要求導致應用是不是要用微服務。

2、應用本身很重很複雜，可以考慮使用微服務。

對於應用本身來說，如果特別簡單，也很靈活，在容器或者虛機場景下就很快使用，那就不需要使用微服務了，如果說容器本身就很重很複雜，有至少幾十個節點，曾經在一個伺服器搭建出來，可以考慮下用微服務。

微服務幫使用者實現故障機制：熔斷、容錯、隔離。達到故障迅速恢復。

微服務上過雲環境，在雲環境體系下就是放在容器下跟另一個容器中你的另一個元件去互動，你會發現不知道這個虛機或者這個容器的地址在哪裡，這樣就需要自己去實現訪問機制，但你在原來傳統的應用伺服器的場景下是固定的IP，在雲上容器IP會根據實際的情況變化。就比如你的節點或者虛機出現故障，它會掛掉，有自己的保護機制能夠拉起來，但是IP就會變。如果IP變掉，你的業務怎麼樣才能不出問題，這樣還是要結合具體的雲場景說。

在雲上用了微服務會碰到在雲上才會發生的故障，比如雲上的容器出了問題，這種場景下我們在傳統應用伺服器上出現的故障情況不同，比如有的時候是網路故障，有的時候是容器遷移了等其他原因。不否認雲上出故障的頻率比傳統物理機上要高，這裡就必須要有個故障保護機制，這個故障機制就需要這個應用自己去做，如果沒有用微服務的話。用了微服務，就會幫你實現故障機制：容錯、熔斷、隔離。微服務幫你做了你需要做的事情，不需要你再考慮，統一幫你解決這些問題。

在雲上可能會面臨如何去運維和定位問題這樣的一個場景。有的應用可能做了很強大的運維手段和系統，有的應用並沒有這麼強大，也有可能做了運維繫統，但是在雲上有些不符合的東西。比如說在物理機環境下運維繫統基於每個IP是固定，然後再構建你的運維繫統，但在雲場景下這個場景就不成立了，你的系統就不成立或者不適合。這就涉及到在雲上是如何運維，其中一種手段就是calling tracker業務呼叫鏈跟蹤，還有很多微服務的運維手段。Calling tracker 會記錄你的每一個元件，用了微服務之後，你的訊息都是經過微服務發的，能做到訊息跟蹤，並不需要你關注，只要你需要的時候開啟。它能幫你跟蹤每個應用的訊息鏈，幫你繪製拓撲圖：比如你元件相互的關係，幫你描繪每個相互關係的時間，比如XX毫秒在這個模組發出，進入這個模組，到另一個模組出來耗時多久，這些資訊都可以用Calling tracker繪製。經過這個拓撲關係繪製之後，你會發現你原來發現不了的問題，比如這個模組消費的時間最大，可能就是你效能消耗點在這裡；還有就是故障發生的時候，原來能走到的一個過程，現在走不到了，比如這條鏈，因為在訪問關係中這條鏈路的呼叫關係中斷了，這個就可以從微服務運維的介面上清晰地看到業務的互動過程，這個就是微服務裡面幫應用解決的一些問題。

二、微服務的管理和技術是如何實現的？

第二個問題就是我們是怎麼實現這個微服務的管理，實現微服務這個技術？裡面涉及到幾個主要的服務/架構。

稍微深入一點，在微服務架構裡面是有個伺服器的。這個伺服器相當於是擔任整個微服務所有資訊的管理，我們可以叫它service center。service center裡面有很多主要的功能點，首先就是一個服務註冊管理：首先要解決的就是把一個應用拆散之後，需要讓各個部件各個小模組之間能夠發現對方，然後能夠通過一個統一的機制找到對方的地址，然後傳送請求，所以這裡面服務中心這邊提供註冊發現的功能，我們這邊就叫service register。

然後在客戶端這邊有個發現的模組，這個模組就是現在微服務框架裡面提供一個微服務的功能，在客戶端是通過SDK，相當於是一個包，就java裡面的包類，然後引用一下，就可以在自己程式碼裡面使用微服務功能，使用起來比較簡單，如果是java語言的話，10-20行之內的程式碼就能用起來。主要引用它的jar包這樣一個SDK。這個邏輯在使用者這裡是看不到，是根據你給的資訊到服務註冊中心去發現你的服務，這個是呼叫者，也就是我們說的消費者：它說我要去訪問某個服務，就去服務中心拿到服務資訊，這邊就實現它的發現；這邊還有個提供服務的角色，就是provider，這個provider同樣在SDK裡面有個註冊的過程，註冊的過程就是註冊到註冊中心，註冊中心會發布這個服務。所以所有的釋出者在註冊中心註冊服務，所有的消費者在註冊中心發現服務，然後實現一個註冊發現。這個是最基本的能力。

第二個就是還會有一些對服務的管理，比如說對服務版本的管理，我們叫service manager，主要是一些資訊的管理，然後讓外部能夠查詢到，就是這邊有一個維護人員，或者是一個管理者看這個中心的有哪些註冊資訊，還有相關的一些服務的管理人員。

第三個就是配置管理。這個對於微服務框架來說也是比較重要的，因為一個應用可能會根據自己的業務調整自己的配置，所以它需要一些配置管理，所以我們需要提供一個配置中心，然後把它的配置同步到所有配置節點上，然後我們不需要逐個節點地管理自己的配置，這個是微服務裡面自然而然提供的一個功能。這個配置中心對微服務系統來說比較重要。

還有就是在因為我們主要的功能點在SDK上。在SDK裡面包含很多特性：比如說我們發現它，然後再解決兩個節點之間簡單地建立連線然後建立請求，這個都是在微服務SDK裡面提供的能力；還有就是解決微服務的監控和運維，因為我們把一個應用拆散之後，他們互相之間的呼叫關係、呼叫情況都需要給使用者一個視覺化的體現；另外需要解決服務治理，比如呼叫過程中異常，如何解決異常。

1服務治理；2、服務註冊發現；3、服務運維這幾個特性都會在SDK裡面體現。

服務治理的模組在這裡叫Business keeper，主要做的就是故障的容錯熔斷，還有就是資源隔離的特性；還有就是IPC(RESTFULL +RPC)，就是我們常說的訊息轉發的過程，通過它來把訊息傳送給遠端，再往下就是我們的calling tracker，就是用來做訊息跟蹤的。

逐個講一下關鍵特性在SDK裡面做了什麼事情：

Business keeper主要做的就是服務治理，首先是容錯。容錯就是向provider請求訊息，如果出錯了，可以有些策略，我們可以重發這個請求，或者說是找下一個節點，可能你當前訪問的節點是不正常的，不代表整個後端的所有節點都是不正常的，所以可以嘗試查詢下一個節點實現容錯，還有就是可以實現自己定製，就是根據自己的業務情況定製容錯處理。

第二就是熔斷，熔斷這部分更可以理解為一個解決依賴的問題。假如說一個後端服務不正常，可能一個訊息發出去，這個訊息內容可能要等到超時才能等到結果，熔斷就是為了解決這方面的問題，根據請求歷史狀態，提前判斷服務後端正不正常，通過這樣的中間控制保證不會因為後端服務不正常導致消費者大量無效的等待，以及等待造成的影響。這個也有自己的檢測機制能夠從熔斷狀態恢復過來。

第三個就是隔離，隔離就是消費者會可能會訪問不同的服務提供者，不同的服務提供者有不同的業務，隔離主要解決的問題就是當它訪問A 這個provider佔用資源和它訪問B服務訪問資源的時候能夠把資源隔離開，不會因為大量訪問B的業務不會導致consumer這邊的資源被耗盡，導致A這邊的業務無法執行，這是隔離這邊做的特性。

IPC就是訊息的構造和傳送，這部分的邏輯主要解決了把應用拆散後，相當於讓所有的功能元件之間有了網路的互動，這裡提供了這樣的模組就是讓你很方便建立元件與元件之間的通道，而不需要自己去構建訊息互動過程，這個模組主要是簡化在拆分微服務之後訊息的處理，就不需要每個開發者自己構建訊息通道，而是由微服務幫你維護和建立訊息通道。在這個訊息傳送過程中有個calling tracker也就是訊息跟蹤的處理，這個處理主要就是去跟蹤你一個業務請求訊息的過程，這個特性也是微服務裡面的一個特點，這種處理方式直觀上讓你知道前後排程的關係，讓你知道你的業務在每個節點上消耗的時間，還有走過的模組，這個比傳統應用上更直觀讓你瞭解業務的執行狀態，讓你瞭解業務消耗時間，定位你的問題。

這幾塊主要都是微服務的特性和功能點，回答如何把應用換成小模組以及之後如何解決訊息的互相訪問，和被拆散之後請求過程中出錯的處理方式，保障業務的正常執行。