微服務專欄地址

目錄

1. 簡介

　　本文的核心是理解概念與流程，沒有涉及多少具體是實際操作層面的內容，後續有計劃會整理相關內容，持續交付流水線也是一塊很大的內容，需要實際探索、實踐、總結出最適合的方案。文章的內容大多數整理於《微服務架構於實踐-王磊》，一本結合實際操作為主的介紹微服務架構實踐。從一下幾個方面對微服務與持續交付進行理解：
1. 簡介
2. 什麼是持續交付
3. 什麼是持續交付的核心
4. 微服務與持續交付有什麼關係
5. 如何構建一套微服務持續交付流水線
5.1 涉及哪些環節
5.2 每個環節具體包含哪些
5.2.1 開發
5.2.2 測試
5.2.3 持續整合
5.2.4 構建
5.2.5 部署
5.2.6 運維

2. 什麼是持續交付

從技術上講，持續交付是軟體系統的構建、部署、測試、稽核、釋出過程的一種自動化實現，而其中的核心則是部署流水線。因為部署流水線能夠將這幾個環節有效地連線起來。

3. 什麼是持續交付的核心

持續交付的核心在於三個字：小、頻、快。

在持續交付過程中，需求以小批量形式在團隊的各個角色間順暢流動，並以較短的週期完成小粒度的頻繁釋出。實際上，頻繁的交付不僅能持續為使用者提供價值，而且能產生快速的反饋，幫助業務人員制定更好的釋出策略。

• 小批量價值流動 ：通過建立自動化的構建及部署機制，將業務功能以小批量的方式，從需求產生端移動到使用者端。
• 頻繁可釋出：通過建立自動化的構建及部署機制，將小批量的業務功能頻繁地從需求產生端移動到使用者端，持續地交付價值。
• 快速反饋：通過建立高效的反饋機制，快速驗證需求是否有效。同時根據反饋，及時指導業務團隊並調整策略，優先為使用者交付高價值的功能。

4. 微服務與持續交付有什麼關係

在微服務架構中，由於每個服務都是一個獨立的、可部署的業務單元，因此，每個服務也應該對應著一套獨立的持續交付流水線，可謂是“麻雀雖小，五臟俱全”。

從交付的角度來分析，對於任何一個可部署的獨立單元，它都應該有一套獨立的部署流水線，來有效支撐其開發、測試、構建、部署與運維的整個過程。

5. 如何構建一套微服務持續交付流水線

5.1 涉及哪些環節

• 開發
• 測試
• 持續整合
• 構建
• 部署
• 運維

5.2 每個環節具體包含哪些

5.2.1 開發

• 獨立程式碼庫：
  
  • 對於每一個服務而言，其程式碼庫和其他服務的程式碼庫在物理上應該是隔離的。所謂物理隔離，是指程式碼庫本身互不干擾，不同的服務有不同的程式碼庫訪問地址。
  • 對某服務的程式碼進行修改，完全不用擔心影響其他服務程式碼庫中的程式碼，在很大程度上避免了修改一處，導致多處發生缺陷的情況。
• 服務說明檔案 ：
  
  • 服務介紹：服務提供什麼功能、誰是服務的消費者
  • 服務維護者：挑選1~2個團隊的成員，作為服務的負責人，登記其姓名、電子郵件、電話等聯絡方式，以便其他團隊遇到問題能及時找到服務的負責人
  • 服務可用期限：服務可用週期、可用率、響應時間
  • 定義環境（描述服務執行的具體環境） :生產環境、類生產環境、測試環境
  • 描述開發相關的資訊：如何搭建開發環境、如何執行服務、如何定位問題
  • 描述測試相關的資訊：測試策略、如何執行測試、如何檢視測試的統計結果，譬如測試覆蓋率、執行時間、效能等。
  • 描述持續整合以及構建相關的資訊：持續整合訪問的URL、持續整合的流程描述、構建後的部署包
  • 描述部署相關的資訊：如何部署到不同環境、部署後的功能驗證
  • 描述運維相關的資訊：日誌聚合的訪問、告警資訊的訪問、監控資訊的訪問、程式碼所有權歸團隊、有效的程式碼版本管理工具、程式碼靜態檢查工具、易於本地執行

5.2.2 測試

• 整合測試的二義性：對於任何一個服務而言，單元測試必不可少。但是否需要整合測試，團隊可以根據喜好自行決定。
• Mock與Stub：對於單元測試而言，我們可以使用Mock框架幫助我們完成對依賴的模擬（Mock）或者打樁（Stub），譬如Java的Mockito、Ruby的RSpec等。
• 介面測試：除了單元測試覆蓋程式碼邏輯外，至少還應該有介面測試來覆蓋服務的介面部分。注意，對於服務的介面測試而言，更關注的是介面部分。譬如，作為資料的生產者，介面測試需要確保其提供的資料能夠符合消費者的要求。作為資料的消費者，介面測試需要確保，從生產者獲取資料後，能夠有效地被處理。另外，對於服務與服務之間的互動過程，最好能設計成無狀態的。
• 測試的有效性：如果單元測試的覆蓋率夠高，介面測試能有效覆蓋服務的介面，那麼基本上測試機制就保障了服務所負責的業務邏輯以及和外部互動的正確性。

5.2.3 持續整合

持續整合經過多年的發展，已成為系統構建過程中眾所周知的最佳實踐之一。對於每個獨立的、可部署的服務而言，應為其建立一套持續整合的環境（Continuous Integration Project）。

• 當團隊成員向服務的程式碼庫提交程式碼後，配置好的持續整合工程會通過定期重新整理或者WebHook的方式檢測到程式碼變化，觸發並執行之前開發階段定義的靜態檢查、程式碼度量、測試以及完成構建的步驟。
• 常用的企業級持續整合伺服器有Jenkins、Bamboo以及GO等，線上的持續整合平臺有Travis-CI、Snap-CI等。

5.2.4 構建

每個服務都是一個可獨立部署的業務單元，經過靜態檢查、程式碼度量、單元測試、介面測試等階段後，構建符合需求的部署包。

• 部署包存在的形式是多種多樣的，可以是deb包、rpm包，能在不同UNIX作業系統平臺直接安裝；也可以是zip包、war包等，只需將其複製到指定的目錄下，執行某些命令，就可以工作。當然，也有可能是基於某特定的IAAS平臺，譬如亞馬遜的AMI，我們稱之為映像包（Image）。
• 另外，作為容器化虛擬技術的代表，Docker（一個開源的Linux容器）的出現，允許開發者將應用以及依賴包打包到一個可移植的Docker容器中，然後釋出到任何裝有Docker的Linux機器上。
• 通過使用Docker，我們可以方便地構建基於Docker的部署映象包。

5.2.5 部署

對於每個獨立的服務而言，如果希望構建獨立的持續交付流水線，需要選擇部署環境並制定合適的部署方式來完成部署。通常，我們可以從如下兩個維度考慮如何進行部署。

1. 部署環境
   
   • 基於雲平臺
   • 基於IAAS層
   • 基於PAAS層
   • 基於資料中心
   • 基於容器技術
2. 部署方式
   
   • 手動部署
   • 指令碼部署
   • 基礎設施部署自動化
   • 應用部署自動化
   • 映像部署
   • 容器部署

5.2.6 運維

由於每個服務都是一個可以獨立執行的業務單元，同時每個服務都執行在不同的獨立節點上。因此，需要為服務建立獨立的監控、告警、快速分析和定位問題的機制，我們將它們統一歸納為服務的運維。

• 監控
  
  • 系統監控：系統監控關注服務執行所在節點的健康狀況，譬如CPU、記憶體、磁碟、網路等
  • 應用監控：關注應用本身及其相關依賴的健康狀況，譬如服務本身是否可用、其依賴的服務是否能正常訪問等
• 告警：當系統出現異常時，通過監控能發現異常。這時候，通過合適的告警機制，則能及時、有效地通知相關責任人，做到早發現問題，早分析問題，早修復問題。由於每個服務都是獨立的個體，因此針對不同的服務，都應該能提供有效的告警機制，確保當該服務出現異常時，能夠準確有效地通知到相關責任人，並及時解決問題。告警工具：PagerDuty
• 日誌聚合：由於微服務架構本質上是基於分散式系統之上的軟體應用架構方式，隨著服務的增多、節點的增多，登入節點檢視日誌、分析日誌的工作將會耗費更高的成本。通過日誌聚合的方式，能有效將不同節點的日誌聚合到集中的地方，便於分析和視覺化

6. 補充

限於沒有實際經驗，只能通過資料和報的相關課程來了解學習持續交付，學以致用，學以致用，學以致用！！！

本文絕大部分摘錄與《微服務架構與實踐-王磊》！！！