數(shù)字化浪潮下的架構融合

經(jīng)常在機場穿行的人們，很難注意不到鋪天蓋地的云計算廣告牌。我素來對于各種大詞不感冒，反倒是廣告里一行小字引發(fā)了關注：“數(shù)字化轉型專家”。過去數(shù)年間，在“互聯(lián)網(wǎng)+”的本土語系中，數(shù)字化轉型其實是一個比較夾生的表達方式。雖然“數(shù)字化”對這一進程本質(zhì)的揭示更為深刻和普適，但不可否認，以“互聯(lián)網(wǎng)”為前綴的表達方式在逆襲正勁的風口，具有更高的市場辨識度。

在一個領域中，話語構建的水平往往也表征了其本身的成熟與進化程度。更多從業(yè)者們對于“數(shù)字化轉型”語系的普遍采納，除了表明近幾年互聯(lián)網(wǎng)與傳統(tǒng)IT企業(yè)基因混雜、彼此融合的特征，也表明了企業(yè)市場在歷經(jīng)顛覆、迷茫、跟風、實踐之后，愈加清朗地辨明了自己的主要矛盾與核心訴求。IBM商業(yè)價值研究院近來發(fā)表了一系列關于“數(shù)字化重塑”（數(shù)字化轉型的進階）和“傳統(tǒng)企業(yè)逆襲”的研究報告。雖然我們并不敢說這預示著傳統(tǒng)企業(yè)數(shù)字化復蘇的春天就要到來了，但是經(jīng)過了這些年商業(yè)與技術的“顛覆”亂局后，人們至少都學會了“以彼之道還施彼身”，在挨打和混戰(zhàn)中學會了打架。以金融科技為例，今天在這個領域里的玩家，既有過去的所謂顛覆者紛紛從2C走向2B，也有傳統(tǒng)銀行突破體制格局，主動向市場輸出科技能力。

數(shù)字化轉型究竟要實現(xiàn)什么

如果以數(shù)字化轉型甚至重塑的視角去打量傳統(tǒng)企業(yè)的主要實踐，至少可以看到三個主要的方向。一、求差異，以數(shù)字化手段重構客戶體驗。二、謀格局，在數(shù)字化建設過程中創(chuàng)造新的業(yè)務模式，以滿足（可數(shù)字化的）業(yè)務能力或者資產(chǎn)更靈活地在廣義的業(yè)務生態(tài)中實現(xiàn)交付，乃至變現(xiàn)。三、孵創(chuàng)新，在企業(yè)內(nèi)部通過機制，培育、孵化業(yè)務和技術的“殺手锏”。當然，對于企業(yè)來講真正困難的并不是找到一招鮮的法寶，而是深刻基于自己的傳統(tǒng)和現(xiàn)狀，找出一條循序漸進的進化道路。我們可以認為這是一種“整合性”的創(chuàng)新能力。如果悖離自己的業(yè)務和技術的傳統(tǒng)和現(xiàn)狀，以突變、割裂的方式妄談創(chuàng)新，往往只會為實踐領域制造更多二元對峙的概念和文化沖突。

而無論在哪個方向上去踐行數(shù)字化轉型，經(jīng)歷過這一波市場的洗禮，大多數(shù)企業(yè)對于“場景”都有了更加深刻的認知和感受。場景作為流量變現(xiàn)的關鍵，成為了事實上驗證業(yè)務和技術的標準。這種共識使得人們比以往更加關注垂直的業(yè)務場景落地。“小而美”的垂直實踐比“高大上”的平臺構想要更加謹慎而務實。以銀行為例，處于業(yè)務敏感前沿的分行或業(yè)務部門近年來涌現(xiàn)出越來越多顆粒度不大，但是時效性比較迫切的數(shù)字化業(yè)務場景需求。這些業(yè)務場景往往具備較強的地域性、行業(yè)性甚至季節(jié)性，在業(yè)務運營模式上也具備較大的靈活自主性。在這種格局之下，全局性的橫向平臺如何去適應活躍、豐富的垂直創(chuàng)新，應該說是一個關鍵問題。近年來，包括銀行在內(nèi)的眾多企業(yè)科技部門紛紛熱衷于PaaS或者原生云應用平臺的建設。在銀監(jiān)會關于“十三五”規(guī)劃的相關指導意見中，也特別強調(diào)要加大互聯(lián)網(wǎng)類應用云化的力度。這些橫向的平臺構建如果僅僅是關起門來自己玩架構和技術，或者為云而云的搞應用移植、平臺替換，可能很難找到業(yè)務和技術良性互動的關鍵點。

解決數(shù)字化業(yè)務的場景性訴求，可能恰恰是這類新平臺的適用領域。在近幾年的實踐中，隨著開源以及所謂分布式架構理念的普及，一個新的數(shù)字化技術堆棧正在發(fā)展成形。而PaaS或者原生云應用平臺的興起進一步驅動了應用架構的變遷，在實踐上大大豐富了這個技術堆棧的內(nèi)涵。從應用架構的角度，基于原生云的12要素架構原則及其大量設計模式得到了更為廣泛的采納。其架構的核心訴求是速度（唯快不破）、安全（容錯）、擴展（彈性）。在開源社區(qū)，這樣的應用設計理念得到了許多開源組件和框架的支持。而微服務架構理念的流行進一步為這些實踐推波助瀾。從技術架構的角度，容器與大規(guī)模容器集群、編排技術的廣泛采納與原生云應用架構可以說是天作之合。此外，隨著容器作為應用和服務的標準分發(fā)/交付單元，Dev和Ops終于可以被無縫的貫穿。由此，從開發(fā)交付的角度，DevOps的采納在技術上消除了壁壘。并進一步在文化和組織上提出了新的要求和挑戰(zhàn)，如何在傳統(tǒng)橫向的組織邊界中（如傳統(tǒng)企業(yè)一部三中心的科技格局）去實現(xiàn)垂直業(yè)務場景的自治式演進。而這也正是微服務理念的核心精髓。此外，在這個新的技術堆棧中，大規(guī)?；诜治龅倪\維與基于開源的支持生態(tài)也都提出了新的挑戰(zhàn)和要求。

在這個新興的技術堆棧中，各種不同的實踐并沒有嚴格的時序先后依賴，而是保持著一種內(nèi)在的邏輯關聯(lián)各自展開，就像一幅拼圖從碎片中逐漸呈現(xiàn)出全景一樣。還記得兩三年前跟一些大型客戶交流時，說微服務和容器就是天作之合。當時大家的反應還是持保守和觀望態(tài)度。而到了今天，我們是不是可以更加清晰的表述一個更大的圖景：數(shù)字化業(yè)務豐富的場景訴求正在驅動一個新的企業(yè)數(shù)字化技術堆棧不斷成熟。數(shù)字化場景、微服務、容器、devOps，這些元素都是天作之合。都是同一個進化過程在不同面向上的表達，其內(nèi)在是彼此暗合、高度一致的。從企業(yè)實踐的角度，不管用什么名稱，從哪個角度去定義，最關鍵的就是找到適合自己的抓手，并且始終在發(fā)展過程中保持全局觀，以堆?；恼w視圖來設計路線圖，并根據(jù)實踐不斷持續(xù)更新。畢竟，這個領域的實踐，以及這個堆棧的發(fā)展，并不是以一種自上而下的方式鋪陳，而是基于社區(qū)、基于實踐的進化?；氐饺昵暗哪潜久度嗽律裨挕返暮诵挠^點，仍然沒有銀彈（No Silver Bullet）！沒有一招鮮,沒有萬能藥！有的就是腳踏實地參與進化的歷程。這個歷程就是企業(yè)在傳統(tǒng)經(jīng)典技術堆棧的基礎之上繼續(xù)演進，生長出新的“數(shù)字化雙翼”。

數(shù)字化堆棧中的對立統(tǒng)一

然而，在新的數(shù)字化堆棧的發(fā)展過程中，我們也特別注意到了一些流行的二元對峙的偏狹觀念，其流弊之廣、危害之深值得實踐者們高度關注。

1.集中式與分布式的對立

集中或者分布本身是兩種處理問題的方式或風格，就像是同步與異步一樣。但是市場上的一些流行理念卻活生生將集中與分布劃分成了兩個彼此對峙的陣營。在所謂的集中式陣營中，如果一定要找一個靶子，那么基于IBM Z（俗稱主機）的技術堆?？梢运愕蒙稀氨娛钢摹钡募惺皆搭^。

圖1 經(jīng)典的基于主機的技術堆棧示意

主機的技術堆棧在半個世紀前開啟了以服務器為核心的計算時代，發(fā)展和成熟于業(yè)務、數(shù)據(jù)大集中處理時代。其一直立足于關鍵事務處理的企業(yè)級計算。作為一個發(fā)展最為成熟的通用商業(yè)計算體系，不難發(fā)現(xiàn)其技術堆棧秉持的一些關鍵性假設和原則：以成熟、領先的貫穿全堆棧的系統(tǒng)優(yōu)勢，來為用戶換取在開發(fā)交付和運行維護上更大的專注性。這其實是多年來流行在企業(yè)級計算領域的一個重要原則-Separation of Concerns（關注分離、專于其事）。經(jīng)典的企業(yè)IT組織格局以及技術支持生態(tài)也都是基于這樣的基本原型逐漸演化形成的。在成熟的主機用戶身上，我們能夠看到一些典型的特征。比如，從系統(tǒng)角度：精簡的系統(tǒng)部署、充裕的擴展能力、連續(xù)的業(yè)務可用、集約的運維規(guī)模。從開發(fā)角度：專注于業(yè)務的開發(fā)模式，更好的架構包容性（有容乃大）。

不難發(fā)現(xiàn)，這個經(jīng)典的技術堆棧要達到的首要目標并不是所謂集中，而是打造一個最高品質(zhì)的通用商業(yè)計算體系。換言之，就是通過系統(tǒng)化的技術手段保障其核心價值的可復制性和普遍性，而不依賴于對運維或應用等外部因素提出過多特質(zhì)化的要求。當然，在多年的實踐中，運維和應用也一定會根據(jù)系統(tǒng)的特點（優(yōu)勢以及短板）而發(fā)展出具有獨特性的資產(chǎn)。可以說這幾年主機用戶一系列以減少消耗為導向的優(yōu)化舉措也是非常有益的探索。但是我們應該認識到，一個成熟的商業(yè)技術堆棧與興起于互聯(lián)網(wǎng)超級玩家的技術堆棧在發(fā)展模式上的確存在差異。超級互聯(lián)網(wǎng)玩家追求對于技術全棧盡可能的自主掌控是基于其超級龐大的業(yè)務和科技體量、爆發(fā)式的發(fā)展增速，以及業(yè)務和科技融為一體的企業(yè)基因。商業(yè)系統(tǒng)的運作則是基于契約式。說白了就是，用經(jīng)濟手段交換能力，用合約手段保障承諾。

其次，就算回到集中與分布的技術紛爭。我認為也很難完全把一個技術體系簡單歸為集中或者分布。很多人可能沒有認識到，基于主機的傳統(tǒng)交易中間件CICS本身就是為分布式服務而構建。作為分布式服務所需要的容器化運行環(huán)境、遠程調(diào)用框架、服務的注冊、發(fā)現(xiàn)、路由、負載均衡等等能力在這個技術體系內(nèi)都有對應的經(jīng)典實現(xiàn)方式。至于在物理部署模式上是采用水平擴展、垂直擴展或者混合模式，更多的是從性能的優(yōu)化、運維的效率、擴展的空間等多種角度來綜合考慮。反觀近年來市場上流行的分布式架構實踐，其實質(zhì)往往無外乎是開源技術的采納，應用的服務化（甚至微服務化）、以及去狀態(tài)或者無狀態(tài)化，嚴格一致性的妥協(xié)，廣泛的異步式處理，再加上數(shù)據(jù)的業(yè)務性或者技術性分散。在過往全球互聯(lián)網(wǎng)巨頭的實踐中，這些手段的運用都是有其上下文和條件的。但是如果將之作為一個教條的概念，也會帶來負面而深遠的影響。

“不把所有雞蛋放到一個籃子里”成為了所謂分布式陣營的一個貌似絕對正確的理念和旗號。在實踐中，可以看到不少過于僵化和教條的做法，比如在沒有擴展性瓶頸的前提下單純用技術性手段強行分拆數(shù)據(jù)。我認為一些問題已經(jīng)超越了雞蛋和籃子的關系。而是要不要把蛋黃和蛋清放到一個蛋殼里！未來運維和業(yè)務將不得不為這些麻煩而買單。

2.微服務與巨石的對立

隨著微服務架構的迅速躥紅，這顆新的“銀彈”又給市場注入了巨大的想象力。人們在傳統(tǒng)的交付和運維苦海中掙扎著，怎么加班交付都不夠敏捷，怎么解耦應用都還是一團亂麻，怎么監(jiān)控生產(chǎn)都還是如履薄冰。與微服務相對的巨石架構隨即躺槍成為了萬惡之源，如過街老鼠人人喊打。

然而如果我們稍微研究一下微服務架構的歷史沿革和實質(zhì)，會發(fā)現(xiàn)其關鍵強調(diào)的是一種架構和交付的文化，“微”的目的是為了服務能夠獨立、自治的垂直演進。記得曾經(jīng)有一種非常有趣的說法，單個微服務的設計、開發(fā)、測試和運維的所有人加在一起吃飯，只需要兩張批薩就夠了，這是就是著名的“Two pizza team”原則。在這種模式之下，devOps幾乎毫無例外的是剛需。然而如果僅僅是教條地將微服務作為一種普遍性準則，不分場合，生搬硬套，同樣會遭遇尷尬。在實踐中，人們往往最多的問題就是，找不到傳統(tǒng)應用重構為微服務的合適場景。而且這種架構和交付方式對于經(jīng)典的組織結構和文化也造成了極大的沖擊。如何跳出傳統(tǒng)的紅海（苦海）的束縛，找到一片業(yè)務和架構的藍海，成為了很多實踐者關心的話題。

圖2 以主機用戶為例的架構融合、雙技術堆棧示意

回到“骨感”的現(xiàn)實中，對于傳統(tǒng)企業(yè)而言，微服務的采納有可能并不是一個最急迫的核心問題。而且我們相信經(jīng)過這么多年應用的治理，在一個有一定水準的企業(yè)內(nèi)，巨石架構的弊端也沒有外界想象那么嚴重。但是在實踐中，必須承認服務化治理本身的確是一個既急迫又長期的過程，自SOA時代以來落下的功課早晚是要交上的?！案邇?nèi)聚、低耦合”在什么時代都是服務的黃金法則。

我們在前面曾經(jīng)提到過，主機架構對于應用有著更大的包容性。這一點在服務治理的歷程中是可以得到印證的。記得十幾年前，IBM就建議主機CICS的用戶在部署應用時，盡量將長交易、短交易，不同業(yè)務目標的應用分配部署到不同群組的CICS容器（region）中去。這樣可以利用系統(tǒng)對于混雜工作負載的調(diào)度管理能力，充分地利用系統(tǒng)資源。然而這么多年過去了，大多數(shù)國內(nèi)銀行的主機用戶仍然利用著系統(tǒng)尚充裕的垂直擴展性，保持著近乎極簡的部署模式。不少用戶不分或者極少劃分業(yè)務群組，在每個CICS容器中都部署近乎全量的應用，并通過外圍路由來區(qū)分不同類型的訪問請求。這樣的做法從積極的意義上，可以認為充分利用了系統(tǒng)架構的優(yōu)勢，簡化了開發(fā)、部署和運維，并通過架構的包容性為服務治理爭取了時間。然而，人們也應該意識到，這樣的架構如果平移到另外一個所謂的分布式應用平臺，其結果將是災難的。

毋庸置疑，服務的治理是一項長治久安的百年大計。從這個意義上，微服務本身并不是解決這個問題的“一招鮮”。微服務或者巨石作為兩種不同風格的架構，從長遠來講是可以共生共存的，更何況在二者之間還有廣闊的地帶。關鍵是找到彼此最合適的領域。我認為在垂直的數(shù)字化場景這個領域中，可以嘗試在新的數(shù)字化堆棧中開展微服務的嘗試。當然這種嘗試也需要找到合適的抓手，不可僵化套用。比如，在一些大型企業(yè)的實踐中，先通過無狀態(tài)的彈性應用去推動新技術堆棧的發(fā)展，有可能是更加符合現(xiàn)實訴求的。

最后，通過以上的探討，讓我們嘗試拋出一些架構融合的觀察和建議。在傳統(tǒng)經(jīng)典的技術堆棧（如基于IBM Z）之外，新的技術堆棧（所謂數(shù)字化雙翼）正在成型，并迅速演變。這些技術堆棧之間并不能簡單用商業(yè)/開源，集中/分布，傳統(tǒng)/顛覆來進行概念化二元對峙的區(qū)分。在各自的發(fā)展路徑上，甚至是可以彼此參照，互相包容，共同進化的。

實現(xiàn)架構融合

以采納了經(jīng)典主機作為核心的企業(yè)為例，在實踐架構融合的進程中，我們建議：

·以Restful API的方式，將主機堆棧的應用和數(shù)據(jù)資產(chǎn)融入到一個原生的API環(huán)境中，提供最大的靈活性。

·開辟全新的純API的主機高速接入/調(diào)出通道，實現(xiàn)兩個技術堆棧的高架合龍。

·繼續(xù)推進服務化改造和優(yōu)化工作。

·推動新的企業(yè)數(shù)字化堆棧建設，找到業(yè)務和應用訴求的突破口。

·頂層布局，總體部署。避免架構和技術堆棧的孤島。共同推動商務與技術的協(xié)同進化。

在本文開篇時，我們曾經(jīng)簡單談到了在數(shù)字化轉型的浪潮中，傳統(tǒng)企業(yè)的復蘇甚至逆襲。隨著數(shù)字化服務生態(tài)的飛速演進，大家也必須看清一些事實。作為數(shù)字化生態(tài)和流量經(jīng)濟事實上的主導者，互聯(lián)網(wǎng)超級巨頭們已經(jīng)實現(xiàn)了入口壟斷。今天要再構建一個上億級別的超級平臺可能性是非常微小的。隨著超級平臺的入口固化，營銷服務場景的不斷前置，巨頭們宣稱的“連接一切內(nèi)容和服務”的策略正在不斷推進。今天，經(jīng)濟生活中各種數(shù)字化的高、低頻場景正在加速演變，愈加依附于超級平臺的入口存在。導流的時代正在結束，巨頭們正無孔不入地參與運營，并試圖主導分潤。那么行業(yè)細分領域的傳統(tǒng)企業(yè)必須同心戮力繼續(xù)開拓、深耕垂直細分領域。殺手級的場景可能比殺手級的平臺更加有現(xiàn)實意義。今天，傳統(tǒng)企業(yè)的不少數(shù)字化業(yè)務創(chuàng)新場景還帶有很大的試探性，或者說是為了刷存在感。而從“存在感”進化到“獲得感”，我們認為只有通過打怪升級、與狼共舞才能實現(xiàn)。

在這樣的格局下，混合、雙速或者融合的技術堆棧格局，恰恰是在快速演進的業(yè)務格局中一種“中道”式的自然過程。企業(yè)必須找到實踐之路，為傳統(tǒng)的業(yè)務資產(chǎn)提供最穩(wěn)健的保障，同時為快速的業(yè)務演進提供騰飛的雙翼。在真實的戰(zhàn)場中參加真實的戰(zhàn)斗，參與進化才有可能順應歷史的潮流找到出路。而歷史的演進，往往是從二元對峙的謬誤中，開啟融合之路。