相對於系統軟件而言，企業軟件往往是面向應用場景、業務邏輯。雖然很多工程師、架構師會面帶嚴峻表情的告訴你，軟件項目所要保障的高可用性、魯棒性、可擴展性、高併發性、低延遲性、安全性、可測試性、靈活性，是如何如何的重要，彷彿一套只有幾個部門三五十人用的軟件系統，其架構也得是多麼科學、嚴謹、隆重的經歷一系列的設計、論證、測試，姿勢拉好、儀式感滿滿。

但現實中，多少企業的軟件系統是由代碼屎山堆成，多少IT運維人員是每天沉浸在救火中，多少開發工程師被業務部門的需求逼迫的996也依然人仰馬翻，多少業務人員則是被“提新需求如油鹽不進、討舊債務似老鼠拉龜”不見效果的系統折磨出焦慮症。

今天面向業務邏輯、應用場景的軟件系統，其底層或者説基礎技術層（例如網絡連接、多線程、內存管理等等）早就被封裝成成熟的組件了，最難、最硬核部分的技術工作，可能九成以上被某些開源項目或者商業組件解決了，企業軟件系統的開發工程師，需要編寫代碼解決的主要問題，都是業務應用問題 - UI編程、表單處理、數據存取、增刪改查、消息隊列、任務調度、領域建模、接口集成、服務封裝、信息同步、批處理... 有多少技術含量？如果你問一個三十年前的C++程序員，手工搓網絡代碼、手工寫線程管理、手工打造應用框架、然後手工建對象模型開發應用邏輯... 今天的這種企業應用開發，對他而言可能就是裱糊匠的工作...

那麼為什麼這些系統的開發、擴展、維護還是這麼痛苦？其最根本原因，如果只選一個的話，那就是：緊耦合。代碼屎山就是因為代碼寫成一坨，環環相扣，牽一髮動全身，歷史代碼誰都不敢亂改亂動，在“意大利麪條”般的條件判斷語句和無窮無盡的打補丁中堆成。“敏捷”大部分情況下是一種口號或者自嗨，從來沒有讓業務部門承認過信服過...

企業應用軟件架構，扯更多的“性”沒用。極端一點的説，如果只選擇一個企業軟件架構設計原則徹底奉行，那只有是：堅持“分而治之”的原則，建立高內聚、低耦合的技術架構。

甚至可以説，一個企業軟件系統的架構師，其終生職業所做的事情，不過是設計低耦合技術架構 - 不斷的梳理問題、解耦千絲萬縷的關係，對問題分而治之，各個擊破，必要時則又對集中統一與解耦分離作出一定的折衷取捨，僅此而已。

分治算法與思想（Divide-and-conquer）

分治算法，對於每一個計算機科學系畢業的學生，都是入門級的“數據結構與算法”必修課裏的基本內容。“高內聚低耦合”的技術架構，可以算是分而治之的算法精神的一個體現。事實上，在軟件世界分治算法無處不在，以下是大家熟悉的例子。

大數據領域：MapReduce與ETL

MapReduce 是一種編程模型和處理大規模數據集的計算框架。它在分佈式計算環境中實現了“分而治之”的思想，將大規模數據處理任務分解為可並行處理的小任務。

Map 階段：在 MapReduce 中，數據首先被分割成若干個小塊，然後通過一系列的 Map 函數進行處理。每個 Map 函數獨立處理一小部分數據，並生成中間鍵值對（key-value pairs）。

• Shuffle 階段：中間鍵值對被重新分配和排序，以便相同的鍵值對能夠被送往同一個 Reduce 函數。
• Reduce 階段：最後，由一系列的 Reduce 函數對相同鍵的數據進行合併和計算，生成最終的輸出結果。
• MapReduce 的優勢在於它能夠高效地處理大規模數據，並通過分階段的操作實現了任務的拆分與聚合。

ETL 是一種用於將數據從一個地方提取、進行轉換，然後加載到另一個地方的數據處理過程。ETL 過程同樣遵循“分治算法”的思想，將複雜的數據處理任務拆分成幾個獨立的步驟。

Extract 階段：數據從源系統中提取出來，可能包括關係型數據庫、日誌文件、API 等。

• Transform 階段：提取的數據進行清理、轉換、過濾等操作，以滿足目標系統的需求。這個階段可以包括數據清洗、格式轉換、計算等處理。
• Load 階段：最後，處理過的數據被加載到目標系統中，可以是數據倉庫、數據湖或其他存儲系統。
• ETL 的分而治之體現在每個階段的獨立性，每個步驟都專注於特定的任務，通過將複雜的數據處理流程拆解為簡單的步驟，提高了可維護性和擴展性。

雲計算領域：微服務、容器、容器編排

微服務（Microservices）。微服務架構是一種軟件設計方法，將一個大型應用程序拆分成一組小型、相對獨立的服務。每個服務都負責一個特定的業務功能，可以獨立開發、部署和擴展。微服務體現了“分而治之”的思想，通過將整個系統分解為小而自治的服務，降低了系統的複雜性，使得每個服務可以獨立演化和擴展：

• 分解：微服務將大型應用拆分成小的、獨立的服務單元，每個服務專注於一個特定的業務功能。
• 自治：每個微服務都是自治的，具有自己的數據存儲、開發團隊和部署流程。
• 獨立演化：微服務之間的鬆耦合使得它們可以獨立演化，而不影響整體系統的運行。

Docker 容器技術: 是一種輕量級的容器技術，通過將應用程序和其依賴項封裝到容器中，實現了跨平台、一致性和可移植性。Docker 的設計理念與“分而治之”相符，通過容器化應用，將大型系統分解為小而可管理的單元：

• 封裝：Docker 封裝了應用程序和其依賴項，形成一個獨立、可重複部署的容器。
• 隔離：每個容器是相互隔離的，一個容器的變化不會影響其他容器，實現了微服務間的高度隔離。
• 可移植性：Docker 容器可以在不同的環境中運行，實現了應用程序的可移植性和一致性。

Kubernetes 技術: 是一個開源的容器編排平台，用於自動化容器的部署、擴展和管理。它體現了“分而治之”的思想，通過將應用程序部署為多個容器，並提供自動化的管理工具，實現了系統的高效、彈性的運維：

• 部署：Kubernetes 將微服務以容器的形式部署在集羣中，每個微服務可以獨立部署。
• 擴展：通過動態調整容器數量，Kubernetes 實現了微服務的彈性擴展，可以根據負載自動調整服務的副本數。
• 自愈：Kubernetes 提供了自動修復和替代故障容器的機制，保證系統的穩定性和可用性。

通過微服務、Docker 容器技術和 Kubernetes 技術的結合使用，系統的複雜性得以降低，每個組件都可以獨立演化和部署，實現了系統的分而治之。這樣的設計思想有助於構建更靈活、可維護和可擴展的分佈式系統。

人工智能領域：神經網絡、大語言模型、多智能體

神經網絡: 神經網絡是一種由多個神經元組成的模型，它們分層組織，通過學習從輸入到輸出的映射關係來完成任務。在神經網絡中，分治算法的思想體現在網絡的分層結構和層級特徵提取上：

• 分層結構：神經網絡通過多層的結構，將複雜的問題分解為多個階段的特徵提取和抽象。每一層負責處理輸入數據的不同層次的特徵，使得神經網絡能夠逐層學習和理解數據的表示。
• 特徵提取：每一層神經元都專注於學習特定的特徵，通過逐層的處理，逐漸提取出數據的抽象表示，實現了對問題的分而治之。

Mixture of Experts 模式: Mixture of Experts 是一種神經網絡結構，其中包含多個專家（experts），每個專家負責處理特定類型的輸入或任務。這種結構體現了“分而治之”的思想，通過將整個問題拆解為多個專家負責的子問題，每個專家獨立學習和處理局部信息。傳説中OpenAI的大語言模型實質上以MOE構成，而在開源大語言模型領域表現突出的Mistral則發佈了Mixtral 8x7B，在多項指標超越GPT 3.5和Llamma2 70B

• 專家組合：在 Mixture of Experts 中，一個 gating network 負責確定每個輸入由哪個專家處理。這樣，每個專家只需關注自己負責的子問題，降低了系統的複雜性。
• 獨立學習：每個專家通過獨立學習局部的任務，而 gating network 則協調這些專家的貢獻，實現了問題的分治和整體優化。

大語言模型的 Multi-Agent 多智能體:大語言模型中的 Multi-Agent 多智能體結構是一種通過協同工作的多個智能體（agents）來解決複雜問題的方法。每個智能體負責學習和處理特定方面的知識，整體上體現了分治算法的思想。每個智能體都可以獨立地思考、決策和行動，同時與其他智能體進行交互。多智能體系統可以用於解決許多複雜的問題，例如協作、博弈、規劃、控制、優化等等：

• 任務分配：每個智能體專注於學習和處理一部分知識，通過任務分配，每個智能體負責處理特定的語境或任務。
• 協同學習：智能體之間通過協同學習，將各自的專業領域的知識整合起來，形成對問題的全局理解。

神經網絡、Mixture of Experts 模式和 Multi-Agent 多智能體都體現了分治算法的思想，通過分解問題、分層學習、任務分配和協同工作，實現了對複雜問題的高效處理。這種分而治之的設計理念使得模型更具有可擴展性、可維護性，並有助於提高系統的整體性能。

系統工程領域：插件、App商店、小程序平台

軟件的插件機制、應用商店和小程序技術在架構設計理念和運作模式上具有以下共性,都體現了“分而治之”的思想:

• 都是基於功能模塊的分解與解耦。插件將特定功能剝離為單獨模塊，小程序將應用劃分為獨立子應用，App商店將軟件產品化為一個個應用。實質上，小程序可以被視為某個“超級App”的插件，而App則可以被視為是某個手機操作系統的插件
• 都是高內聚與鬆耦合的結合。插件、小程序或App內部功能高度內聚一致;而它們之間通過簡單且穩定的接口進行數據交互或消息通信,實現鬆耦合。
• 都可通過配置或編排自由組合。用户可以靈活啓用插件，下載安裝不同App，組合使用小程序,來滿足多樣化的定製需求。
• 開發者都無需瞭解或修改“母體軟件”內部實現，只需依照規範、接口，實現自己的內容“單元”。開發者之間毫無關聯關係
• 都構成了生態系統。插件模式、應用商店和小程序生態都通過這種“分而治之”的機制形成了非常充滿活力的軟件或服務生態。系統內高水平的協作創新與共生共榮得以實現。
• 這三種技術作為典型的體現機制,都驗證了基於“分而治之”的低耦合組件化設計,是構建靈活、易擴展、協同創新的軟件系統的有效模型。這為企業軟件架構提供了可資借鑑的設計模式。

架構模式：管道-過濾器架構、SOA

管道-過濾器架構和麪向服務架構(SOA)都體現了“分而治之”的思想,主要體現在:

管道-過濾器架構將一個處理流程分解為一個一個的過濾器組件,每一個過濾器實現某一個步驟的處理功能。這些過濾器之間鬆耦合,通過管道(如流)串聯起來,實現流水線式的並行處理,大大提高了效率。過濾器和服務內部是高內聚的模塊,具有單一職責;而它們之間通過管道或標準化接口進行鬆耦合,降低了依賴,提高了靈活性。通過配置和編排框架,可以複用和靈活調度這些可組合的服務或過濾器構建流水線,以滿足不同的業務處理需求。實現了可重用性和業務流程的敏捷配置。

SOA是一種軟件架構風格，它將應用程序中的功能模塊封裝成服務，每個服務實現一組內聚統一的業務能力,服務之間通過定義良好的接口契約進行通信與交互。這種方法可以實現應用程序的快速開發和部署，同時也可以方便用户獲取應用程序。SOA體現了分治算法的精神，將一個大問題分解成若干個小問題，然後逐個解決這些小問題，最後將結果合併起來得到大問題的解。

輕應用的“商店模式”應成為下一代企業軟件基礎架構

在上述眾多體現“分治”精神的軟件架構模式下，對於企業來説，“商店模式”最為值得借鑑，這是數字化時代任何企業在數字化轉型過程中最為有用的企業技術架構。

企業IT思維從扮演“集成商”角色轉變為扮演“平台運營商”角色。過去企業IT的開發人員最主要做的事情是充當裱糊匠，調用、粘合第三方系統，沒完沒了的“集成” 。是時候提高“平台”意識，由IT基於企業訴求搭建框架、技術平台，制定標準，讓開發商、技術供應商遵循這些標準來提供“插件”、“樂高”。即使是IT自己，內部的很多開發團隊實際上也是這類“插件”的提供者。

“插件”應聚焦業務應用，而不是底層技術，業務插件實際上是一種“輕應用”。輕應用型的“插件”機制是高層技術載體，讓開發者無需瞭解插件的“母體”軟件系統或者説“宿主”，即可開發、調試業務內容。且開發者之間無關聯關係，互相不影響，可以（1）並行開發互無干擾，（2）無上限的擴展開發小組/團隊的數量。讓每個業務部門的數字化業務內容得以平行進行。

“插件”的上下架、審核、審計、搜索發現、升級更新、分發出版，均應在企業內統一管理。這個管理的技術載體，就是“應用商店” - 也可以稱之為“插件商店”、“樂高商店”。這類的“應用”，不是手機上的App，更有可能是基於HTML5或在其基礎上擴展的DSL（Domain Specific Language）開發的業務邏輯代碼模塊。

走向開放與連接。傳統企業IT思維是，強烈假設一個軟件系統的內容必然由IT開發或集成，由內而外的輸出。但在數字化時代，這個假設未必再成立，數字企業需要在安全可控的基礎上更加開放，其中包括如何允許業務部門引入第三方合作伙伴或業務內容供應商的源代碼運行在己方的系統（例如App）中，或者説，如何讓第三方而不僅是IT自己提供插件，從而形成自己的數字化合作生態，起到借力打力的效果。從某種角度看，數字生態與連接是數字化企業無法繞開的。擁有一個插件“商店”並開放，就擁有一個數字生態。

企業化小程序技術平台 - 符合國情的新一代企業軟件載體

有想法有能力的企業IT，採用“商店模式”自主研發一個內部的“插件商店”、軟件模塊的“零部件倉庫”，説難不難，但要讓其有生命力、長期可持續發展，則是一件相當挑戰的事情。

例如，在移動互聯網發展中後期，不少技術團隊也探索出用HTML5實現業務邏輯導向的、變更相對頻繁的模塊並支持熱更新，降低對手機上原生App的變更所產生的成本，提高開發測試和發版的敏捷度。

但是這種做法有幾個不足之處：

• 首先是“土法煉鋼” - 相當於自己發明了一次“輕應用”（基於HTML5的代碼模塊）
• 其次，這種“作坊式”DIY的“輕應用”，因為一開始就不是從一種工業標準或被廣泛接受的規範的角度考慮，而是基於某個企業自己的應用場景和一些工程實踐的積累，“迭代”而來，因此往往缺乏周詳完備的考慮，對通用性考慮不足，可能經過相當長時間的積累後趨於穩定，但也可能沉澱了不少的早期歷史包袱和技術債（例如因團隊早期工程經驗或業務焦點所導致的侷限性而形成）
• 第三是這樣的內部自研封閉技術，很難做到對外開放 - 例如如果企業希望打開一個輕應用“商店”，爭取外部合作伙伴、開發者向商店開發新內容或者遷移存量內容，面臨相當困難，因為要求外部開發者重新學習瞭解一個非標準的技術，開發、遷移成本高，也沒有其他商業化回報
• 第四是自我維護這麼一套不直接與業務內容相關的“中間件”成本不低，在業務導向的傳統行業的企業中，這類成本投入也不見得能被業務部門、財務預算的控制部門所理解。長期來説變成一種食之無味棄之可惜的“雞肋”的機會頗高
• 第五是無法衍生出專業的開發工具、測試工具，因為這種研發投入對於一般的企業來説是不划算的，不是它們的本業

説到底，自我發明“插件”機制、自我定義“輕應用”規範，最大的問題是：缺乏工業標準。沒有標準就沒有開放性，也就沒有技術生態、內容生態可言。技術供應商、系統集成商等乙方需要根據不同的甲方客户的技術要求，把相同的技術內容作重複開發。因為給每一家客户都是做人力密集型的“外包”，實施成本高並且因客户而異，所以乙方也不得不把成本轉嫁於甲方。簡單的説，甲方乙方的對接成本都非常高。

那麼，對於傳統企業IT而言，是否足夠大的企業就有資格去制定某個行業內的“輕應用”標準，從而約束業內軟件供應商、開發商、集成商去共同遵循，達到整個行業的降本增效？答案恐怕也是否定的，因為被某個行業共同接受的標準，不僅制定週期長、涉及眾多同業機構的協商和扯皮，更往往同樣沒有生命力，終究要被互聯網標準、市場約定俗成的“既成事實”標準所替代。

鑑於這樣的觀點和認知，市場上出現了以凡泰極客FinClip引領的“小程序容器”技術，它專為企業軟件系統建設而生，背後的設計邏輯是：

• 最大程度兼容互聯網上最主流的、擁有最多開發者、沉澱最多存量內容的小程序規範，直接採用小程序作為下一代企業軟件中“輕應用”的技術載體。這相當於在ToB賽道重新發明了一次小程序（但除遵循相似規範或標準外，與互聯網上的小程序平台並無關係）。從而讓傳統企業的IT能夠更容易的獲得開發人才、吸引合作伙伴提供內容
• 逐步向W3C MiniApps（國際互聯網技術標準制定組織W3C的MiniApps 工作組牽頭的小程序技術標準）靠攏，讓傳統企業節省“重新發明車輪”的麻煩與成本，以工業標準去打造自己的企業軟件系統
• 整體上為任何行業的甲乙方合作、對接，提供最根本的降本增效方案。甲方無需徒勞的去定義行業標準，乙方也無需被迫接受、適配相對封閉的行業標準，大家都採用最普遍、最廣為人知的技術即可
• 以小程序作為現成標準，提供產品化的開發工具如IDE（FinClip Studio）、調試工具（如FinClip App、FinClip Browser）、低代碼生成工具等等

PWA（Progressive Web App）、.Net以及眾多JavaScript Meta Framework（諸如Next.js、Nuxt.js、SvelteKit、Astro、Vite、Remix... 以及涉及Hydration、SSR等諸多技巧與概念），在移動互聯網高度繁榮、人機交互體驗領先全球的中國市場，從來都沒有取得過成功或者成為主流。相比之下，小程序技術是最符合國情的輕應用技術。凡泰極客把這種技術重新發明為企業應用軟件的基礎平台，有非常合理的市場基礎。

極致的高內聚、低耦合

小程序技術可以説是把高內聚低耦合的架構設計思想發揮到極致。
從業務功能解耦的角度看，任何業務場景、應用邏輯，都可以獨立在某個小程序中實現，而小程序之間互無關係、互不影響。

從開發團隊解耦的角度看，任何開發小組、開發團隊僅負責自己的小程序，彼此無依賴關係。運行在小程序容器中的代碼，彼此之間有安全隔離、資源隔離，所以小程序代碼庫及知識產權均獨立維護。

從規模效應（Economy of Scale）的角度，任何擁有小程序容器技術的企業，均可以像某些互聯網巨頭一樣，引入、運行無上限的小程序內容 - 注意這是“數字化轉型”的關鍵，當企業可以低成本甚至接近零成本的引入極其豐富的小程序化業務內容時，即可讓其客户、員工、合作伙伴“不離線”的在平台上獲得一切的數字服務，所謂數字化就達到“從量變到質變”。

從敏捷觸達市場（Time to market）的角度看，任何小程序化的業務場景、應用邏輯，均可以“小程序粒度”發佈或回收。以銀行為例，通過這樣的技術，在其App中，每天可以由各業務線、各區域分支行灰度發佈和上下架小程序內容百千次，誰都不用等候誰，功能上架沒有在IT樞紐排期一説。內容發佈變成一個以IT、法務、合規、風控等部門聯合管控的運營事務。

從數字內容生命週期的角度看，小程序化的業務數字內容，其開發、測試、灰度發佈、審核、審計、上架、下架等全生命週期的管理，完全由“業主”部門自主負責，和它所運行的軟件系統“宿主”環境（例如某個App）無關。

從生態化的角度看，擁有小程序技術平台的企業，技術上也擁有了自己的“小程序商店”，具備了自主打造合作生態、發展合作伙伴的可能性。數字化轉型的焦點，從建設基礎技術平台，轉移為運營數字化生態。生態建設的成功，不再受技術掣肘，全在於企業的線上開放合作的營銷推廣能力。

企業應用軟件系統的小程序化，可以説是“分治算法”精神下一種極致的低耦合技術架構，企業軟件的“可測試性”、“可擴展性”、“靈活性”、“魯棒性”等等，會隨之而來。