部署:持續集成（CI）與持續交付（CD）——《微服務設計》讀書筆記

    系列文章目錄：

    《微服務設計》讀書筆記大綱

 

一.CI（Continuous Integration）簡介

　　 CI規則1：儘可能頻繁地把代碼簽入到分支中以進行集成

　　CI規則2：不光要對語法進行驗，也要提供一系列的自動化來驗證

　　CI規則3：CI失敗後，要把修復CI當作第一優先級的事情

　　說明：做爲CI流程的一部分，咱們提供的製品應該每次只生成一次，而後在全部的部署一切使用，這不只避免屢次重複作一件事情，還能夠保證部署上線的製品與測試經過的那是同一個。

 

二.把CI映射到微服務

     這裏有幾種作法：

    作法1：全部的東西都放在一塊兒，向代碼庫的任何一次提交都會觸發構建，同時會構建出多個製品。

    通常來講，咱們絕對應該避免這個模式，但在項目初期是個例外。我即便只修改一個服務的一行代碼也須要進行總體的驗證和構建，事實上這有多是不須要的，這會影響CI的週期。

    作法2：將每一個CI映射到代碼庫中不一樣的目錄，這種作法比第一種好。

    作法3：每一個服務都有本身的代碼庫，都有本身的CI，這樣就更加獨立了。

 

三.CD（Continuous Delivery）簡介

     正如咱們項目組正在使用的PipeLine，這就是一個CD產品，它告訴咱們每一個步驟是否完成，距離最終的產品交付還有哪幾項，軟件質量的可視化獲得了極大改善。

     

 

四.製品的選擇

     Java能夠生成Jar包和War包，Ruby有gem，它們在運行的時候須要特定的環境，Chef、Puppet、Ansible是集中配置管理系統，支持一些通用技術棧的構建物部署。

     咱們也能夠選擇生成與操做系統相關的製品，如RedHat或CentOS的RPM、Ubuntu的deb包、Windows的MSIqn。使用操做系統的製品好處是，不須要考慮底層使用的是什麼技術，只須要簡單使用內置的工具就能夠完成軟件的安裝。

     若是使用自動化配置管理工具來管理環境問題，一個問題是，須要花費大量的時間運行這些腳本，它們會一遍遍地安裝 這些重複的工具，並且還可能有新的軟件加進來，其安裝時間會繼續被拉長。咱們可使用虛擬機鏡像，在部署軟件時，只須要根據鏡像建立一個實例，以後在其安裝最新的微服務便可，不須要再花費時間來安裝依賴，由於它們已經在鏡像中安裝好了，這樣能夠節省不少時間。但安裝鏡像也會花費不少時間，同時不一樣平臺的鏡像是不同的，咱們能夠經過Packer來解決這個問題，它能夠從Chef、Ansible、Puppet中的同一套配置中生成不一樣平臺的鏡像。

     那麼，咱們可能將微服務也包含在鏡像中，那麼當你啓動鏡像時，微服務就已經就緒了。

     但這同時也會帶來一個問題，有人會進生產服務器修改其中某一臺的配置，致使配置漂移問題，怎麼辦？應該禁止對任何運行的服務器作手動修改。

 

五.服務的配置管理

     對於不一樣的生產環境有不一樣的配置，咱們應該如何處理？應該最小化環境間配置的差別，好比用來鏈接數據庫的用戶名和密碼。

    另外，配置文件應該單獨管理，如IT部正在使用的JFrog製品庫。

 

六.服務與主機之間的映射

      這樣的形式有多種。

      第1種：單主機多服務

      這種方式簡單，可是也會存在挑戰，如監控困難，咱們不知道哪一個服務使用CPU的頻率更高一點，同時服務之間會形成影響，一個服務可能會形成系統資源用盡，這樣其餘服務也會有相應的影響。

      第2種：應用程序容器

      這種方式，從根本上說，是想試圖優化資源的使用，但如今雲服務的出現使得已經沒有必要了。

      這種方式將5個Java服務打包在一個容器（如Jetty）中，這樣不可避免地限制了技術的選擇，同時在聚合監控時也會難以支持。

      第3種：每一個主機一個服務

      這種方式很容易對服務進行擴展，安全性也能夠在更小的範圍內進行，但主機數據的增長也會是個問題。

      第4種：使用Pass（平臺即服務）

      Pass平臺會提供一些特定製品（如Java Jar包或Ruby 的gem等）的支持，還會幫你自動配置機器而後運行，可以透明地對系統進行彈性管理，容許你控制運行服務的節點數量，Pass平臺幫你處理其餘的工做。

 

七.如何管理微服務帶來的大量主機：自動化

       爲了讓你從衆多的服務器中解脫出來，你須要自動化，你須要寫一行代碼來啓動或開戶一個虛擬機，你須要可以自動部署軟件，你須要自動完成數據庫的變動。

      方法1：傳統的虛擬化技術

              

      如上圖所示，這就是傳統的虛擬化技術，在操做系統之上，存在着Hypervisor，它的任務主要有兩個，對CPU和內存資源作從虛擬主機到物理主機的映射和給上層提供一個控制的層，但Hypervisor也須要必定的資源來完成本身的工做，它也會佔用CPU、IO和內存等，Hypervisor主機越多，佔用的資源就越多。

      方法2：Vegrant

      這是一個部署平臺，一般在開發和測試環境中使用，能夠在一臺機器上建立一個虛擬的雲，它的底層使用的是標準的虛擬化系統，好比你能夠同時建立多個VM，經過關掉其中的幾臺來測試故障模式，而且能夠把本地目錄映射到虛擬機上，這樣就能夠在修改代碼後當即查看效果。

      方法3：Linux容器

      Linux容器能夠建立一個隔離的進程空間，進而在這個空間運行其餘的進程。在Linux中，進程必須由用戶來運行，而且根據權限的不一樣擁有不一樣的能力，進程能夠建立其餘進程，舉個例子，若是我在終端啓動了一個乾，你能夠認爲它是終端程序的子進行，Linux內核的任務就是維護這個進程樹。

      Linux容器擴展了這一想法，每一個容器就是整個系統進程樹的一棵子樹，內核已經幫咱們完成了給這些容器分配物理資源的任務， LXC就是這樣一種容器（相似的還有Solaris Zones、Open VZ），它的基本結構以下：

             

      它再也不須要Hyervisor，其實儘管每一個容器能夠運行不一樣的操做系統發行版，但必須共享相同的內核，由於進程樹存在於內核中，這意味着，咱們的主機操做系統能夠是Ubuntu,而在容器中能夠運行CenOS，只要它們的內核相同便可。

      容器更輕量，因此在相同的硬件上可以運行的容器數量比虛擬機要多得多，並且啓動速度更快，但容器在隔離性上也還存在必定問題。

      方法4：Docker

      Docker是構建在輕量級容器之上的平臺，它幫你處理了大多數與容器管理相關的事情，你能夠在Docker中建立和部署應用，這些基於容器的應用與VM鏡像很相似，Docker也能管理容器的配置，並幫你處理一些網絡問題。

      Docker自己並不能解決全部的問題，它只是一個在單機上運行的簡單的Paas，你還須要一些工具來幫你管理多臺機器上的Docker實例上的服務。好比，當你向這些工具請求一個容器時，它會幫你找到容器並運行它。Google的Kubernetes和Deis就是這樣的軟件。

      Docker+調度工具構成的解決方案介於IaaS和PaaS之間，咱們能夠稱之爲CaaS（容器即服務）。

 

八.使用自動化腳本

       參數化的命令行調用是任何部署的最合理方式，可使用CI工具來觸發腳本的調用，從Windows的Bash到Python Fabric腳本等，好處是一次編寫後面基本不用改了，也可使用Terraform、Salt Stack這樣的工具。

 

參考

      《微服務設計》（Sam Newman 著 / 崔力強 張駿 譯）