微服務下的持續交付環境

背景

隨着互聯網行業的興起，敏捷開發、Devops被愈來愈多的公司說起或實施，力求有效地下降交付過程所耗費的成本並提升交付的效率。 持續交付經過創建自動化的構建、測試、部署機制，實現業務快速上線的過程。 在微服務架中，因爲每一個服務都是一個獨立的，可部署的單元，由一個服務或多個服務組合對外提供服務，服務拆分粒度更細、服務之間依賴更加的複雜，服務的開發、測試、上線也必將帶來更大的挑戰。

微服務環境下持續交付面臨的挑戰

任何事情都有兩面性，在享受微服務便利的同時，也必須面對微服務交付所帶來的挑戰。 常常聽到你們聊到微服務架構時，聊得最多的是服務的拆分、實施微服務時採用的框架、技術選型、K8S、SpringCloud等等，所見到微服務架構項目，大多都沒有真正作到「服務的獨立部署」。 這裏的的「獨立部署」並不只僅是簡單的自動化部署，自動化部署相對簡單，經過一些自動化工具、腳本等咱們能夠作到自動化部署。而微服務爲何不能簡單的作到獨立部署，不是「不能部署」而是「不敢部署」。

• 微服務依賴關係錯綜複雜，沒有依賴的統一管理和依賴檢查。
• 微服務是雖然在物理上被拆分紅多個小的服務，但從交付角度來看仍以一個總體對外提供服務。
• 無統一的視圖對開發、測試、生產環境的各個階段進行管理。
• 服務上線後無完備的手段對服務的監控、安全、容災、擴縮容、流量保護等。

所以微服務的實施不光是Devops的過程，更是一套生態環境、一套標準化開發、測試、生產上線的流程。

須要達成的目標

在持續交付中，咱們須要構建一個標準交付流程，將開發、測試、運維、實施以及用戶結合成一個總體。咱們但願：

• 讓軟件構建、部署、測試和發佈過程對全部人可見，促進合做。
• 有效的反饋，以便在整個過程當中，咱們可以儘早地發現並解決問題。
• 經過預約義流程保障不一樣角色在本身關注的領域內正確、高效的完成任務。
• 使團隊可以經過一個徹底自動化的過程在任意環境上部署和發佈軟件的任意版本。

怎樣實施

整合公司現有基礎設施平臺（持續構建平臺、容器雲平臺、監控平臺、網關平臺、微服務編程框架）結合微服務的特性，抽象定義了服務的整個生命週期， 從服務的定義、構建、依賴鑑權、部署、提測、發佈、回收等各個階段以流程的形式來規範開發、測試、運維等角色在各自領域的職責。

服務定義

在整個微服務的生命週期內，從微服務的定義開始，服務元數據會保存到分佈式和版本化配置系統，爲了規範在微服務環境中服務對外表述咱們將從如下方面來定義服務：

• 服務統一描述符
• 服務依賴標識
• 服務維護者
• 服務受權級別
• 服務證書、祕鑰
• 服務開發、測試、生產各環境地址
• 服務監控大盤地址

服務初始化事件：

• 調用監控組件生成服務的監控大盤模板、服務健康拔測任務
• 調用容器雲平臺生成服務證書、公鑰、私鑰、服務黑白名單
• 調用網關平臺綁定服務域名

服務構建

xx是微服務環境下的編程框架，不只僅只是高性能的Web容器，更重要的實現了服務治理的能力，提供了監控日誌埋點、Metric、Trace等能力...

服務構建會基於編程框架的特性做如下動做：

• 掃描服務依賴列表
• 掃描API列表（爲統計和追蹤API提供更精確的API管理，排除Restful格式下PathVariable干擾）
• 檢查開發框架分區版本
• 排除依賴Jar包的檢查

服務構建以自定義插件掃描的方式輸出服務依賴列表、API列表、檢查開發框架分區版本、排除依賴Jar包檢查等動做能最大限度的保障在微服務環境下 服務定義的完整性、依賴描述的準確性，提早避免部署運行時的兼容性。

服務依賴受權

在微服務環境下，咱們提供了一套標準的基於TLS的訪問控制策略。經過服務構建時掃描出的依賴服務列表，在服務部署以前須要先申請對被依賴服務的受權申請，被依賴服務(維護者)經過受權申請後 自動進入標準受權流程完成對依賴服務的受權操做。

關於認證和受權 詳見：

服務部署

微服務環境中部署一個應用是很大的挑戰，不可以像單體應用同樣要求服務多副本部署，能正常啓動就好了。 在微服務環境裏因爲一個應用由多個微小的服務組成並對外提供統一的服務，服務之間的相互依賴關係、服務之間的訪問控制權限、服務對資源的消耗、服務健康檢查機制、服務上下游拔測手段、服務之間流量管理等問題將是咱們不得不面對和解決的。

咱們經過標準化流程管理組件來觀察和規範服務部署、資源回收、線上運維等流程，標準化流程管理組件會將各事件抽象成「元語」，將「元語」下發到各組件執行並根據執行狀況來串聯起整個流程。 根據開發、測試、生產運維環境需求咱們制定了以下流程：

• 部署流程
• 藍綠部署流程
• 服務受權流程
• 灰度流量調整流程
• 回收流程
• 藍綠回收流程
• 強制回收流程

這裏咱們將以部署流程來重點講解，其主要節點包括：資源規劃、前置檢查、資源申請、服務部署、功能驗證、服務准入等操做。

資源規劃

將一個應用拆分爲多個微服務，每個微服務單獨部署，服務數量會成倍增長，所以有必要在部署時對消耗的資源進行規劃，不然會形成資源的極大浪費，增長公司運營成本。

在資源規劃時不能簡單粗爆的限制CPU、內存、磁盤、網絡帶寬等，咱們應該根據服務的特性把服務劃分爲不一樣的類型，好比：IO密集型、CPU密集型等，這樣提交給容器雲平臺（資源調度）時能將服務正確的調度到不一樣類型的NODE節點上。

前置檢查 && 資源申請

在部署以前除了進行一系列檢查外還須要申請並臨時鎖定申請到的資源，防止在部署的過程當中其它服務搶佔資源形成部署失敗，主要包括以下幾點：

• 構建結果檢查
• 依賴服務受權檢查
• 配置文件檢查
• 可用資源（CPU、內存、磁盤）申請（鎖定資源） 檢查是否有足夠的資源支持本次部署（容器雲平臺）
• 域名資源申請（鎖定域名）衝突檢查（網關平臺）
• 監控模板是否生成，服務健康拔測任務是否正常 （監控平臺）

服務部署 && 功能測試

當完成上述前置檢查和資源申請後進入到部署環節，容器雲平臺接收到部署事件後開始驗證部署計劃並執行部署計劃完成部署，部署執行完成後驗證部署結果。

• 容器是否啓動完成
• 服務註冊是否成功
• 服務配置（框架、業務、流量、依賴等）是否拉取正確（全局時鐘檢查）
• 上下游服務是否正常訪問（依賴受權檢查）
• 服務健康檢查

服務准入

完成服務部署及功能測試後進入到服務准入階段，咱們就能夠導入流量完成服務准入了，因爲一些服務既做爲邊界服務又做爲其它服務的被依賴服務，在微服務環境下咱們拆內網准入和外網准入兩個概念。

內網准入：

微服務環境內依賴和被依賴關係，爲了便於描述咱們稱被依賴服務爲「服務端」，依賴服務稱爲「客戶端」，服務端服務須要被客戶端服務發現，客戶端服務調用服務端服務的流量規則等都屬於內網准入的範圍。

外網准入： 做爲邊界或邊緣服務而言，網關平臺綁定域名與部署實例，分配流量規則、流量比例等操做屬於外網准入的範圍。

在服務部署及功能測試經過後，由持續交互組件（Hooke）下發准入命令，部署服務將其置爲準入狀態，這樣「客戶端」就能發現剛剛部署好的服務，網關平臺接收到准入命令後開始掛載域名分配流量規則等操做完成服務的整個部署。

資源回收

微服務環境下的交付最重要的是儘可能減小流量的損失，下降出錯機率，提升服務的可用性，除了部署流程外當一個服務須要下線，或者當部署過程當中出錯後咱們須要進入到資源回收流程。

資源回收流程與部署流程正好相反，主要節點包括：中止健康拔測、禁止容器調度、解綁域名、內網彈出（微服務環境內不能被發現）、狀態驗證、服務Shutdown、回收容器、釋放資源

資源回收流程又分爲普通回收流程、藍綠回收、強制回收流程等，在服務部署過程的不一樣階段對應不一樣的回收流程，這時不做詳細介紹。

服務配置管理

服務在上線和部署過程當中，出現問題最多的是配置管理問題，爲了最大限度的減小開發、測試、生產環境部署的差別性特做以下規定：

• 一次部署對應一次配置
• 配置的生成由開發環境產生，是否「環境敏感」、是否「可動態下發」的配置項須要顯示的標明
• 配置以K-V的形式保存隨提測、發佈流程流轉到其它分區環境
• 配置項在提測、生產環境部署時不能被新增、刪除、修改，配置項的值能夠修改
• 環境敏感項在提測、生產環境須要確認和修改
• 運行時配置變動和下發僅限於 標明 「可動態下發」的配置項
• 完成配置下發配置版本自動更新，並可回滾到歷史配置版本

環境分區與提測發佈流程

爲了儘量的保證開發、測試、生產環境服務表述的一致性，減小因環境形成的上線差別性，同時基於對環境隔離、權限認證、資源規劃的考慮， 劃分爲3套環境（開發、測試、生產）和8個環境分區。

分區提測： 開發並自測完成後提交提測發佈計劃：選擇將要提測到的測試分區，提測流程會做服務分區初始化，依賴服務分區受權等檢查，完成檢查後生成分區提測單。

分區發佈： 在提測經過後，根據提測發佈計劃提起發佈流程，一樣的在發佈流程中咱們也會做服務分區初始化，依賴服務分區受權檢查及配置文件流轉確認等，而後生成分區發佈單。

特別說明一下：爲了儘量的在測試中靠近生產，盡最大限制減小因網絡等環境因素形成的差別性，不一樣的測試分區對應不一樣的生產分區，原則上部署在同一中心。 好比說提測到北京測試分區的服務上線也只有上到北京生產分區

總結

本文中咱們瞭解到在微服務環境下持續交付所面臨的問題與挑戰，同時也大體清楚了在微服務環境中爲了持續交付咱們所付出的努力，最後再強調一下：微服務環境下的持續交付並非自動化的devops ，其核心仍是有沒有規範和流程去保證微服務正確的獨立部署。

參考

• Microservice Architecture（https://martinfowler.com/articles/microservices.html）
• The Twelve Factors （https://12factor.net）
• Challenges of micro-service deployments