[TOC]

Docker容器平臺選型調研

編排選型

Swarm

1. Swarm可以從一個Dockerfile來構建映象，但是構建的映象只能在單一節點上執行，而不能夠被分佈到叢集上的其他節點上。因此，應用被認為是一個容器，這種方式不是細粒度的。

2. Swarm需要使用docker-compose scale來擴充套件其中一個容器，這個新的容器將會根據排程器規則進行排程。如果容器負載過重，Docker Swarm並不會自動擴充套件容器

   • 正常情況下,必須去檢查容器是否達到瓶頸, 能夠及時的擴容

3. Swarm cluster ,在docker1.12版本中已經支援失敗節點自動檢測並拉取

4. 目前 Swarm 可以通過overlay networks 來支援多主機容器網路的訪問, 舊版不支援.

Mesos & Marathon(最新版1.4.1)

1. Mesos 提供資源管理和排程框架抽象的功能，第三方應用需要實現 Mesos 框架提供的 API 才能接入 Mesos 所管理的資源.

   • mesos在底層新增一個輕量的共享層,提供一個統一的api介面,供其他框架叢集訪問.
   • Mesos並不負責排程而是負責委派授權，有很多相應框架已經實現了複雜的排程,如Marathon

2. 相比於Swarm，Mesos的容錯性更強，因為Mesos能夠在JSON檔案中對某個應用使用監測檢查

3. Marathon 有使用者UI介面，可以將其視為一個應用程式，它可以看作一個框架來管理容器, 容器可以通過REST API 與Marathon 一起工作, 方便運維。

   • 新版Marathon很好的支援了應用的更新和回滾，除去了容器啟動對靜態配置檔案的依賴，使應用容器更新發布、回滾更加方便.

4. Mesos在彈性擴縮容後會導致宿主機上產生大量的 Exit 狀態的 Docker 容器，清除時較消耗資源，影響系統穩定性。

   • 預設 Mesos 只有基於時長的清除策略，比如幾小時，幾天後清除，沒有基於指定時間的清除策略，比如在系統閒時清除，也無法針對每個服務定製清除策略。
   • 可以修改 Marathon 的原始碼程式，新增 Docker 容器垃圾清理介面，可以對不同服務按指定策略將Exit狀態的Docker容器進行清理。

5. Mesos不支援搶佔，無法設定任務優先順序

   • 目前 Apache Aurora 這個外掛已經支援優先順序和資源搶佔, 但是它是和marathon同級別的.

6. 對於 mysql / Kafka這類有狀態的儲存類應用，目前 mesos+ Marathon還支援得不是很好

   • 在有失敗發生或者一個簡單的服務重啟的場景下，Marathon會隨機的在任何符合服務定義約束的資源上重啟服務，這樣對於有狀態服務是不適合的，因為這樣的話需要很高的操作代價來將本地狀態遷移到新的服務上
   • 但是可以通過Marathon本地持久化捲來達到能夠部署有狀態服務的目的
     • 本地持久化卷後,下次再啟動該容器的時候marathon與mesos會將這個容器再次部署到原先的宿主機上，而不是其他機器.

7. 可以自研所需的framwork.外掛化處理. 不過Marathon本身是Scala編寫的，UI是React編寫,不利於二次開發

8. 其他元件如: mesos-dns 和 marathon-lb.

   • mesos-dns 是一個服務發現工具
   • marathon-lb 不僅是服務發現工具，還是負載均衡工具, 要使用marathonn-lb，每組app必須設定HAPROXY_GROUP標籤, 採用haproxy進行負載均衡

9. 接入mesos的公司: http://mesos.apache.org/documentation/latest/powered-by-mesos/

Kubernetes(最新版1.6)

1. Kubernetes使用ReplicationController來保證應用至少有一個例項在執行。當在Kubernetes叢集中建立了一個pod時，需要建立一個叫做負載均衡的Kubernetes服務，它負責轉發流量到各個容器。

   • 如果只有一個例項，也可以使用這種服務，因為它決定了能否將流量準確的轉發到擁有動態IP的pod上。

2. Kubernetes新增了pod和replica的邏輯。這個為排程器和編排工具提供了更加豐富的功能，比如說負載均衡，擴充套件或者收縮應用的能力。並且還能夠更新正在執行中的容器例項。Kubernetes 擁有自我修復，自動化推出和回滾和儲存編排. 主要優點:

   • AutoScale：根據收集的業務 metric 來決定是否需要自動擴縮容
   • Rolling Deployents：滾動部署新版本並不中斷服務，在新版本部署完成後老版本退出
   • Work Queue：將 Service 從 1:1 的關係擴充套件到 1：N，為被訪問的 Service 前置一層代理 Agent，用來轉發請求

3. Kubernetes 擅長自動修復問題, 並且可以快速地對容器進行重啟. 這會導致使用方不會注意容器是否崩潰

   • 為了解決這個問題，可以新增一個集中式日誌系統 或其他方式 進行監控

4. 有狀態服務集: StatefulSets (1.4版本叫PetSets )

   • 對於PetSet中的Pod，每個Pod掛載自己獨立的儲存，如果一個Pod出現故障，從其他節點啟動一個同樣名字的Pod，要掛在上原來Pod的儲存繼續以它的狀態提供服務。(保證ip/hostname不變)
   • 適合於PetSet的業務包括資料庫服務MySQL/PostgreSQL，叢集化管理服務Zookeeper、etcd等有狀態服務。
   • 使用PetSet，Pod仍然可以通過漂移到不同節點提供高可用，而儲存也可以通過外掛的儲存來提供高可靠性，PetSet做的只是將確定的Pod與確定的儲存關聯起來保證狀態的連續性

5. golang語言編寫, 有助於二次開發, 社群活躍度高, 可以加入社群提高公司影響力

6. 大致統計下使用kubernetes的公司: eBay、Yahoo、微軟、IBM、英特爾、華為、VMware、HPE、Mirantis、網易、普元、亞信, 樂視 , 騰訊, 京東

容器技術棧

技術點	技術方案
資源排程 & 編排	Mesos + marathon Swarm(Compose) Kubernetes
映象 & 倉庫	harbor DockerHub Quay.io Artifactory
監控	cAdvisor Graphite Sysdig Datadog Prometheus ,Zabbix + pythonAgent
日誌	ELK Graylog flume heka fluentd
服務註冊和發現 / 負載均衡	HAProxy Etcd consul nginx Confd / DNS(好像有坑)
儲存	devicemapper, overlayfs, Volume, Ceph ，Gluster ， NFS, OpenStack swift， glance ,iSCSI SAN
網路	HOST, VXLAN IPSEC . OpenFlow .Flannel. Docker Bridge, Calico, Neutron ,pipework ,weave , SocketPlane
分散式計劃任務	chronos
安全	Notary Vault
自動化工具	ansible, salt

業界使用架構

1. 京東

   • Openstack Icehouse + docker1.3 + OVS2.1.3/2.3.2+Centos6.6 ==> K8s + Docker + Flannel +Neutron + OVS + DPDK +JFS
   • 某個容器失效,自動觸發RC(保持IP丌變“遷移”)
   • OVS-VLAN

2. 知乎

   • Git+Jenkins(CI/CD) + mesos + 自研framework + group(隔離) + Consul + haproxy + DNS + Graphite + cAdvisor
     • 通過group做故障隔離
     • 映象倉庫通過hdfs和水平擴充套件做高可用
     • Mesos 叢集的橫向擴充套件
   • docker網路
     • bridge
     • NAT is not bad
     • iptables 有些坑
   • 服務發現
     • DNS Client
   • 自動Scale
     • 突發響應 & 資源高效利用
     • 根據cpu指標調整容器數量
     • 快伸慢縮
     • Max & Min Hard Limit
     • 支援自定義指標

3. 攜程

   • Openstack + Mesos + Docker + Chronos + ELK
   • 監控：telegraf -> Influxdb -> Grafana
   • 日誌：elk
     • mesos stdout、stderr

4. 去哪兒

   • OpenStack + nova-docker + VLAN =>Mesos + Marathon + Docker(--net=host) + 隨機埠 => Mesos + Marathon + Docker + Calico

5. 阿里電商雲

   • 自研EWS, 基於compose, 參考Kubernetes的設計. 支援多region.
     • cAdvisor + InfuxDB + prometheus
     • etcd + consul + zk + docker overlay
       • 使用RDS,OSS,OCS等服務化儲存
   • docker容器的正確姿勢
     • 每次程式碼提交重新構建映象
     • 禁止修改執行中的映象
     • 利用volume儲存持久化資料
   • 儲存管理
     • 利用docker volume plugin支援不同的儲存型別
       • 塊儲存，雲盤
       • 物件儲存，OSSFS
       • 網路檔案系統 NFS

6. 同程

   • swarm + swarm agent + etcd + zabbix + Jenkins + (Nginx+Lua) + 配置中心
   • 使用現狀
     • 容器5000個,高峰擴容到8000
     • Docker應用600個, 塞入容器的還有:Mongodb, Redis,Mysql
     • cpu利用率由20%提升為80%
   • 資源隔離層面
     • 物理機利用率提升，合理的編排應用
     • 各應用間資源隔離，避免環境和資源的衝突，提示安全性
     • 爆發式流量進入： 快速擴容和遷移
     • 應用遷移： 減少買伺服器的花費
     • 運維工作： 更多的自動化，更精細化的監控和報警
   • 優化
     • dockfile 優化，縮小層數從20層到5層，構建速度快1倍
     • 儲存驅動從devicemapper改到overlayfs，構建速度快1倍
     • 釋出一個較大應用，耗時只需40s
     • 自動測試系統直接呼叫容器系統部署環境，測試完成就可回收，供其他測試使用
     • 實測物理機和Container之間的效能幾乎沒有損耗
       • redis效能對比： redis-benchmark -h 127.0.01 -p6379 -q -d 100
   • 映象管理
     • 基礎映象池的建設
     • 基礎映象之上再構建應用映象
     • 應用映象每次釋出時重新構建
     • 應用映象多版本儲存
     • 一次構建映象，各處可用
     • 各應用的回滾、擴容全部基於應用的映象來完成
   • 網路的思考
     • 在私有云的網路可控性本身比較高
     • 多租戶的隔離在私有云的意義不多
     • 穩定可控可擴充套件才是急需求
     • 整體頻寬的高保證
     • 對docker容器的網路考慮
       • 本機網路模式和OVS模式
         • 本機網路模式：如web
         • OVS模式： 如資料分析

7. 網易蜂巢

   • openstack + K8S + etcd + OpenFlow + iscsi + Ceph + billing + 多機房

8. 騰訊

   • Kubernetes + 網路(Bridge + VLAN / SR-IOV / overlay) + lxcfs + Ceph + configmap\secret + 藍鯨管控平臺
   • 目前，大概有15000多常駐的Docker容器, Docker平臺上已經跑了數十款端遊、頁遊和手遊
   • 叢集都是同時相容Docker應用和非Docker型別的應用的
   • Gaia將網路和CPU、記憶體一樣，作為一種資源維度納入統一管理。業務在提交應用時指定自己的網路IO需求，我們使用TC（Traffic Control）+ cgroups實現網路出頻寬控制，通過修改核心，增加網路入頻寬的控制
   • 具體網路選型
     • 叢集內 pod 與 pod 的之間的通訊，由於不需要內網 IP（可以用虛擬 IP）所以採用 overlay 網路，由 flannel 元件實現。
     • 公司內網到叢集內 pod 通訊，例如 HAProxy，遊戲某些模組，採用 SR-IOV 網路，由自己定製的 sriov-cni 元件實現。這類 pod 具備雙重網路， eth0 對應 overlay 網路， eth1 對應 SR-IOV 網路。
     • pod 到公司內網之間的通訊。在微服務場景下，遊戲的資料儲存，周邊系統等，部署在物理機或者虛擬機器上，因此 pod 到這些模組、系統的訪問，走的是 NAT 網路。
     • (Internet) 接入，採用公司的 TGW 方案。

9. 滴滴

   • Kubernetes
   • 目前瞭解的資料,滴滴使用docker化的時間不長,沒有太多參考架構設計

10. uber

    • 待補充

11. 蘑菇街

    • Kubernetes + VLAN

12. 七牛雲

    • Mesos + 自研容器排程框架（DoraFramework) + Bridge+ NAT + Open vSwitch + Consul + Prometheus + Ansible
    • 七牛目前已經達到近千臺物理機的規模, mesos支援大規模排程更合適
    • 不選擇Mesos的核心框架Marathon 而選擇自研
      • Marathon有些方面不支援我們期望的使用姿勢，比如不太好無縫對接服務發現
      • Marathon採用 scala 開發，出了問題不好排查，也不方便我們做二次開發
      • 如果選用 Marathon的話，我們上面還是要再做一層對 Marathon的包裝才能作為Dora的排程服務，這樣模組就會變多，部署運維會複雜

13. 魅族雲

    • OVS & VLAN + SR-IOV +ceph(保證映象儲存可靠性) + 自己現有的監控系
    • 主機間Container通過大二層網路通訊，通過vlan隔離
    • 異地映象同步
    • 容器設計理念
      • 容器化的虛擬機器,建立的Container需要長時間執行
      • 每個Container擁有獨立、唯一的IP
      • 主機間Container通過大二層網路通訊,通過vlan隔離
      • Container開啟ssh服務,可通過堡壘機登陸
      • Container開啟其他常用服務,如crond
    • 網路
      • Iperf test: Bridge < OVS veth pair < OVS internal port
      • Iperf test: Native > SR-IOV > OVS > Bridge
      • Docker with DPDK
        • 輪詢處理資料包,避免中斷開銷
        • 使用者態驅動,避免記憶體拷貝、系統呼叫 - CPU親和、大頁技術
      • Idea
        • virtio作後端介面
        • 使用者態socket掛載到Container
        • Container內跑DPDK applications
    • Container儲存
      • Devicemapper: 成熟穩定, 裸裝置, snapshot
      • IOPS: Native 基本等於 Devicemapper
      • 資料盤儲存-LVM
        • 按Container進行配額, 支援線上更改配額
    • 映象儲存與同步
      • 映象儲存
        • LVS前端負載均衡,保證高可用
        • distribution管理映象
        • 後端ceph保證映象儲存可靠性
      • 異地映象同步
        • webhook notification機制
        • 強一致同步機制
    • 容器叢集排程系統
      • 排程請求落到叢集相應節點
      • 根據IDC、資源與區、Container型別篩選宿主機
      • 根據宿主機資源狀態、請求的CPU/記憶體/磁碟大小動態排程
      • 機櫃感知,將同一業務Container排程到不同機櫃

14. ucloud

    • kubernetes + Jenkins
      • -v 掛載到主機, Flume/Logstash/rsyslog + elasticserach (日誌)
      • vswitch overlay的"大二層"網路SDN組網方案 + ipvlan
    • 主要問題型別和解決思路

      • 模組配置

        • 模組上下游關係, 後端服務
        • 執行環境,機房的差異性配置等

      • 一致性和依賴

        • 開發、測試、執行環境的不一致性
        • 依賴於不同的基礎庫

      • 部署

        • 部署效率低下，步驟多，耗時長
        • 部署狀態缺少檢查機制
        • 應用管理
          • 大量容器例項的管理、擴容、縮容成本高
          • 程式構建、打包、執行和運維統一管理
          • 監控、日誌分析

      • 解決方案

        • 模組配置
          • 分離環境、IDC、資源類等差異化的配置項資訊
          • 配置模板，提交到cedebase進行版本化管理
          • 對不同的deploys派生不同配置值，填充模板，啟動指令碼
          • 執行在不同的deploys彙總，只需通過環境變數傳遞給container即可
        • 一致性和依賴
          • 開發、測試、線上執行環境均採用docker生成的映象，保證一致
          • 基礎系統、基本工具、框架，分層構建
          • 基礎映象在開發、測試、線上環境統一預部署
        • 私有映象倉庫
          • V2版本
          • 支援UFile驅動
          • 定時pull最新映象

      • 一些經驗

        • docker日誌
          • 日誌列印耗費效能
          • 最好關閉logdriver，將日誌列印在後臺
        • docker daemon
          • 退出kill container， 升級docker daemon， kill可選
        • docker網路
          • NAT模式下會啟用nf_conntrack，造成效能下降，調節核心引數
        • docker映象
          • 編寫dockfile規範、減少映象層數，基礎部分放前面
          • 分地域部署映象registry

主要問題

1. 單例項效能調優 + 萬兆卡的效能發揮出來。需要對OVS（Open vSwitch）做一些改進

2. 多機房:多機房及可用域支援

3. 容器網路需求

   • Iptables 有些坑
   • 跨主機容器間網路訪問
   • 容器網路是否需要具備IP地址漂移能力

4. 容器網路面臨的問題

   • Docker Host 模式,混布存在埠衝突。
   • Docker NAT 模式,Ip地址敏感服務改造大,無法支援服務發現
   • Overlay網路,涉及IP地址規劃,MAC地址分配,網路裝置收斂比等問題
   • Overlay網路安全性,可維護性, 容量規劃

5. 版本升級(docker/mesos/k8s)本身的升級

6. docker 對有狀態的服務進行容器化的問題

   • kafka / mysql

網路選型(k8s和mesos)

思考 && 痛點

1. 可否跨機器訪問? 跨域訪問?

   • flannel可以跨容器通訊
   • 跨主機的容器互聯
   • 容器與外部互聯

2. 是否支援靜態ip , 固定ip ? 域名訪問?

   • 固定ip的話,那麼就需要每次部署或者更新或重啟的時候,ip保持不變
   • overlay network, Docker 1.6 可以實現跨主機通訊

3. 是否支援dns?

4. 4層/7層訪問

5. 容器庫容後的網路

6. ip埠,最好不要自行手動規劃

7. 網路策略,防禦 ,隔離 ?

   • 容器叢集不同應用之間的網路隔離和流量限制

8. docker 網路

   • host模式: 容器都是直接共享主機網路空間的，容器需要使用-p來進行埠對映, 無法啟動兩個都監聽在 80 埠的容器, 並且沒有做到隔離
   • container模式: 一個容器直接使用另外一個已經存在容器的網路配置：ip 資訊和網路埠等所有網路相關的資訊都共享
   • Bridge模式: 從docker0子網中分配一個IP給容器使用，並設定docker0的IP地址為容器的預設閘道器
     • 容器的IP在容器重啟的時候會改變
     • 不同主機間容器通訊需要依賴第三方方案如:pipework

方案

1. 方案類別

   • 隧道方案, 通過隧道，或者說Overlay Networking的方式：
     • Weave，UDP廣播，本機建立新的BR，通過PCAP互通。
     • Open vSwitch（OVS），基於VxLAN和GRE協議，但是效能方面損失比較嚴重。
     • Flannel，UDP廣播，VxLan。
   • 路由方案
     • Calico，基於BGP協議的路由方案，支援很細緻的ACL控制，對混合雲親和度比較高。
     • Macvlan，從邏輯和Kernel層來看隔離性和效能最優的方案，基於二層隔離，所以需要二層路由器支援，大多數雲服務商不支援，所以混合雲上比較難以實現。
     • 效能好,沒有NAT，效率比較高, 但是受限於路由表,另外每個容器都有一個ip,那麼業務ip可能會被用光.

2. 網路的兩大陣營

   • Docker Libnetwork Container Network Model（CNM）陣營(Docker Libnetwork的優勢就是原生，而且和Docker容器生命週期結合緊密)

     • Docker Swarm overlay
     • Macvlan & IP network drivers
     • Calico
     • Contiv（from Cisco）

   • Container Network Interface（CNI）陣營 (CNI的優勢是相容其他容器技術（e.g. rkt）及上層編排系統（Kuberneres & Mesos))

     • Kubernetes
     • Weave
     • Macvlan
     • Flannel
     • Calico
     • Contiv
     • Mesos CNI

3. 常見的解決方案有：

   • flannel vxlan，overlay方式

   • calico

     • 容器間網路三層隔離，無需要擔心arp風暴
     • 基於iptable/linux kernel包轉發效率高，損耗低
     • Calico沒有多租戶的概念，所有容器節點都要求可被路由，IP地址不能重複

   • ipvlan macvlan，物理二層/三層隔離，目前需要pipework工具在單個節點上配置，僅做了vlan隔離，不解決arp廣播

   • swarm native vxlan，跟flannel vxlan類似

   • neutron sdn，選擇就多種了，ml2+ovsplugin，midonet，vlan or vxlan

   • Weave

     • 能夠建立一個虛擬網路來連線部署在多臺主機上的Docker容器, 外部裝置能夠訪問Weave網路上的應用程式容器所提供的服務，同時已有的內部系統也能夠暴露到應用程式容器上

   • contiv

     • 思科主導，sdn解決方案，可以用純軟的ovs，也可以用ovs+cisco硬體sdn controller
     • 基於 OpenvSwitch，以外掛化的形式支援容器訪問網路，支援 VLAN，Vxlan，多租戶，主機訪問控制策略等
     • SDN能力，能夠對容器的網路訪問做更精細的控制
     • 京東基於相同的技術棧（OVS + VLAN）已支援10w+ 容器的執行

   • linux bridge+三層交換機：host上 linux bridge 設定為三層交換機的子網網段，容器之間通訊走二層交換，容器與外部走三層交換機的閘道器。

4. 業界常用網路選型

   • kubernetes + flannel

     • Kubernetes採用扁平化的網路模型，要求每個Pod擁有一個全域性唯一IP，Pod直接可以跨主機通訊。目前比較成熟的方案是利用Flannel
     • Flannel已經支援UDP、VxLAN、AWS VPC和GCE路由等資料轉發模式。
     • kubernetes 下有 flannel、openvswitch和weave可以實現Overlay Network
     • 唯品會 contiv netplugin方案(固定外網ip) + flannel
     • 京東 Flannel + Neutron + OVS
     • Flannel效能: 官方:頻寬沒有下降,延遲明顯變大

   • Mesos + Caclio

     • Mesos支援CNI標準規範
     • 一容器一ip, 網路隔離, DNS服務發現, ip分配, L3的虛擬網路
     • 去哪兒 Mesos + Caclio
     • 七牛 Bridge+ NAT + Open vSwitch

   • 魅族雲 OVS & VLAN + SR-IOV

   • ucloud: vswitch overlay的"大二層"網路SDN組網方案 + ipvlan

日誌監控選型(包括監控,統計)

docker由於分層設計模式,容器裡面無法固化資料, 容器銷燬裡面的資料就會丟失, 因此建議將日誌掛載到宿主機上, 或者使用分散式儲存如ceph

stdout/stderr型別的日誌，可通過logspout轉發到syslog中心來收集

Docker 的LogDriver 能輸出日誌到特定的端點，例如Fluentd，Syslog，或者Journald。 Logspout能將容器日誌路由到Syslog或者第三方的諸如Redis，Kafka或者Logstash的模組中。

0. 方案介紹

   • 採用容器外收集。將主機磁碟掛在為容器中的日誌目錄和檔案。
   • 將容器中應用的控制到日誌也重定向到日誌目錄。
   • 在主機上對應用日誌目錄和docker日誌目錄做日誌收集和輪換。

1. 監控可選方案

   • cAdvisor + InfluxDB + Grafana
   • cAdvisor + Prometheus + Grafana
   • Graphite
   • Zabbix
   • Datadog

2. 日誌可選方案

   • logstash
   • ELK
   • Graylog
   • flume
   • heka
   • fluentd

3. 業界方案

   • 阿里雲 : cAdvisor + InfuxDB + prometheus
   • 協程: ELK
   • 知乎: Graphite + cAdvisor

映象管理

1. 映象總是從Dockerfile生成
2. 映象之間應該避免依賴過深，建議為三層，這三層分別是基礎的作業系統映象、中介軟體映象和應用映象
3. 所有映象都應該有對應的Git倉庫，以方便後續的更新
4. Registry
   • 單點問題，對應的解決方案可以考慮DRBD、分散式儲存以及雲端儲存
   • Regitry的效能問題，目前可用的解決方案是通過HTTP反向代理快取來加速Layer的下載, 或者提供映象mirror
   • Registry使用者許可權，Nginx LUA可以提供一個簡單快速的實現方案

個人理解

1. 選型不能只看編排, 還要看儲存/網路等方面的支援

   • swarm以前有些缺陷,如不能檢測失敗節點並重啟,最新版的也實現
   • k8s 只是用來排程docker
   • mesos是用來管理機器叢集. 通過Marathon才能間接管理docker

2. 對應網路的支援

   • 是否能夠跨主機/跨域
   • 是否能夠固定ip/ dns解析?
   • CNI 標準的支援?

3. 對於儲存的支援

   • 是否能夠固化?
   • 是否支援分散式儲存?

4. 對於編排/排程/升級

   • 是否支援回滾? 線上升級? 滾動升級?
   • 是否能夠細粒度分配cpu/記憶體等
   • 是否支援有狀態服務的容器化 和 排程
   • 自動擴縮容能力?

5. 服務註冊/發現機制 / 負載均衡

   • 是否有合適的服務序號產生器制?
   • 負載均衡是否能夠滿足各種業務場景需求?

6. 其他

   • 隔離, 除了cgroup和namespace, 還有其他的隔離,比如網路隔離