十三：對微服務與持續傳遞之整體的了解

微服務專欄位址

　　專欄：微服務

　　微服務系列總目錄

目錄

• 微服務專欄位址
• 目錄
• 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 運維
• 6. 補充

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. 補充

限于沒有實際經驗，隻能通過資料和報的相關課程來了解學習持續傳遞，學以緻用，學以緻用，學以緻用！！！

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