行業信息化應用架構演進與發展解析

鄭金輝

（中國電信系統集成公司，北京 100035）

0 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 研發管理的數字化推動應用架構持續優化

3.1 從信息化走向數字化

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

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

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

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

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

3.3 低代碼研發的嘗試和探索

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

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

4 結束語

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