運維自動化之域名系統的文章發出去之後，有小夥伴問既然拿到了域名及所有基礎資源資料，那能不能從入口域名開始實現全鏈路自動化的系統拓撲構建？全鏈路的系統拓撲構建需要知道鏈路上所有節點之間的資料流轉關係，之前在落地APM監控時有接觸過，APM透過程式碼埋點拿到鏈路節點之間的資料流轉關係，而流轉關係僅透過基礎資源是沒有辦法獲取的，除非人工維護，人工往往不靠譜，程式碼埋點成本又太高，還是要從這些基礎資源資料出發，尋求簡潔點自動化解決方案。今天剛好有空就簡單想了下這個問題，初步實現，效果如下
這篇文章就簡單介紹一下我的實現方案，並不完美，甚至還有很多問題，歡迎探討。這裡有個前提就是無法透過埋點拿資料
域名可能指向到負載均衡、伺服器、CDN、高防或者是CNAME到其他的域名，有一部分資料流轉關係我們是確定的，那就是域名到伺服器這一段，以上圖域名指向負載均衡為例，域名到負載均衡的解析是固定的，然後可以透過負載均衡拿到監聽器的資料，再透過監聽器就能獲取監聽器下掛的伺服器。再往下伺服器究竟使用了哪些中介軟體我們就沒辦法獲取了，如何知道接下來的資料鏈路呢？這裡提供幾個思路
子網
我們通常會拿不同的子網來做網路隔離，如果你的網路規劃非常標準，一個專案/服務位於同一個子網下，不同專案/服務之間子網隔離，那就可以考慮使用這種方式
伺服器資料已經拿到了，那伺服器的子網也就是確定的了，就可以很容易的獲取同一子網下的其他資源資料，例如資料庫、快取等等
這種方式的準確率取決於網路的規範程度
名稱
如果子網劃分不規範，存在多個專案/服務使用同一子網的情況，那上邊的方法就不奏效了。此時如果你的資源命名都是規範的，也可以透過規範的資源名稱來獲取下一層的資料
例如如下命名：project-environment-service-name。同一專案同一環境同一服務不同資源的命名僅有最後一部分不同，那就可以遍歷資源，獲取到相同命名規則的資源，也能繼續進行下一級的自動拓撲
這種方式的準確率取決於命名的規範程度
關係樹
如果以上兩種都沒有，那還可以透過服務樹來獲取，我們在構建多雲系統時確定，所有資源都隸屬於服務樹上的某個節點，服務樹往往是規範的，那獲取與伺服器同一服務樹節點下的其他資源也是屬於同一個業務，之間的資料流向幾乎也是確定的
這種方式的話就要求你的服務樹是規範的
很明顯，雖然可以透過以上幾種方式來獲取最後一段的關係資料，但都不夠準確，尤其是在業務邏輯比較複雜的情況下，僅是做個參考而已。幾個小時的時間從思考到編碼實現，有很多不完善的地方，此文也就拋磚引玉