構建可複用的流水線步驟

　     構建可複用的伟德注册注步驟:

        微服務使得各個(ge) 服務相互獨立並能夠選用不同的技能方案，但這些優(you) 勢也是有價(jia) 值的。（1）開,發者在各個(ge) 團隊之間活動的難度增,大，因為(wei) 各個(ge) 團隊的技能棧或許差異巨大。（2）對於(yu) 工程師來說，分析和了解不同服務的功用和履行情況變得越來越困難和複雜。（3）開,發者需求花費更多的時刻投入到同一問題的不同完成（比方布置、日誌和監控）上。（4）人們(men) 或許會(hui) 孤登時做出一些技能決(jue) 策，存在部分優(you) 而非全局優(you) 的風險。為(wei) 了平衡這些風險並一起堅持技能的自由度和靈活性，咱們(men) 應該逐漸將服務運轉所需求的平台和東(dong) 西標準化。這樣做能夠保證，即使更換了技能棧，那些通用的籠統概念還是能夠與(yu) 不同服務堅持盡或許嚴(yan) 密的聯係。

　　運用微服務底座將通用的、和業(ye) 務邏輯無關(guan) 的功用進行籠統，比方監控和服務發現；運用Docker容器作為(wei) 標準化的服務布置工件；運用容器調度器Kubernetes作為(wei) 通用的布置平台。讀者相同能夠將這種辦法應用於(yu) 布置流水線。

　　進程式構建流水線和聲明式構建流水線目前所編寫(xie) 的流水線腳本有3個(ge) 缺點：特定的——這些腳本都是綁定到單個(ge) 代碼庫的，其他代碼庫並不能共用這些腳本；進程式——這些腳本顯式描述了所期望的構建履行進程；沒有內(nei) 部籠統——這些腳本假定用戶對Jenkins非常了解，比方怎麽(me) 啟動節點、履行命令和運用命令行東(dong) 西。

　　理想情況下，一個(ge) 服務布置流水線應該是聲明式的。工程師描述他們(men) 所期望履行的內(nei) 容（測試服務、發布服務等），而框架負責決(jue) 定怎麽(me) 履行這些進程。這種辦法一起會(hui) 抽離出對這些進程的履行進程的修正：假如讀者想調整某個(ge) 進程的工作，則能夠僅(jin) 更改底層框架完成。

　　將這些完成決(jue) 策從(cong) 服務中籠統出來，能夠提高整個(ge) 微服務應用的一致性。這個(ge) 腳本定義(yi) 了一些通用的配置信息（服務名稱）以及一係列進程（構建、測試、發布、布置），但是對服務開,發者而言，它隱藏了履行這些進程的複雜度。這樣任何一名工程師都能夠很快地遵從(cong) 佳實踐來快速且高,效地將新服務發布到生產(chan) 環境。

　　在流水線中，讀者能夠運用同享庫來完成聲明式流水線。因為(wei) 篇幅限製，本章並不會(hui) 對此展開深入介紹，但是本章的Github代碼庫包含了一個(ge) 流水線庫的例子。此外，文檔也供給了運用同享庫的具體(ti) 參考資料。