如何理解：業務架構、應用架構、數據架構、技術架構與系統和復雜度

關于系統的理解

???1.1?系統的概述

隨著人類社會的發展，人們面對越來越多的規模巨大、關系復雜、參數眾多地復雜問題，這些問題的復雜度已經遠遠超出人類的理解能力，系統論就是為了分析和解決這些問題而生。我們平時接觸的計算機系統包括軟件系統，本質上屬于系統論的一個范疇。系統論是一門獨立的學科，經歷了多年的發展已經形成了體系化的理論。系統論里的一些原則、理論、方法同樣適用于計算機系統，計算機系統里遇到的復雜性問題在系統論里肯定會有原則性的指導。相信前人肯定比我們聰明，我們遇到的問題，前人肯定也遇到過，只不過以另外一種形式呈現。多年的互聯網從業經驗很容易讓我們拘泥于互聯網軟件系統，這樣很容易忽略更一般性的規律和原理。

所以，把互聯網軟件系統放到軟件系統里看，把軟件系統放到系統論里看。

從計算機系統出來，進入系統論的層面，再回到計算機系統。這種思維的切換，仿佛上帝視角與人間視角的來回切換。

關于系統定義：系統由相互作用和相互依賴的若干組成部分結合成的、具有特定功能的有機整體。系統論強調整體與局部、局部與局部、系統本身與外部環境之間互為依存、相互影響和制約的關系。

系統論要求：把事物或者現象當作系統來研究，并用數學模型去描述和確定系統的結構和行為。系統的思考，區別于系統化的思考，系統的思考是要求我們把事情當做一各個個的系統來看。

系統的整體不是系統的部分之和，系統的整體一定大于系統的部分之和。一個系統能支撐的能力超越于系統組成之和。例如汽車由輪子、發動機、車架組成。汽車都能行駛，但是輪子、發動機、車架都不能行駛。

???1.2?系統三大基本特征

目的性：任何系統都有一定的目的。

這里可以理解為業務系統的邊界。我們的系統是為了做什么事而設立的？能做什么事？不能做什么事？

動態性：動態性說明系統會發展。

放到我們的業務系統上來說，就是會演進，會向前動態發展。系統內部會隨著時間而變化，系統與外部的交互關系也會隨著時間而改變。

有序性：任何系統本質上都是有序的，如果不是，說明我們對系統的描述還不夠深刻。

如果我們的業務系統仍然很亂，很雜，那說明我們還沒有找到系統的深層次的結構，復雜是因為我們掌握不夠。

???1.3?系統思維的四層境界

認識系統：認識并了解系統的形式與功能、結構與關系。

預測系統：當系統發生某個事件時，能夠根據已有知識對系統的行為做出預測。

決策系統：對系統足夠了解，擁有充足的依據，可以干預系統，對系統進行認定、分析、權衡，最終做出決策。

組裝系統：系統思維的最高境界，可以根據系統的部件重組一套系統。

系統思維的方法論：

通過抽象思維識別出系統中的實體并用概念模型表達。

通過整體思維對關鍵問題進行分析、歸納，篩選出恰當的實體作為系統的組裝部件。

???1.4?系統的分類

系統的分類有很多，按照不同的維度可以劃分不同的系統，例如按照是否人工可以分為人工系統、自然系統、社會系統等。

這里簡要講一下兩個系統，決定論系統，演化系統。

決定論系統：有明確的因果關系，掌握系統內部規律就可以做出明確的判定。機械系統、軟件系統等均屬于這個范疇。

例如飛機、汽車等只要掌握對應的物理原理，就能夠讓飛機飛行，讓汽車在馬路上奔馳。

演化系統：更多的是相關性，因果關系不明確或者難以理清，其難度是深不可測。例如人類的免疫系統，醫學上雖然知道免疫系統，但是仍然難以理清其原理。人類的大腦，自然界中的蟻群系統，自然界的生態平衡系統等。

對于不同的系統，有不同的方法論，處理的策略也不一樣。

系統論是一門科學，也是一門哲學，有興趣可以深入研究，這里只是蜻蜓點水。

02

關于架構的理解

“把桌子放在房間里看，把房間放在院子里看，把院子放在城市規劃里看。”

???2.1?什么是架構

架構，是對系統的描述。

維基百科的定義是：軟件架構是有關軟件整體結構與組件的抽象描述，用于指導大型軟件系統各個方面的設計。

系統的三大特征表現在架構上就是：橫向可并列，縱向可推導，整體可演進。

物理學的熵增定律表明孤立系統總是趨向于熵增的方向發展。在軟件系統里同樣適用，只不過是以復雜度的增加表現的。

互聯網軟件系統總是朝著復雜度增加的方向發展。所以架構的第一目的是控制復雜，使系統朝著可控的方向發展。

???2.2?什么是好的架構圖

簡潔抽象：好的架構圖一定是簡潔的，表現上簡潔有力，能夠一眼看上去就經緯分明。有一定的抽象度的，如果一個架構圖存在各種飛線環線，那一定是抽象的不夠。抽象才有意義，架構里如果存在各種細節，那就是堆砌。

可解釋：好的架構圖一定能夠用來解釋當前系統的現狀和行為。

指導行動：好的架構圖一定是可以指導行為的，指導行動才是架構圖的最大價值。能夠預測未來，指導行動。對于某個領域架構圖，根據架構圖都不知道把某個模塊放哪里，那就是失敗的。好的架構圖應該是對于一個沒有經驗的人，都能根據架構來做模塊劃分。

可進化：對應于系統的動態性，架構也會隨著時間而進化的。不能進化的架構就像花瓶，看著很美，一碰就碎。

???2.3?架構圖

對架構的呈現業界已經存在不同的框架。有4+1視圖、C4 模型、TOGAF 提出的企業架構模型等。不管哪種模型，其核心思想都是從不同的維度對軟件架構進行描述。下面著重從這幾個方面來簡述。

???2.3.1 4+1模式

4+1視圖由 Philippe Kruchten 提出的對軟件工程邏輯架構的描述，目前已經成為事實上的軟件結構標準，分別以終端使用者、開發者、系統工程師、軟件經理等不同的視角對軟件進行描述。如下圖所示：

邏輯視圖（Logic View）：終端使用者的視角，從功能角度來描述不同功能組件的層次關系。

開發視圖（Development View）：開發者視角下，從實現層面描述不同代碼的包、類、庫的構成關系。

過程視圖（Process View）：不同組件之間的行為關系，通常以時序圖的形式來表示，有一定的時序延展性。

物理視圖（Physical View）：部署視圖，系統所依托的物理視圖。

場景視圖（Scenarios）：系統所涉及的不同對象之間的關系。通常以用例圖的形式來呈現。

基于這5個視角，可以衍生出5種架構模型。場景、功能、實現、過程、部署，一層層的抽象。

4+1架構視圖，構建了一個觀察了解系統框架。它告訴我們可以從邏輯視圖、開發視圖、過程視圖、物理視圖、場景視圖這幾個層面來對系統進行描述、觀察、理解。對于一個系統，這5個視角已經是很完備了。值得注意的是4+1更大的價值是提供了一套分析系統的框架，實際上怎么呈現不同的團隊可能有不同的形式。對于一個系統從不同的視角看會得到不同的理解，橫看成嶺側成峰。

???2.3.2?C4模型

C4 模型是由 Simon Brown 在2006年至2011年之間創建，在4+1模型的基礎上建立（ https://c4model.com/ ），實際上就是以下4個單詞的縮寫：

上下文 Context：描述的系統與周邊系統、人的關系。重點是該系統與外界的關系。這里的外界包含人、以及其他的系統。?

容器 Containers：容器是一個功能的單位，是從技術層面來描述，可以是一個服務，也可以是一個技術組件或者一個功能模塊。例如一個基金系統會包含交易服務、訂單服務、商品服務等。

組件 Components：組件是容器的的組成，組件是對容器的放大，例如商品服務里包含 sku 管理、行情數據、衍生指標等。

代碼 Code：這一層次是代碼級別，包含接口、類、對象的繼承、組合、包含等。

該模型是對一個系統從宏觀到微觀逐級展開來描述，猶如拿著放大鏡從太空看地球一樣。

第一層看到的是地球與其星球的環繞、第二層是看到地球上的山川海河，第三層看到的是不同的國家城市，第四層看到的是不同的房子家庭。

C4 模型基于4+1模型，但是也有些差異。如果說4+1重點是橫看成嶺側成峰。那 C4 模型則是一窺到底的放大鏡。

C4 模型告訴我們，不同抽象層次的關注點、挑戰點、問題域都是不同的，站在不同的層次就要思考對應的事情。

關注點一旦與該層次不匹配就會出現邏輯錯亂問題。能分清楚問題域在何種層次其實已經把問題解決一大半了。

有時候，在低層次很難解的問題，上升一個層次就迎刃而解了。?

有時候，在高層次看不清的問題，降低一個層次就一目了然了。

高層次是低一層的抽象，低層次是高一層的具化。

高手應該是能夠識別不同的抽象層次，并且可以游刃有余地在不同抽象層次之間穿梭。

處于高層次時不應該被低層次的具體牽絆，處于低層次的時候也不應該好高騖遠。

???2.3.3?TOGAF-4A 架構

業務架構：業務戰略，治理，組織和關鍵業務流程。從企業視角來看，重在價值、信息、協作，關聯多部門。

應用架構：要部署的各個應用程序的藍圖，其交互以及與組織核心業務流程的關系。

數據架構：一個組織的邏輯和物理數據資產和數據管理資源的結構。

技術架構：支持部署業務，數據和應用程序服務所需的邏輯軟件和硬件功能。這包括IT基礎設施，中間件，網絡，通信，處理和標準。

TOGAF 認為架構的目的是為了幫助企業實現如下能力：

異構到同構（塑造同構 IT）、事后到事先（塑造規劃 IT）、離散到統一（塑造統一 IT）、無序到有序（塑造有序 IT）

???2.3.4?實際模型-互聯網模型

實際上，相對于傳統的軟件系統，互聯網行業發展比較快，業務存活周期比較短，就形成了互聯網行業特定的架構描述方式。更多是以業務架構、技術架構、部署架構三種形式呈現。

業務架構：從業務角度描述系統承載的功能集合、領域邊界、各組成部分的邏輯關系。區別于技術架構，業務架構圖里避免出現技術類的術語，如 DB、MySQL、CMQ、同步、異步、并發等。?

技術架構：從技術角度描述系統各組成部件之間的交互關系，技術架構體現的要具有技術特色，例如同步、異步、消息等。

部署架構：從物理角度描述系統的部署分布。

???2.4?微服務的理解

軟件架構歸根結底無非兩種模式：從技術層面和業務功能層面來設計。在理解這兩個之前先區分一下技術語言和業務語言：

技術語言：是實現層面的。如 DB、MySQL、查詢、超時、讀寫分離、快慢分離、邏輯層、緩存、創建訂單、同步、異步、多線程、多進程。

業務語言：是功能層面的。如買入、取出、基金信息、行情、基金詳情、資產、產品列表、持倉列表、申購列表、贖回列表。

技術人員要做的是擺脫技術語言體系，走進業務體系，不能被技術語言限制住。從本質上來說技術是為了業務服務的，所以理解業務第一，技術第二。對業務有了深刻的理解，再轉過去用技術來實現業務。最好的實踐就是在業務代碼中看不到技術詞匯，只有業務。

微服務最早由martinfowler提出，定義如下：

“In short, the microservice architectural style? is an approach to developing a single application as?a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are?built around business capabilities?and independently deployable by?fully automated deployment machinery.?There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.” --- https://www.martinfowler.com/architecture/

說一下我的理解，微服務不是小服務，如果只是因為規模小，那直接叫小服務即可，更準確的叫法是：小而完整的服務，這里的小是指體積，完整是指能夠提供完整的業務能力。微服務是一種理念，其表達的是用一個服務來表達一個實體相關的所有行為，某個實體與外部的所有聯系均通過該服務來發生。區別于以往按照技術功能劃分的服務，ao 做邏輯層，dao 做存儲層，vo 做展示層。一個實體的行為要通過 vo、ao、dao 三個服務的關聯才能表達出來。而微服務是純粹從業務語義層面出發，只需要一個服務，對外的表示只有一個。類似于一個國家，雖然小，但是有自己的法律、武裝、稅收等。微服務擁有自己的邏輯、存儲、領域等。微服務核心思想：服務即實體，我即全部。服務是實體概念的載體。其出發點是從業務領域或者功能層面就進行徹底的解耦。微服務之間完全異構，微服務之間甚至都無技術層面的共通性。

例如代表保單的微服務，所有跟保單的相關行為都是該服務提供的，該服務內部實現保單的存儲和查詢，外界無需關心，創建保單、查詢保單、理賠保單均是通過該保單微服務實現的。

但是在實操中，限于硬件水平和當前的技術能力，單個微服務又難以承接實體相關的所有行為。例如保單的查詢對性能要求比較高，保單的寫入對一致性要求比較高，這種情況下，如果放在一個服務里就會帶來實現上的困難。這時可能又會回到了傳統技術功能劃分服務上來，考慮讀寫分離，分出一個查詢和讀的保單微服務。有時候也是無奈的妥協，但是一般的原則是先堅持原則再妥協。先按照微服務領域的不可分割性來設計，遇到技術性的挑戰再做調整與妥協。

03

關于復雜的理解

“計算機編程的本質就是控制復雜度”? ?---Brian Kernighan

???3.1 什么是復雜？

對于一個系統來說達到怎么樣的情況下才是復雜呢？物理學家勞埃德提出了一個觀點：

描述它有多困難；

產生它有多困難；

其組織程度如何？

我個人的理解是，如果對于一個系統出現如下情況，即可認為是復雜的：

無法表達其概念，超出了人類語言的表達能力范疇

無法描述其過程，超出了人類的理解能力。

無法度量其結果，沒有度量就無法管理，復雜到難以有精確的方式進行度量。

???3.2?復雜的分類

表面復雜度：一個系統經過抽象、簡化、分層、構建呈現出來的復雜度，是人類最直觀理解的復雜度。例如一個系統架構圖所呈現的復雜度就是表面復雜度。
必備復雜度：支持一個功能所需要的必備復雜度，也就是理論復雜度。
實際復雜度：實際上包含因為技術限制、資源限制、過程浪費導致的不必要的復雜度。

表面復雜度是人類所能理解的復雜度，必備復雜度和實際復雜度往往超出人類的理解能力。

有一種觀點認為：系統架構的目的就是為了把系統的表面復雜度控制在人類的理解范疇內，把實際復雜度降低到接近必備復雜度。

???3.3 CyneFin 框架

關于復雜，內涵很豐富。有一個大佬叫戴夫·斯諾登，他于1999年創建了一套輔助決策的框架 Cynefin 框架，這套框架里就很好地把我們平常說的復雜進行了歸類。見下圖。

這個圖直觀上看，分五個象限，從右下角依次逆時針看。

Simle（簡單）、Complicated（繁雜）、Complex（復雜）、Chaotic（混亂），中間有一個黑色區域是Disorder（無序）。

這五組概念，可以理解為復雜度逐級提高。簡單理解：

Simple（簡單）：知道因就能知道果。
Complicated（繁雜）：由因可能推出不同的果，需要一定的領域知識，才能分析出因果。
Complex（復雜）：不知因，也不知果。直觀上找不出因果，必須事后復盤才可以。
Chaotic（混亂）：知道因果不重要了，重要的是要構建秩序，使系統穩定下來。
Disorder（無序）：復雜到都無法按照以上四個概念定義。

我們平常遇到的任何的業務、環境、情形、項目、系統都可以用這五個概念中的一個來形容。

一個系統的發展也大概會沿著從簡單->繁雜->復雜->混亂->無序的狀態發展。這個過程跟物理中的熵增概念很吻合。

Simle（簡單）：已知的知識，存在直接因果關系，一看就明白。這個不需多說，任何我們已經熟悉的系統，都是這樣的。

對于這種狀態的，我們最好應對方式，是采用感知-分類-響應模式。因果關系非常明確，我們只需要進行歸類就好。

Complicated（繁雜）：?這個系統存在大量的已知的未知，非專業人士很難看出其中的因果關系，需要專業人士結合大量的專業知識才能分析出因果。

例如在政府部門的設置上分縱線和橫線兩套體系，俗稱“條條塊塊”。既垂直又水平。某縣教育局縱線要向上級教育廳匯報，橫線又要向地方縣政府匯報。諸多類似的部門形成了錯綜復雜的關系，呈現出來就是網狀的關系。面對這樣的系統，體制外的人很難理清某個部門應該向誰匯報。這個時候如果來個公務員老司機，他能夠很快速地告訴你其中的奧秘。

再例如，對于一個沒有任何醫學專業背景的人，你給他一堆指標，然后問他為啥會胃痛。他肯定覺得太繁雜了，無從下手。對于他來說最好的方式，就是請教醫學生或者系統性學習醫學類的專業知識。

所以面對繁雜的情形，最好的方式是，學習領域知識，快速入門。實踐上采用：“感知-分析-響應”的模式。注意重點是分析。分析的前提要擁有領域知識。所以深入學習+分析才是應對之道。大部分情況下我們遇到的是這種系統，我們需要的是增加專業技能，補充領域知識，提高識別能力。這種也最好解。

Complex（復雜）：代表了未知的未知。存在不確定的情況，可能存在也可能不存在，需要復盤才能找到原因。需要逐步探索，通過反饋才能分析到原因。

例如你突然被提拔為一個管理者，你的任務是團隊文化建設。面對這項任務，既不知道因也不知道果。因為團隊文化是個很虛的東西，你都不知道怎么衡量。更不用說采取什么方法去預測了。對于這種，你只能通過試探，然后事后歸因。

所以采用模式是：“探索-感知-響應”。關鍵是要去探索，不斷地探索，不斷地反饋，最終找到因果關系。

Chaotic（混亂）：混亂狀態通常是指危機時刻。是指你能接觸到信息都是不穩定的。這種情況下因果關系不清晰，處于雜亂無序的狀態。嘗試去識別因果已經沒有意義了。

處于各種不穩定中，行動起來，把無序狀態穩定下來。用行動來構建秩序。

對于這種情況，一切未知，只要行動起來，通過行動構建秩序。使混亂場面扭轉到復雜的場面。這種狀態下的應對模式是：“行動-感知-響應”。

Disorder（無序）：復雜到無法對系統復雜度進行分類。完全無序，抓瞎狀態。這種的應對策略，就是先觀察，以靜待變，等你理清楚了處于某種復雜度狀態的時候，再去想對策。想不清復雜度，就不要動。一直想。直到你能區分系統處于以上四種狀態的一種。

總結：

不同級別的復雜對應的處理策略也不一樣。我們每天面對各種的情形，利用這個框架的指導思路，有助于我們透過現象看本質。能力越強的人處理的復雜度的也越高。