IBM技術專家:數字化浪潮下的架構融合淺談

　　原文標題：《數字化浪潮下的架構融合淺談- 中道為正、無問西東》

　　本文作者：老鷹 (應宏敬)， 現供職於國際商業機器(中國)有限公司。擁有17年服務於大型企業的IT架構設計與技術支援經驗，是IBM認證的首席技術專家以及全球資深雲端計算顧問。

　　曾作為核心的IBM客戶架構師全程參與了工商銀行兩地三中心同城雙活工程的規劃、設計、研究、實施工作;併為眾多金融行業的客戶提供了基於IBM主機的軟體技術支援和架構設計服務。

　　此外，作為全球雲端計算顧問，深度參與了IBM的雲端計算業務轉型，為眾多行業客戶提供了雲端計算諮詢、規劃和落地服務。曾作為技術負責人，帶領IBM研究院、實驗室和雲端計算服務團隊全程參與了工商銀行PaaS雲平臺建設專案。對於企業IT架構和業務生態的演進發展有著深刻的理解和洞察。

　　正文：

　　經常在機場穿行的人們，很難注意不到鋪天蓋地的雲端計算廣告牌。尤其是近幾年阿里雲的一系列廣告創意相當霸氣，大肆宣稱“超過第二名至第十名規模總和”。我素來對於各種大詞不感冒，反倒是廣告裡一行小字引發了關注：“數字化轉型專家”。過去數年間，在“網際網路+”的本土語系中，數字化轉型其實是一個比較夾生的表達方式。雖然“數字化”對這一程式本質的揭示更為深刻和普適，但不可否認的是，以“網際網路”為字首的表達方式在逆襲正勁的風口，具有更高的市場辨識度。

　　在一個領域中，話語構建的水平往往也表徵了其本身的成熟與進化程度。更多從業者們對於“數字化轉型”語系的普遍採納，除了表明近幾年網際網路與傳統IT企業基因混雜、彼此融合的特徵，也表明了企業市場在歷經顛覆、迷茫、跟風、實踐之後，愈加清朗地辨明瞭自己的主要矛盾與核心訴求。IBM商業價值研究院近來發表了一系列關於“數字化重塑”(數字化轉型的進階)和“傳統企業逆襲”的研究報告。雖然我們並不敢說這預示著傳統企業數字化復甦的春天就要到來了，但是經過了這些年商業與技術的“顛覆”亂局後，人們至少都學會了“以彼之道還施彼身”，在捱打和混戰中學會了打架。以金融科技(FINTECH)為例，今天在這個領域裡的玩家，既有過去的所謂顛覆者紛紛從2C走向2B，也有傳統銀行突破體制格局，主動向市場輸出科技能力。近來坊間還多有FINTECH和TECHFIN的概念紛爭，其本質無非是攜帶著不同基因的參與者，共同匯入了一場金融數字化的進化之旅。強調TECH或者FIN也許並不重要，有資格活著參與進化的意義要遠遠大於技術性的炮製概念化差異。

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

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

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

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

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

　　1) 集中式與分散式的對立

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

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

(圖示：經典的基於主機的技術堆疊示意)

　　不難發現，這個經典的技術堆疊要達到的首要目標並不是所謂集中，而是打造一個最高品質的通用商業計算體系。換言之，就是透過系統化的技術手段保障其核心價值的可複製性和普遍性，而不依賴於對運維或應用等外部因素提出過多特質化的要求。當然，在多年的實踐中，運維和應用也一定會根據系統的特點(優勢以及短板)而發展出具有獨特性的資產。可以說這幾年主機使用者一系列以減少消耗為導向的最佳化舉措也是非常有益的探索。但是我們應該認識到，一個成熟的商業技術堆疊與興起於網際網路超級玩家的技術堆疊在發展模式上的確存在差異。超級網際網路玩家追求對於技術全棧儘可能的自主掌控是基於其超級龐大的業務和科技體量、爆發式的發展增速，以及業務和科技融為一體的企業基因。商業系統的運作則是基於契約式。說白了就是，用經濟手段交換能力，用合約手段保障承諾。當然，今天國內網際網路巨頭紛紛開始以科技輸出進入這個領域，都面臨著從“自食狗糧”向商業契約化的過渡和轉化。這一點遲早會把不同基因的參與者拉回到同一個角鬥場。

　　其次，就算回到集中與分佈的技術紛爭。我認為也很難完全把一個技術體系簡單歸為集中或者分佈。很多人可能沒有認識到，基於主機的傳統交易中介軟體CICS本身就是為分散式服務而構建。CICS的縮寫據說可以解釋為CICS IS CONTAINER SERVICE，這並非笑談!作為分散式服務所需要的容器化執行環境、遠端呼叫框架、服務的註冊、發現、路由、負載均衡等等能力在這個技術體系內都有對應的經典實現方式。至於在物理部署模式上是採用水平擴充套件、垂直擴充套件或者混合模式，更多的是從效能的最佳化、運維的效率、擴充套件的空間等多種角度來綜合考慮。反觀近年來市場上流行的分散式架構實踐，其實質往往無外乎是開源技術的採納，應用的服務化(甚至微服務化)、以及去狀態或者無狀態化，嚴格一致性的妥協，廣泛的非同步式處理，再加上資料的業務性或者技術性分散。在過往全球網際網路巨頭的實踐中，這些手段的運用都是有其上下文和條件的。但是如果將之作為一個教條的概念，甚至賦予新一代“銀彈”的期望，不求甚解甚至囫圇吞棗，也會帶來負面而深遠的影響。

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

　　套用流行的佛系用語，“是諸法空相，不生不滅，不垢不淨，不增不減，不集中不分佈，不同步不非同步。”實踐者需要睜開智慧的架構之眼，以己之眼明辨是非，而不人云亦云。

　　2) 微服務與巨石的對立

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

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

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

(圖示：服務治理的急迫性，圖片摘自《斷舍離》)

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

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

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

(圖示：以主機使用者為例的架構融合、雙技術堆疊示意)

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

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

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

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

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

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

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

　　在這樣的格局下，混合、雙速或者融合的技術堆疊格局，恰恰是在快速演進的業務格局中一種“中道”式的自然過程。企業必須找到實踐之路，為傳統的業務資產提供最穩健的保障，同時為快速的業務演進提供騰飛的雙翼。在真實的戰場中參加真實的戰鬥，參與進化才有可能順應歷史的潮流找到出路。而歷史的演進，往往是從二元對峙的謬誤中，開啟融合之路。記得《舊約》中巴別塔的故事，人們雄心勃勃地構建通往天堂的高塔，最終卻受阻於不同語言以及種族所導致的分裂。這似乎是一個難以逃脫的詛咒，註定人類所有整合性的偉大舉措都必須經受聚沙成塔的考驗。從爭執、割裂到邁向溝通、整合的道路上，人們沒有單純的規則或經驗可以遵循，只能經歷艱難、曲折的迂迴與試探，努力跨越諸多二元的對峙與矛盾，擺脫自我中心與偏見，在對話和融合中逐漸夯實更廣泛的團結與共識，並最終在整合中找回真正的自我，實現更高的發展與超越。

　　如此往復，生生不息。

　　如此混雜鉅變的時代，IT人亟待更新自己的哲學觀。

　　老鷹於北京