[[405083]]

本文轉(zhuǎn)載自微信公眾號「zartbot」，作者扎波特的網(wǎng)線鉗。轉(zhuǎn)載本文請聯(lián)系zartbot公眾號。

似乎到處都在談融合，前幾年超融合、如今云網(wǎng)融合，卻沒有從最根本的地方去思考什么是融合.

昨天看到一頁ppt雖然在講其它的融合，但是這個總結(jié)非常好：

接下來我們將從這幾個話題中逐漸展開來談?wù)剶?shù)字化轉(zhuǎn)型中的融合應(yīng)該怎么做. 整個的融合必定是自頂而下的，以業(yè)務(wù)為中心的視角。

業(yè)務(wù)融合

Business Convergence 通常是在很多MBA課程里面都會談到的一個話題，也就是我們常說的數(shù)字化轉(zhuǎn)型，利用信息技術(shù)將企業(yè)研發(fā)設(shè)計(jì)、生產(chǎn)制造、經(jīng)營管理、市場營銷、風(fēng)險控制等各個業(yè)務(wù)條線進(jìn)行融合。比較有代表性的是一些新型的供應(yīng)鏈管理、網(wǎng)絡(luò)營銷、數(shù)字化風(fēng)控等系統(tǒng)的出現(xiàn)。

服務(wù)融合

然后就是從業(yè)務(wù)融合出發(fā)，需要提供一套可行的服務(wù)架構(gòu)支撐業(yè)務(wù)條線，也就是我們看到的中臺架構(gòu)出現(xiàn)的原因，本質(zhì)是中臺的出現(xiàn)是業(yè)務(wù)的需求，但是中臺是否合理，其實(shí)反過來是從業(yè)務(wù)上看是否需要服務(wù)融合，因此很多企業(yè)大中臺發(fā)展了很多年卻成了整個企業(yè)發(fā)展的瓶頸，這就是很多管理者盲目中臺賦能導(dǎo)致的。當(dāng)然從技術(shù)上也有這樣的趨勢，微服務(wù)的出現(xiàn)，Service-Mesh的架構(gòu)，本質(zhì)上都是服務(wù)融合產(chǎn)生的結(jié)果。

基礎(chǔ)設(shè)施融合

緊接著就是基礎(chǔ)設(shè)施的融合，從SDN到超融合所謂的SD-Storage，到最近IaC(Infra as Code)，然后演進(jìn)到Software-Defined infrastructure. 但這一點(diǎn)上卻出現(xiàn)了一個巨大的鴻溝，服務(wù)器(計(jì)算或者應(yīng)用)和網(wǎng)絡(luò)的融合，超融合的成功本來可以理解為計(jì)算和存儲都發(fā)生在服務(wù)器上，是一個團(tuán)隊(duì)內(nèi)部的事情。而網(wǎng)絡(luò)和服務(wù)器的融合則是一個非常痛苦的過程，很多做智能網(wǎng)卡、DPU的公司銷售額并不好，而有智能網(wǎng)卡的云也在面臨著各種內(nèi)卷.業(yè)務(wù)融合需求、服務(wù)融合需求都很好的契合了，但是也能讓MPLS這樣的老司機(jī)快翻車了...問題在哪?

ACI的成功在于TOR Overlay很好的找到了一個主機(jī)和網(wǎng)絡(luò)的分割點(diǎn)。而HostOverlay以后，智能網(wǎng)卡的控制權(quán)歸誰?云上VPC的控制權(quán)歸誰?這就是組織架構(gòu)上帶來的問題，更加加劇了網(wǎng)絡(luò)和應(yīng)用兩個團(tuán)隊(duì)中間的矛盾，甚至開始互相對立起來。例如網(wǎng)絡(luò)團(tuán)隊(duì)需要在云上構(gòu)建NFV部署SDWAN時，網(wǎng)絡(luò)團(tuán)隊(duì)通常需要向計(jì)算團(tuán)隊(duì)申請資源，畢竟云上的賬號和計(jì)費(fèi)歸計(jì)算團(tuán)隊(duì)，因此計(jì)算的團(tuán)隊(duì)通常會選擇云提供的SDWAN方案，而網(wǎng)絡(luò)的團(tuán)隊(duì)則會選擇和私有云網(wǎng)絡(luò)架構(gòu)同構(gòu)的解決方案。多云互聯(lián)出現(xiàn)問題時，計(jì)算團(tuán)隊(duì)又需要網(wǎng)絡(luò)團(tuán)隊(duì)協(xié)助，相互之間的矛盾逐漸多起來，特別是遇到事故時的相互指責(zé)也會多起來。

其實(shí)本質(zhì)上就是在管理域上現(xiàn)有的智能網(wǎng)卡、SDWAN方案并沒有提供一個很好的分界點(diǎn)來使兩個團(tuán)隊(duì)融合，或者構(gòu)建第三個橋梁團(tuán)隊(duì)的可能性。

而這些問題就需要在協(xié)議上進(jìn)行融合了。

協(xié)議融合

兩個團(tuán)隊(duì)的融合通常來自于相互間的協(xié)議和接口的標(biāo)準(zhǔn)化。JSON、gRPC這一系列的協(xié)議在應(yīng)用層完成了很好的API整合，但是網(wǎng)絡(luò)呢?雖然也有yang/netconf Openflow這些東西，最終SDX還是沒有很好的和應(yīng)用融合。本質(zhì)上網(wǎng)絡(luò)的團(tuán)隊(duì)都在3層以下思考問題，應(yīng)用的團(tuán)隊(duì)都在7層以上思考問題。各自都有各自的Domain Specific Language，讓應(yīng)用寫P4寫B(tài)GP的TLV擴(kuò)展，讓做網(wǎng)絡(luò)的去寫C去搞Service-Mesh，這些都屬于某種Scale-up的做法，但是否存在一種Scale-out的做法呢?這就是協(xié)議的融合，也就是我說的，各自退一步在Layer-4上構(gòu)建傳輸網(wǎng)絡(luò)。

最典型的就是現(xiàn)在大火的各種豬食和在線會議業(yè)務(wù)，通常應(yīng)用會組建自己的團(tuán)隊(duì)來做RTN和CDN，這就是演變的趨勢，管理上逐漸會產(chǎn)生一個小規(guī)模的以應(yīng)用為中心的SecOps和NetOps小團(tuán)隊(duì)去配合應(yīng)用的DevOps，這樣的一個小團(tuán)隊(duì)便是應(yīng)用和網(wǎng)絡(luò)的融合點(diǎn)，但是同時這樣的團(tuán)隊(duì)需要一個抓手，那么就是相應(yīng)的協(xié)議棧上需要給他們進(jìn)行賦能。

目標(biāo)自然就定在了傳輸層上，各個云都在成立所謂的高性能網(wǎng)絡(luò)的部門，但是從未有人想過這個上層需求背后是需要一個更加獨(dú)立的團(tuán)隊(duì)來做，而傳輸協(xié)議上是Swift? 是NDP? 是HPCC? 是RoCE?是QUIC?還是SRv6? 這些對于應(yīng)用而言，我TM只懂怎么調(diào)用Socket啊...

所以一切的事情只能發(fā)生在Socket上, 這也是我在設(shè)計(jì)Ruta時優(yōu)先考慮到的問題，如果控制面用BGP,網(wǎng)絡(luò)資源無法抽象暴露給應(yīng)用，并以應(yīng)用友好的方式調(diào)度，因此控制面遷就應(yīng)用的熟悉度采用了ETCD。另一方面是數(shù)據(jù)面上，讓應(yīng)用知道除了默認(rèn)網(wǎng)關(guān)以外，也可以通過在payload中加入一些Socket數(shù)組(也就是Segment List)的方式來構(gòu)建，讓應(yīng)用遷就網(wǎng)絡(luò)做出一些改變?nèi)ビ?jì)算路徑和控制流量，學(xué)習(xí)Segment Routing。

但是同時網(wǎng)絡(luò)也需要考慮應(yīng)用的視角，盡量能夠以應(yīng)用可理解的方式進(jìn)行編碼，而不是復(fù)雜的uSID、gSID編碼方式。

軟硬件融合

最后一步也是基礎(chǔ)設(shè)施融合的關(guān)鍵，畢竟Software Defined Infra的核心遲早會觸及到軟硬件融合。P4能夠在業(yè)界獲得一系列關(guān)注到最后Barefoot成功上岸的原因就是，P4本質(zhì)上是一個介于Verilog和C之間的一個DSL. 也是在軟件和硬件之間取得一個很好的平衡點(diǎn)。但是問題也來了，你見過哪個搞應(yīng)用的會去簽了NDA才能用gcc?活生生的把自己作死吧...

吐槽歸吐槽，但是可編程硬件本身的需求還是會越來越大，不一定是FPGA，也不一定是P4 MAU，有很多的解法，最終還是要考慮到一個同構(gòu)的問題，在邊緣和云如何實(shí)現(xiàn)底層本的同構(gòu)，這才是融合的關(guān)鍵。