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

前言

人機對抗旨在聯(lián)合各個安全團隊，共同治理黑灰產(chǎn)。由于歷史原因，業(yè)務端對各個安全能力的訪問方式入口多，對接系統(tǒng)/協(xié)議有十幾個，呈現(xiàn)碎片化的狀態(tài)，對外不利于業(yè)務對安全能力的便捷接入，對內(nèi)不利于安全團隊間的協(xié)同共建。為了提升各方面的效率，人機對抗服務在建設過程中大范圍使用云服務，取得了很好的效果?；仡櫚踩芰ι显频倪^往，是一個從模糊到清晰，從遲疑到堅定的過程，在此給大家做個簡要的分享。

關于云

云是什么

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

對云的期待

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

·自動容災(異常拉起，故障遷移)

·輕松異地部署(多集群)

·資源隔離-死道友不死貧道，你貪心了，安息吧

·快捷擴容，資源呼之即來，來即能戰(zhàn)

一切多么完美，開發(fā)運維測試兄弟的福音??！

系統(tǒng)上云分析

隨著公司基礎服務的完善，目前公司內(nèi)已有的服務設施可支持我們上云。經(jīng)過調(diào)研發(fā)現(xiàn)，公司云相關平臺及部署方式有:

CVM

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

容器化部署平臺

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

而類似K8s這樣的容器編排調(diào)度系統(tǒng)的出現(xiàn)，支持了自動容災/故障切換/多集群部署等強大的平臺特性，使我們離云服務的目標更近一步?；贙8s容器編排調(diào)度機制，目前公司內(nèi)開發(fā)出一系列的部署平臺，比如123平臺，GaiaStack，TKE等，再完美配合L5/北極星等尋址服務的自動關聯(lián)管理，為云服務提供了完整的平臺機制支撐。再加上基于資源管理平臺對資源的靈活調(diào)配，使云計算使用的便捷性更上一臺階。

比如在云梯上資源申請TKE容器資源(CPU/內(nèi)存/存儲等)，過程就像到淘寶下單購物一樣流暢，資源到位快速，在強推動審批下可達到分鐘級到位，我第一次體驗時是驚訝贊嘆的。

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

上云對開發(fā)的核心影響

上云帶來一個核心變化就是資源是易變的，為了便于系統(tǒng)資源調(diào)度，服務結點IP是可變的，上云后需要面對包括上游業(yè)務端/自身/下游依賴端的IP變化，由此衍生出一系列的約束及依賴

1.上游變化:對客戶端通過來源IP鑒權模式不再可行，需要一種更靈活有彈性的鑒權方式

2.自身變化:對外服務地址可將服務地址關聯(lián)綁定到北極星的方式向外提供服務，如果所依賴的下游需要鑒權且使用源IP鑒權的話，下游需要改造支持更靈活的鑒權方式。多數(shù)情況下，服務需要對自身做一些例行運維工作，比如需要頻繁修改配置下發(fā)，老的運維工具不再行得通，需要一個集中的運維配置中心。

3.下游的變化:這個倒問題不大，只要提供L5或北極星方式自動尋址即可，目前平臺提供了相應的服務管理功能。

系統(tǒng)架構及上云規(guī)劃

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

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

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

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

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

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

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

發(fā)現(xiàn)云中君

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

1.創(chuàng)建負載，就是讓服務跑起來，我們的已經(jīng)沒問題了。

2.為負載創(chuàng)建一個對應的北極星服務，供后面使用。

3.新建北極星關聯(lián)規(guī)則，先進入北極星關聯(lián)操作頁面如下圖

注意選擇到對應的業(yè)務集群，進入創(chuàng)建頁面:

如此這般，把已經(jīng)創(chuàng)建的北極星服務信息填進去，再跟指定的容器服務關聯(lián)起來，再提交完成，最后完成北極星與動態(tài)服務地址的綁定

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

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

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

云上鑒權思路的改變

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

SSL/TLS認證方式，這種方式經(jīng)常被用來做傳輸加密，而不是訪問控制，tRPC-Go的API已經(jīng)有了相應支持。

基于Token的認證方式，這也是本系統(tǒng)重點要實現(xiàn)的方案

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

上游接入鑒權

當用戶申請接入訪問時，需要對用戶進行認證鑒權，來源IP鑒權肯定是行不通的，權衡之下我們使用了token鑒權的方式，當用戶申請接入時，我們會給他們分配appid/token，當用戶來訪問時，我們會要求他們在消息頭中帶上時間戳，序列號，appid，rand字符串，簽名。

其中簽名根據(jù)時間戳，序列號，appid，rand字符串及token聯(lián)合生成。當服務端收到請求時，也會根據(jù)相應的字段使用與客戶端同樣的算法生成簽名，并與請求的簽名做比較，如果一致則通過，否則拒絕。其中時間戳的作用可用于防重播。

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

下游依賴鑒權

目前我們的下游比較簡單，大數(shù)據(jù)查詢代理(見架構圖)已經(jīng)改造為支持token鑒權方式，ckv+是登錄時密碼鑒權方式。除了CDB，其它服務沒有太多的問題。訪問CDB，按安全規(guī)范不允許使用root，而且需要針對IP授權訪問，而授權需要先指定特定IP，在上云過程中，容器IP經(jīng)常漂移。

這些情況TKE已經(jīng)在規(guī)劃實現(xiàn)跟業(yè)務下游打通授權，CDB就在其中。各個業(yè)務也可以對接TKE來打通注冊。其實本質是在CDB與TKE之間增加一個自動注冊機制，根據(jù)服務IP的變化，自動將IP注冊到CDB的鑒權列表，邏輯上類似北極星之與TKE負載變動的關聯(lián)關系。

為什么是tRPC-Go

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

1.訪問量大，高并發(fā)性要求及較高的機器資源利用率

2.業(yè)務的快速發(fā)展要求我們高效支撐，包括開發(fā)/運維發(fā)布/定位問題/數(shù)據(jù)分析

3.公司內(nèi)各服務上云是趨勢，將會用到公司內(nèi)各種云相關平臺及服務，所用語言及framework最好能方便快捷把這些能力用起來，c++及AppFramework看起來就頭大，各種服務支撐不夠或用起來很難，有點力不從心

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

1.Golang語言簡單，各種代碼包完備豐富，性能接近c++，但是天生支持協(xié)程且并發(fā)控制簡單，簡單的并發(fā)設計就可榨干機器資源，相對c++心智負擔更低，生產(chǎn)能力更強。

2.spp framework和tRPC-C++等公司內(nèi)的一系列協(xié)程框架都是基于c++，同時spp框架下，worker單進程最多只能使用單核，而且proxy本身會成為瓶頸，tRPC-C++也使用過，復雜性比較高

3.tRPC是公司力推的OTeam，并在不斷完善，tRPC-Go服務接口開發(fā)簡單，而且周邊服務支持組件豐富，增加到配置文件即可以跑起來，比如北極星/L5，智研日志/監(jiān)控，各種存儲訪問組件(比如mysql/redis等)，使用R配置服務等。開發(fā)層面各個環(huán)節(jié)基本覆蓋，再加上原來有一定的使用使用經(jīng)驗，熟悉程度高，調(diào)用各種服務如臂使指。

使用tRPC-Go構建系統(tǒng)過程中，除了在熟悉過程碰到一些問題，但沒碰到過很大的坑，代碼寫錯也能很快定位，沒碰到過那種神鬼莫測的詭異問題?？傮w上是流暢順滑的，心智負擔輕，能更聚焦于業(yè)務，生產(chǎn)能力強。

眾生之力加持

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

統(tǒng)一日志

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

·智研，TEG產(chǎn)品，操作簡單，易用，在驗證碼有成功實踐。在tRPC-Go框架使用下，更簡單易用，只要配置一下，不修改業(yè)務代碼就可以把日志轉發(fā)到日志中心

·鷹眼，系統(tǒng)功能豐富，但接入復雜，易用性需要加強

·uls，cls等

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

1.在代碼中引入代碼包

2.在yaml中簡單配置即可使用:

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

具體中間件實現(xiàn)細節(jié)及幫助可見tRPC-Go下面的智研日志插件工程

強大監(jiān)控

監(jiān)控服務有:

1.智研:TEG產(chǎn)品，多維度監(jiān)控，功能強大易用，使用簡捷，部門內(nèi)多次使用驗證

2.monitor:基于屬性定義的監(jiān)控，老產(chǎn)品，成熟穩(wěn)定，但是監(jiān)控方式單一

3.007:系統(tǒng)功能豐富，接入復雜，易用性需要加強

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

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

統(tǒng)一配置中心

我們的業(yè)務一般是基于一定配置運行的，我們也會經(jīng)常修改配置再發(fā)布。過去傳統(tǒng)的方式是到每個機器上修改配置文件，再重啟?；蚴前雅渲眉写鎯?，各機器上模塊定時讀取配置，再加載到程序中去。在Oteam協(xié)作的情況下，公司提供了各種配置同步服務，目前公司主要有兩種同步方案：

T配置服務

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

·配置權限控制單一，經(jīng)咨詢數(shù)據(jù)加密方面也沒版本計劃

R配置服務

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

·配置同步有權限控制，后續(xù)會支持加密特性

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

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

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

先在R配置服務上注冊項目，并配置分組

在代碼中連接R配置服務，讀取數(shù)據(jù)并偵聽可變配置項的變化。

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

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

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

上云帶來了什么

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

穩(wěn)定性提升

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

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

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

3.資源隔離，異常業(yè)務不影響正常業(yè)務

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

提升資源利用率

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

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

上云后的提升

1.利用公司內(nèi)的開源技術，需求開發(fā)效率提升50%以上

2.由于機器資源利用率的提升，人機對抗方面的機器預算比原來縮減了50%

3.各種服務的中心化使得發(fā)布及問題定位變得更快捷，比如R配置服務及智研的投入使用，發(fā)布及問題解決由半小時->分鐘級

4.容器部署模式，系統(tǒng)進入天然強維護狀態(tài)。因為鏡像是完整可重演的，有問題修復后也會肯定記錄入庫，沒有丟失或遺漏的后顧之憂。在物理機/CVM時代，程序/腳本/配置很可能是單一放置到某個機器上(特別是某些離線預處理系統(tǒng))，機器損壞或系統(tǒng)崩潰這些東西就沒了，當然你會說物理機部署也能做到備份或及時入庫，但是那需要依賴于人的自覺或對行為的強約束，成本是不一樣的。但是大多數(shù)情況下，墨菲定律會變成你繞不開的夢魘

結語

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

認識并建設云，創(chuàng)新并開拓云，我們腳踏大地，可是我們更仰望星空。子在川上曰：“逝者如斯夫！不舍晝夜?！?/p>

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