本節開始，我們將詳細講解 Nova 的各個子服務。
前面架構概覽一節知道 Nova 有若干 nova-* 的子服務，下面我們將依次學習最重要的幾個。
今天先討論 nova-api 和 nova-conductor。
nova-api
Nova-api 是整個 Nova 組件的門戶，所有對 Nova 的請求都首先由 nova-api 處理。 Nova-api 向外界暴露若干 HTTP REST API 接口。 在 keystone 中我們可以查詢 nova-api 的 endponits。
客戶端就可以將請求發送到 endponits 指定的地址，向 nova-api 請求操作。 當然，作為最終用戶的我們不會直接發送 Rest AP I請求。 OpenStack CLI，Dashboard 和其他需要跟 Nova 交換的組件會使用這些 API。
Nova-api 對接收到的 HTTP API 請求會做如下處理： 1. 檢查客戶端傳人的參數是否合法有效 2. 調用 Nova 其他子服務的處理客戶端 HTTP 請求 3. 格式化 Nova 其他子服務返回的結果並返回給客戶端
nova-api 接收哪些請求？ 簡單的說，只要是跟虛擬機生命周期相關的操作，nova-api 都可以響應。 大部分操作都可以在 Dashboard 上找到。
打開Instance管理界面
點擊下拉箭頭，列表中就是 nova-api 可執行的操作。
OpenStack 用術語 “Instance” 來表示虛擬機，后面我們將統一使用這個術語。
nova-conductor
nova-compute 需要獲取和更新數據庫中 instance 的信息。 但 nova-compute 並不會直接訪問數據庫，而是通過 nova-conductor 實現數據的訪問。
這樣做有兩個顯著好處：
-
更高的系統安全性
-
更好的系統伸縮性
更高的安全性
在 OpenStack 的早期版本中，nova-compute 可以直接訪問數據庫，但這樣存在非常大的安全隱患。 因為 nova-compute 這個服務是部署在計算節點上的，為了能夠訪問控制節點上的數據庫，就必須在計算節點的 /etc/nova/nova.conf 中配置訪問數據庫的連接信息，比如
[database] connection = mysql+pymysql://root:secret@controller/nova?charset=utf8
試想任意一個計算節點被黑客入侵，都會導致部署在控制節點上的數據庫面臨極大風險。
為了解決這個問題，從 G 版本開始，Nova 引入了一個新服務 nova-conductor，將 nova-compute 訪問數據庫的全部操作都放到 nova-conductor 中，而且 nova-conductor 是部署在控制節點上的。 這樣就避免了 nova-compute 直接訪問數據庫，增加了系統的安全性。
更好的伸縮性
nova-conductor 將 nova-compute 與數據庫解耦之后還帶來另一個好處：提高了 nova 的伸縮性。
nova-compute 與 conductor 是通過消息中間件交互的。 這種松散的架構允許配置多個 nova-conductor 實例。 在一個大規模的 OpenStack 部署環境里，管理員可以通過增加 nova-conductor 的數量來應對日益增長的計算節點對數據庫的訪問。
下一節我們討論計算節點調度服務 nova-scheduler.
