系列文章目錄：
一.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 著 / 崔力強 張駿 譯）