摘要：架構的選擇對於DevOps的實踐是至關重要的，從某種程度上來說，架構就是DevOps這場戰役的糧草，它是支撐著DevOps成功落地的重要前提。

善用兵者，役不再籍，糧不三載。取用於國，因糧於敵，故軍食可足也。

——《孫子兵法》

在古代，帶兵作戰的將領，不僅要能善於用兵，而且要能保障糧食的充足。正所謂兵馬未動，糧草先行。糧草永遠擺在第一位，因為在冷**時代，戰爭中的將士都是在拼力氣，吃飽才有力氣打仗。

在今天網際網路的“戰爭”環境中，我們為了能更快的應對市場變化，一直以來不斷調整著作戰的方針和打法，也從傳統的開發方式轉變為了敏捷開發，由敏捷開發又過渡了到DevOps。在2019年的中國DevOps行業報告中指出：“儘管受訪企業期望 DevOps 能夠帶來更高效的交付效率，提升客戶滿意度，創造更多的商業價值，但成功實踐 DevOps 依然是一個難題 。”

其中28.22% 被調查者認為自己組織的 DevOps 實踐是不成功的， 41.13%的被調查者不清楚如何衡量自己組織的 DevOps 實踐是否成功。如果以一個更加直觀的資料來展示，就是在接受調查的企業中有69.35%是沒有能很好的瞭解和實踐DevOps的。

也許，在實踐DevOps的這幾年來，並沒有多少公司是真正知道什麼是DevOps的。DevOps只是從字面上理解的打破部門牆的一鍵釋出的工具鏈嗎，是否有了這個工具鏈就是DevOps？答案是否定的。

那麼，DevOps是什麼？

DevOps 是集文化理念、實踐和工具於一身，可以提高組織高速交付應用程式和服務的能力，與使用傳統軟體開發和基礎設施管理流程相比，能夠幫助組織更快地發展和改進產品。這種速度使組織能夠更好地服務其客戶，並在市場上更高效地參與競爭——AWS

從AWS給出的定義來看，好像也還是比較的抽象。那如果簡單的來說，DevOps就是讓軟體過程既“快”又“穩”。

何為快和穩，這個快和穩體現在，部署頻率、交付週期、平均修復時長、變更失敗比例這4個維度上。

在2018年的DevOps調查報告中基於上述4個維度，由於僅有6%達到了所規定的高效能指標，為了避免特殊原因造成資料過低，所以放寬的條件，並給出了準高效能DevOps指標。

從達成這一準高效能DevOps指標的團隊分析來看，其具體體現在三個方面：一方面是自動化、標準化、質量保證、敏捷方法的實踐活動上；一方面是DevOps各個階段的對應工具上。除此以外就是，團隊正在開發應用的架構上。

架構的選擇對於DevOps的實踐是至關重要的，從某種程度上來說，架構就是DevOps這場戰役的糧草，它是支撐著DevOps成功落地的重要前提。受訪的準高效能DevOps指標的團隊將“使用微服務框架”作為團隊正在開發應用的架構上的Top1。

什麼是微服務

是一種軟體架構風格，它是以專注於單一責任與功能的小型功能區塊 (Small Building Blocks) 為基礎，利用模組化的方式組合出複雜的大型應用程式，各功能區塊使用與語言無關 (Language-Independent/Language agnostic) 的 API 集相互通訊。

微服務的起源是由 Peter Rodgers 博士於 2005 年度雲端計算博覽會提出的微 Web 服務 (Micro-Web-Service) 開始，Juval Löwy 則是與他有類似的前導想法，將類別變成細粒服務 (granular services)，以作為Microsoft下一階段的軟體架構，其核心想法是讓服務是由類似 Unix 管道的訪問方式使用，而且複雜的服務背後是使用簡單URI來開放介面，任何服務，任何細粒都能被開放 (exposed)。這個設計在 HP 的實驗室被實現，具有改變複雜軟體系統的強大力量。

2014年，Martin Fowler與James Lewis共同提出了微服務的概念，定義了微服務是由以單一應用程式構成的小服務，自己擁有自己的行程與輕量化處理，服務依業務功能設計，以全自動的方式部署，與其他服務使用 HTTP API 通訊。同時服務會使用最小的規模的集中管理 (例如Docker) 能力，服務可以用不同的程式語言與資料庫等元件實現。

微服務的特點

根據Martin Fowler的分析，微服務架構有以下的一些通用特性，但並非所有微服務架構應用都必須具備所有這些特性：

1. 通過服務實現應用的元件化(Componentizationvia Services)：微服務架構中將元件定義為可被獨立替換和升級的軟體單元，在應用架構設計中通過將整體應用切分成可獨立部署及升級的微服務方式進行元件化設計。
2. 圍繞業務能力組織服務(Organizedaround Business Capabilities)：微服務架構採取以業務能力為出發點組織服務的策略，因此微服務團隊的組織結構必須是跨功能的（如：既管應用，也管資料庫）、強搭配的DevOps開發運維一體化團隊，通常這些團隊不會太大（如：亞馬遜的“Two pizza team”- 不超過12人）。
3. 產品而非專案模式(Productsnot Projects)：傳統的應用模式是一個團隊以專案模式開發完整的應用，開發完成後就交付給運維團隊負責維護；微服務架構則倡導一個團隊應該如開發產品般負責一個“微服務”完整的生命週期，倡導“誰開發，誰運營”的開發運維一體化方法。
4. 智慧端點與管道扁平化(Smartendpoints and dumb pipes)：微服務架構主張將元件間通訊的相關業務邏輯/智慧放在元件端點側而非放在通訊元件中，通訊機制或元件應該儘量簡單及鬆耦合。RESTful HTTP協議和僅提供訊息路由功能的輕量級非同步機制是微服務架構中最常用的通訊機制。
5. “去中心化”治理(DecentralizedGovernance)：整體式應用往往傾向於採用單一技術平臺，微服務架構則鼓勵使用合適的工具完成各自的任務，每個微服務可以考慮選用最佳工具完成(如不同的程式語言)。微服務的技術標準傾向於尋找其他開發者已成功驗證解決類似問題的技術。
6. “去中心化”資料管理(DecentralizedData Management)：微服務架構倡導採用多樣性持久化(PolyglotPersistence)的方法，讓每個微服務管理其自有資料庫，並允許不同微服務採用不同的資料持久化技術。
7. 基礎設施自動化(InfrastructureAutomation)：雲化及自動化部署等技術極大地降低了微服務構建、部署和運維的難度，通過應用持續整合和持續交付等方法有助於達到加速推出市場的目的。
8. 故障處理設計(Designfor failure)：微服務架構所帶來的一個後果是必須考慮每個服務的失敗容錯機制。因此，微服務非常重視建立架構及業務相關指標的實時監控和日誌機制。
9. 演進式的設計(EvolutionaryDesign)：微服務應用更注重快速更新，因此係統的計會隨時間不斷變化及演進。微服務的設計受業務功能的生命週期等因素影響。如某應用是整體式應用，但逐漸朝微應用架構方向演進，整體式應用仍是核心，但新功能將使用應用所提供的API構建。再如在某微服務應用中，可替代性模組化設計的基本原則，在實施後發現某兩個微服務經常必須同時更新，則這很可能意味著應將其合併為一個微服務。

微服務適用的場景

基於微服務的優勢，我們可以看到，微服務比較實用於以下場景：

1. 對於業務流程較為複雜，且業務會變得逐漸複雜的專案，可以考慮使用微服務架構
2. 專案存在多個團隊（公司）多種開發語言時
3. 核心業務和非核心業務變得涇渭分明
4. 需要平滑升級時（服務無中斷、客戶無感知）
5. 想對系統進行細粒度監控時 （bug調查困難或效能等問題）

既然微服務有其使用的場景，那麼也一定有其優缺點。

微服務的優勢

微服務的誕生正是在網際網路高速發展，技術日新月異變化以及傳統架構無法適應快速變化等多種因素共同推動下的必然產物。從一個網站的演變可以看到使用微服務後帶來了很多優點，總結如下：

• 邏輯清晰：這個特點是由微服務的單一職責的要求所帶來的。邏輯清晰帶來的是微服務的可維護性，在我們對一個微服務進行修改時，能夠更容易分析到這個修改到底會產生什麼影響，從而通過完備的測試保證修改質量。
• 簡化部署：微服務則可以只對一個微服務單獨進行部署，不影響其他功能的同時，在效率上也得到了提升，從而快速的釋出新的功能。
• 可擴充套件性強：在分散式系統中，採用微服務的系統相對單塊系統具備更好的可擴充套件性。
• 靈活組合減少浪費：在微服務架構中，可以通過組合已有的微服務以達到功能重用的目的，減少了重複浪費。
• 技術異構：微服務間鬆耦合，不同的微服務可以選擇不同的技術棧進行開發。

微服務的缺點

以往單體應用，排查問題通常是看一下日誌，研究錯誤資訊和呼叫堆疊。而微服務架構整個應用分散成多個服務，定位故障點非常困難。在微服務架構中，一個服務故障可能會產生雪崩效用，導致整個系統故障。微服務架構雖然邏輯設計上看是完美的，但就像積木搭建的華麗宮殿一樣，經不起風吹草動。微服務架構雖然解決了舊問題，也引入了新的問題：提高了系統的複雜度，此外還有：

1. 服務的註冊與發現問題；
2. 服務之間的分散式事務問題；
3. 資料隔離再來的報表處理問題；
4. 服務之間的分散式一致性問題；
5. 服務管理的複雜性，服務的編排；
6. 不同服務例項的管理。

微服務在使用上是一把“雙刃劍”，這就像糧草如果在搬運的過程中被敵方奪取，那可能會是毀滅性的。所以DevOps團隊在微服務的架構上需要非常的重視，一個成熟度高的微服務框架才是實現其DevOps的重要前提，反之亦然。

本文分享自華為雲社群《沒有它你的DevOps是玩不轉的，你信不？》，原文作者：敏捷的小智。

點選關注，第一時間瞭解華為雲新鮮技