為什麼要做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% 以上