1.2 容器集群與分布式服務

1.2.1 微服務架構

近年來容器技術的繁榮同樣得益于大規模分布式軟件架構的推波助瀾。隨著現代軟件規模不斷擴大，單純地增加節點內存和運算能力已經不足以應對業務請求的需要，由于能夠利用服務數量的橫向擴展來獲得更好的業務性能和承載量，分布式架構成為了許多企業選擇的探索方向。

微服務架構（Microservices Architecture）是在Martin Fowler和James Lewis合著的一篇博客里正式提出的一種軟件架構形式，它是分布式架構在互聯網時代發展過程中的全新詮釋。微服務架構提倡將應用分割成一系列細小的服務，每個服務專注于單一業務功能，運行于獨立的進程中，服務之間邊界清晰，采用輕量級通信機制（如HTTP/REST）相互溝通，配合起來又能實現完整的應用，滿足業務和用戶的需求。

康威定律（Conway's law）指出：“任何設計系統的組織，最終產生的設計等同于組織之內、之間的溝通結構”。在傳統軟件開發項目中，通常將開發者按技能分為前端層、中間層、數據層。這種項目設計架構的分層結構對應了不同團隊的人員組織結構：前端對應的角色為網頁開發和設計人員；中間層對應的角色為服務端業務和開發人員；數據層對應著DBA等角色。所有的軟件層需要最終被集成在一起，才能成為一個可部署的整體。而微服務架構的開發模式則將項目按業務能力劃分為不同的服務，每個服務都要求在對應業務領域的全棧（從前端到后端）軟件中實現，從界面到數據存儲再到外部溝通協作等。這樣，原本單一的服務就按照功能邊界被分解成一系列獨立、專注的微服務。每個微服務對應傳統項目中的一個組件，但是可以獨立編譯、測試和部署。

相較于分層架構的項目，微服務架構具備以下優勢。

1．復雜度可控

在將項目分解的同時，微服務架構規避了復雜度無止境積累的惡性趨勢。每一個微服務專注于單一功能，并通過定義良好的接口來清晰地表述服務邊界。由于體積小、復雜度低，每個微服務可由一個小規模開發團隊完全掌控，易于保持高可維護性和開發效率。

2．獨立部署

由于微服務具備獨立的運行進程，所以每個微服務也可以獨立部署。當某個微服務發生變更時無須編譯、部署整個項目。由微服務組成的項目相當于具備一系列可并行的發布流程，使得發布更加高效，同時可降低對生產環境所造成的風險，最終實現縮短項目交付周期。這十分契合互聯網SaaS類型服務每天都要發布很多次的常態需求。

3．技術選型靈活

微服務架構中的技術選型是去中心化的。每個團隊可以根據自身服務的需求和行業發展的現狀，自由選擇最適合的技術棧。由于每個微服務相對簡單，因此對技術棧進行升級時所面臨的風險較低，甚至可以完全重構一個微服務。這使得對于特定領域的功能，可以充分利用該領域中最好的框架或編程語言來解決問題，而不受系統中其他服務的技術選型制約。

4．容錯和故障隔離

當某一組件發生故障時，在單一進程的傳統架構下，故障很有可能在進程內擴散，形成系統全局性的不可用。在微服務架構下，故障會被隔離在單個服務中。若設計良好，其他服務可通過重試、平穩退化等機制實現系統層面的容錯。

5．靈活的擴展性

分層開發的整體系統并非一定不能進行橫向擴展，只是對于大型系統而言，以整個系統為單位進行復制擴展的代價相對較高。事實上系統中網絡流量和計算資源的需求差異往往是與業務功能掛鉤的，例如報表計算的業務可能需要大量CPU，而購票的業務系統則需要更多的入口帶寬，此時微服務架構的靈活性就體現出來了，因為每個服務可以根據實際需求獨立進行擴展。

然而，這樣的架構要是在早些年提出來，也許還要面臨著項目運維的極大挑戰。微服務架構項目中的每個獨立服務團隊都是自己構建、發布和維護自己的分布式微服務應用的，出于技術棧和工具選擇的差異，完整部署這樣一套系統就需要所有服務團隊集體參與，因為很難有人能夠熟悉每一個微服務的部署細節。容器技術則為微服務理念提供了統一的打包、部署和狀態監控的方式，成為這個架構實施不至于失控的十分關鍵的環節。

微服務架構本質上是一種分布式的系統，在部署結構上與集群關系十分緊密。容器技術在集群上的運用已經比較成熟，特別是在服務調度和資源分配方面，這使得服務在設計完成后能夠獨立、快速地完成上線。

1.2.2 容器集群生態圈

容器集群技術的發展并不是孤立的單點，而是伴隨著虛擬化技術、容器引擎、編排技術、操作系統、容器倉庫、監控技術等周邊技術鏈的共同繁榮。

圖1-5是容器集群所處的完整生態。

1．容器引擎

容器引擎是容器集群生態圈的核心部分，它是與內核Namespace和CGroup等功能直接交互，并提供相應API使得外部能夠與之集成的工具或服務。Docker無疑是目前為止設計最成功、使用最廣泛的容器引擎之一。在1.12版本以后，Docker的容器化功能實際上已經由獨立的項目RunC來實現，但Docker項目依然作為一種集成完備的容器引擎工具得到許多用戶的喜愛。下面列舉一些開源的容器引擎。

·Docker:https://www.docker.com。

·Rkt:https://coreos.com/rkt。

·Pouch:https://github.com/alibaba/pouch。

·Systemd-nspawn:https://www.freedesktop.org/wiki/Software/systemd。

·Hyper:http://hyper.sh。

·Garden:https://github.com/cloudfoundry/garden。

·LXC:https://linuxcontainers.org。

·Photon:https://github.com/vmware/photon。

·Jetpack:https://github.com/3ofcoins/jetpack。

·Kurma:https://github.com/apcera/kurma。

·Vagga:https://github.com/tailhook/vagga。

2．監控和數據收集

由于容器基于內核的特殊隔離方式，其對容器性能和狀態的監控與虛擬機存在一些差別。傳統的虛擬機監控工具，例如Nagios和Zabbix等，對容器監控的原生支持并不完善。而以下一些新啟動的開源項目對這種場景具有更友好的體驗。

·cAdvisor:https://github.com/google/cadvisor。

·Sysdig:http://sysdig.org。

·Prometheus:https://prometheus.io。

·TICK-Stack:https://influxdata.com。

·Docker-Alertd:https://github.com/deltaskelta/docker-alertd。

·Grafana:https://grafana.com。

其中的TICK-Stack指的是Influxdata推出的Telegraf、InfluxDB、Chronograf、Kapacitor四款開源工具，不過自TICK-Stack推出1.0版本以后，這些工具分別提供了開源版本和企業版本，后者增加了例如高可用、云端存儲等企業級功能。

3．容器管理和界面工具

可視化是用戶友好性十分重要的一種體現，Shipyard和Decking是Docker早期十分受歡迎的可視化工具，之后Docker又收購了Kitematic作為官方的容器管理UI。但隨著容器應用集群化，早期的UI工具不再流行，一些針對特定集群平臺定制的新型管理UI開始出現。例如Kubernetes官方推出的Dashboard項目可用于可視化地管理集群，Cockpit則是紅帽公司推出的Kubernetes集群管理界面。以下是一些開源的容器管理UI項目。

·Kitematic:https://kitematic.com。

·DockerUI:https://github.com/crosbymichael/dockerui。

·Panamax:http://panamax.io。

·Rapid Dashboard:https://github.com/ozlerhakan/rapid。

·Cockpit:http://cockpit-project.org。

·Portainer:https://www.portainer.io。

·Shipyard:http://shipyard-project.com。

·Seagull:https://github.com/tobegit3hub/seagull。

·Dockeron:https://github.com/dockeron/dockeron。

·DockStation:https://dockstation.io。

4．基礎設施集成

容器集群的實施是需要以硬件基礎設施作為依托的，有些輔助工具能夠簡化這個過程。這些項目往往與具體的底層平臺相關，如下所示。

·Nova-docker:https://github.com/stackforge/nova-docker。

·Magnum:https://github.com/openstack/magnum。

·Machine:https://docs.docker.com/machine。

·Boot2Docker:https://github.com/boot2docker/boot2docker。

·Clocker:https://github.com/brooklyncentral/clocker。

·MaestroNG:https://github.com/signalfuse/maestro-ng。

Nova-docker和Magnum都是在OpenStack中集成容器集群的項目。不過目前OpenStack官方正在嘗試通過讓Kubernetes直接創建虛擬機的方式來統一它在IaaS層和CaaS層的差異，其中的Nova-docker已經被廢棄了。Machine是Docker公司推出的基礎設施管理工具。Boot2Docker曾經是在Windows和Mac上使用Docker的官方方案，但隨著Docker 1.12版本發布了多種操作系統的發行版后，已經不再被推薦使用了。

5．編排和調度

編排和調度是容器集群的基本功能，因此選擇編排和調度工具實際上就是在選擇容器集群的方案。以下是一些開源的容器任務編排調度工具。

·SwarmKit:https://github.com/docker/swarmkit。

·Kubernetes:http://kubernetes.io。

·Marathon:https://github.com/mesosphere/marathon。

·Rancher:http://www.rancher.com。

·Nomad:https://github.com/hashicorp/nomad。

·OpenShift:https://www.openshift.com。

·Crane:https://github.com/michaelsauter/crane。

·Nebula:https://github.com/nebula-orchestrator。

·GearD:http://openshift.github.io/geard。

其中的OpenShift主要是指其3.0之后的發行版（早期版本未開源），它是紅帽公司基于Kubernetes二次開發的集持續集成和交付于一體的容器集群方案，它具有開源和商業兩個版本。

6．容器鏡像倉庫

鏡像倉庫是基于容器的、在軟件發布流程中必要的組成部分，Docker開源了其鏡像倉庫的最小實現，但對于企業級應用來說，它缺少了高可用、權限控制、管理界面等必要功能。Docker Hub和國內的許多容器云平臺都提供了公有云的企業級倉庫服務，社區中也有一些容器倉庫的開源實現，如下所示。

·Repository:https://github.com/docker/distribution。

·Nexus:http://www.sonatype.org/nexus。

·Habor:http://vmware.github.io/harbor。

·Portus:https://github.com/SUSE/Portus。

·Docker Registry UI:https://github.com/atcol/docker-registry-ui。

其中的Nexus是一種通用的軟件包倉庫解決方案，支持包括Maven、NPM、PIP、RPM等許多主流打包格式的分發和管理，它在3.0以后的版本才開始支持作為Docker鏡像倉庫。Habor是VMware推出的企業級開源Docker倉庫解決方案。

7．服務發現和容器域名服務

服務發現和域名服務實際上是微服務架構和容器集群的調度工具所需的組件，它們在容器集群中十分常見，也是這個生態圈中舉足輕重的一部分，以下是其中一些在實際工程中被提及較多的工具。

·Etcd:https://github.com/coreos/etcd。

·Consul:http://www.consul.io。

·ZooKeeper:https:// ZooKeeper.apache.org。

·Eureka:https://github.com/Netflix/eureka。

·Traefik:https://traefik.io。

·Muguet:https://github.com/mattallty/muguet。

·Registrator:https://github.com/gliderlabs/registrator。

·SkyDNS:https://github.com/skynetservices/skydns。

8．容器日志收集處理

和容器集群的監控類似，收集容器中的服務運行日志，與在虛擬機中的實現同樣存在許多差異。目前Docker已經內置支持的日志收集工具包括Splunk、Fluentd、Graylog和AWS、GCE等主流云丁商的日志平臺。一些過去用于虛擬機的日志收集器，比如LogStash或Flume，同樣能夠使用容器中的服務，只是它們都不再是首選的方案。但Elastic公司新推出的Beats項目同樣值得關注。以下是其中一些工具的鏈接。

·Splunk:https://www.splunk.com。

·Fluentd:https://www.fluentd.org。

·ElasticSearch:https://www.elastic.co/products/elasticsearch。

·Kibana:https://www.elastic.co/products/kibana。

·Beats: https://www.elastic.co/products/beats。

·LogStash:https://www.elastic.co/products/logstash。

·Flume:https://flume.apache.org。

ElasticSearch和Kibana是開源日志索引和展示的主流選擇，因此也屬于與日志相關的工具。值得指出的是，Splunk并不是開源或免費的，但它在企業級日志處理方案中的應用十分廣泛。

9．與容器相關的系統發行版

有些Linux發行版是為容器運行而優化的，Atomic和ClearLinux系統都屬于此類。另一些Linux發行版在設計之初就充分地將容器機制融入了系統的架構理念，例如CoreOS。有的系統甚至將Docker作為系統的核心服務來管理其他用戶進程，例如RancherOS和Hyper容器引擎所使用的操作系統。類似的項目還有許多，它們都是架設容器集群時十分稱手的基礎設施，如下所示。

·Container Linux:http://coreos.com。

·Project Atomic:http://www.projectatomic.io。

·RancherOS:http://rancher.com/rancher-os。

·ClearLinux:https://clearlinux.org。

·Photon OS:https://vmware.github.io/photon。

·CargoOS:https://cargos.io。

·SmartOS:https://www.joyent.com/smartos。

第8章將進一步介紹Container Linux和RancherOS這兩個操作系統的細節。

10．容器平臺

容器平臺是大規模容器運用的產物，它通常會與持續集成、持續交付的工具結合，連接上層應用服務和底層基礎設施，幫助使用者快速實現從代碼提交到產品上線全過程的端到端交付過程。這些平臺繼承并發揚了PaaS（Platform as a Service）服務的定位，并由此衍生出CaaS（Container as a Service，容器即服務）的概念。以下是其中一些相關的開源項目。

·Deis:https://deis.com。

·Flynn:http://flynn.io。

·Dokku:https://github.com/progrium/dokku。

·Fabric8:http://fabric8.io。

·Kel:http://www.kelproject.com。

·Nanobox:https://nanobox.io。

·Tsuru:https://tsuru.io。

除了這些開源的容器平臺服務實現之外，互聯網上還有許多在線按資源使用量付費的CaaS平臺，它們也是整個容器集群生態的一部分。

11．容器網絡

容器技術在解決環境隔離和配額問題的同時，也引入了網絡層面的復雜性。由于使用了Network Namespace，每個容器都可以獲得獨立的IP地址，這對于單個主機的情況并無大礙，但對于容器集群的情況，IP地址的分配和互聯就成為了新的問題。因此在設計容器集群時，通常需要針對網絡的連接方式加以特殊考慮。常用的開源方案有以下這些。

·Libnetwork:https://github.com/docker/libnetwork。

·Flannel:https://github.com/coreos/flannel。

·Calico:http://www.projectcalico.org。

·Weave:https://github.com/zettio/weave。

·Romana:http://romana.io。

·Canal:https://github.com/projectcalico/canal。

·Open vSwitch:http://openvswitch.org。

·Pipework:https://github.com/jpetazzo/pipework。

這些網絡方案大多采用了七層網絡的Overlay Network方式，也就是在容器之間通信的網絡包上封裝了用于路由尋址的額外包頭，這種方式會導致網絡通信效率的下降，具體影響程度與所封裝的額外數據大小有關。而Calico采用修改每個主機節點上的IPtables和路由表規則來實現容器間數據路由和訪問控制，屬于三層網絡的方式，這種方案在節點規模不太大（最多幾百個節點）時的效率優勢十分明顯，是一種比較受推薦的容器網絡工具。除了這些較常用的方案，一些條件允許的企業也會結合MacVLAN等二層網絡方案實現容器的互聯，以獲得更好的網絡性能。

12．容器安全

容器安全性問題的根源在于容器和宿主機共用內核，因此受攻擊的可能性特別大。另外，如果容器里的應用導致Linux內核崩潰，整個宿主機系統都會崩潰，這一點與虛擬機是不同的。此外，鏡像的安全性也是容器安全的一部分，如何保障用戶下載的鏡像是可信的、未被篡改過的，以及如何保證鏡像中不會意外包含具有大量漏洞的老舊軟件，都是需要考慮的問題。目前這些安全課題主要在一些企業級應用中引起較多重視，下面是一些相關的開源工具和項目。

·Notary:https://github.com/docker/notary。

·Clair:https://github.com/coreos/clair。

·AppArmor:https://en.wikipedia.org/wiki/AppArmor。

·SELinux:https://selinuxproject.org。

·Twistlock:https://www.twistlock.com。

·OpenSCAP:https://github.com/OpenSCAP/container-compliance。

13．容器數據持久化

容器是一種不可變的基礎設施，容器的數據應該通過Volume的方式保存到外部的介質上，容器持久化存儲本質上就是要解決如何簡便地將外部存儲掛載到容器中使用的問題。Docker在其1.9版本后提供了存儲的插件，這也為許多存儲方案提供了便利，以下列舉幾個例子。

·Flocker:https://github.com/clusterhq/flocker。

·Convoy:https://github.com/rancher/convoy。

·REX-Ray:https://github.com/codedellemc/rexray。

·Netshare:https://github.com/ContainX/docker-volume-netshare。

·OpenStorage:https://github.com/libopenstorage/openstorage。

其中的Ceph是通用的網絡存儲工具，它對容器化存儲具有良好的支持。

14．容器相關開發流程工具

容器的鏡像可以被看作一種新型的應用打包方式，因此容器常常與軟件的開發和持續集成、持續交付流程相結合，提供在不同環境中的一致性部署能力。以下是一些利用容器改善軟件開發和交付的工具或平臺。

·Drone.io:https://drone.io。

·Shippable:http://shippable.com。

·Cyclone:https://github.com/caicloud/cyclone。

·Screwdriver:http://screwdriver.cd。

·WatchTower:https://github.com/v2tec/watchtower。

·Wercker:http://wercker.com。

·Totem:http://totem.github.io