為什麼要做Thor？
360搜尋有多個團隊，幾百号人。每個團隊各自有多個平台工具，但各團隊各自為戰，帶來的問題是沒有統一的開發、管理規範，不論是交接還是擴充，做的人都很痛苦。當老人離開，新人接手會掉入無盡的坑中
Thor的目标
重新定義工具&平台該如何優雅的開發和産生
簡潔、快速地将現有的平台工具內建進來
以工廠化的思維，讓平台能産生平台，不再為了同類需求造輪子
簡略架構
從Web端發起請求到Gateway，Gateway做一系列校驗和處理後請求底層微服務；底層微服務提供服務，再由Gateway 傳回響應。
完整架構
這是完整的架構圖，在thor中，每個服務都運作在Docker下，放在(Kubernetes)K8S叢集中，對外暴露host:port，挂在最上層LVS(其實就是K8S提供的VIP)下，然後統一對外提供服務，這種方式大大提高了我們系統的可用性
web
Web端對前端提供HTTP RESTful API，這裡的Auth 權限校驗，實際也是一個微服務，放在這裡是因為它主要在這裡使用。我們也在這一層加上打點監控之類，用于統計PV、UV情況等。
gateway
ETCD作為元資訊存儲媒體，它存儲了Gateway的路由表等元資訊。然後Gateway另外提供了一個admin作為元資訊的後天管理系統，也就意味着，admin寫，proxy讀。
每個server就是一個運作中的DOCKER容器
多個微服務容器挂在一個Cluster下，對外提供服務，這裡Cluster就是一個LVS的概念，一個Cluster可以視作一個微服務對外暴露的入口，但我們沒有這樣做，因為我們使用的K8S已經提供了統一對外的一個K8S-VIP(LVS)，是以其實在Thor下，一個Cluster就隻是挂了一個K8S-VIP(LVS)，然後K8S-VIP(LVS)下才挂了多個Server。
proxy讀取etcd流程
proxy啟動時，先從etcd擷取路由表routetable加載到自身記憶體，當有請求到達時，直接從記憶體中查找對應轉發規則，然後對底層微服務進行調用并将結果傳回給上遊。
proxy會watch住etcd服務，當etcd上路由表有更新時，則實時拉取更新，保證自身緩存的routetable為最新
結果
我們在Thor的架構下，完成了通用資料管理系統（通過界面配置，5分鐘生成一個功能強大的CURD工具）、智能分析平台（承接90%的資料分析需求，不懂技術的小白使用者也能輕松使用）、通用檔案服務（為其他平台提供檔案存取服務，解決各個平台各自為戰的尴尬）、SSO+權限管理系統（單點登陸、配置化的通路權限控制）等多個系統。并接入了多個其他團隊開發的平台和工具。
收益
覆寫了95%的内部平台工具
節省80% 人力
減少開發成本 40% 以上