OpenStack 通用設計思路 - 天天5分鐘玩轉 OpenStack（25）

 

API 前端服務

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

以 Nova 爲例，nova-api 做爲 Nova 組件對外的惟一窗口，向客戶暴露 Nova 可以提供的功能。 當客戶須要執行虛機相關的操做，能且只能向 nova-api 發送 REST 請求。 這裏的客戶包括終端用戶、命令行和 OpenStack 其餘組件。

設計 API 前端服務的好處在於： 1. 對外提供統一接口，隱藏實現細節 2. API 提供 REST 標準調用服務，便於與第三方系統集成 3. 能夠經過運行多個 API 服務實例輕鬆實現 API 的高可用，好比運行多個 nova-api 進程

Scheduler 調度服務

對於某項操做，若是有多個實體都可以完成任務，那麼一般會有一個 scheduler 負責從這些實體中挑選出一個最合適的來執行操做。

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

調度服務就比如是一個開發團隊中的項目經理，當接到新的開發任務時，項目經理會評估任務的難度，考察團隊成員目前的工做負荷和技能水平，而後將任務分配給最合適的開發人員。

除了 Nova，塊服務組件 Cinder 也有 scheduler 子服務，後面咱們會詳細討論。

Worker 工做服務

調度服務只管分配任務，真正執行任務的是 Worker 工做服務。

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

1. 當計算資源不夠了沒法建立虛機時，能夠增長計算節點（增長 Worker）

2. 當客戶的請求量太大調度不過來時，能夠增長 Scheduler

Driver 框架

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 框架的應用。

Messaging 服務

在前面建立虛機的流程示意圖中，咱們看到 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 這類分佈式系統中，一般採用異步調用的方式，其好處是：

1. 解耦各子服務 子服務不須要知道其餘服務在哪裏運行，只須要發送消息給 Messaging 就能完成調用。

2. 提升性能 異步調用使得調用者無需等待結果返回。這樣能夠繼續執行更多的工做，提升系統總的吞吐量。

3. 提升伸縮性 子服務能夠根據須要進行擴展，啓動更多的實例處理更多的請求，在提升可用性的同時也提升了整個系統的伸縮性。並且這種變化不會影響到其餘子服務，也就是說變化對別人是透明的。

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

Database

OpenStack 各組件都須要維護本身的狀態信息。 好比 Nova 中有虛機的規格、狀態，這些信息都是在數據庫中維護的。 每一個 OpenStack 組件在 MySQL 中有本身的數據庫。

小結

Nova 是 OpenStack 中最重要的組件，也是很典型的組件。 Nova 充分體現了 OpenStack 的設計思路。 理解了這種思路，再來學習 OpenStack 的其餘組件就可以觸類旁通，清晰容易不少。

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