[[405083]]

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

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

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

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

業(yè)務融合

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

服務融合

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

基礎設施融合

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

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

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

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

協(xié)議融合

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

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

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

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

但是同時網絡也需要考慮應用的視角，盡量能夠以應用可理解的方式進行編碼，而不是復雜的uSID、gSID編碼方式。

軟硬件融合

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

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