本文來自微信公眾號“twt企業(yè)IT社區(qū)”，作者/汪照輝，中國銀河證券架構(gòu)師，專注于容器云、微服務(wù)、DevOps、數(shù)據(jù)治理、數(shù)字化轉(zhuǎn)型等領(lǐng)域，對相關(guān)技術(shù)有獨(dú)特的理解和見解。擅長于軟件規(guī)劃和設(shè)計，提出的“平臺融合”的觀點(diǎn)越來越得到認(rèn)同和事實(shí)證明。發(fā)表了眾多技術(shù)文章探討容器平臺建設(shè)、微服務(wù)技術(shù)、DevOps、數(shù)字化轉(zhuǎn)型、數(shù)據(jù)治理、中臺建設(shè)等內(nèi)容，受到了廣泛關(guān)注和肯定。
近期NVIDIA發(fā)布了新一代架構(gòu)的GPU Blackwell，采用多芯片封裝設(shè)計，同樣的模型訓(xùn)練所需GPU數(shù)量和能耗約只是原來的25%。大模型的應(yīng)用促使企業(yè)采購大量的GPU服務(wù)器，但也對傳統(tǒng)數(shù)據(jù)中心的電力、制冷等帶來挑戰(zhàn)。需求驅(qū)動新技術(shù)的創(chuàng)新和應(yīng)用，新技術(shù)應(yīng)用也會帶來新的問題，又驅(qū)動新的技術(shù)和方法來解決出現(xiàn)的問題，從而形成循環(huán)螺旋向前發(fā)展的趨勢。在數(shù)字化時代，面對敏捷響應(yīng)、業(yè)務(wù)轉(zhuǎn)型等眾多目標(biāo)要求，認(rèn)識并深刻理解IT架構(gòu)的演進(jìn)方向和趨勢，知其然并知其所以然，是企業(yè)數(shù)字化生產(chǎn)力轉(zhuǎn)型的關(guān)鍵。
隨著IT技術(shù)的創(chuàng)新和發(fā)展，逐步地能滿足不同的業(yè)務(wù)場景需求，也驅(qū)動著IT架構(gòu)不斷地演進(jìn)中，因此IT系統(tǒng)的更新和迭代是一種常態(tài)。
IT系統(tǒng)初期架構(gòu)
信息化初期，受限于當(dāng)時的軟硬件技術(shù)，只能采用簡單的信息系統(tǒng)代替人工完成計算、存儲等能力。信息系統(tǒng)的所有功能代碼部署在一臺服務(wù)器中，就是最早的單體系統(tǒng)架構(gòu)。單體架構(gòu)指的是IT系統(tǒng)的部署架構(gòu)，單體架構(gòu)的應(yīng)用程序的業(yè)務(wù)邏輯往往緊密耦合，系統(tǒng)的所有功能必須部署為一個單元，難以拆分，導(dǎo)致了高度耦合的體系結(jié)構(gòu)。隨著時間和功能的累積，單體系統(tǒng)功能往往會越積越多，成為難以修改和變更的單體巨石應(yīng)用。
隨著硬件、軟件和網(wǎng)絡(luò)等技術(shù)的發(fā)展，出現(xiàn)了一個server并行支持多個client訪問的Client/Server架構(gòu)模式，這是初始的二層分布式模式。軟件研發(fā)人員將前端功能和數(shù)據(jù)存儲分離，形成前端+數(shù)據(jù)庫的二層模式，滿足不同用戶根據(jù)授權(quán)從多個客戶端訪問同一個功能的需求。隨著互聯(lián)網(wǎng)技術(shù)的出現(xiàn)和應(yīng)用，一個瀏覽器就可以訪問互聯(lián)網(wǎng)上的內(nèi)容，稱為B/S架構(gòu)模式。雖然B/S模式下的Server端可能也分離出并訪問數(shù)據(jù)庫，但從互聯(lián)網(wǎng)整體模式上，WebServer和數(shù)據(jù)庫是運(yùn)行在數(shù)據(jù)中心的機(jī)器上，而用戶接口運(yùn)行在用戶的瀏覽器上，因此還是看作是二層架構(gòu)。隨著軟件高級開發(fā)語言能力的增強(qiáng)和軟件研發(fā)框架的出現(xiàn)和增多，軟件系統(tǒng)的層次演進(jìn)為三層架構(gòu)或多層架構(gòu)。表示層使用php、jsp、asp、javascript、html等實(shí)現(xiàn)，應(yīng)用邏輯層封裝在應(yīng)用層，數(shù)據(jù)庫訪問封裝在數(shù)據(jù)層，Java的MVC等是非常典型的三層架構(gòu)框架。初期IT系統(tǒng)需求相對簡單，只側(cè)重一個單點(diǎn)領(lǐng)域功能，比如財務(wù)管理等，幾乎所有功能堆積在一起，基本上沒有架構(gòu)的概念，至多實(shí)現(xiàn)代碼或函數(shù)的復(fù)用，隨著系統(tǒng)需求的擴(kuò)展和復(fù)雜度增加，逐步進(jìn)行了架構(gòu)分層、模塊分解等。隨著系統(tǒng)建設(shè)數(shù)量越來越多，系統(tǒng)間共享成為迫切需求。
共享復(fù)用驅(qū)動集成
IT技術(shù)和軟件系統(tǒng)的出現(xiàn)驅(qū)動每家公司都逐步建設(shè)了眾多的單體系統(tǒng)，比如說人力、財務(wù)、辦公、客戶管理、供應(yīng)商管理等，解決了企業(yè)單點(diǎn)的效率問題。但隨著時間的推移，單體系統(tǒng)建設(shè)的越來越多，企業(yè)業(yè)務(wù)流程可能會涉及散落于各個單體系統(tǒng)中的數(shù)據(jù)，系統(tǒng)之間數(shù)據(jù)的共享需求越來越多，由于這些系統(tǒng)可能不同的廠商提供的，從而也帶來了架構(gòu)不同、開發(fā)語言不同、數(shù)據(jù)結(jié)構(gòu)不同、技術(shù)路線不同等眾多異構(gòu)系統(tǒng)間數(shù)據(jù)共享難題，系統(tǒng)與系統(tǒng)之間彼此隔離，數(shù)據(jù)形成孤島。早期的二層或三層架構(gòu)等理論上是一種分布式單體架構(gòu)，雖然進(jìn)行了分層，卻依然是緊耦合的。另外，供應(yīng)商往往為了突出自己的系統(tǒng)功能支持多個場景，不斷增加和擴(kuò)展系統(tǒng)功能邊界，都希望自己提供的系統(tǒng)盡可能多的滿足客戶需求，從而也造成多個系統(tǒng)都有類似的功能。不但造成重復(fù)建設(shè)，也使系統(tǒng)之間的集成和共享復(fù)雜化。
為了實(shí)現(xiàn)這些單體豎井系統(tǒng)之間的數(shù)據(jù)共享和功能復(fù)用，不得不去做系統(tǒng)集成。系統(tǒng)間數(shù)據(jù)共享需求驅(qū)動了系統(tǒng)間的集成，驅(qū)動從DBLink到EAI、消息集成、SOA服務(wù)化等多種集成方式的出現(xiàn)和發(fā)展。不過系統(tǒng)集成是一種加層補(bǔ)丁方式，如ESB，會導(dǎo)致整個業(yè)務(wù)鏈路加長，性能和效率降低。
復(fù)用和敏捷變更驅(qū)動系統(tǒng)分解和組件重構(gòu)
隨著使用的深入以及系統(tǒng)集成需求，企業(yè)往往會提出一些定制化的需求，從而使系統(tǒng)的版本不斷迭代，功能越來越多。隨著功能的增多，系統(tǒng)越來越復(fù)雜，變更迭代的難度越來越大，變更速度就越來越低，早期的系統(tǒng)往往沒有規(guī)劃組件架構(gòu)關(guān)系，彼此之間是緊耦合的，牽一發(fā)動全身，某一個點(diǎn)的更新可能會影響到其他功能的正常運(yùn)行，也就導(dǎo)致開發(fā)人員不敢輕易變更。特別在開發(fā)人員變化之后，后續(xù)的開發(fā)人員對前期代碼的不熟悉，很容易導(dǎo)致系統(tǒng)的重大異?；驍?shù)據(jù)錯誤，從而帶來損失。
為了解決重復(fù)建設(shè)的問題，將一些共用的能力或模塊分離出來實(shí)現(xiàn)復(fù)用。復(fù)用有很多層次，比如說代碼復(fù)用、函數(shù)復(fù)用、類復(fù)用、服務(wù)復(fù)用、組件復(fù)用、平臺復(fù)用等等，不同的發(fā)展階段復(fù)用的層次也不一樣。最初通常通過代碼復(fù)制實(shí)現(xiàn)代碼復(fù)用或者定義函數(shù)來實(shí)現(xiàn)代碼的復(fù)用；在面向?qū)ο缶幊毯蟾嗖捎妙?、?組件復(fù)用的方式；系統(tǒng)集成越來越多的使用組件復(fù)用和服務(wù)化服務(wù)復(fù)用等。比如將消息處理分解為一個消息中間件工具，日志處理分解為日志中間件工具等。這也促使單體系統(tǒng)的分解，單體系統(tǒng)架構(gòu)逐步分拆為分布式架構(gòu)，最終成為當(dāng)前的分布式微服務(wù)架構(gòu)。當(dāng)然也是基于技術(shù)的創(chuàng)新和發(fā)展能夠支持分布式的系統(tǒng)交互。在一臺服務(wù)器無法再縱向擴(kuò)展支撐越來越多的業(yè)務(wù)請求時，就需要解析單體架構(gòu)為分布式架構(gòu)，將功能模塊進(jìn)行分解，逐步沉淀為一個個組件或工具，比如日志平臺、權(quán)限認(rèn)證平臺、基礎(chǔ)設(shè)施平臺等。
資源復(fù)用驅(qū)動資源池化、云化和基礎(chǔ)設(shè)施融合
為了充分利用資源，提升資源利用率，存儲資源池、網(wǎng)格計算、并行計算、虛擬化等技術(shù)的發(fā)展，使計算、存儲、網(wǎng)絡(luò)等能夠統(tǒng)一管理和分配調(diào)度?；ヂ?lián)網(wǎng)的巨大需求也使通過網(wǎng)絡(luò)提供各種服務(wù)的云計算迅猛發(fā)展。虛擬化和云計算使應(yīng)用所需的計算、存儲、網(wǎng)絡(luò)等資源更容易提供，在這個過程中存儲資源池、虛擬化、超融合、多云管理等也逐步實(shí)現(xiàn)了基礎(chǔ)設(shè)施資源的融合，從而從基礎(chǔ)設(shè)施資源層屏蔽了異構(gòu)基礎(chǔ)設(shè)施資源細(xì)節(jié)，提供標(biāo)準(zhǔn)化的基礎(chǔ)設(shè)施資源服務(wù)。這也使當(dāng)前的平臺工程成為可能。
隨著云計算分層服務(wù)能力的完善，應(yīng)用和基礎(chǔ)設(shè)施完全分離，甚至多家云廠商提供了無服務(wù)器Serverless架構(gòu)模式，云成為企業(yè)業(yè)務(wù)應(yīng)用系統(tǒng)研發(fā)和部署運(yùn)行的底座。不過Serverless往往受限于云廠商所提供的框架和能力，而微服務(wù)粒度的敏捷迭代、可復(fù)用的服務(wù)化架構(gòu)基于云平臺的自動化構(gòu)建和部署運(yùn)行受到了更多企業(yè)的關(guān)注和應(yīng)用?；谠频鬃邪l(fā)和部署微服務(wù)架構(gòu)的應(yīng)用，實(shí)現(xiàn)自動化的部署和運(yùn)行運(yùn)維管理等能力，從而也促進(jìn)了云原生體系的構(gòu)建和應(yīng)用。
企業(yè)級復(fù)用驅(qū)動“中臺架構(gòu)”出現(xiàn)
隨著企業(yè)規(guī)模的增長，為了實(shí)現(xiàn)企業(yè)級功能和數(shù)據(jù)復(fù)用，國內(nèi)廠商提出了“中臺”的概念。但“中臺”沒有明確合適的可復(fù)用粒度，使“大中臺”過于笨重，導(dǎo)致不得不“拆中臺”。中臺架構(gòu)的核心在于定義可共享復(fù)用的粒度。共享和復(fù)用有不同的粒度，粒度過小則難以管理，比如函數(shù)級的粒度，會導(dǎo)致量過大而難以管理；粒度過大，則增加額外的對接和封裝工作量，比如以整個系統(tǒng)或工具為粒度，都需要基于該系統(tǒng)或工具的接口或API進(jìn)行額外的對接，而且一旦版本或工具變更，所有的工作都需要重新做一遍。
以抽象、提取可共享可復(fù)用的企業(yè)級微服務(wù)作為中臺層，支撐這些服務(wù)的平臺和工具作為后臺層，中臺層的微服務(wù)來自于后臺的工具和平臺能力的抽象和沉淀，而不是直接依賴于后臺工具和平臺的API。簡單的說，就是需要在后臺平臺和工具之上封裝一層微服務(wù)作為企業(yè)級可復(fù)用中臺層。這樣，即便后臺工具版本變更或工具替換，也可以不影響前臺的業(yè)務(wù)應(yīng)用。這就明確中臺的可復(fù)用粒度和可復(fù)用服務(wù)來源。中臺架構(gòu)嘗試以連通、融合企業(yè)內(nèi)各業(yè)務(wù)條線的數(shù)據(jù)和基礎(chǔ)設(shè)施能力，形成聯(lián)動，從而減少重復(fù)建設(shè)、提升響應(yīng)能力。服務(wù)化和中臺融合，從而可以實(shí)現(xiàn)以微服務(wù)粒度為單位的企業(yè)級復(fù)用能力，也因此可以以PaaS平臺為依托，支撐云原生可復(fù)用中臺微服務(wù)的部署、運(yùn)行、高可用、可觀測性、韌性等。云原生容器提供了一致性環(huán)境、彈性伸縮、輕量、無狀態(tài)等特性，契合微服務(wù)的敏捷變更需求，從而也促進(jìn)了云原生架構(gòu)的進(jìn)一步應(yīng)用和發(fā)展。
云化驅(qū)動云原生的出現(xiàn)和應(yīng)用
云計算提供了敏捷的、自服務(wù)的、不變的基礎(chǔ)設(shè)施等內(nèi)容，使業(yè)務(wù)應(yīng)用上云逐漸成為一種共識，但不進(jìn)行云原生架構(gòu)重構(gòu)而直接上云可能是危險的。傳統(tǒng)業(yè)務(wù)應(yīng)用架構(gòu)無法在云上進(jìn)行彈性擴(kuò)展和敏捷響應(yīng)，無法有效利用云計算的特性賦能企業(yè)，所以這需要對傳統(tǒng)架構(gòu)的業(yè)務(wù)系統(tǒng)進(jìn)行分布式微服務(wù)分拆重構(gòu)，部署運(yùn)行在容器平臺之中，使用DevOps思想通過CI、CD等提升持續(xù)交付效率，等等。使應(yīng)用從一開始被創(chuàng)建就具備云的特性，為云而生，它是為了充分利用云計算的分布式和彈性擴(kuò)展等特征，使其具備或適應(yīng)云上部署運(yùn)行的要求，或者直接用云的思想、方法、工具在云中創(chuàng)建，天生具備云的特性。所以云原生可以認(rèn)為是一種基于云來構(gòu)建和運(yùn)行云應(yīng)用程序的方法論和技術(shù)體系，使用云原生技術(shù)和方法論來構(gòu)建和運(yùn)行管理云上應(yīng)用。
架構(gòu)演進(jìn)趨勢
從單體架構(gòu)到云原生，IT架構(gòu)從出現(xiàn)到現(xiàn)在一直是不斷的分解過程中，分解的越來越細(xì)，但彼此之間卻又不斷地集成、融合。因?yàn)榉纸獾脑絹碓郊?xì)，使相互之間的依賴加深。如果架構(gòu)定義不好，往往導(dǎo)致影響面巨大的事故，比如多個大廠的持續(xù)故障就是在于整體架構(gòu)存在局限。IT系統(tǒng)在不斷分解融合的過程中，需要越來越關(guān)注架構(gòu)的設(shè)計和健壯性。
架構(gòu)演進(jìn)趨勢和社會化分工發(fā)展趨勢是一致的。專業(yè)化分工提升效率，但也彼此依賴加深，但一體化融合的架構(gòu)是不可逆的，就像全球化，雖然不少人反全球化，但總的來說，全球化更符合大多人的利益，更符合資源的最大化配置。因此，對于一家企業(yè)來說，需要考慮企業(yè)級的一體化融合架構(gòu)。我以前也提到過，我們都習(xí)慣于做加層，導(dǎo)致整個系統(tǒng)的架構(gòu)體系越來越復(fù)雜，系統(tǒng)中的垃圾也越來越多。一個應(yīng)用動不動就是幾個G，可能不必要的組件就占了一大部分。這也導(dǎo)致了額外的風(fēng)險和潛在故障。多一個組件就多一個故障點(diǎn)，復(fù)雜度就增加一分，因此，在考慮企業(yè)級一體化架構(gòu)時，需要盡可能消除不必要的組件，簡化組件功能，使每個組件成為一個自治的單體，同時又是整個體系的一部分。每個組件的故障不應(yīng)影響和導(dǎo)致其他組件不可用。每個組件都是可替代的。
總的來說，科技在不斷的進(jìn)步，促進(jìn)了業(yè)務(wù)的創(chuàng)新和發(fā)展以及社會的發(fā)展，而系統(tǒng)架構(gòu)也在持續(xù)的演進(jìn)，但總的趨勢和方向趨同于人類社會的發(fā)展趨勢。
