把乙個大的單體應用拆分成多個微服務之後，每個服務都可以獨立進行開發、測試和運維。但當拆分的微服務足夠多時，卻又彷彿陷入乙個新的泥沼，無論是業務**的開發還是測試和運維，工作量都比之前提公升了很多。
採單體應用架構時，乙個業務需求只需要修改單體應用的**，然後針對這個單體應用進行測試，測試通過後再把單體應用的**發布到線上即可。而拆分為微服務之後，乙個大的系統被拆分為多個小的系統，乙個業務需求可能要同時修改多個微服務的**，這樣的話多個微服務都需要進行測試，測試通過了都需要把**發布到線上，顯然工作量成倍增加。這時候就迫切需要一種新的開發、測試和運維模式來解決這個問題，這就是今天我要給你講的微服務與devops。
在介紹devops之前，我先來帶你回顧一下傳統的業務上線流程：開發人員開發完業務**後，把自測通過的**打包交給測試人員，然後測試人員把**部署在測試環境中進行測試，如果測試不通過，就反饋bug給開發人員進行修復；如果通過，開發就把測試通過的**交給運維人員打包，然後運維人員再發布到線上環境中去。可見在傳統的開發模式下，開發人員、測試人員和運維人員的職責劃分十分明確，他們往往分屬於不同的職能部門，一次業務上線流程需要三者之間進行多次溝通，整個週期基本上是以天為單位。你肯定會想假如能夠把開發、測試和發布流程串聯起來，就像生產流水線上那樣，每個步驟完成後，就自動執行下乙個步驟，無須過多的人為干預，業務的迭代效率不就能提公升很多嗎。
沒錯，devops的思想正是如此。在我看來，devops是一種新型的業務研發流程，業務的開發人員不僅需要負責業務**的開發，還需要負責業務的測試以及上線發布等全生命週期，真正做到掌控服務全流程。devops就是下圖中心的部分，集開發、測試和運維三者角色於一體。
而要實現devops，就必須開發完成**開發後，能自動進行測試，測試通過後，能自動發布到線上。對應的這兩個過程就是ci和cd，具體來講就是：
其中cd還有另外乙個解釋就是持續交付（continuous delivery），它與持續部署不同的是，持續交付只需要做到**達到線上發布要求的階段就可以了，接下來的**部署到線上既可以選擇手動部署也可以選擇自動部署。實際服務發布時，**能否自動部署到線上本身並不是難點，關鍵在於是否需要人為判斷整個發布過程是否正常，畢竟有些異常只有在真正的線上發布過程中才能被發現，人為介入相對來說要保險一些，所以只做到持續交付也可以算是實現了devops。
devops的關鍵是如何實現**開發自測通過，自動部署到測試環境，驗證通過後再自動部署到生產環境，小流量驗證後再自動發布到線上去。在傳統的採用物理機部署服務的時代，這個流程的很難自動化執行的最大原因就是**環境的可移植性差，這是因為開發自己的環境，跟測試環境以及生產環境的軟體配置往往存在很大差異，經常會出現開發在自己的環境中執行通過的**，部署到測試環境就執行不了的問題。而容器化正好解決了**環境的可移植性的問題，使得devops取得了突飛猛進的發展，並成為業界推崇的開發模式。那麼具體該如何實現devops呢？下面我就以微博的業務實踐為例，來給你詳細講解。
目前業界比較通用的實現devops的方案主要有兩種，一種是使用jenkins，一種是使用git
lab。微博就主要使用的是gitlab來實現devops，下面我就從微博乙個服務的開發、測試到上線的具體流程，看看是如何實現devops的。
從上面圖中你可以看到，乙個服務的發布流程主要包含了三個步驟。
1.持續整合，這個步驟的主要作用是確保每一次**的merge request都測試通過，可隨時合併到**的develop分支，主要包括四個階段：build階段（開發分支**的編譯與單元測試）、package階段（開發分支**打包成docker映象）、deploy階段（開發分支**部署到測試環境）、test階段（開發分支**整合測試）。
2.持續交付，這個步驟的主要作用是確保所有**合併merge request到develop分支後，develop分支的**能夠在生產環境中測試通過，並進行小流量灰度驗證，可隨時交付到線上。主要包括五個階段：build階段（develop分支的**編譯與單元測試）、package階段（develop分支的**打包成docker映象）、deploy階段（develop分支的**部署到測試環境）、test階段（develop分支的**整合測試）、canary階段（develop分支的**的小流量灰度驗證）。
3.持續部署，這個步驟的主要作用是合併develop分支到master主幹，並打包成docker映象，可隨時發布到線上。主要包括四個階段：build階段（master主幹的**編譯與單元測試）、package階段（master主幹的**打包成docker映象）、clear階段（master主幹的**merge回develop分支）、production階段（master主幹的**發布到線上）。
那麼，上面這些流程是如何實現自動化的呢？在gitlab中可以通過乙個叫「.gitlab-ci.yml」的檔案來定義自動化流程都包含哪些階段，以及每個階段所具體執行的指令碼，這樣的話在提交**merge request後會自動觸發gitlab-ci.yml檔案中定義的各個流程按順序執行。
上面我講了具體業務中如何使用gitlab來實現devops，在具體實施時，每個階段都有關鍵問題，只有解決了這些關鍵問題，才能真正實現devops。
1.持續整合階段
持續整合階段的主要目的是保證每一次開發的**都沒有問題，即使合併到主幹也能正常工作，這裡主要依靠三部分的作用。
除此之外，還有乙個值得關注的問題，就是整合測試階段業務**部署的測試機器從何而來。在單體應用的時候，一般是開發把**打包交給測試，測試人員再分配給自己的測試機中部署業務，然後進行整合測試。但是現在問題來了，由於拆分成了微服務，需要測試的服務變多了，如果同時有多個需求在測試，測試人員的測試機可能就不夠用了，而出於成本考慮，一般公司都不會花費採購大量的測試機器。乙個好的辦法就是通過kubernetes之類的容器平台對測試集群進行管理，當有業務**正在執行整合測試時，就從測試集群中建立乙個容器部署服務，完成測試後，再銷毀容器，及時進行資源**。這樣測試機器不需要分配給某個具體的個人，實現按需使用，提高了測試集群的資源使用率。
2.持續交付階段
持續交付階段的主要目的是保證最新的業務**，能夠在類生產環境中可能夠正常執行，一般做法都是從線上生成環境中摘掉兩個節點，然後在這兩個節點上部署最新的業務**，再進行整合測試，整合測試通過後再引入線上流量，來觀察服務是否正常。通常需要解決兩個問題：
curl -s -d action=503&ip=11.75.21.155&service_pool=openapi_friendship-yf-docker&user=weibo_rd_user持續部署階段的主要目的把在類生產環境下執行通過的**自動的發布到線上所有節點中去，這裡的關鍵點就在於實際的線上發布階段並不是想象中的那麼直接。以微博api的業務為例，同樣的服務也分為核心池和非核心池，核心池提供給移動端和pc呼叫，非核心池提供給其他內部業務呼叫，並且還按照機房分為不同的服務池，比如永豐機房服務池和土城機房服務池。實際發布的時候，考慮到線上服務的穩定性，並不是說按照一定的步長，自動把所有服務池都發布了，而是先發布非核心池以及土城機房的核心池，然後驗證觀察一段時間線上服務一切正常後，再繼續發布永豐機房的核心池，以防止某些問題在服務發布的過程中才暴露出來，但又不至於影響線上所有的服務節點。所以這個階段，持續部署一般並不要求那麼完美，許多公司在這個階段都採用了手動發布的方式以控制風險，或者只做到持續交付階段，對於持續部署並不要求自動化。
今天我給你介紹了devops對於微服務的意義，它通過將開發、測試和運維流程自動化，以減輕微服務拆分後帶來的測試和運維複雜度的提公升，同時還提高了業務研發的效率。為了實現devops，需要實現持續整合、持續交付以及持續部署，可以採用jenkins或者gitlab這些開源devops工具來搭建你自己的ci/cd流程，關鍵點在於如何把已有的自動化測試用例，以及現有容器管理平台整合到ci/cd流程當中去，以完成自動化的ci/cd流水線處理。
微服務 學習筆記 DevOps
帶無阿潑斯 devops維基百科定義 devops development和operations的組合詞 是一種重視 軟體開發人員 dev 和 it運維技術人員 ops 之間溝通合作的文化 運動或慣例。透過自動化 軟體交付 和 架構變更 的流程，來使得構建 測試 發布軟體能夠更加地快捷 頻繁和可靠。...
微服務devops 用於微服務的安全DevOps
微服務devops 容器和微服務徹底改變了應用程式開發和基礎架構管理。他們還提出了新的安全挑戰，而沒有解決舊的挑戰。有哪些新的安全挑戰，您可以如何應對？微服務正在改變一切。不變的基礎架構，無共享架構和容器化應用程式 微服務 是當今大多數企業路線圖的重點。微服務提供了一種以小型，自治且可自我維持的能力...
如何實現微服務架構
一 技術選型 相對單體應用的交付，微服務應用交付要複雜得多，不僅需要開發框架支援，還需要一些自動化部署的工具，以及iaas paas或caas的支援。下面從開發和執行平台兩個維度考慮挑選技術選型 1 開發框架的選擇 可使用spring cloud作為微服務開發框架。首先，spring cloud具備...