容器化應用的服務可用性

本文講的是<b>容器化應用的服務可用性</b>【編者的話】高可用性的容器化應用是指服務可用性（連續運作時間）。本文介紹了如何借助于容器管理工具來監控和測量服務。

<a href="http://dockone.io/article/2626">【燒腦式Kubernetes實戰訓練營】本次教育訓練理論結合實踐，主要包括：Kubernetes架構和資源排程原理、Kubernetes DNS與服務發現、基于Kubernetes和Jenkins的持續部署方案 、Kubernetes網絡部署實踐、監控、日志、Kubernetes與雲原生應用、在CentOS中部署Kubernetes叢集、Kubernetes中的容器設計模式、開發Kubernetes原生應用步驟介紹等。</a>

我作為軟體工程師的第一份工作是在阿靈頓高地（Arlington Heights, IL）的摩托羅拉公司。工作是關于蜂窩基站軟體（cellular base station software ）開發，以前稱作為跨無線協定狀态管理（state management across different radio protocols）。對于電話軟體，99.999%的服務可用性是必需具備的（例如每年隻能有小于5.26分鐘的故障當機時間）。我在摩托羅拉和貝爾實驗室的後續幾年，學習了如何建立和運維高可用性系統。

在那個時代裡（約為90年代中期），高可用性系統需要昂貴且複雜的硬體，并且每個元件都得有個随時可用的備份。現在事情則變得容易多了。可以使用各種常見的硬體主機來主從備份應用元件，建立高可用性的系統。此外，使用容器來部署和運維，我們還可以獲得更快的系統恢複時間，如Kubernetes、Nirmata這樣的智能緩沖、精緻的容器管理工具能将系統恢複時間降低至幾毫秒。

然而，一直保持不變的是設計合理的系統管理需求，這包括管理系統所有元件的狀态更新。而且對于微服務應用來說，一個應用可能有多個服務組成，每一個服務可能有多個執行個體，實作可靠性和伸縮性的系統管理正變得越來越複雜，因為有很多不相關的元件需要來跟蹤和管理！讓我們來看一看如何使用Nirmata來解決這個複雜的挑戰。

為了管理服務可用性，我們首先需要知道三件事：

哪個元件對服務來說至關重要

每個元件可能有哪些狀态

如何定義和測量服務可用性

下圖是Nirmata的部分領域實體（對象）圖。如圖所示，Nirmata收集和管理的資訊既包含基礎設施相關的對象（雲供應商、主機、容器等），又包含軟體應用對象（應用、服務等）。

<a href="http://dockerone.com/uploads/article/20170829/a3b1bebba1739eb31932823a9c21d049.png" target="_blank"></a>

建立一個優雅的狀态模型需要及時更新每個對象的狀态資訊，同樣重要的是需要對跨對象間的依賴和聯系有深刻的了解。例如，由于主機重新開機導緻某個服務不可用，那麼這二者需要關聯起來并進行上報。

這樣的模型還能幫助我們區分嚴重問題與瞬間發生的故障。例如，某個容器的退出不會影響整個服務的可用性。實際上，服務編排引擎（orchestration engine）在多個服務執行個體上安排鏡像滾動更新時，容器退出是正常的。

一旦我們知道了跟蹤哪些實體，下一步就是定義和管理狀态，及狀态間的轉換。在Nirmata，每個對象有兩個主要狀态和幾個次要的過渡狀态。主要狀态有：

運維狀态：這個狀态代表對象目前是否可運維或者可以如何運維。例如“上線”、“下線”、“故障”組成了一個對象的可運維狀态模型。

管理狀态：這個狀态是由使用者或者管理者來管理的。例如，“關閉”、“暫停”是由使用者觸發的。

除了主要狀态，每個對象可以有幾個次要狀态。這些狀态是跟對象相關的，它們提供了更多的細節資訊。例如，在Nirmata大多數管理的對象有“執行狀态”，表示一個系統維護正在執行。

這裡是一些在Nirmata中應用裡服務有可操作狀态：

正在運作：服務的所有執行個體健康并且正在運作

降級：服務的一些執行個體已經故障，或者正在執行某些操作

正在執行：服務的所有執行個體正在執行更改

故障：服務的所有執行個體已經産生故障

<a href="http://dockerone.com/uploads/article/20170829/7641127a53bab9f7f40de35ce611536b.png" target="_blank"></a>

現在我們有了服務的狀态模型，跟蹤可用性就變得簡單多了。在Nirmata，可用性是通過服務正在執行或降級時間占用總時間的比例來計算的。同樣的方法也應用在應用級别的傳播狀态。未來版本，我們計劃允許使用者自己定義應用中每個服務如何被應用到整體的服務可用性計算中。

下面我們來看下Nirmata裡的環境視圖。每個環境可能有多個應用，每個應用都有自己的可用性，同時我們也可以看到該環境的整體可用性。

<a href="http://dockerone.com/uploads/article/20170829/d207a98f8d61201572e934ed92c24eae.png" target="_blank"></a>

向下拉動，可以容易的看到特定應用的可用性。Nirmata還展示了應用的相關狀态轉換，并辨別出應用的故障原因。

<a href="http://dockerone.com/uploads/article/20170829/a6a4ec588d0424b9ae806d58f64d116e.png" target="_blank"></a>

這裡我們可以看到單個服務視圖和它的狀态變化：

<a href="http://dockerone.com/uploads/article/20170829/a98e28e2a4738ba5864c5cc68a40d2b0.png" target="_blank"></a>

容器化微服務應用的可用性管理是複雜的，因為有很多項需要衡量和跟蹤。而且，衡量系統可用性需要一個良好定義的狀态模型。對象狀态需要在跨實體設施和軟體實體間可管理、可關聯和可傳播。

使用合适的系統管理平台，才有可能衡量、跟蹤并報告服務、應用或者環境的可用性。運維人員通過聚焦于服務可用性，可輕易地實作“信噪分離”，隻關注影響服務的問題。

<b>原文釋出時間為：</b>2017-08-29

<b>本文作者：</b>姜俊厚

<b>本文來自雲栖社群合作夥伴Dockerone.io，了解相關資訊可以關注Dockerone.io。</b>

<b></b>

<b>原文标題：</b><b>容器化應用的服務可用性</b>