一.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 著 / 崔力強 張駿 譯）

相關文章： 

原文地址：http://www.cnblogs.com/gudi/p/6667102.html

.NET社群新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注