背景
這是本系列的第二篇，主要關注Trove的目前架構。
Trove的目前架構圖
Trove的目前架構說明
trove-api
提供REST風格的API,支援json和xml,程式源代碼入口在trove/cmd/api.py。API server與兩個元件通信，所有複雜的異步任務它都交給taskmanager去完成，有些資訊它會直接從trove的後端DB中獲得。
根據其配置檔案api-paste.ini,可以看到起最終APP的入口是：trove/common/api.py,這就是整個trove除了version和extension外所有資源對象操作的總入口。在API類中明确定義了url和處理的controller的路由關系，非常的清晰。
trove-taskmanager
負責配置資料庫虛拟機執行個體,管理資料庫虛拟機執行個體的生命周期和執行這對資料庫虛拟機執行個體的各種操作.監聽消息隊列伺服器的RPC service,程式源代碼入口在trove/cmd/taskmanage.py。需要特别注意：trove-taskmanager是一個有狀态的服務，它負責組織複雜的業務流程。如果在有狀态的處理流程當中，taskmanager挂了，則任務就被認為失敗。
trove-guestagent
運作于資料庫虛拟機執行個體的内部，負責管理和實際執行對資料庫管理程式的任務。guestagent在消息總線上監聽RPC消息，執行要求的操作。程式源代碼入口在trove/cmd/guest.py。每一種資料庫都有與之對應的不同的guestagent，顯而易見，redis的guestagent和mysql的guestagent的行為不可能是一樣的。
trove-conductor
負責從guestagents收集狀态資訊然後将其寫入Trove的後端資料庫,其與guestagent互動基于RPC實作。這個元件的引入就是為了實作這樣的目的，即db instance内的gusestagent不應直接與trove的後端資料庫相連。程式源代碼入口在trove/cmd/conductor.py。從目前的代碼看，這個元件就兩個功能函數：
- def heartbeat(self, context, instance_id, payload, sent=None)
上報DBinstance的心跳和狀态資訊，如NEW to BUILDING to ACTIVE
- def update_backup(self, context, instance_id, backup_id, sent=None, **backup_fields)
更新目前backup的狀态資訊,如目前狀态，已備份的大小，類型和校驗情況
規劃中的改進
将Trove-conductor作為通路trove後端資料庫的唯一入口，所有模型的資料庫CRDU操作都依靠他來完成。openstack很多服務元件都有這樣的設計傾向，如nova，都想将db的操作隔離出來，就我目前的了解，這樣做的好處是可以将服務的後端DB與應用層隔離，後端DB可以運作在另一個網絡中，實作網絡隔離，除conductor外的所有元件都不能直接通路到DB所在的網絡。
參考連結
https://wiki.openstack.org/wiki/TroveArchitecture
http://www.mirantis.com/blog/the-present-and-the-future-of-openstack-trove-architecture/
http://www.mirantis.com/blog/improving-trove-architecture-design-conductor-service/