如何削減50%機(jī)器預(yù)算？“人機(jī)對(duì)抗”探索云端之路

前言

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

關(guān)于云

云是什么

我理解的云本質(zhì)可以理解為自由靈活的資源共享。資源隨時(shí)加入，隨時(shí)脫離，如空中飄動(dòng)的云，來(lái)去無(wú)定，云起云落，看起來(lái)是那片云，細(xì)看又不一樣。

對(duì)云的期待

站在計(jì)算機(jī)應(yīng)用的角度，理想的云是可以讓計(jì)算/網(wǎng)絡(luò)/存儲(chǔ)資源變成生活中的水和電，操控開(kāi)關(guān)即可呼之即來(lái)?yè)]之即去。對(duì)比物理機(jī)部署時(shí)代，云用戶不用因某臺(tái)機(jī)器死機(jī)造成數(shù)據(jù)損壞而暴走，也不用因機(jī)器損壞加班恢復(fù)服務(wù)而黯然神傷。

·自動(dòng)容災(zāi)(異常拉起，故障遷移)

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

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

·快捷擴(kuò)容，資源呼之即來(lái)，來(lái)即能戰(zhàn)

一切多么完美，開(kāi)發(fā)運(yùn)維測(cè)試兄弟的福音?。?/p>

系統(tǒng)上云分析

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

CVM

在物理機(jī)基礎(chǔ)上是對(duì)機(jī)器硬盤(pán)及cpu等資源做了虛擬化，用戶使用方式上本質(zhì)還是物理機(jī)的方式，只是可以避免機(jī)器裁撤的痛苦，用戶體驗(yàn)層面上沒(méi)有本質(zhì)的改變。

容器化部署平臺(tái)

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

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

比如在云梯上資源申請(qǐng)TKE容器資源(CPU/內(nèi)存/存儲(chǔ)等)，過(guò)程就像到淘寶下單購(gòu)物一樣流暢，資源到位快速，在強(qiáng)推動(dòng)審批下可達(dá)到分鐘級(jí)到位，我第一次體驗(yàn)時(shí)是驚訝贊嘆的。

基于對(duì)公司服務(wù)的深入了解及分析，最終我們決定使用TKE部署平臺(tái)，采用docker容器化部署的方式對(duì)人機(jī)對(duì)抗服務(wù)上云。

上云對(duì)開(kāi)發(fā)的核心影響

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

1.上游變化:對(duì)客戶端通過(guò)來(lái)源IP鑒權(quán)模式不再可行，需要一種更靈活有彈性的鑒權(quán)方式

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

3.下游的變化:這個(gè)倒問(wèn)題不大，只要提供L5或北極星方式自動(dòng)尋址即可，目前平臺(tái)提供了相應(yīng)的服務(wù)管理功能。

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

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

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

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

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

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

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

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

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

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

1.創(chuàng)建負(fù)載，就是讓服務(wù)跑起來(lái)，我們的已經(jīng)沒(méi)問(wèn)題了。

2.為負(fù)載創(chuàng)建一個(gè)對(duì)應(yīng)的北極星服務(wù)，供后面使用。

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

注意選擇到對(duì)應(yīng)的業(yè)務(wù)集群，進(jìn)入創(chuàng)建頁(yè)面:

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

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

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

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

云上鑒權(quán)思路的改變

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

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

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

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

上游接入鑒權(quán)

當(dāng)用戶申請(qǐng)接入訪問(wèn)時(shí)，需要對(duì)用戶進(jìn)行認(rèn)證鑒權(quán)，來(lái)源IP鑒權(quán)肯定是行不通的，權(quán)衡之下我們使用了token鑒權(quán)的方式，當(dāng)用戶申請(qǐng)接入時(shí)，我們會(huì)給他們分配appid/token，當(dāng)用戶來(lái)訪問(wèn)時(shí)，我們會(huì)要求他們?cè)谙㈩^中帶上時(shí)間戳，序列號(hào)，appid，rand字符串，簽名。

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

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

下游依賴鑒權(quán)

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

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

為什么是tRPC-Go

在人機(jī)對(duì)抗服務(wù)平臺(tái)建設(shè)開(kāi)始階段，曾經(jīng)面對(duì)過(guò)語(yǔ)言框架選型問(wèn)題，部門(mén)原來(lái)習(xí)慣c++，框架上有SecAppFramework或spp framework，新系統(tǒng)我們要怎么抉擇?回答這個(gè)問(wèn)題前，回到我們面對(duì)的問(wèn)題及目標(biāo):

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

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

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

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

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

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

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

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

眾生之力加持

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

統(tǒng)一日志

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

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

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

·uls，cls等

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

1.在代碼中引入代碼包

2.在yaml中簡(jiǎn)單配置即可使用:

在問(wèn)題定位的時(shí)候，可以在web端查看日志:

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

強(qiáng)大監(jiān)控

監(jiān)控服務(wù)有:

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

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

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

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

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

統(tǒng)一配置中心

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

T配置服務(wù)

·使用簡(jiǎn)單，功能豐富程度一般

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

R配置服務(wù)

·公司級(jí)方案，有專(zhuān)門(mén)的Oteam支持

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

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

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

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

先在R配置服務(wù)上注冊(cè)項(xiàng)目，并配置分組

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

下面是簡(jiǎn)單易用的操作界面:

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

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

上云帶來(lái)了什么

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

穩(wěn)定性提升

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

1.TKE支持服務(wù)心跳檢查，應(yīng)用異常拉起，故障遷移

2.輕松支持異地部署，多地容災(zāi)

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

如果99.999%是我們對(duì)服務(wù)穩(wěn)定性的追求，相對(duì)老部署模式下小時(shí)/天級(jí)別的機(jī)器異?；謴?fù)時(shí)間，服務(wù)穩(wěn)定性提升1-2個(gè)9這是可以預(yù)見(jiàn)的。

提升資源利用率

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

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

上云后的提升

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

2.由于機(jī)器資源利用率的提升，人機(jī)對(duì)抗方面的機(jī)器預(yù)算比原來(lái)縮減了50%

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

4.容器部署模式，系統(tǒng)進(jìn)入天然強(qiáng)維護(hù)狀態(tài)。因?yàn)殓R像是完整可重演的，有問(wèn)題修復(fù)后也會(huì)肯定記錄入庫(kù)，沒(méi)有丟失或遺漏的后顧之憂。在物理機(jī)/CVM時(shí)代，程序/腳本/配置很可能是單一放置到某個(gè)機(jī)器上(特別是某些離線預(yù)處理系統(tǒng))，機(jī)器損壞或系統(tǒng)崩潰這些東西就沒(méi)了，當(dāng)然你會(huì)說(shuō)物理機(jī)部署也能做到備份或及時(shí)入庫(kù)，但是那需要依賴于人的自覺(jué)或?qū)π袨榈膹?qiáng)約束，成本是不一樣的。但是大多數(shù)情況下，墨菲定律會(huì)變成你繞不開(kāi)的夢(mèng)魘

結(jié)語(yǔ)

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

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

以上是我在人機(jī)對(duì)抗上云過(guò)程中的一點(diǎn)實(shí)踐跟感悟，跟大家分享共勉。