在 MicroXchg 2017 柏林大會上，DigitalOcean 的微服務可擴展性專家 Martin Campbell 針對如何使用分佈式調度器運行基於微服務的架構做了一個演講。在演講中，Campbell 著重介紹了在他們在部署過程中遇上的一些問題，以及在他們是如何權衡選用 Kubernetes、Nomad 和 Mesos 等產品的。

關鍵要點

• 分佈式調度器使得用戶可將集群理解為單一的物理機。

• 分佈式調度器簡化了 DevOps，大大降低了普遍存在於微服務架構中的操作複雜性。

• 沒有任何現有產品可以完美地運行有狀態服務，因此最好不要使用現有產品去運行這類服務。

• 在網絡分區的情況下，即便有些過程所在的主機節點不能與主服務器通信，容錯的分佈式調度器也應該保持所有進程的運行。

Campbell 首先指出，操作系統內核就是一種集中式調度器，因為它在單一計算機上實現了對多個進程的管理。

他進而闡述了分佈式調度在概念上與集中式調度器是類似的，差別在於它是跨集群中各機器工作的，而非工作於單一機器上。“我們可以與整個數據中心通信，就像是面對單臺物理機一樣。”

分佈式調度器 尤其適用於微服務架構。Cambell 認為這是考慮到那些額外的操作開銷，這些操作開銷是由不斷得以擴展和部署的多個服務所導致的。

選擇分佈式調度器Mesos

對於如何選擇多種分佈式調度器的問題，Campbell 首先介紹了他在 Mesos 上的實戰經驗。

當使用 Mesos 時，用戶不需操心進程所在的實際物理機，因為 Mesos 是基於對 CPU 和 RAM 等資源的限額處理做部署的。

Mesos 還提供了一個儀表盤，可像查看單一物理機那樣方便地實現數據中心的可視化。

Campbell 指出，Mesos 的主要問題在於它對 網絡分區的處理方式。如果一個進程不能與 Mesos 的主服務器通信，那麼該進程就會被殺掉。在 Campbell 看來，這並非是一種好的設計方式。

事實上，因為網絡分區普遍存在於分佈式系統中，在這種情況下應該繼續保持應用的運行。他以 Kafka 為例說明了這種行為會導致數據的丟失。

雖然 Kafka 是一種分佈式消息總線，在設計上考慮了彈性問題，但是分區還是可以導致丟失幾乎全部的單一節點及數據。

Nomad

Campbell 最終棄用了 Mesos，他先是轉向 Nomad 作為替代。Nomad 的優點在於，它具有自身的 Gossip 協議，允許服務器在同一數據中心中及跨數據中心間的相互通信。

在網絡分區的情況下，同一分區中的服務會保持功能及通信，並在分區識別時成為最終一致的。但是由於 Campbell 並不瞭解有任何在生產環境中運行 Nomad 的應用，因而不想冒險遷移到 Nomad 上。

Kubernetes

他最終選定了 Kubernetes。儘管 Kubernetes 類似於 Mesos，Campbell 還是從中發現一些 獨到之處。最主要的是，Kubernetes 對網絡分區處理機制不同，並不會在上述情況下殺死實例。它也提供了儀表盤，讓用戶易於瞭解集群的狀態，減少了處理應用中的抽象層級。

Java工程化、高性能及分佈式、高性能、深入淺出。高架構。性能調優、Spring，MyBatis，Netty源碼分析和大數據等多個知識點。如果你想拿高薪的，想學習的，想就業前景好的，想跟別人競爭能取得優勢的，想進阿里面試但擔心面試不過的，你都可以來，群號為：647631030

附註：加群要求

1、具有1-5工作經驗的，面對目前流行的技術不知從何下手，需要突破技術瓶頸的可以加。

2、在公司待久了，過得很安逸，但跳槽時面試碰壁。需要在短時間內進修、跳槽拿高薪的可以加。

3、如果沒有工作經驗，但基礎非常紮實，對java工作機制，常用設計思想，常用java開發框架掌握熟練的，可以加。

4、覺得自己很牛B，一般需求都能搞定。但是所學的知識點沒有系統化，很難在技術領域繼續突破的可以加。

5.阿里Java高級大牛直播講解知識點，分享知識，多年工作經驗的梳理和總結，帶著大家全面、科學地建立自己的技術體系和技術認知！

6.小號加群一律不給過，謝謝。