OpenStack 通用設計思路
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 非常容易擴充套件：
- 當計算資源不夠了無法建立虛機時，可以增加計算節點（增加 Worker）
- 當客戶的請求量太大排程不過來時，可以增加 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 這類分散式系統中，通常採用非同步呼叫的方式，其好處是：
解耦各子服務
子服務不需要知道其他服務在哪裡執行，只需要傳送訊息給 Messaging 就能完成呼叫。提高效能
非同步呼叫使得呼叫者無需等待結果返回。這樣可以繼續執行更多的工作，提高系統總的吞吐量。提高伸縮性
子服務可以根據需要進行擴充套件，啟動更多的例項處理更多的請求，在提高可用性的同時也提高了整個系統的伸縮性。而且這種變化不會影響到其他子服務，也就是說變化對別人是透明的。
在後面各章節，我們都能看到 Messaging 的應用。
Database
OpenStack 各元件都需要維護自己的狀態資訊。
比如 Nova 中有虛機的規格、狀態，這些資訊都是在資料庫中維護的。
每個 OpenStack 元件在 MySQL 中有自己的資料庫。
小結
Nova 是 OpenStack 中最重要的元件，也是很典型的元件。
Nova 充分體現了 OpenStack 的設計思路。
理解了這種思路，再來學習 OpenStack 的其他元件就能夠舉一反三，清晰容易很多。
我們在後面 Cinder 和 Neutron 的學習中還會回顧這些設計思路。
