## 前言

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

## 關於雲

### 雲是什麼

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

### 對雲的期待

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

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

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

### 系統上雲分析

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

#### 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 框架開發，系統架構圖如下:

![](https://main.qcloudimg.com/raw/c8e8d6e60f67a7c5af7d6e64fc3d6b82.png)

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

![](https://main.qcloudimg.com/raw/cd71c8c2c02c69ef9c99c77ac9863e0a.png)

整個系統的部署規劃，分別在 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. 新建北極星關聯規則，先進入北極星關聯操作頁面如下圖

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

![](https://main.qcloudimg.com/raw/62cb5c4bfa37db463d8b1efc765dbc6d.png)

如此這般，把已經建立的北極星服務資訊填進去，再跟指定的容器服務關聯起來，再提交完成，最後完成北極星與動態服務地址的繫結

![](https://main.qcloudimg.com/raw/185db8bf80e499ec8182d383921e7f36.png)

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

同時北極星為了相容一些老使用者使用L5的習慣，還支援對北極星服務建立L5的別名，使用者可以利用別名，使用L5方式，就可以愉快定址到與北極星釋出的相同的服務。進入北極星官網左側的選單欄"服務管理"->"服務別名"建立別名

![](https://main.qcloudimg.com/raw/e0dfe8237a412412b83a100dc5aa5e3a.png)

過往分析是老版本的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 中簡單配置即可使用:

![](https://main.qcloudimg.com/raw/909a87625b442d61e636ebec286461f1.png)

在問題定位的時候，可以在 web 端檢視日誌:

![](https://main.qcloudimg.com/raw/8ef97bd50b222444c7b93c9590d70790.png)
具體中介軟體實現細節及幫助可見 tRPC-Go 下面的智研日誌外掛工程

### 強大監控

監控服務有:

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

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

![](https://main.qcloudimg.com/raw/13a0de7769fd94e2eb5ff48fdc452a27.png)

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

### 統一配置中心

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

#### T 配置服務

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

配置許可權控制單一，經諮詢資料加密方面也沒版本計劃

#### R 配置服務

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

配置同步有許可權控制，後續會支援加密特性

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

支援公有/私有配置組，方便配置的複用及配置在模組間的劃分，同時支援灰度/分步釋出

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

1. 先在R配置服務上註冊專案，並配置分組
2. 在程式碼中連線R配置服務，讀取資料並偵聽可變配置項的變化。

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

![](https://main.qcloudimg.com/raw/eed31121d3a33c0cb174e0f12d06646e.png)

以對外發布變數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%的系統資源利用率。

![](https://main.qcloudimg.com/raw/6095224eb329e0a3186277315ff28446.jpg)

![](https://main.qcloudimg.com/raw/b507dec2471012971d3f9a5c39e5068d.png)

### 上雲後的提升

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

##  結語

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

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

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

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

相關文章