在過去的兩年里，微服務架構已經成了非常熱門的名詞，它出現在很多論壇、視頻、演講中。作為一種更靈活、可靠、開放的架構，其應用實踐也越來越多。因此，由七牛主辦的開發者***實踐日第13期，成功邀請到對持續項目交付深有研究的ThoughtWorks***咨詢師王磊、一站式Docker云平臺DaoCloud聯合創始人&研發副總裁郭峰、使用Docker應用于電商場景的京東資深架構師季錫強和對容器技術有著一定研究的七牛云CTO韓拓，分別就微服務架構實踐、容器技術帶來的技術價值、微服務帶來的挑戰和解決目標等方面的總結經驗分享給大家。

微服務大探險

軟件架構是在考慮業務、技術能力、團隊、可維護性、安全性、可靠性及可持續性等多重因素下對軟件內部進行的劃分。通過劃分，讓軟件內部不同的部分之間能夠相互鼓勵，又能夠相互協作，同時給用戶提供最終的價值。但什么是微服務架構呢?ThoughtWorks***咨詢師王磊通過一個互聯網門戶案例為大家解釋了微服務架構的概念，以及它如何影響傳統的軟件架構設計。

一年前，該門戶每簽一個10萬的合同所耗費的成本是3.5天。他們當時的CRM結構是典型的三層架構，整個應用程序由一個40萬行的代碼庫組成，后端有一個主動的數據庫。雖然使用三層架構的成本比較小，但隨著代碼和功能的增加，代碼庫不斷膨脹，修改代碼存在的風險很大，整個維護成本也變得越來越高。

每當開發人員提交代碼后，所需的數據集成和構建需要50分鐘，意味著每天8小時工作時間最多能有9次代碼提交。但為了系統的穩定性，持續集成過程中要盡量避免提交代碼，因此，整個團隊的交付能力受到了限制。此外，從準備部署包到上線需要3天，3天后才能讓用戶真正用到部署包，才能實現價值。而如果增加新人，要開發新的環境，包括測試和產品環境，培養周期會很長。針對以上難題，ThoughtWorks制定了如何在團隊中對系統進行改造從而滿足業務需求的策略。

將現有的系統保護起來，把所有開發新功能的優先級都降下來，只需對系統做最緊急的修改，其他和部門進行協商，讓團隊保持新的精力和時間在重要的業務上。

功能剝離。通過定義新服務，在前端用一些代碼的機制讓用戶逐漸訪問新服務，可以達到從原有系統抽出小功能，讓客戶訪問小功能。

數據解耦。對于龐大的系統，因為無法很快將所有系統換掉，所以為了保證系統仍然可用，要啟用數據同步機制，讓服務里的數據同步到原有數據庫。

漸進替換。通過不斷地運行以上策略，將原有系統的復雜功能抽離出來用新的方式來做。

目前，每簽一個10萬的合同所耗費的成本由3.5天變為1天，持續集成構建從50鐘降低到18分鐘，團隊成員從10人降到7人，部署周期由3天降到2小時。

對于每個應用程序，可能有一組小的服務組成，每個服務運行在自己的進程中，服務與服務之間通過輕量級的機制進行交互。那么，如何使用微服務做系統改造呢?

為每個服務建立獨立的環境，包括基礎設施、持續集成環境、運維、監控、日志聚合、報警。

不斷演進的微服務開發模板，發現問題及時修改，讓模板更高效。

輕量級的通信協議。

消費者的契約測試，解決隨著服務增多帶來集成測試效率低的問題。

基礎設施自管理，幫助管理自己需要的資源。

Container為微服務帶來了什么?

七牛云CTO 韓拓從服務端的架構和運維兩個方面介紹了Container和微服務帶來的價值。他認為Container是基于內核的空間。一個操作系統的內核主要管理資源，把服務器交給操作系統的內核，它把內存、CPU和硬盤等資源管理起來。Container進一步做隔離，這個隔離以進程為單位，讓一個進程只能看到這個網卡收發的數據，但是看不到其他的網卡。

Container有以下幾個名字空間。

網絡的空間，它隔離了和網絡相關的資源，如服務器上的網卡、IP地址、服務表等，之后這個進程在某個網絡的空間內運行就看不到其他空間相關的網絡資源。

文件系統，這個名字空間把這類資源也進行了隔離。一個進程運行時看到的根目錄可能不是操作系統原生的根目錄，看到的塊設備也不是原來的塊設備。

PID，每運行一個進程都有一個PID，現在內核里的名字空間，PID的資源也被隔離起來。

Container對系統調用做了權限的控制。例如一個進程啟動的時候限制它的權限，讓很多系統調用做不了。Container的作用包括鏡像管理和運行實例的管理，還有輸入輸出的管理。

那么，Container對服務端架構有什么影響呢?

七牛CTO韓拓認為不管做什么架構，很重要的工作是換模塊，去定義這個模塊的邊界，怎么工作、怎么測試及在生產環境如何部署。因此，從組件的角度看微服務化主要有以下三點。

組件劃分的方式，Container以功能為單位來劃分組件的邊界。

組件物理邊界，以前的邊界有靜態或動態的庫，模塊間的邊界通常是函數調用。而微服務組件的物理邊界是網絡，這些組件都是獨立的、可編譯的進程(即每個單獨的服務實例)，這些服務實例之間通過網絡來溝通。

組件的依賴方式，以前是在編譯期考慮怎么才能把ESC可執行程序編譯出來，只要編譯出來，就能肯定依賴關系肯定被解決了。當微服務化之后，依賴方式的處理被延后了，延后到運行的時候，因此錯誤被延后了，組件間的依賴方式變復雜了。Container中組件間的依賴可通過渲染文件和環境變量等實現。

關于Container對運維的影響，主要是告別DevOps。作為勇敢的DevOps實踐者，七牛認為，DevOps的核心是試圖尋找一個合理的開發和運維的邊界。有很多方法論尋找這個邊界，DevOps是其中一種，主要將運維平臺化，做監控平臺、日志平臺等。

在持續集成方面，以前的任何一行代碼做了更變都要把整個業務重新做一遍，需要很長時間。微服務化之后，每個模塊獨立編譯、獨立打包、獨立測試，其邊界也很明確，代碼的變更影響的是一個組件和服務，單獨進行編譯和測試的動作會很快。

部署和升級方面變得簡單，可以獨立地部署和升級。

資源規劃方面，按峰值申請資源會存在資源浪費。微服務化后，可以按模塊去擴容。對資源的規劃更靈活和合理。尤其再結合Container，因為Container以進程為單位，它對資源的使用是競爭的，不需要提前規劃。

網絡方面，Container一般通過端口映射的方式做網絡。

監控方面，業務的運行狀態對運維來講更透明，小的服務可以單獨監控，一些問題出來之后可以做報警。但監控變多了，需要監控系統更智能。

***在高可用方面，傳統的架構會做成透明的。現在，高可用由外部的框架完成，例如在做服務間依賴時就可以做高可用，不僅屏蔽了服務在哪里，服務了多少人，而且還可以把服務是死是活的細節屏蔽掉。

Micro Service，Continuous Delivery and Docker

DaoCloud聯合創始人&研發副總裁郭峰認為容器技術解決了原來PaaS技術不能解決的問題。于是他給大家展示了微服務帶來的挑戰，即如果將一個應用微服務化，那么很容易導致一臺機器上跑很多程序。因為服務糾纏在一起，所以微服務需要運用自包含。DaoCloud的容器技術是把最古老的幾個技術融合在一起，用了一個很方便的腳本化的工具，讓大家都可以用起來。它提供了標準化的鏡像，不僅方便地用容器，而且可以方便地發布容器。

容器和虛擬機是什么關系呢?虛擬機有物理環境、有操作系統，但容器下面是server，上面跑應用程序和庫，這樣的架構使得容器的性能比虛擬機好很多。首先沒有虛擬機的虛擬化過程，直接把跑內核的進程跑到OS上。別人想發一個微服務，可以利用在鏡像上面加一層，即使有很多鏡像，有時多個鏡像會一起依賴，會省資源和容量。那么，為什么容器是輕量級的?因為它只有應用和應用的依賴所打成的包，如果應用做了一點點修改，不需要完全打一個，在原有的運用上打一個補丁，把修改記下來即可。

上圖是Docker的流程圖， Dockerfile這個鏡像可以運行在本機。在上面運行容器，等容器開發好并且測試通過了再把這個容器push到鏡像倉庫上。任何一個人都可以從鏡像倉庫上下載，下載后，Docker運行一套命令讓行為一致。重要的是，Docker官方維護了DockerHA，所以Docker允許以鏡像的方式發布Container，發布的Container像未來的VM，這個VM很輕量，大家可以把它pull下來，不管用什么物理硬件資源，都可以讓Docker運行起來，而且運行結果和其他沒有差別。Docker是如何做到自包含的呢? Docker的自包含是它容器的本身包括了OS的版本，以及依賴的環境和客戶，所有的都描述成Dockerfile。Docker可以幫助兩類人——開發人員和運維人員，它跨越了開發和運維間的那道鴻溝。

僅僅自包含就做微服務是不夠的，微服務要求把之前大系統的問題分解為很多簡單的小問題，然后將每個簡單的小問題用最合適的技術實現。但這導致現在有很多小應用，原來靠人工可以解決的事現在解決不了，比如做CI(持續集成)/CD(持續交付)。微服務化以后，會導致一個企業的應用CI很難做。

此外，他還向大家介紹了Docker的三件法寶。***個是Docker Compose，如果應用不是單應用可以用同一方法描述應用和應用的依賴，然后上線。第二個是Volumes，可以共享文件。***一個是環境變量，不管是微服務和微服務之間的依賴以及微服務運行時的依賴的環境變量也好，還是端口也好，都描述清楚，定義好后給運維人員。這是可復制的迭加過程，不僅把代碼和運行做自包含變成一個鏡像，而且鏡像用運行的方式提供出來。運維人員不需要關心應用內部的邏輯，只需要關心模塊的鏡像以及如何將鏡像運行起來，這樣可以大大地減少運維成本。

Docker的應用與實踐

來自京東的資深架構師季錫強分享了Docker的應用與實踐。主要講了Docker的系統整體架構及其技術實現、鏡像存儲部分、Container啟動流程，還介紹了制作鏡像命令的原理以及volume掛載的原理。

他為大家介紹了Docker的組件，Docker真正的實現主要是幾個組件組成，***層是鏡像存儲的模塊，實現有很多種，比如device mapper、aufs以及btrfs。第二層是exec driver，主要是libcontainer及lxc。第三層是network driver，主要是主機以及網絡命名空間，而Namespace支持ipc、mnt、pid、net、uts及user。組件CGroup主要做資源控制，涉及的方面有CPU、IO，IO可以不依賴于Namespace單獨使用，和操作文件一樣改一下值就可以。CGroup的限制主要是通過子系統來實現，相應的模塊有IO、CPU等。而組件Device Mapper的實現有DM – thin provision。

上圖是啟動容器的流程。啟動的命令請求首先會把設備mount到指定的掛載點上訪問。啟動go monitor會帶著參數啟動里面的命令，接下來會用Dockerinit做初始化，最終命令會進行系統調用，再exec執行。停止容器則比較粗暴，相當于Docker根據PID直接將容器中的進程殺掉，再做一些資源的釋放，這樣就完成了停止容器的流程。Docker啟動的時候，如果Docker是意外死掉的(人為或者程序的破壞)，那么之前的程序不會消失，這時候Docker會把所有的容器kill掉，會把之前容器創建的操作信息保存在Docker的目錄下。Docker將所有的容器都kill掉后，資源會被釋放，這個時候就會觸發一個***性的bug。因為當容器重啟的時候，會檢查mount count，這個初始化的值是0，而Docker死掉后重啟則會發現mount count不為0，所以會導致mount失敗，導致出錯;這個時候我們想啟動容器的話，關鍵的動作是把設備釋放并重新掛載到mount下。因此，告誡大家，如果Docker異常死掉了，要及時清理資源。

關于制作鏡像的原理，你可以建立一個鏡像生成一個容器，這個鏡像可以分到某一個文件目錄下，可以做一些直接的操作。首先mount上去，鏡像原來的版本也會mount上去，遍歷所有的文件看兩者之間的狀態是否有變化，然后打包，產生diff。這時要創建新的容器，因為已經獲得了diff，接下來要創建一個新的鏡像。創建新的鏡像之前要拿到Container的基本鏡像，這時要把這個鏡像mount，就可以看到所有的文件。***的操作是解壓一個文件到一個新的snapshot，就相當于有一個新的鏡像了。

***，他對Docker做了一些總結，Docker主要用到CGroup的一部分子系統;Docker啟動和停止之間有一個大Bug需要及時關注;commit要打包、解壓文件，機器磁盤很高的時候commit會相當耗時。

以上是牛小七對本期開發者***實踐日內容的概括性介紹，如需獲取詳細的演講信息和往期內容回顧，可以訪問活動專題。

「開發者***實踐日」是由七牛云存儲發起并聯合各方小伙伴為開發者舉辦的系列技術沙龍，關注開發者在實際應用中可能遇到的技術問題。致力于為勇于創新的開發者們提供行業內最前沿最熱門的技術干貨，以技術驅動應用創新，讓更多的開發者享受技術帶來的生活樂趣。