數字化浪潮下的架構融合

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

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

數字化轉型究竟要實現什么

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

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

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

在這個新興的技術堆棧中，各種不同的實踐并沒有嚴格的時序先后依賴，而是保持著一種內在的邏輯關聯各自展開，就像一幅拼圖從碎片中逐漸呈現出全景一樣。還記得兩三年前跟一些大型客戶交流時，說微服務和容器就是天作之合。當時大家的反應還是持保守和觀望態度。而到了今天，我們是不是可以更加清晰的表述一個更大的圖景：數字化業務豐富的場景訴求正在驅動一個新的企業數字化技術堆棧不斷成熟。數字化場景、微服務、容器、devOps，這些元素都是天作之合。都是同一個進化過程在不同面向上的表達，其內在是彼此暗合、高度一致的。從企業實踐的角度，不管用什么名稱，從哪個角度去定義，最關鍵的就是找到適合自己的抓手，并且始終在發展過程中保持全局觀，以堆棧化的整體視圖來設計路線圖，并根據實踐不斷持續更新。畢竟，這個領域的實踐，以及這個堆棧的發展，并不是以一種自上而下的方式鋪陳，而是基于社區、基于實踐的進化。回到三十年前的那本名著《人月神話》的核心觀點，仍然沒有銀彈（No Silver Bullet）！沒有一招鮮,沒有萬能藥！有的就是腳踏實地參與進化的歷程。這個歷程就是企業在傳統經典技術堆棧的基礎之上繼續演進，生長出新的“數字化雙翼”。

數字化堆棧中的對立統一

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

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

集中或者分布本身是兩種處理問題的方式或風格，就像是同步與異步一樣。但是市場上的一些流行理念卻活生生將集中與分布劃分成了兩個彼此對峙的陣營。在所謂的集中式陣營中，如果一定要找一個靶子，那么基于IBM Z（俗稱主機）的技術堆棧可以算得上“眾矢之的”的集中式源頭。

圖1 經典的基于主機的技術堆棧示意

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

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

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

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

2.微服務與巨石的對立

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

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

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

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

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

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

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

實現架構融合

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

·以Restful API的方式，將主機堆棧的應用和數據資產融入到一個原生的API環境中，提供最大的靈活性。

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

·繼續推進服務化改造和優化工作。

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

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

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

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