微服務設計模式與容器云平臺

• 時速云聯合創始人

• 主要負責時速云產品基礎架構、研發和產品安全等工作

介紹基于Kubernetes的微服務特性，及在容器平臺上所創建的容器服務其背后所具有的彈性伸縮、自啟動、微服務架構等特點。

什么是微服務，用Martin Fowler的一段話：沒有一個明確的定義，但簡單來說是，以一組小型服務來構建成應用，每個服務運行在單一獨立的進程，不同服務間采用輕量級的交互機制 來通信，例如HTTP(REST API)。這些組成應用的服務圍繞業務能力來構建，完全采用自動化部署方式，可獨立部署擴展，不同的服務可以采用不同的編程語言來實現，由獨立的團隊來維 護。

實際上多年前的所謂的SOA面向服務架構，現在的微服務架構依然是SOA的一種思想實現。微服務的特點還是顯而易見的，組件化，獨立部署，傳統實 現組件的方式是通過庫（library）,C++ java通過靜態或動態鏈接構建成軟件，不強調進程分化，升級時需要整體重新部署或服務重啟。但微服務的方式把他們各部分拆分了，變成一系列服務以進程的 粒度運行，意義就在于，升級部署時，只需局部更新過時組件，而不需要牽動整個系統。當然這種跨進程的調用方式需要考慮邊界問題，也就是各組件的容錯性，在 設計之初需要考慮各部分明確職責。

容器技術的逐步成熟給DevOps帶來了一場變革，也給微服務思想的實現提供了便利。當我們討論容器技術的優勢時，通常會提到輕量級、快速部署、 遷移方便等，這些優勢大大方便了應用的測試、部署和升級，而很少提到開發。DevOps的目標是整合產品開發、測試、部署和維護，保證產品的性能和穩定 性，同時加快新功能的開發和上線。借助于容器技術和微服務架構，開發真正融入到產品交付流程中。

我們不妨考慮下面幾個問題：1. 服務升級是否頻繁，單次耗時情況怎樣，升級時能否提供不間斷的服務；新版本的應用意外崩潰，打熱補丁的時間，服務是否會中斷；2. 新增feature時，是否需要整體重新部署或者重啟核心服務，是否需要重新測試已有功能，服務是否會中斷；3. 出現故障的原因，多少是因為程序本身的bug，多少是因為部署/升級時的人為疏忽或者溝通不暢；4. 隨著用戶的增長，關鍵組件（服務）是否能夠水平擴展。如果考慮系統升級頻率較高以及希望熱升級避免服務間斷，而且面臨上面提到的問題的話，微服務架構很可 能是個不錯的選擇。

傳統上，軟件的架構是自上而下瀑布模式，模塊間耦合分離采用調用庫鏈接方式，一部分原因是主流的編程語言（C/C++、Java等）是過程式或面 向對象式的，便于實現流線型的程序。微服務提倡的是便于橫向擴展的應用，對內，一組微服務是相互獨立的進程，通過輕量級的協議交互，可能使用不同的編程語 言實現；對外，一組微服務作為一個應用為用戶提供不間斷的服務。下面我們介紹幾個微服務設計模式，看看容器技術和微服務在生產中的應用。

通常情況下，不同的服務會有一定的耦合，比如說nodejs web應用和redis服務、php web應用。我們以web服務和redis服務為例，來重現下可能的問題。

主服務要訪問redis服務，所以必須知道redis是如何部署的。redis發生變化時，原先訪問redis的方式通常會失效，這時候我們不得 不重新修改主服務。但主服務代碼中可能包含大量的業務邏輯，訪問redis的代碼散落在各個角落，給下次升級留下了很多潛在bug。如果把訪問redis 的代碼從web主服務中剝離出來，放到一個單獨的容器里，即 (web app)-> (Ambassador: redis proxy) -> (redis server)，我們就不需要頻繁修改web app了。

使用SideCar模式，我們可以從外圍對核心服務做一些增強工作。比如，在部署主服務容器時，同時部署一個用于日志搜集的應用容器，定時搜集并 發送日志到日志服務器；或者監控服務容器，用以監控主服務的運行狀態。主服務實例過多時，可以部署一個git同步服務容器，無需人工干預就可以定時更新服 務器上的代碼。

這個模式主要是將應用適配到不同的環境中。例如，為跨云端的應用部署統一的監控系統，假如應用部署在AWS、阿里云等多個IaaS上，監控系統為了獲取日志等信息可能需要針對每個IaaS廠商進行適配。

為了保證核心服務的穩定性和獨立性，可以另外實現服務獲取應用運行和運行環境信息，這個服務可以對不同IaaS的API進行適配。部署和升級時，主服務容器和監控服務容器同步創建和銷毀。

實際上前面所舉的模式需要在容器的技術基礎上，平臺具有彈性伸縮動態更新的功能，而例如像伴隨者模式，這個服務伺服變動頻繁，體量微小，最好能與主服務共享部分資源并且共存生命周期。這個在kubernetes的pod概念里有非常好的實現特性。

Kubernetes是集群級別的容器編排系統，是源于google的borg項目，它在構建應用時，物理和邏輯上構建了3個層次，即pod、 replicationctroller、service。通過將一個或多個容器放入pod來實現最小調度單元，通過 replicationctroller來實現pod的副本控制即彈性伸縮，service是邏輯概念，通過proxy的方式讓多副本pod為上層服務提 供負載均衡。Kubernetes本身支持多種網絡類型，但自身并不解決多機集群的網絡問題，還支持多種類型的分布式存儲。

Kubernetes的Pod對微服務有先天的支持，Pod內的容器共享存儲共享網絡，這讓處于微服務模式中的容器聯系更加緊密。同時，控制器又 可以對他們進行靈活的更新升級。比如Ambassador 模式，proxy的部分根據外部db的變化需要較頻繁的更新，在k8 pod的內部與主服務是以localhost的方式通信，無需暴露到外部。 這樣既可以充分利用Kubernetes在資源調度上的優勢，也可以充分利用微服務的優勢。Kubernetes中的Pod具有獨立的IP，從這個角度來 看，比容器更像一個虛擬機。將多個相關關聯的容器應用部署在同一個Pod中，pod的生命周期由上層的調度機制決定，真正實現了松耦合、高可用和負載均 衡。

在容器微服務方面，時速云支持docker本身的compose方式，支持多容器互聯，只需要ymal格式以指定的組合對服務進行構建。同時利用控制器維持服務的可用性。

而利用主機產品，搭建私有的caas平臺，將會具有更多的權限，支持較大數目的容器，未來會開通api，擁有對kubernetes更多的控制權限。