OpenStack 通用設計思路 - 每天5分鐘玩轉 OpenStack（25）API 前端服務Scheduler 排程服務Worker 工作服務Driver 架構Messaging 服務Database小結

每個 OpenStack 元件可能包含若幹子服務，其中必定有一個 API 服務負責接收客戶請求。

以 Nova 為例，nova-api 作為 Nova 元件對外的唯一視窗，向客戶暴露 Nova 能夠提供的功能。 當客戶需要執行虛機相關的操作，能且隻能向 nova-api 發送 REST 請求。 這裡的客戶包括終端使用者、指令行和 OpenStack 其他元件。

設計 API 前端服務的好處在于： 1. 對外提供統一接口，隐藏實作細節 2. API 提供 REST 标準調用服務，便于與第三方系統內建 3. 可以通過運作多個 API 服務執行個體輕松實作 API 的高可用，比如運作多個 nova-api 程序

對于某項操作，如果有多個實體都能夠完成任務，那麼通常會有一個 scheduler 負責從這些實體中挑選出一個最合适的來執行操作。

在前面的例子中，Nova 有多個計算節點。 當需要建立虛機時，nova-scheduler 會根據計算節點當時的資源使用情況選擇一個最合适的計算節點來運作虛機。

排程服務就好比是一個開發團隊中的項目經理，當接到新的開發任務時，項目經理會評估任務的難度，考察團隊成員目前的工作負荷和技能水準，然後将任務配置設定給最合适的開發人員。

除了 Nova，塊服務元件 Cinder 也有 scheduler 子服務，後面我們會詳細讨論。

排程服務隻管配置設定任務，真正執行任務的是 Worker 工作服務。

在 Nova 中，這個 Worker 就是 nova-compute 了。 将 Scheduler 和 Worker 從職能上進行劃分使得 OpenStack 非常容易擴充：

當計算資源不夠了無法建立虛機時，可以增加計算節點（增加 Worker）

當客戶的請求量太大排程不過來時，可以增加 Scheduler

OpenStack 作為開放的 Infrastracture as a Service 雲作業系統，支援業界各種優秀的技術。 這些技術可能是開源免費的，也可能是商業收費的。 這種開放的架構使得 OpenStack 能夠在技術上保持先進性，具有很強的競争力，同時又不會造成廠商鎖定（Lock-in）。

那 OpenStack 的這種開放性展現在哪裡呢？ 一個重要的方面就是采用基于 Driver 的架構。

以 Nova 為例，OpenStack 的計算節點支援多種 Hypervisor。 包括 KVM, Hyper-V, VMWare, Xen, Docker, LXC 等。

Nova-compute 為這些 Hypervisor 定義了統一的接口，hypervisor 隻需要實作這些接口，就可以 driver 的形式即插即用到 OpenStack 中。 下面是 nova driver 的架構示意圖

在 nova-compute 的配置檔案 /etc/nova/nova.conf 中由 compute_driver 配置項指定該計算節點使用哪種 Hypervisor 的 driver

在我們的環境中因為是 KVM，是以配置的是 Libvirt 的 driver。

不知大家是否還記得我們在學習 Glance 時談到：

OpenStack 支援多種 backend 來存放 image。

可以是本地檔案系統，Cinder，Ceph，Swift 等。

其實這也是一個 driver 架構。

隻要符合 Glance 定義的規範，新的存儲方式可以很友善的加入到 backend 支援清單中。

再後面 Cinder 和 Neutron 中我們還會看到 driver 架構的應用。

在前面建立虛機的流程示意圖中，我們看到 nova-* 子服務之間的調用嚴重依賴 Messaging。

Messaging 是 nova-* 子服務互動的中樞。

以前沒接觸過分布式系統的同學可能會不太了解為什麼不讓 API 直接調用Scheduler，或是讓Scheuler 直接調用 Compute，而是非要通過 Messaging 進行中轉。

這裡做一些解釋。

程式之間的調用通常分兩種：同步調用和異步調用。

同步調用

API 直接調用 Scheduler 的接口就是同步調用。

其特點是 API 送出請求後需要一直等待，直到 Scheduler 完成對 Compute 的排程，将結果傳回給 API 後 API 才能夠繼續做後面的工作。

異步調用

API 通過 Messaging 間接調用 Scheduler 就是異步調用。

其特點是 API 送出請求後不需要等待，直接傳回，繼續做後面的工作。

Scheduler 從 Messaging 接收到請求後執行排程操作，完成後将結果也通過 Messaging 發送給 API。

在 OpenStack 這類分布式系統中，通常采用異步調用的方式，其好處是：

解耦各子服務

子服務不需要知道其他服務在哪裡運作，隻需要發送消息給 Messaging 就能完成調用。

提高性能

異步調用使得調用者無需等待結果傳回。這樣可以繼續執行更多的工作，提高系統總的吞吐量。

提高伸縮性

子服務可以根據需要進行擴充，啟動更多的執行個體處理更多的請求，在提高可用性的同時也提高了整個系統的伸縮性。而且這種變化不會影響到其他子服務，也就是說變化對别人是透明的。

在後面各章節，我們都能看到 Messaging 的應用。

OpenStack 各元件都需要維護自己的狀态資訊。

比如 Nova 中有虛機的規格、狀态，這些資訊都是在資料庫中維護的。

每個 OpenStack 元件在 MySQL 中有自己的資料庫。

Nova 是 OpenStack 中最重要的元件，也是很典型的元件。

Nova 充分展現了 OpenStack 的設計思路。

了解了這種思路，再來學習 OpenStack 的其他元件就能夠舉一反三，清晰容易很多。

我們在後面 Cinder 和 Neutron 的學習中還會回顧這些設計思路。

本文轉自CloudMan6 51CTO部落格，原文連結:http://blog.51cto.com/cloudman/1767372