如何削減 50% 機器預算？“人機對抗”探索雲端之路

前言

人機對抗旨在聯合各個安全團隊，共同治理黑灰產。由於歷史原因，業務端對各個安全能力的訪問方式入口多，對接系統/協議有十幾個，呈現碎片化的狀態，對外不利於業務對安全能力的便捷接入，對內不利於安全團隊間的協同共建。為了提升各方面的效率，人機對抗服務在建設過程中大范圍使用雲服務，取得了很好的效果。回顧安全能力上雲的過往，是一個從模糊到清晰，從遲疑到堅定的過程，在此給大家做個簡要的分享。

關於雲

雲是什么

我理解的雲本質可以理解為自由靈活的資源共享。資源隨時加入，隨時脫離，如空中飄動的雲，來去無定，雲起雲落，看起來是那片雲，細看又不一樣。

對雲的期待

站在計算機應用的角度，理想的雲是可以讓計算/網絡/存儲資源變成生活中的水和電，操控開關即可呼之即來揮之即去。對比物理機部署時代，雲用戶不用因某台機器死機造成數據損壞而暴走，也不用因機器損壞加班恢復服務而黯然神傷，

• 自動容災(異常拉起，故障遷移)
• 輕松異地部署(多集群)
• 資源隔離-死道友不死貧道，你貪心了，安息吧
• 快捷擴容，資源呼之即來，來即能戰

一切多么完美，開發運維測試兄弟的福音啊！

系統上雲分析

隨着公司基礎服務的完善，目前公司內已有的服務設施可支持我們上雲。經過調研發現，公司雲相關平台及部署方式有:

CVM

在物理機基礎上是對機器硬盤及 cpu 等資源做了虛擬化，用戶使用方式上本質還是物理機的方式，只是可以避免機器裁撤的痛苦，用戶體驗層面上沒有本質的改變。

容器化部署平台

docker 容器化部署是目前業界雲主要部署方式，docker 容器化部署讓我們一次建構，到處運行，完美滿足自由運行，資源隔離的要求，系統環境天然是強維護的，一切程序/腳本/配置都在鏡像中，不再有丟失或遺漏維護的問題。物理機時代機器損壞導致腳本配置破壞無法恢復的現象不會再出現，系統維護靠自覺或強約束這些問題天然地消失了。

而類似 K8s 這樣的容器編排調度系統的出現，支持了自動容災/故障切換/多集群部署等強大的平台特性，使我們離雲服務的目標更近一步。基於 K8s 容器編排調度機制，目前公司內開發出一系列的部署平台，比如 123 平台，GaiaStack，TKE 等，再完美配合L5/北極星等尋址服務的自動關聯管理，為雲服務提供了完整的平台機制支撐。再加上基於資源管理平台對資源的靈活調配，使雲計算使用的便捷性更上一台階。比如在雲梯上資源申請TKE容器資源(CPU/內存/存儲等)，過程就像到淘寶下單購物一樣流暢，資源到位快速，在強推動審批下可達到分鍾級到位，我第一次體驗時是驚訝贊嘆的。

基於對公司服務的深入了解及分析，最終我們決定使用 TKE 部署平台，采用 docker 容器化部署的方式對人機對抗服務上雲

上雲對開發的核心影響

上雲帶來一個核心變化就是資源是易變的，為了便於系統資源調度，服務結點IP是可變的，上雲后需要面對包括上游業務端/自身/下游依賴端的IP變化，由此衍生出一系列的約束及依賴

1. 上游變化: 對客戶端通過來源IP鑒權模式不再可行，需要一種更靈活有彈性的鑒權方式
2. 自身變化: 對外服務地址可將服務地址關聯綁定到北極星的方式向外提供服務，如果所依賴的下游需要鑒權且使用源IP鑒權的話，下游需要改造支持更靈活的鑒權方式。多數情況下，服務需要對自身做一些例行運維工作，比如需要頻繁修改配置下發，老的運維工具不再行得通，需要一個集中的運維配置中心。
3. 下游的變化: 這個倒問題不大，只要提供L5或北極星方式自動尋址即可，目前平台提供了相應的服務管理功能。

系統架構及上雲規划

人機對抗數據中心主要模塊為變量共享平台，它的核心有2個，一個查詢服務模塊，另一個是支持變量管理 api 的 web 模塊，這兩模塊都基於 tRPC-Go 框架開發，系統架構圖如下:

忽略一些依賴系統，目前暫時只對兩個核心部分使用 TKE 部署上雲，整個 TKE 部署架構如下:

整個系統的部署規划，分別在 TKE 上創建兩個系統負載 black_centre，http_apiserver，這兩部分都是核心，其中 black_centre 承載用戶的變量查詢，web 端的請求經過智能網關，再經過 CLB，然后進入 http_apiserver 才得到了真正的業務處理，主要支持查 case 及系統變量管理，變量查詢接入申請等功能。大家可能注意到，為什么 http_apiserver 引入了 clb 而不是直接由智能網關訪問，主要因為模塊上雲后，計算結點的IP是隨時可能變動的，但是公司內部申請域名指定服務地址時是不支持北極星或L5配置的，只能配置固定IP，而 CLB 提供的固定VIP的特性，很好地解決這個問題。

這里簡單提一下CLB（Cloud Load Balancer），它是對多台雲服務器進行流量分發的服務。CLB 可以通過流量分發擴展應用系統對外的服務能力，通過消除單點故障提升應用系統的可用性。最常見的用法時是根據關聯轉發規則(訪問端口/http url等，自動轉發到規則綁定的工作負載上。回到人機對抗的應用場景，我們主要是低負載的 http 服務，多個服務只要配置一下對url的轉發規則就可以共用同一個服務地址資源。比如集群服務A和B都對外提供 http 服務，但是都需要使用80端口，按傳統方式一般至少需要部署兩台機器，但是利用共享的 CLB，我們只要配置 url 分發規則，就可以將不同接口分發到相應的雲服務上。當然使用 nginx 也有類似的功能，但是易用性可維護性穩定性方面，CLB 強了不止一個級別

TKE 雲應用部署時，容器易於縮擴容，容器本身一般不固定在某個IP上，所以雲應用天生就應該設計為無狀態依賴的模式。整個鏡像盡量小，業務邏輯盡量微服務模式，避免同時糅合過多的邏輯。由於人機對抗相關模塊是一個全新的模塊，沒有太多的負累，雖然協議靈活兼容性強，但是本質上功能獨立，責職單一的，比較好地適應了這個場景。

至於如何申請資源，如何創建空間，創建負載之類的，流程很長，就不再大量截圖了，產品幫助文檔已經提供了較良好的指引，可參見https://cloud.tencent.com/document/product/457/54224，雖然我使用的是內網TKE，但內外網的雲服務，總體上體驗差別不大。

在使用 TKE 過程中，持續感受到 TKE 的強大和穩定，但最迫切的感受是需要一個容器參考復制功能，因為在現實的使用場景中，經常是想基於某個已存在的容器，稍修2-3個參數(大概率就是負載名/鏡像版本)，就能快速把負載創建起來。常用使用場景是測試驗證/異地部署，或負載重部署(負載中有很多參數改不了，要改只能重建)，甚至部署新服務(跟已有負載的資源使用及運行模式一樣)。現在碰到要創建新負載，要填很多參數操作多了就感覺很繁瑣，小需求，大進步，如果能解決這個問題，TKE 使用的便捷性相信也能上一大台階。

發現雲中君

從上面的架構流程分析來看，准備好鏡像，利用 TKE 平台我們的服務已經跑起來，但是別人怎么找到我的服務地址? 有人說將服務地址錄入L5/北極星搞定，但是不要忘了，雲結點運行過程中，服務IP是隨時可變的，需要想辦法把雲服務的變動的地址跟北極星建立關聯，對北極星的地址列表進行關聯管理，才能真正做到舉重若輕。剛好 TKE 就提供了這樣的特性，完美實現我們的目的。按下面的步驟來可解決:

1. 創建負載，就是讓服務跑起來，我們的已經沒問題了。
2. 為負載創建一個對應的北極星服務，供后面使用。
3. 新建北極星關聯規則，先進入北極星關聯操作頁面如下圖

注意選擇到對應的業務集群，進入創建頁面:

如此這般，把已經創建的北極星服務信息填進去，再跟指定的容器服務關聯起來，再提交完成，最后完成北極星與動態服務地址的綁定

當我們對負載中的容器服務進行擴縮容時，我們可以發現北極星服務中的地址列表也會跟着進行增加或刪除，這樣無論服務部署變更或容災遷移，業務方看到的服務地址都是有效的。

同時北極星為了兼容一些老用戶使用L5的習慣，還支持對北極星服務創建L5的別名，用戶可以利用別名，使用L5方式，就可以愉快尋址到與北極星發布的相同的服務。進入北極星官網左側的菜單欄"服務管理"->"服務別名"創建別名

過往分析是老版本的l5agent對這方面兼容性不夠，把l5agent升級到最新版本就能解決了。

雲上鑒權思路的改變

系統上雲后，由於結點IP的不固定，帶來最典型的變化就是鑒權模式的影響。老模式下的按來源IP鑒權已經不適用，需要使用更靈活的鑒權方式。業界常用的兩種認證鑒權的方案:

1. SSL/TLS認證方式，這種方式經常被用來做傳輸加密，而不是訪問控制，tRPC-Go的API已經有了相應支持。
2. 基於Token的認證方式，這也是本系統重點要實現的方案

雖然方法很多，但是我們需要根據不同的場景根據需求選擇不同的方案。

上游接入鑒權

當用戶申請接入訪問時，需要對用戶進行認證鑒權，來源IP鑒權肯定是行不通的，權衡之下我們使用了 token 鑒權的方式，當用戶申請接入時，我們會給他們分配 appid/token，當用戶來訪問時，我們會要求他們在消息頭中帶上時間戳，序列號，appid，rand 字符串，簽名。其中簽名根據時間戳，序列號，appid，rand 字符串及 token 聯合生成。當服務端收到請求時，也會根據相應的字段使用與客戶端同樣的算法生成簽名，並與請求的簽名做比較，如果一致則通過，否則拒絕。其中時間戳的作用可用於防重播。

其實公司內的鑒權平台 knocknock 也提供了一套 token 簽名鑒權方式，它是一種基於 tRPC-Go 認證鑒權方式。但是基於用戶訪問的簡單性及降低平台依賴，所以最終人機對抗按上面的思路定制了自己的 token 鑒權方式。

下游依賴鑒權

目前我們的下游比較簡單，大數據查詢代理(見架構圖)已經改造為支持token鑒權方式，ckv+ 是登錄時密碼鑒權方式。除了 CDB，其它服務沒有太多的問題。訪問 CDB，按安全規范不允許使用 root，而且需要針對IP授權訪問，而授權需要先指定特定IP，在上雲過程中，容器IP經常漂移。這些情況 TKE 已經在規划實現跟業務下游打通授權，CDB 就在其中。各個業務也可以對接TKE來打通注冊。其實本質是在 CDB 與 TKE 之間增加一個自動注冊機制，根據服務IP的變化，自動將IP注冊到CDB的鑒權列表，邏輯上類似北極星之與 TKE 負載變動的關聯關系。

為什么是 tRPC-Go

在人機對抗服務平台建設開始階段，曾經面對過語言框架選型問題，部門原來習慣c++，框架上有 SecAppFramework 或 spp framework，新系統我們要怎么抉擇? 回答這個問題前，回到我們面對的問題及目標:

1. 訪問量大，高並發性要求及較高的機器資源利用率
2. 業務的快速發展要求我們高效支撐，包括開發/運維發布/定位問題/數據分析
3. 公司內各服務上雲是趨勢，將會用到公司內各種雲相關平台及服務，所用語言及 framework 最好能方便快捷把這些能力用起來，c++ 及 AppFramework 看起來就頭大，各種服務支撐不夠或用起來很難，有點力不從心，

面對部門老框架/spp Framework/tRPC-cpp/tRPC-Go 等一系列的選擇，從性能/開發便捷性/並發控制/周邊服務支撐豐富程度多個角度，最終選用了 tRPC-Go，目標就是圍繞研效提升，更細化的分析如下:

1. Golang 語言簡單，各種代碼包完備豐富，性能接近c++，但是天生支持協程且並發控制簡單，簡單的並發設計就可榨干機器資源，相對c++心智負擔更低，生產能力更強。
2. spp framework 和 tRPC-C++等公司內的一系列協程框架都是基於 c++，同時 spp 框架下，worker 單進程最多只能使用單核，而且 proxy 本身會成為瓶頸，tRPC-C++ 也使用過，復雜性比較高
3. tRPC 是公司力推的 OTeam，並在不斷完善，tRPC-Go 服務接口開發簡單，而且周邊服務支持組件豐富，增加到配置文件即可以跑起來，比如北極星/L5，智研日志/監控，各種存儲訪問組件(比如 mysql/redis 等)，使用R配置服務等。開發層面各個環節基本覆蓋，再加上原來有一定的使用使用經驗，熟悉程度高，調用各種服務如臂使指。

使用 tRPC-Go 構建系統過程中，除了在熟悉過程碰到一些問題，但沒碰到過很大的坑，代碼寫錯也能很快定位，沒碰到過那種神鬼莫測的詭異問題。總體上是流暢順滑的，心智負擔輕，能更聚焦於業務，生產能力強

眾生之力加持

除了模塊的核心邏輯，為了讓服務更穩定，運維更高效，需要一系列的周邊服務來支持，比如日志/監控/配置中心等支持服務

統一日志

雲上結點，寫本地日志對定位問題是不合適的，最核心原因在於問題出現時，本地日志你得先找到問題所在的結點再進去查看，光這個就是個麻煩的過程，而且雲結點重啟可能會使日志丟失，所以使用一個統一的網絡日志中心勢在必行，目前公司內主流的日志服務有:

• 智研，TEG產品，操作簡單，易用，在驗證碼有成功實踐。在 tRPC-Go 框架使用下，更簡單易用，只要配置一下，不修改業務代碼就可以把日志轉發到日志中心
• 鷹眼，系統功能豐富，但接入復雜，易用性需要加強
• uls，cls等

最終選用的是智研日志，主要是在滿足要求條件下足夠簡單易用，在 tRPC-Go 加持下，僅需要:

1. 在代碼中引入代碼包
2. 在 yaml 中簡單配置即可使用:

​

在問題定位的時候，可以在 web 端查看日志:

具體中間件實現細節及幫助可見 tRPC-Go 下面的智研日志插件工程

強大監控

監控服務有:

1. 智研: TEG 產品，多維度監控，功能強大易用，使用簡捷，部門內多次使用驗證
2. monitor: 基於屬性定義的監控，老產品，成熟穩定，但是監控方式單一
3. 007: 系統功能豐富，接入復雜，易用性需要加強

最終選用的是智研監控，智研的多維度監控，使監控能力更豐富，定位問題更快速，且使用足夠簡單，在 tRPC-Go 體系下，僅需要插件配置/插件注冊/調用api進行數據上報，即可完成例行的數據監控，同時多維度監控，可以利用合適的維度定義，使監控數據更立體，更利於分析問題:

以上面這個圖為例，可以定義一個變量查詢的指標，關聯來源ip/處理結果兩個緯度，在我們關注對應業務的訪問情況時，可以看到來自每個來源IP的訪問量，也可以看到每種處理結果(如上圖)的各個訪問量，服務的整體情況一目了然，跟原來 monitor 監控相比，這是一個維度提升。

統一配置中心

我們的業務一般是基於一定配置運行的，我們也會經常修改配置再發布。過去傳統的方式是到每個機器上修改配置文件，再重啟。或是把配置集中存儲，各機器上模塊定時讀取配置，再加載到程序中去。在 Oteam 協作的情況下，公司提供了各種配置同步服務，目前公司主要有兩種同步方案:

T 配置服務

使用簡單，功能豐富程度一般

配置權限控制單一，經咨詢數據加密方面也沒版本計划

R 配置服務

公司級方案，有專門的 Oteam 支持

配置同步有權限控制，后續會支持加密特性

配置形式支持豐富，json，yaml，string，xml 等

支持公有/私有配置組，方便配置的復用及配置在模塊間的划分，同時支持灰度/分步發布

兩個服務在 tRPC-Go 的開發模式下都簡單易用，而且數據修改后后台可以即時生效，綜合考慮下最終選用R配置服務做為配置同步同台，使用方式比較簡單:

1. 先在R配置服務上注冊項目，並配置分組
2. 在代碼中連接R配置服務，讀取數據並偵聽可變配置項的變化。

下面是簡單易用的操作界面:

以對外發布變量ID的配置為例，這個ID列表會根據需求不停增加或修改，只要用戶在web端修改發布，雲上各結點就能感知到配置的變化並立即生效。無論是服務穩定性還是發布效率，相對傳統配置修改發布方式都有了質的提升

tRPC-Go 對服務進行插件形式的設計，大大簡化了各個服務的調用方式，再加上 tRPC-Go 下面活躍的開源項目，對研效的提升超過50%。以我們常用的訪問 mysql/redis 為例，以通常的開源庫使用或封裝，需要處理異常/連接池封裝/尋址封裝(公司內使用L5或北極星)等，開發+測試基本需要1-2天，但是使用 trpc-go/database 下的對應開源組件可降到2小時左右。再說配置同步/日志中心服務的使用與自研或半自研相比，開發時間可以由2天降到4小時。客觀而論，相關組件如果自研或半自研，在這么短的時間內，只能做到定制能用，穩定性通用性方面，相信是較難比得上平台服務的。關鍵是公司內的代碼協同及各種 Oteam，將會有特性日益豐富強大的過程，他們成熟度的的提升，也會衍化為整個組織生產力的躍升。整體評估，使用公司內成熟的中間件是一個正確的選擇

上雲帶來了什么

目前人機對抗服務不斷在引入老系統流量或接入新業務，整個系統讀寫訪問量最高超過 1200萬/min，變量緯度訪問流量最高達 1.4億/min(單個訪問請求可以訪問多個變量)。整個服務在雲上穩定運行超3個月，不負眾望。

穩定性提升

忽略模塊本身的代碼質量，穩定性提供主要是由雲上容器部署所具有的幾個平台特性所帶來的:

1. TKE支持服務心跳檢查，應用異常拉起，故障遷移

2. 輕松支持異地部署，多地容災

3. 資源隔離，異常業務不影響正常業務

如果99.999%是我們對服務穩定性的追求，相對老部署模式下小時/天級別的機器異常恢復時間，服務穩定性提升1-2個9這是可以預見的

提升資源利用率

在物理機/CMV的部署模式下，一般整機資源利用率達到20%就不錯了，特別是一些小模塊。但是上雲后TKE的彈性擴縮容機制之下，通過配置輕松可以使容器資源利用率達到70%。

比如下面就是目前我的應用大盤監控，為了應對可能的大流量沖擊，我配置了自動擴容，且設置了較多的基礎結點數，所以 cpu 占用率較低，實際上這些都是可以配置的。雲上容器模式部署相對傳統模式可以提升50%的系統資源利用率。

上雲后的提升

1. 利用公司內的開源技術，需求開發效率提升50%以上
2. 由於機器資源利用率的提升，人機對抗方面的機器預算比原來縮減了50%
3. 各種服務的中心化使得發布及問題定位變得更快捷，比如R配置服務及智研的投入使用，發布及問題解決由半小時->分鍾級
4. 容器部署模式，系統進入天然強維護狀態。因為鏡像是完整可重演的，有問題修復后也會肯定記錄入庫，沒有丟失或遺漏的后顧之憂。在物理機/CVM時代，程序/腳本/配置很可能是單一放置到某個機器上(特別是某些離線預處理系統)，機器損壞或系統崩潰這些東西就沒了，當然你會說物理機部署也能做到備份或及時入庫，但是那需要依賴於人的自覺或對行為的強約束，成本是不一樣的。但是大多數情況下，墨菲定律會變成你繞不開的夢魘

結語

回首這么多年中心和公司在研效提升的努力，系統框架從最開始的 srv_framework，到中心的 Sec Appframework，再到 spp framework 等各種協程框架，再到 tRPC 的蓬勃發展。數據同步一致性從手工同步，主備同步，到使用同步中心同步再到公司內的各種分布式存儲服務，系統部署從物理機手工部署到各種五花八門的發布工具到織雲藍鯨，從物理機，CVM再到承載服務的雲得到大規模業務的成功驗證等，公司的研效提升一路走來，從一個蹣跚學步的小孩，成長為一個健步如飛的少年。站在現代算力體系巔峰的雲上回望，公司對雲的的認識和探索實踐，也經歷了從模糊到清晰，從遲疑到堅定的過程，而我們的努力並沒有被這個時代所辜負，一串串提升的各種指標描述及用戶的認可就是對我們的肯定和嘉獎，激勵我們義無反顧向未來前行。

認識並建設雲，創新並開拓雲，我們腳踏大地，可是我們更仰望星空。子在川上曰：“逝者如斯夫！不舍晝夜。”

以上是我在人機對抗上雲過程中的一點實踐跟感悟，跟大家分享共勉。

【騰訊雲原生】雲說新品、雲研新術、雲游新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！