下面是 Metadata Service 的架構圖，本節我們詳細討論各個組件以及它們之間的關系。
nova-api-metadata
nova-api-metadata 是 nova-api 的一個子服務，它是 metadata 的提供者，instance 可以通過 nova-api-metadata 的 REST API 來獲取 metadata 信息。
nova-api-metadata 運行在控制節點上，服務端口是 8775。
通過進程 ID 13415 查看該啟動程序。
我們這個環境是 devstack，nova-api-metadata 的程序名稱就是 nova-api，nova-api-metadata 與常規的 nova-api 服務是合並在一起的。不過在 OpenStack 的其他發行版中可能有單獨的 nova-api-metadata 進程存在。
nova.conf 通過參數 enabled_apis 指定是否啟用 nova-api-metadata。
osapi_compute 是常規的 nova-api 服務，metadata 就是 nova-api-metadata 服務。
neutron-metadata-agent
nova-api-metadata 在控制節點上，走 OpenStack 內部管理網絡，instance 是無法通過 http://controller_ip:8775 直接訪問 metadata service 的，因為網絡不通。
那怎么辦呢？
答案是：借助 neutron-metadata-agent。
neutron-metadata-agent 運行在網絡節點上。instance 先將 metadata 請求發給 neutron-metadata-agent，neutron-metadata-agent 再將請求轉發到 nova-api-metadata。
這里還有個問題需要解釋清楚：instance 如何將請求發送到 neutron-metadata-agent？
實際上 instance 是不能直接與 neutron-metadata-agent 通信的，因為 neutron-metadata-agent 也是在 OpenStack 內部管理網絡上的。不過好在網絡節點上有另外兩個組件，dhcp agent 和 l3 agent，它們兩兄弟與 instance 可以位於同一 OpenStack network 中，這樣就引出了下一個組件： neutron-ns-metadata-proxy。
neutron-ns-metadata-proxy
neutron-ns-metadata-proxy 是由 dhcp-agent 或者 l3-agent 創建的，也運行在網絡節點。更精確的說法是：運行在網絡節點的 namespace 中。
如果由 dhcp-agent 創建，neutron-ns-metadata-proxy 就運行在 dhcp-agent 所在的 namespace 中；如果由 l3-agent 創建，neutron-ns-metadata-proxy 就運行在 neutron router 所在的 namespace 中。“neutron-ns-metadata-proxy” 中間的 ns 就是 namespace 的意思。neutron-ns-metadata-proxy 與 neutron-metadata-agent 通過 unix domain socket 直接相連。
這樣整個鏈路就打通了：
1. instance 通過 neutron network（Project 網絡）將 metadata 請求發送到 neutron-ns-metadata-proxy。
2. neutron-ns-metadata-proxy 通過 unix domain socket 將請求發給 neutron-metadata-agent。
3. neutron-metadata-agent 通過內部管理網絡將請求發送給 nova-api-metadata。
可能大家對於 neutron-ns-metadata-proxy 還會有些疑慮：既然 dhcp-agent 和 l3-agent 都可以創建和管理 neutron-ns-metadata-proxy，使用的時候該如何選擇呢？
簡單的說：各有各的使用場景，並且兩種方案可以共存。大家不用擔心，后面我們會通過例子詳細討論。
Metadata Service 的架構已經討論清楚了，下一節將通過實踐加深理解。
