1.4 云原生應用

云原生應用程序的關鍵在于提供彈性、敏捷性、可操作性和可觀察性。彈性的概念隱含了允許應用程序失敗而不是試圖阻止程序失敗的意思。敏捷性允許應用快速部署和快速迭代，這就需要引入DevOps文化。可操作性是指從應用程序內部控制應用程序的生命周期，而不是依賴外部進程和監視器。可觀察性是指應用程序需要提供信息以反映應用程序的狀態。目前實現云原生應用程序所需特性的常用方法有：

● 微服務。

● 健康狀況報告。

● 自動測量數據。

● 彈性。

● 聲明模式而不是響應模式。

1.4.1 微服務

傳統應用程序是以單個實體為目標進行管理和部署的，這也是國內軟件行業常用的開發方式，簡稱為單體應用程序。單體應用程序的好處是顯而易見的，但是它無法解決面向大量互聯網用戶提供服務的并發量問題，且使得開發過程變得臃腫，開發進程變得緩慢，維護也越來越困難。

解決這些問題最好的方法之一就是分解單體應用為眾多小的服務模塊。如圖1-5所示，這些服務模塊相互獨立，使得開發人員可以獨立維護這些小系統，而且開發和維護過程也變得敏捷。分解成微服務后，各服務的編寫語言也可以自行確定，只需要遵守總體的API優先和通信要求即可。

微服務更像是UNIX哲學的實踐和改造。UNIX哲學是“程序應該只關注一個目標，并盡可能把它做好。讓程序能夠互相協同工作。”例如UNIX命令行上的統計文件數量，通過下面的命令管道就可以把列表和統計兩個命令串聯起來使用。

微服務也是如此，服務更專注于其用途，也就是只應做一件事，并把這件事做好。

但是微服務不能等同于云原生架構，微服務只是云原生文化的一種實現。

1.4.2 健康狀況報告

為了能夠由軟件控制一切，應用程序必須提供可供管理軟件監測的度量指標。而一個應用程序的度量指標只有創建應用程序的作者最清楚，因此在應用程序中內置度量指標是最好的設計方式。這要求各應用程序提供必要的端點，供管理軟件訪問以判斷應用程序狀態。例如Kubernetes、ETCD都通過HTTP提供了大量的度量指標。

此外，應用程序應該提供更加豐富且必要的狀態報告。在云原生架構下，一切皆是代碼，一切皆可由軟件控制。為了可以控制，各應用程序必須提供度量接口讓管理軟件獲知應用程序運行狀態以做出必要的反應，例如應用程序崩潰時，管理程序可做出停掉當前應用程序實例然后啟動新實例的操作。應用程序的健康狀況只是能夠自動執行應用程序聲明周期的一部分，管理程序還需要知道應用程序是否正在工作。

1.4.3 自動測量數據

自動測量數據是做出決定所必需的信息，這些數據與健康狀況報告的數據是有重疊的，但是它們的用途不一樣。健康報告是告知管理程序所轄應用程序的生命周期狀態，而自動測量數據是告知應用程序的業務度量指標。

度量的指標一般稱為服務級別指標（Service Level Indicator，SLI）或關鍵績效指標（Key Performance Indicator，KPI）。這些指標是特定于應用程序的數據，讓管理程序監測應用程序的性能在服務級別目標（Service Level Objectives，SLO）內。自動測量數據可以解決以下問題：

● 應用程序每分鐘收到的請求數。

● 是否有任何錯誤。

● 應用程序延遲多久。

● 業務處理需要多長時間。

監測數據經常被抓取或推送到時間序列數據庫（如Prometheus或InfluxDB），然后再由度量指標模型進行處理分析，以便后續提醒或者大屏展示。

有一點需要注意的是，自動測量數據應該用于提醒場景而不是健康監測。在一個動態可自我修復的環境中，管理程序幾乎不關心單個應用程序的生命周期，而更多關心應用程序的SLO，因為若是一個程序崩潰，管理程序可以動態重啟應用程序實例以恢復正常運行狀態。

舉一個例子，在Kubernetes中運行以下命令可以看到coredns重啟過兩次和3次，但是管理程序不關心這個行為，只關心它是否在正常運轉，因為管理程序的SLO就是要正常運轉。

1.4.4 彈性處理故障

云原生應用程序應當正視故障而不是竭力避免故障。唯一不應該有故障的系統是那些維持生命的系統。任何系統都應該有一個合理的SLO，如果無視SLO而去避免故障發生，則花費的成本將非常巨大。為此，必須假設應用程序可能發生故障，并采取必要的措施應對故障，這是云原生應用的一種模式。

無論發生什么樣的故障，云原生應用都必須適應，并采取合理的調整措施應對。

此外，云原生應用還需要設計一種方法應對過載，這也是互聯網應用面臨的常見問題，例如12306售票、淘寶雙11活動時的并發訪問過載。處理過載的一種常見方法是適度降級。在《Site Reliability Engineering》一書中對于應用程序的優雅降級做了詳細描述。書中指出在負載過重的情況下，可以采取降低準確性、反饋少量數據等方式給用戶適度響應，而不是拒絕服務。

盡管減少應用程序負載可以通過負載均衡設備或者動態擴展等基礎架構進行處理，但是應用程序仍有可能接收到超負載的請求。所以云原生應用要求具備服務優雅降級的能力。最現實的處理方式是服務降級，返回部分回應或使用本地緩存中的舊信息進行回應。

這部分內容在Service Mesh中得到了很好的解決。

1.4.5 聲明式通信

由于云原生應用程序在云環境中運行，因此它們與基礎架構和支持應用程序的交互方式與傳統應用程序不同。在云本機應用程序中，與任何內容進行通信的方式都是通過網絡。很多時候，網絡通信是通過RESTful HTTP調用完成的，但也可以通過其他接口實現，例如遠程過程調用（RPC）。

傳統應用程序可以通過消息隊列、共享存儲上的文件或觸發shell命令的本地腳本來自動執行任務。事件發生后，通信方法根據本地服務器上的信息做出反應。例如，如果用戶點擊提交，則運行本地服務器上的提交腳本。

在傳統應用程序中，通信的介質可能是文件或者消息隊列，但是這些方式都是嘗試構建避免失敗的方式，它們在云原生架構下存在一些問題。例如應用程序把結果寫入到文件，寫完后應用程序崩潰了。此時會出現了一種情況：應用程序崩潰之前，計算結果已經寫入文件中。按照云原生理念，此時應用程序將重啟，再次執行計算過程，計算結果再次寫到文件中。因此，開發人員應該停止使用反應式通信，開始使用聲明式通信，從而提高應用程序的健壯性，并且減少應用程序的依賴。