作者介紹
張真，宜信技術研發中心進階架構師，負責基礎系統架構演進與優化、服務治理、監控平台、微服務建設、devops平台、自動化測試架構及電子簽約、短信、郵件等應用系統。早年就職于ibm中國研發中心，負責ibm websphere應用伺服器的設計與開發。目前主要關注微服務架構實施，微智能設計思想應用，虛拟化技術應用，共識計算研究。
一、服務情景感覺與監控
高效的服務運維需要實作對服務的有效監控。微服務計算平台在設計上考慮了兩個方面：
服務運作的監控
服務上下文的監控
1服務運作的監控
服務運作的監控是針對服務處理能力的監控，正常的名額包括吞吐量（qps）,響應時間，錯誤，響應碼等等。
我們采用了自動發現+自動捕獲的方式：
服務能力實作架構中http服務架構除了可以被畫像以外，也天然內建了名額計數器。
在服務接口運作的過程中，各種名額計數器被更新。
基礎服務能力“服務監控捕獲”定期從http服務架構采集各個服務接口的名額資料并打包成監控資料。
服務監控捕獲會将監控資料通過消息隊列發送到具備服務能力“服務監控存儲”的計算節點。
當然實際上基于java的微服務計算節點，還會采集很多jvm的名額，它們包括heap各個區的使用狀态，gc次數&累計時間，class加載情況，程序cpu占用率，線程使用狀況等。
監控資料采用json作為傳輸格式
2服務上下文的監控
服務上下文是服務計算節點運作環境，主要是系統層面的監控：cpu占用率，記憶體使用狀況，連接配接數量，相關端口的進出流量（kb），磁盤使用狀況等等。服務上下文的狀況會直接影響服務運作的性能以及健壯性。
微服務計算中的情節感覺
首先，每個服務計算節點通過服務能力“運作環境感覺”調用各種系統功能來擷取監控資料。這些系統功能一般包括三類：
系統指令：作業系統内置的指令，常用的有netstat，top，du，df。通過netstat可以獲得目前程序所有監聽端口以及連接配接數；通過top可以獲得目前程序的cpu占用率和記憶體消耗。通過df指令可以獲得各個挂載的磁盤消耗，du指令可以擷取節點程序占用的相關目錄的磁盤消耗。
系統api：擷取程序各個端口的進出流量，需要通過raw socket來截取。使用c或python程式設計調用raw socket api來實作。
系統目錄：linux系統所有系統行為基本上都有一組檔案對應。比如為了實作服務計算節點的自動值守或自重新開機，通過readlink讀取/proc/<程序id>/xx下的資訊，通過這些資訊可以建構任意程序的啟動指令。
通常來說，優先使用系統指令，因為原生，執行代價小；系統api是應對較為底層的監控資料擷取；系統目錄需要深入作業系統了解運作機理，代價最大，但是也最為準确。需要根據實際情況而定。
然後，運作環境感覺會将捕獲到的監控資料通過心跳用戶端發送給心跳服務端，再由心跳服務端交由服務能力“運作環境監控存儲”實作持久化。情景感覺資料是另一種心跳資料，之是以采用心跳系統來傳輸的原因是：
與服務注冊接口資料保持高度的時間同步性，因為微服務計算平台期望每個服務計算節點根據上下文監控資料進行自适應調整，這個話題也會在以後的分享專題中進行說明。
上下文監控資料無需“高頻”（間隔30秒~1分鐘）采集且名額數量固定，這意味着實際payload不大，這符合http攜帶資料的特性，也能保證其随多級心跳上行。
那麼為什麼服務監控資料是通過消息隊列傳輸，而不是使用心跳上行？主要是以下原因：
監控資料的使用方式不同：服務監控資料指導自動适應調節是依靠一段時間内的名額資料的聚集結果（比如平均值，求和值等），這也可以消除系統誤差，而非依靠“瞬時”資料，而且這個過程需要服務監控數查詢提供運算支援；上下文監控資料是客觀反映服務計算節點的環境狀況，瞬時資料保證精确性，可以直接使用，反而一段時間的聚集結果會丢失精确性。
服務監控資料的資料量會遠遠大于上下文監控資料： 服務監控資料量=服務接口數量*名額個數*采集頻率。因為它采用頻率更高（間隔5秒~15秒），服務接口數量會遠遠大于服務計算節點數量，除了固定的一些名額外，可以包含業務名額，随之名額數量會增加許多。心跳系統不适合“重，多”的場景，而消息隊列适合資料payload大的場景，且一定程度保證資料有序。此外，消息隊列會持久化資料，防止由于接收端當機導緻的資料丢失。
二、服務調用的自适應機制
服務調用過程中往往會遇到各種異常。單體架構的年代，由于基本都是記憶體調用，幾乎很少遇到這類問題，隻有在跨系統的時候才會出現；到了soa的時代，逐漸出現了服務調用問題，不過主要是服務與服務總線（service bus）之間，服務連接配接到服務總線也缺少容錯機制。微服務架構出現以後，服務之間的依賴變得直接而且更多元化，面對龐大的服務接口如何使其更“平順，聰明，可靠”是一個必須解決的問題。
“服務熔斷”是微服務架構的熱詞之一，這本是個電力工程的術語，原意大緻是當輸傳入連結路電力過載時，為了保護下遊鍊路以及裝置，自動“熔斷”電力鍊路。最常見的就是保險絲機制。
那麼服務熔斷又是什麼含義呢？主要展現以下三個方面：
失效自動切換（failover）
失效隔離（isolation）
自動高效重試（retry）
如果再加上服務調用的負載均衡（load balance），其本質展現的是服務調用的自适應。
服務調用自适應基本模型
自适應機制的展現實際也是服務計算節點/服務接口的資源可用性的狀态轉化過程：
可用的計算節點/服務接口是能夠被負載均衡機制發現的；
服務調用中出現異常，調用方會切換好的資源，而異常的資源可能被隔離起來；
需要通過重試來确定異常的資源是否恢複，是否解除隔離；
重試成功的資源會解除隔離，變成可用狀态而被負載均衡機制發現；
多次重試都失敗的資源，可能被更”強”的隔離起來。
下面會分别解讀它們是如何實作的。
1負載均衡與失效自動切換
在微服務計算平台中，負載均衡與失效切換是密不可分的，這裡會放在一起說明。
負載均衡分為兩種模式：
代理模式：通過前置代理，代理向後對接服務計算節點，比如ngnix，haproxy。經典netflix微服務架構中的“服務網關”實際上也是一個代理，它對外是代理網關，對内則類似服務總線。
用戶端模式：由調用用戶端決定使用何種政策來通路目标服務。像dubbo，dubbox等就是使用zookeeper用戶端擷取服務位址清單，然後使用負載均衡政策來通路服務。
兩種模式沒有“絕對”的優劣之分，主要看适用場景。在微服務架構下，用戶端模式應該更加适合。
微服務計算平台中的負載均衡是由服務能力實作架構提供的一種通用型元件。無論是何種通信協定（http，rpc，rmi等）實際都可以統一成一種通用型元件。負載均衡的實質是對調用目标的政策，關于負責均衡的政策很多，也有很多實作算法，本節不做讨論。
它的處理機制是：
每個服務接口注冊以後，都可以通過服務注冊中心的api（對外暴露的服務，人工調用）來設定這些服務接口的負載均衡政策。
在服務發現的過程，調用方業務服務能力x除了可以獲得服務接口位址清單，還同時獲得了服務接口的負載均衡政策，此外還有失效切換政策。這麼做也可以實作政策的動态更新。
在負責輪轉的過程中，如果出現調用異常，則需要進行失效切換的操作。服務調用異常可分為四類：
服務接口位址無法連接配接
服務調用逾時異常: 目标服務計算節點可能程序存活，但由于某種原因無法響應或hang住。這中場景通常棘手，不容易第一時間發現，危害比服務計算節點挂掉更大，會拖延整個調用鍊路恢複的時間
業務處理異常（系統性，可恢複）：由于目标服務的處理過程以及上下文環境造成的異常，這種異常的特點是換一個同類型的服務計算節點異常可能就解決了。
舉個例子，電子簽章服務在處理檔案簽章時，需要一個臨時目錄來做暫存，如果因為某種原因使得該服務所在的機器上磁盤滿了，導緻臨時目錄無法寫入，這時簽章調用就會失敗。但如果切換到另外一個磁盤未滿的節點上，調用就成功了。
業務處理異常（業務資料引起，難以恢複）：目标服務的處理過程是“完好正确”的，但由于業務資料的問題（資料格式，資料内容缺失，資料一緻性等等）造成調用失敗。請注意，這類異常通常不能進行切換。
是以失效切換實質是對前三類異常進行切換，我們把切換分為兩類：
非通異常切換：針對連接配接不可用異常和調用逾時異常。
業務異常切換：針對系統性的業務處理異常。注意，這是用戶端模式獨有的切換方式，因為在代理模式下無法識别業務異常類型，甚至無法識别業務異常（例如業務上在響應封包中提示異常，但http響應碼仍然是200）。
前文在說明服務注冊與發現時提到了服務接口失效的快速回報，它為失效服務接口位址送出提供了通道，使得其他可能的調用方能夠不再去嘗試失效服務接口位址，也為失效資源隔離提供了全局視圖。
微服務計算平台還提供了一項“黑科技”，是基于動态服務編排的切換機制。這種切換機制可以不依賴與人工設定，它能夠自主的根據目标服務能力需求，全網同類型服務能力計算節點的運作狀況來做出決策，決定由哪個或哪些服務計算節點來完成計算任務。這會在以後的專題分享中進行解讀。
2自動高效重試
重試是服務接口失效後的補償操作，它的目的是為了确認失效資源是否“back online”。
微服務計算平台中的重試也是由服務能力實作架構提供的能力，也是通用型元件的一部分。我們把它設計成與負載均衡，失效切換一體化的機制：
首先，服務調用重試是由第一個發生對該服務接口進行失效切換的節點來嘗試，這個節點會緩存這個服務接口位址
在這個節點進行負載均衡的某次請求中，會再次傳回失效的服務接口位址，當然是以保證隻有這次請求的線程獲得，而其他并發請求的線程是按照正常的負載均衡政策進行的。之是以這樣做是因為：
1）無需引入額外資源來進行重試，沒有維護額外資源的代價
2）用盡可能小的代價進行重試，僅僅是某次請求的線程
在業務服務能力類型很多，且關聯複雜時，實際很難實作一個合适的重試機制。因為往往微服務之間的編排不像做一個網絡探測一樣容易
如果這次重試成功，調用方節點立即解除隔離，并将這個“好消息”上傳到服務注冊中心服務注冊中心則可以“通知”所有可能的調用方。
如果經過多次重試（失效切換政策決定）後仍然不成功，也将這個“壞消息”上傳到服務注冊中心，服務注冊中心會根據隔離政策進行相關的動作。
3失效隔離
失效隔離是有前提的，不一定所有調用失敗的服務接口都能隔離。這個前提是被隔離的服務接口不會對業務或資料一緻性産生影響。比如如果某個服務計算節點的某服務能力是作為分片持久化資料的一個節點，如果該節點被隔離可能造成分片錯誤，這時則不能隔離該節點。
失效隔離可以分為：
失效軟隔離（調用隔離）：在服務的可通路性上進行隔離。這種隔離是從調用方角度來考慮，而對失效額服務計算節點本身不會施加影響。比如讓某個服務接口位址從服務位址清單中消失。軟隔離應該是隔離場景中最常見的，也使用最多。
失效強隔離（資源隔離）：在服務使用的資源上進行隔離。這種隔離不僅僅從服務可通路性上，也會直接對失效的服務接口施加操作。比如如果因為磁盤寫錯誤問題造成某個服務計算節點上的某個服務能力出問題，則直接停止該服務能力，注意隻是停止了一個服務能力，而不是服務計算節點，除非該節點上所有服務能力都不可用，則應停止該節點。
微服務計算平台以失效軟隔離為主，也支援失效強隔離。它的處理機制是：
在服務注冊中心收到失效回報後，将服務注冊緩存中對應的服務接口資訊置為不可用，這樣在其他服務計算節點通過心跳下行重新整理位址清單時，該服務接口的位址将不可見。當然這中間會因為延遲，出現“二次失效回報”的現象，但由于每個服務計算節點會使用相同的失效切換政策，從業務上是保障正确的。
對于某些多次重試都失敗的服務計算節點，服務注冊中心會采用強隔離。由服務注冊中心直接調用該服務計算節點的管控接口（心跳也會注冊這個接口），送出停止服務能力指令
該節點的心跳用戶端收到指令後，調用服務能力生命周期管理api來停止服務能力。當然有時候失效隔離政策也是“挽救”政策。例如某個證書申請服務接口失效了，從經驗上講可能隻要重新開機一下就可以解決問題，那麼在設定隔離政策時，将隔離操作的指令改為停止并啟動其對應的服務能力，那麼最終該證書申請服務接口的服務能力是被重新開機了，當它被再次重試時，就會從強隔離中解除。
其實服務隔離除了失效隔離，還有一種是防禦隔離，也是“熔斷”的一部分，它不是因為服務失效，恰恰服務運作是正常的，而因為業務上或安全上的某個需求，主動進行隔離的方式，比如某些服務計算節點受到請求轟炸，為了避免業務鍊條癱瘓，将收到轟炸的服務計算節點停服。關于這方面的内容會與以後分享專題中的軟體定義服務叢集（sdsc）一起介紹。
三、總結
本文從經典的微服務治理系統的特點和問題出發，結合“微智能”思想，“拟社會化”分布式設計來考慮微服務計算平台的節點抽象模型。并在該模型基礎上就微服務計算的三項基礎：服務注冊與發現，服務情景感覺與監控，服務調用的自适應分别進行說明，如何落地微服務節點抽象模型。
當然微服務計算平台的建設還包括一些話題：
外部如何通路（內建問題），api網關的實作
服務之間的信任以及外部通路授權
服務sla如何量化，如何讓系統聰明的使用
動态服務內建與編排
動态計算編排
原文釋出時間為：2016-11-29
本文來自雲栖社群合作夥伴dbaplus