行業(yè)信息化應用架構演進與發(fā)展解析

鄭金輝

（中國電信系統(tǒng)集成公司，北京 100035）

0 引言

應用架構描述了設計和構建應用的模式與技術，也是業(yè)務需求與具體技術之間的連接橋梁。應用架構有兩層含義：一是企業(yè)級應用架構，也就是EA的概念。企業(yè)層面的應用架構起到了承上啟下的作用，向上承接了企業(yè)戰(zhàn)略發(fā)展方向和業(yè)務模式，向下規(guī)劃和指導企業(yè)各個IT系統(tǒng)的定位和功能，更關注企業(yè)的應用架構藍圖、架構標準/原則、系統(tǒng)的邊界和定義、系統(tǒng)間的關聯(lián)關系等方面的內容。二是單系統(tǒng)的實現(xiàn)邏輯和組成架構，從前端展示到業(yè)務處理邏輯，再到后臺數(shù)據(jù)，整體設計需要遵循企業(yè)總體應用架構原則。

1 從單體應用到微服務，應用架構逐漸走向成熟

應該明確，應用架構一定是為業(yè)務服務的，是圍繞業(yè)務需求展開的。應用架構應從業(yè)務需求出發(fā)，是一個不斷演進和完善的過程，是需求在推動技術落地，而不是為了技術而改變架構。先進的技術必然會引起架構復雜度的上升，而這種成本和代價不是誰都能承受得起的。應用架構演進，是一個從小到大的漸進明細的過程，也是一個從孤立走向集中，又從集中重新到分散的過程。

（1）垂直應用架構。其實可以簡單理解成單體應用架構，最初業(yè)務流量小，對資源的需求也小，所有的應用打包在一起部署在一臺物理機上，可以運行得很流暢。后來考慮到系統(tǒng)安全，做了主備配置，實現(xiàn)了部分高可用。再后來流量上來了，先考慮把數(shù)據(jù)部分拆走，有了App和DB分開部署的模式。再后來人們用負載均衡設備或者Nginx等組件實現(xiàn)應用服務的負載均衡。這樣的架構陪我們走過了很多年，直到現(xiàn)在還能在很多客戶那里見到。不是說單體應用架構一定不好，只要能滿足業(yè)務的需求，越簡單的東西越有實際價值。

（2）分布式架構。隨著業(yè)務的發(fā)展和組織的壯大，在康威定律的加持下，組織的復雜性開始影響系統(tǒng)的復雜性，單體應用已經(jīng)不能滿足生產(chǎn)的需要，不得不考慮把一部分應用功能分開部署。系統(tǒng)各模塊分開部署以后必然帶來協(xié)同工作的問題，于是有了RPC和消息中間件等技術手段來解決這個問題。其實簡單說，RPC側重于功能調用，多為同步方式，MQ主要是面向性能的，多為異步。RPC和MQ看似不是一個層面的東西，但是卻能解決很多共性的問題，比如分布式、解耦等，區(qū)別只是實現(xiàn)方式和效果的不同。

（3）SOA（面向服務架構）。SOA跟分布式緊密相關，SOA是一種直到現(xiàn)在依然適用的架構理念，SOA不是技術，卻在指導技術如何落地。SOA的特點就是服務中心理念，隨著業(yè)務發(fā)展，服務數(shù)量越來越多，服務生命周期管控和運行態(tài)的治理成為瓶頸，此時用于提升服務質量的SOA成為架構治理的關鍵。

（4）微服務架構。系統(tǒng)的復雜度發(fā)展到了一定程度，就必然會做進一步拆分。微服務的目的就是進行有效應用拆分，實現(xiàn)敏捷開發(fā)和部署。拆分以后的服務可以獨立部署、運行、升級。不僅如此，不同微服務之間在結構上也實現(xiàn)了松耦合，但在功能上則表現(xiàn)為一個統(tǒng)一的整體[1]。統(tǒng)一的整體表現(xiàn)出來就是統(tǒng)一的風格界面、統(tǒng)一的權限管理、統(tǒng)一的安全策略、統(tǒng)一的上線過程、統(tǒng)一的日志和審計方法、統(tǒng)一的調度方式以及統(tǒng)一的訪問入口等。

以上應用架構的演進過程，不是新老交替的過程，而是不同架構模式逐漸適配各自場景的過程。適合自己的才是最好的，假如業(yè)務負載始終比較穩(wěn)定，業(yè)務邏輯也比較清晰，那保持單體應用的架構也不是不可以。業(yè)務壓力如果變化劇烈，新需求層出不窮，恐怕不想改應用架構都不行，盲目追新和故步自封都不可取。

2 應用架構演進的問題與困境

在傳統(tǒng)模式下，業(yè)務側的需求管理是是粗放的。業(yè)務團隊單獨考慮自身的業(yè)務邏輯，不可避免地進行了大量重復建設，而且這種重復建設往往是基于單體架構的。在這種情況下，重復建設所導致的成本、效率和數(shù)據(jù)不一致問題一直困擾著行業(yè)信息化建設[2]。于是我們開始接受服務化和中臺化的理念，試圖尋找突破口。

我們嘗試用中臺理念對業(yè)務側做調整，形成了以中臺為核心的業(yè)務架構，中臺的核心是“重用”，重用是一種通用邏輯，但是只有通用邏輯是解決不了問題的，還需要業(yè)務流程的定制，也就是個性化邏輯。這就會出現(xiàn)一個新問題，中臺所代表的通用邏輯與前臺所代表的個性化邏輯會出現(xiàn)節(jié)奏不一致的情況，需要在協(xié)同、排期、優(yōu)先級等問題上做出協(xié)調和平衡，存在巨大的溝通成本。

伴隨著應用架構的演進和中臺的發(fā)展，我們做了大量服務化改造，形成了很多新的服務。這在技術上也帶來了很多新問題和新風險，比如，調用鏈開始變長，運維難度變大，排障變得困難，組件使用成本開始上升。尤其是到了PaaS層面，如何管控眾多服務，是一個必須面對和考慮的問題。

在業(yè)務、應用、數(shù)據(jù)的數(shù)量和復雜度都快速增長的大背景下，解耦是始終需要考慮的根本原則[3]。

業(yè)務和應用的架構變革，如果只從架構升級改造本身出發(fā)，就會出現(xiàn)“頭疼醫(yī)頭腳疼醫(yī)腳”的情況。從上分析可以看出，癥結都指向了一個問題，那就是研發(fā)管理。

3 研發(fā)管理的數(shù)字化推動應用架構持續(xù)優(yōu)化

3.1 從信息化走向數(shù)字化

當前階段，研發(fā)管理的主流模式已經(jīng)實現(xiàn)了信息化，基本告別了小作坊時代，實現(xiàn)了項目協(xié)作、應用開發(fā)、交付部署等環(huán)節(jié)的工具化和平臺化。項目協(xié)作主要解決工單管理和工單流轉以及知識沉淀等問題，應用開發(fā)主要是通過工具完成各工序工作，交付部署主要是實現(xiàn)成果發(fā)布上線和交付運維。

研發(fā)信息化基于工具和流程管控的模式，是用工具代替了人工，從本質上說還是以人為核心的。研發(fā)信息化向研發(fā)數(shù)字化轉型，自動化工具和平臺的使用仍然是基礎工作，在此基礎上，研發(fā)數(shù)字化還需要關注全局透明化、協(xié)同效率提升和效率可度量，這就需要將工具和平臺產(chǎn)出的過程數(shù)據(jù)盡量沉淀到數(shù)據(jù)平臺，并結合業(yè)務場景逐步形成統(tǒng)一的研發(fā)數(shù)據(jù)模型，打造以業(yè)務價值為核心的研發(fā)體系。

工具和平臺的使用實現(xiàn)的是流程管控，解決的是局部效能的問題，尤其是資源調度的效能，但這并不代表交付效能的整體提升，我們要做的是從以工具流程為核心向以業(yè)務價值為核心轉型，實現(xiàn)從局部效能向全局效能的轉型。簡單說，應該分成三步走，第一步是局部效能的提升，重點還是大量自動化工具的使用以及過程數(shù)據(jù)的積累和沉淀；第二步是實現(xiàn)整體高效交付，核心思想是實現(xiàn)業(yè)務、產(chǎn)品和研發(fā)的目標一致化，通過對研發(fā)過程數(shù)據(jù)管理實現(xiàn)研發(fā)過程的整體可控；第三步是實現(xiàn)持續(xù)改進，主要是根據(jù)可視化的結果，進行可量化的持續(xù)改進。這里面關鍵就是需要將研發(fā)過程數(shù)據(jù)鏈接到研發(fā)的價值鏈管理上去。

3.2 以技術標準化屏蔽復雜性

傳統(tǒng)應用的研發(fā)過程需要從物理基礎設施開始關注，從設備類型、資源提供方式、中間件選型到技術路線和架構方式都需要逐一落實。隨著新技術的使用，通過將技術標準化實現(xiàn)了從資源到服務的轉換。虛擬化和云平臺屏蔽了資源類型的差異，將差異化的物理資源統(tǒng)一成了標準化的云資源，PaaS和分布式基礎環(huán)境實現(xiàn)了中間件層的標準化，DevOps實現(xiàn)了開發(fā)環(huán)境的統(tǒng)一和標準化，智能運維實現(xiàn)了運維監(jiān)控的整合和標準化，也就是說云原生應用構建了一個新的技術關注平面，我們不用再去關心各種資源的細節(jié)和差異性。不斷推進技術的標準化建設，推動IT從資源建設向服務提供轉型，這也是持續(xù)提升研發(fā)整體效能的關鍵手段。

3.3 低代碼研發(fā)的嘗試和探索

有觀點說低代碼研發(fā)是潮流，很多客戶也在開始關注，希望通過研發(fā)工具和平臺已經(jīng)抽象出來的一些通用代碼，以及可視化的操作快速創(chuàng)建所需的功能組件，加快軟件研發(fā)的進度。這無論對客戶還是軟件開發(fā)商來說都是好事，也是提升效率和效能的重要手段[4]。其實無論低代碼還是0代碼，都是APaaS的范疇，是應用全生命周期的一個環(huán)節(jié)，但是代碼量的降低，并不意味著工作量的降低，這對業(yè)務架構和應用架構的靈活性和敏捷程度提出了更高的要求，所以說架構永遠都是第一位的。

從這個角度來說，低代碼開發(fā)平臺應該為開發(fā)者盡可能屏蔽底層技術細節(jié)、減少不必要的技術復雜度，并支撐其更好地應對業(yè)務復雜度，滿足靈活通用的業(yè)務場景需求，這是一個低代碼開發(fā)平臺者所應該盡到的核心職責。

4 結束語

應用架構隨著技術發(fā)展和業(yè)務復雜度的提升而不斷演進，它不一定是新人替舊人，而是需要根據(jù)具體的業(yè)務場景靈活選擇。新架構必然有新的風險和成本，不一定適合；傳統(tǒng)架構成熟穩(wěn)定，不一定不適合。上層應用的核心關注點是敏捷，遵循短周期功能迭代原則；中間平臺層的核心關注點是復用，遵循中周期能力迭代原則；底層技術底座的核心關注點是可持續(xù)，遵循長周期技術迭代原則。