案例題目

信息系統架構設計

基本概念

信息系統架構（ISA）是對某一特定內容里的信息進行統籌、規劃、設計、安排等一系列的有機處理的活動。特點如下

1. 架構是對系統的抽象，它通過描述元素、元素的外部可見屬性及元素之間的關系來反映這種抽象，因此僅與內部具體實現有關的細節是下屬于架構的，即定義強調元素的“外部可見”屬性
2. 架構由多個結構組成，結構是從功能角度來描述元素之間的關系的，具體的結構傳達了架構某方面的信息，但是個別結構一般不能代表大型信息系統結構
3. 任何軟件都存在架構，但不一定有對該架構的具體表述文檔，那架構可以獨立于架構的描述而存在。如文檔已過時，則該文檔不能反映架構
4. 元素及行為的集合構成架構的內容，體系系統由那些元素組成，這些元素各有那些功能（外部可見），以及這些元素間如何連接于互動。
5. 架構具有“基礎”性，它通常涉及解決各類關鍵重復問題的通用方案（復用性），以及系統設計種影響深遠（架構敏感）的各項重要決策（一旦貫徹，更改的代價昂貴）
6. 架構隱含有“決策”，即架構是由架構設計師根據關鍵的功能和非功能性需求（質量屬性及項目相關的約束）進行設計與決策的結果

架構分類

信息系架構可分為物理結構與邏輯結構，物理結構是指不考慮系統各部分的實際工作與功能結構，只抽象的考察其硬件系統的空間發布情況，邏輯結構是指系統各功能子系統的綜合體。

物理結構一般分為集中式與分布式兩大類

邏輯結構在信息系統開發中，強調對各種子系統進行統一規劃，并對子系統進行綜合

1. 橫向綜合：將同一管理層次的各種職能綜合在一起，例如將運行控制層的人事和工資子系統綜合在一起，使基層業務處理一體化
2. 縱向綜合：把某種職能的各個管理層的業務組織在一起，這種綜合溝通了上下級的聯系，如工廠的會計系統和公司會計系統綜合在一起，它們都有共同之處，能形成一體化的處理過程
3. 縱橫綜合：主要是從信息模型和處理模型兩個方面來進行綜合，做到信息集中共享，程序盡量模塊化，注意提取通過部分，建立系統公用數據庫和統一的信息處理系統

信息系統常用四種架構模型

1. 單機應用模式：是最簡單的軟件結構，是指運行在物理機器上的獨立應用程序。單機系統本身也可以很復雜
2. 客戶機/服務器模式：即兩層、三層C/S、B/S模式、MVC模式等
3. 面向服務的架構（SOA）模式
4. 企業數據交換總線：不同企業應用之間進行信息交換的公共通道

企業信息系統總體框架

要在企業中建立一個有效集成的ISA，必須考慮企業中的四個方面：戰略系統、業務系統、應用系統和信息基礎設施

• 戰略系統：是在企業中與戰略指定、高層決策有關的管理活動和計算機輔助系統

  在ISA中戰略系統由兩個部分組成，其一是以計算機為基礎的高層決策支持系統，其二是企業的戰略規劃體系

  在ISA中設立戰略系統有兩重含義，一是它表示信息系統對企業高層管理者的決策支持能力；二是它表示企業戰略規劃對信息系統建設的影響和要求

• 業務系統：企業中完成一定業務功能的各部分（物質、能量、信息和人）組成的系統

  作用：對企業現有業務系統、業務過程和業務活動進行建模，并在企業戰略的指導下，采用業務流程重組（BPR）的原理和方法進行業務過程優化重組

• 應用系統：即應用軟件系統，指信息系統中的應用軟件部分。如TPS、MIS、DSS等

  兩個基本組成部分：內部功能實現部分和外部界面部分

• 企業信息基礎設施：是指根據企業當前業務和可預見的發展趨勢，及對信息采集、處理、存儲和流通的要求，構筑由信息設備、通信網絡、數據庫、系統軟件和支持性軟件等組成的環境。

  這里可以將企業信息基礎設施分成三部分：技術基礎設施、信息資源設施和管理基礎設施

  1. 技術基礎設施：由計算機、網絡、系統軟件、支持性軟件、數據交換協議等組成
  2. 信息資源設施：數據與信息本身、數據交換的形式與標準、信息處理方法等組成
  3. 管理基礎設施：企業中信息系統部門的組織結構、信息資源設施管理人員的分工、企業信息基礎設施的管理辦法與規章制度等

開放式企業框架標準

開放式企業框架標準（TOGAF），它是為標準、方法論和企業架構專業人員之間溝通提供一致性保障

該框架通過下面四個目標幫助企業組織和解決所有關鍵業務需求：

1. 確保從關鍵利益相關方到團隊成員的所有用戶都使用相同的語言
2. 避免被“鎖定”到企業架構的專有解決方案
3. 節省時間和金錢更有效地利用資源
4. 實現客觀的投資回報

TOGAF框架核心思想：模塊化架構、內容框架、擴展指南、架構風格

TOGAF的關鍵是架構開發方法（ADM），為開發企業架構所需要執行各個步驟以及它們之間的關系進行詳細的定義

ADM方法是由一組按照架構領域的架構開發順序排列成一個環的多個階段所構成

ADM三個級別的迭代：基于ADM整體的迭代、多個開發階段間的迭代、在一個階段內部的迭代

ADM的全生命周期主要活動如下

ADM階段	ADM階段內的活動
準備階段	為實施成功的企業架構項目做好準備，包括定義組織機構、特定的架構框架、架構原則和工具
需求管理	完成需求的識別、保管和交付，相關聯的ADM階段則按優先級順序對需求進行處理 TOGAF項目的每個階段，都是建立在業務需求之上并且需要對需求進行確認
階段A（架構愿景）	設置TOGAF項目的范圍、約束和期望。創建架構愿景，包括如下： 1.定義利益相關者； 2.確認業務上下文環境； 3.創建架構工資說明書； 4.取得上級批準；
階段B（業務架構） 階段C（消息系統架構應用 & 數據） 階段D（技術架構）	從業務、信息系統和技術三個層面進行架構開發，在每一個層面分別完成以下活動： 1.開發基線結構描述； 2.開發目標架構描述； 3.執行差距分析
階段E（機會和解決方案）	進行初步實施規劃，并確認在前面階段中確定的各種構建塊的交付物形式： 1.確定主要實施項目； 2.對項目分組并納入過度架構； 3.決定途徑（制造/購買/重用、外包、商用、開源）； 4.評估優先順序； 5.識別相依性
階段F（遷移規劃）	對階段E確定的項目進行績效分析和風險評估，制訂一個詳細的實施和遷移計劃
階段G（實施治理）	定義實施項目的架構限制： 1.提供實施項目的架構監督； 2.發布實施項目的架構合同； 3.監測實施項目以確保符合架構要求
階段H（架構變更管理）	提供持續監測和變更管理的流程，以確保架構可以響應企業的需求并且將架構對于業務的價值最大化

信息化總體架構方法

實現信息化就要公租和完善6個要素（開發利用信息資源，建設國家信息網絡，推薦信息技術應用，發展信息技術和產業，培育信息化人才，指定和完善信息化政策）的國家信息化體系

完善的信息化內涵包括四方面內容：信息網絡體系、信息產業基礎、社會運行環境、效用積累過程

信息化建設：指利用現代信息技術來支撐品牌管理的手段和過程。信息化建設包括了企業規模，企業在電話通信、網站、電子商務方面的投入情況，在客戶資源管理、質量管理體系方面建設成就等

信息化主要體系已下6種特征：易用性；健壯性；平臺化、靈活性、擴展性；安全性；門戶化、整合性；移動性

信息化架構兩種模式：數據導向架構，流程導向架構。

對于數據導向架構重點是在數據中心，BI商業智能等建設中使用較多，關注數據模型和數據質量；對流程導向架構，SOA本身是關鍵方法和技術，關注端到端流程整合，以及架構對流程變化的適應度。兩種架構并且沒有一個的邊界，而是相互配合和補充

• 數據導向架構研究的是數據對象和數據對象之間的關系，這個是首要的內容。在這個完成后仍然要開始考慮數據的產生、變更、廢棄等數據生命周期，這些自然涉及的數據管理相關流程
• 流程導向架構關注的是流程，架構本身目的是為了端到端流程整合服務。因此研究切入點會是價值鏈分析，流程分析和分解，業務組件劃分

信息系統的生命周期階段

階段	工作	輸出
系統規劃階段	對組織的環境、目標及現行系統的狀況進行初步調查，根據組織目標和發展戰略確定信息系統的發展戰略，對建設新系統的需求做出分析和預測，同時考慮建設新系統所受的各種約束，研究建設新系統的必要性和可行性。根據需要與可能，給出制建系統的備選方案	可行性研究報告、系統設計任務書
系統分析階段	根據系統設計任務書所確定的范圍，對現行系統進行詳細調查，描述現行系統的業務流程，指出現行系統的局限性和不足之處，確定新系統的基本目標和邏輯功能要求，即提出新系統的邏輯模型。系統分析階段稱為邏輯設計階段。這個階段是整個系統建設的關鍵階段，也是信息系統建設與一般項目的重要區別所在	系統說明書
系統設計階段	系統分析階段的任務是回答系統“做什么”的問題，而系統設計階段回答的問題是“怎么做”。該階段的任務是根據系統說明書規定的功能要求了，具體設計實現邏輯模型的技術方案，也就是設計新系統的物理模型。這個階段又稱為物理設計階段，可分為總體設計（概要設計）和詳細設計兩個子階段	系統設計說明書（概要設計、詳細設計說明書）
系統實施階段	將設計的系統付諸于實施的階段，這一階段的任務包括計算機等設備的購置、安裝和調試、持續的編寫和調試、人員培訓、數據文件交換、系統調試與轉換等	實施進展報告、系統測試分析報告
系統運行和維護階段	系統投入運行后，需要經常進行維護和評價，記錄系統運行的情況，根據一定的規則對系統進行必要的修改，評價系統的工作質量和經濟效益	維護日志、變更日志

價值驅動的體系結構

價值模型核心的特征可以簡化為三種基本形式：

1. 價值期望值：表示對某一特定功能的需求，包括內容（功能）、滿意度（質量）和不同級別質量的實用性
2. 反作用力：系統部署實際環境中，實現某種價值期望的的難度，通常期望越高難度越大，即反作用力越大
3. 變革催化劑：表示環境中導致價值期望值發生變化的某種事件，或者是導致不同結果的限制因素，因為一個或多個限制因素使得滿足一個或者多個期望值變得更加困難

優化體系結構需要權衡：重要性、程度、后果、隔離

信息系統架構案例分析

Web服務在HL7上的應用

對于給定的衛生保健領域，HL7 3.0版本說明書是基于參考消息模型的（RIM）。是一種公共的模型框架，包括病例模型、信息模型、交互模型、消息模型和實現信息說明書，可以抽象出HL7發送者/接收者內部的這兩組功能：商業邏輯和Web服務適配器

商業邏輯的任務

發送端：創建一種具體HL7消息類型的XML描述。將消息傳送到Web服務適配器，適配器負責傳送到接收應用端

接收端：“找回”由Web服務適配器接收的HL7消息，同時從接收到的XML消息哪里打開消息；驗證HL7消息是否滿足用來交互的商業規劃和約束；核實發送應用端是否需要一個應用層的確認消息（HL7消息類型MCI）如果是那樣的話，發送那個消息

Web適配器功能

用來處理消息的分發和確認信息

發送端

1. 讀取接受到的HL7消息的Transmission Wrapper，以便決定如何送達Web服務基層結構上的發送容器（例如接收應用軟件），從而配置SOAP
2. 基于HL7消息類型、應用配置和規則（如安全性）來準備一個SOAP消息，包括作為一個SOAP消息體部分的HL7 XML消息，這個消息被發送到Web服務基層組織
3. 把SOAP消息傳遞到Web服務代理，通過網絡進行傳輸
4. 無論發送端什么時候請求，都準備接收并存儲來自接收端的效應信息或是應用層的確認消息

接收端

1. 從Web服務站處接收SOAP消息
2. 驗證接收的SOAP消息滿足應用配置和一些約束條件（如安全性）
3. 或者將這些接收到的消息在內存中以永久的形式保留
4. 有選擇性地從SOAP消息里打開HL7 XML消息，同時核對接收到的HL7消息是否與期望的HL7消息類型相符合
5. 驗證是否任意通信層的確認信息都需要被執行，在那種情況下需要返回一個合適的消息發送到源消息發送端
6. 傳遞HL7消息給接收應用端

以服務為中心的企業整合

某航空公司已經在幾個主要的核心系統之間構建了用于信息集成的Hub，其他應用間也有不少點到點的集成，然而存在如下困難

1. 因為大部分核心應用構建在主機之上，所有Information Hub是基于主機技術開發，很難被開發系統使用
2. Information Hub對Event支持不強，被集成在系統間的事件以點到點流轉為主，被集成系統間耦合性強
3. 牽扯到多個系統間的業務寫作以硬編碼為主，將業務活動自動化的成本高，周期長，被開發的業務活動模塊重用性差

為了解決這寫企業集成中的問題，該公司決定以Ramp Control系統為例探索一條以服務為中心的企業集成道路

在航空業中，Ramp Coordination是指飛機從降落到起飛過程中所需要進行的各種業務活動的協調過程。需要協調的業務有：檢查機位環境是否安全、以及卸貨、裝貨和補充燃料是否方便和安全等

三種類型航班：short turn around（降落后不久就起飛）、Arrival Only（降落后隔夜起飛）、Departure Only（每天第一班飛機）

每種細分航班類型的Ramp Coordination的流程都是略有不同。如此多的流程之間共享一個業務活動的集合，如此多種類型的流程都是這些業務活動的不同組裝方式。以服務為中心的企業集成種流程服務就是通過將這些流程間共享的業務活動抽象為可重用的服務，并通過流程服務提供的流程編排能力將它門組成各種大同小異的流程類型，來降低流程集成成本，加快流程集成開發效率。以服務為中心的企業集成，通過服務建模過程發現這些可重用的服務，并通過流程模型將這些服務組織在一起

Ramp Coordination相關的服務模型和Ramp Coordination流程相關的有兩個業務組件

1. Ramp Control 負責Ramp Control相關各種業務活動的組件
2. Flight Management負責航班相關信息的管理，包括航班日程，乘客信息等

這兩個業務 組件分別輸出如下服務

1. Retrieve Flight BO：由Flight Management輸出，主要用于提取和航班相關的數據信息
2. Ramp Coordination：由Ramp Control輸出，主要用于Ramp Coordination流程的編排
3. Check Spot：由Ramp Control輸出，用于檢測機位安全信息
4. Check Unloading：由Ramp Control輸出，用于檢查卸貨狀況
5. Check Loading：由Ramp Control輸出，用于檢查轉貨狀況
6. Check Push Back：用Ramp Control輸出，用于檢查關門動作

目前，Ramp Coordintaion流程需要4種類型的外圍應用交互

1. 從乘務員管理系統提取航班乘務員的信息
2. 從訂票系統中提取乘客信息
3. 從機務人員管理系統中提取機務人員信息
4. 接收來自航班調度系統的航班到達事件

主要架構元素如下

1. 消息服務：Federation Service是Ramp Coordination流程中需要從已有系統中提取4類信息，在Service建模階段這4類信息被聚合為Flight BO（Business Object），集成了Crew Info、Cockpit Info 和 Passage Info等信息
2. 企業服務總線中的事件服務：Event Service 是在檢查機務環境安全（Check Spot）前，Ramp Cordiator需要被通知航班已經到達。這個業務事件由航班調度系統激發，Flight Arrival是典型事件發現服務（Event Detect Service），它通過MQ將事件傳遞給Message Broker，通過JMS的Pub/Sub，這個事件被分發給Check Spot
3. 流程服務
4. 企業服務總線中的傳輸服務：RCMS是即將新建系統，用于提供包括Ramp Coordination在內的Ramp Control的功能

層次式架構設計

軟件層次式結構是最通用的架構，也被叫作N層架構模式。大部分的應用會分成表現層（或稱為展示層）、中間層（或稱為業務層）、數據訪問層（或稱為持久層）、數據層

表現層設計

通常用XML設計表現層

UIP提供了一個擴展的框架，用于簡化用戶界面與商業邏輯代碼的分離的方法，可以用它來寫復雜的用戶界面導航和工作流處理，并且它能夠復用在不同的場景、并可以隨著應用的增加而進行擴展

使用UIP框架的應用程序把表現層分為以下幾層

User Interface Components：這個組件就是依賴的表現層，用戶看到的和進行交互都是這個組件，它負責獲取用戶的數據并且返回結果

User Interface Process Components：這個組件用于協調用戶界面的各部分，使其配合后臺的活動，例如導航和工作流控制，以及狀態和視圖的管理。用戶看不到這一組件，但是這些組件為User Interface Components提供了重要的支持功能

表現層動態生成設計

基于XML的界面管理技術可以實現靈活的界面配置（靜態）、界面動態生成和界面定制（動態）。其思路是用XML生成配置文件及界面所需的元數據，按不同需求生成界面元素及軟件界面

中間層設計

組件設計

業務邏輯組件分為接口和實現類兩個部分。接口用于定義業務邏輯組件，定義業務邏輯組件必須實現的方法是整個系統運行的核心。增加業務邏輯組件的接口，是為了提供更好的解耦，控制器無需與具體的業務邏輯組件耦合，而是面向接口編程

工作流設計

工作流定義為業務流程的全部或部分自動化，在此過程中，文檔、信息或任務按照一定的過程規則流轉，實現組織成員間的協調工作以達到業務的整體目標。工作流參考模型見圖，其中包含6給基本模塊，分別是工作流執行服務、工作流程引擎、流程定義工具、客戶端應用、調用應用和管理監控工具

• 接口1：過程定義導入/導出接口。這個接口的特點是轉換格式和API調用，從而支持過程定義信息間的相互交換
• 接口2：客戶端應用程序接口。通過這該接口工作流可以與任務表處理器交互，代表用戶資源來組織任務。然后由任務表處理器負責，從任務表中選擇、推進任務項目。由任務表處理器或者終端用戶來控制應用工具的活動
• 接口3：應用程序調用接口。允許工作流直接激活一個應用工具，來執行一個活動。典型的是調用以后臺服務為主的應用程序，沒有用戶接口。當執行活動要用到的工具，需要與終端用戶交互，通常是使用客戶端應用程序接口來調用那個工具，這樣可以為用戶安排任務時間表提供更多的靈活性
• 接口4：工作流機協作接口。其目標是定義相關標準，以使不同開發商的工作流系統磁盤相互間能進行無縫的任務項傳遞
• 接口5：管理和監視接口。提供的功能包括用戶管理、角色管理、審查管理、資源控制、過程管理和過程狀態處理器等

實體設計

業務邏輯層實體提供對業務數據及相關功能的狀態編程訪問。業務邏輯層實體可以使用具有復雜架構的數據來構建，這種數據通常來自數據庫中的多個相關表

在應用程序中表示業務邏輯層實體的方法有很多，如XML、通用DataSet、有類型的DataSet等

如下左圖是業務實體XML表示，右圖所示為用于Order業務邏輯層實體的通用DataSet對象。此DataSet對象具有兩個DataTable對象，分別保存訂單詳細信息。每個DataTable具有一個對應的UniqueConstraint對象，用于標識表中的主鍵。此外該DataSet還有一個Relation對象，用于將訂單詳細信息與訂單相關聯

業務框架

業務框架位于系統架構中間層，是實現系統功能的核心組件。采用容器的形式，便于系統功能的開發、代碼重用和管理。下圖便是在吸收了SOA思想之后的一個三層體系結構的簡圖

業務層采用業務容器的方式存在于整個系統當中，采用此方式可以大大降低業務層和相鄰各層的耦合，表示層代碼只需要將業務參數傳遞給業務容器，而不需要業務層多余的干預。如此一來，可以有效地防止業務層代碼滲透到表示層

在業務容器中，業務邏輯是按照Domain Model – Service – Control 實現來實現的

1. Domain Model：是領域業務對象，它僅僅包含業務相關的屬性
2. Service：是業務過程實現的組成部分，是應用程序的不同功能單元，通過在這些服務之間定義良好的接口和契約聯系起來
3. Control：服務控制器，是服務之間的紐帶，不同服務之間的切換就是通過它來實現的

數據訪問層設計

5種數據訪問模式

1. 在線訪問：會占用一個數據庫連接，讀取數據，每個數據庫操作都會通過這個連接不斷地于后臺的數據源進行交互
2. DataAccess Object（Dao）：是標準J2EE設計模式之一，開發人員常常用這種模式將底層數據訪問操作于高層業務邏輯分離開
3. Data Transfer Object（DTO）：是經典的EJB設計模式之一。DTO本身是這樣一組對象或是數據的容器，它需要跨不同的進程或是網絡的邊界來傳輸數據。這類對象本身應該不包含具體的業務邏輯，并且通常這些對象內部只能進行一些諸如內部一致性檢查和基本驗證之類的方法，而且這些方法最好不要再調用其他的對象行為
4. 離線數據模式：是以數據為中心，數據從數據源獲取之后，將按照某種預定的結構存放在系統種，成為應用的中心。離線，對數據的各種操作獨立于各種于后臺數據源之間的連接或是事務
5. 對象/關系映射（Object/Relation Mapping，O/R Mapping）：簡稱ORM，大多數應用中的數據都是依據關系模型存儲在關系數據庫中；而很多應用程序中的數據在開發或是運行時則是以對象的形式組織起來的。那么，對象/關系映射就提供了這樣一種工具或是平臺，能夠幫助將應用程序中的數據轉換成關系數據庫中的記錄；或是將關系數據庫中的記錄轉換成應用程序中代碼便于操作的對象

工廠模式在數據訪問層的應用

首先定義一個操縱數據庫的接口DataAccess，然后工具數據庫的不同，由類工廠實例化對應的類

因為DataAccess的具體實現類有一些共同的方法，所以先從DataAccess實現一個抽象的AbstracDataAccess類，包含一些公用方法。然后分別為SQL Server、Oracle和OleDb數據庫編寫三個數據訪問的具體實現

選擇已完成了所要的功能，下面需要創建一個Factory類，來實現自動數據庫切換的管理。這個類很簡單，主要功能就是根據數據庫類型，返回適當的數據庫操作類

事務處理設計

JavaBean中使用JDBC方式進行事務處理：在JDBC中，打開一個連接對象Connecton時，默認是auto-commit模式，每個SQL語句被當作一個事務，即每次執行一個語句，都會自動地得到事務確認。為了能夠將多個SQL語句組合成一個事務，要將auto-commit模式屏蔽掉。在auto-commit模式屏蔽之后，如果不調用commit()方法，SQL語句不會得到事務確認。在最近一次commit()方法調用之后所有SQL會在方法commit()調用時得到確認

連接對象的管理設計

通過資源池解決資源頻繁分配、釋放造成的問題

建立連接池的第一步，就是建立一個靜態的連接池。所謂靜態，是指池中的連接是在系統初始化時就分配號的，并且不能夠隨意關閉。Java中給我們提供了很多容器類，可以方便地用來構建連接池，如Vector、Stack等。在系統初始化時，根據配置創建連接并放置在連接池中，以后所使用的連接都是從該連接池中獲取的，這樣就可以避免連接隨意建立、關閉造成的開銷

有了這個連接池，下面就可以提供一套自定義的分配、釋放資源策略。當客戶請求數據庫連接時，首先看連接池中是否有未分配出去的連接。如果存在空閑連接則把連接分配給客戶，并標記連接已分配。若連接池中沒有空閑連接，就在已分配出去的連接中，尋找一個合適的連接給客戶，此時該連接在多個客戶間復用

當客戶釋放數據庫連接時，可以根據該連接是否被復用，進行不同的處理。如果連接沒有使用者，就放入到連接池中，而不是被關閉

數據架構的規劃與設計（數據層）

數據庫設計與XML設計融合

XML文檔分為兩類：一類是以數據為中心的文檔，這種文檔的結構上是規則的，在內容上是同構的，具有較小的混合內容和嵌套層次，人們只關心文檔中的數據而并不關心數據元素的存放順序，這種文檔簡稱為數據文檔，它常用來存儲和傳輸Web數據。另一類是以文檔為中心的文檔，這種文檔的結構不規則，內容比較零散，具有較多的混合內容，并且元素之間的順序是有關的，這種文檔常用來在網頁上發布描述信息、產品性能介紹和E-mail信息等

經提出的XML文檔的存儲方式有兩種：基于文件的存儲方式和數據庫存儲方式

1. 基于文件的存儲方式：基于文件存儲方式是指將XML文件按其原始文本形式存儲，主要存儲技術包括操作系統文件庫、通用文檔管理系統和傳統數據庫的列。這種存儲方式需維護某種類型的附加索引，以建立文件之間的層次結構。

   特點：無法獲取XML文檔中的結構化數據；通過附加索引可以定位具有某些關鍵字的XML文檔，一旦關鍵字不確定，將很難定位；查詢時只能以原始文檔的形式返回，即不能獲取文檔內部信息；文件管理存在容量大、管理難的缺點

2. 數據庫存儲方式：數據庫在數據管理方面具有管理方便、存儲占用空間小、檢索速度快、修改效率高和安全性號等優點。一種比較自然的想法是采用數據庫對XML文檔進行存錢操作，這樣可以利用相對成熟的數據庫技術處理XML文檔內部的數據。

   特點：能夠管理結構化和半結構化數據；具有管理和控制整個文檔集合本身的能力；可以對文檔內部的數據進行操作；具有數據庫技術的特性，如多用戶、并發控制和一致性約束等；管理方便，易于操作

物聯網層次架構設計

物聯網可以分三個層次，底層是用來感知數據的感知層，即利用傳感器、二維碼、RFID等設備隨時隨地的獲取物體的信息。第二層是數據傳輸處理的網絡層，即通過各種傳感網絡與互聯網的融合，將對象當前的信息實時準確的傳遞出去。第三層則是與行業需求結合的應用層，即通過智能計算、云計算等將對象進行智能化控制

感知層

用于識別物體、采集信息。感知層包括二維碼標簽和識讀器、RFID標簽和讀寫器、攝像頭、GPS、傳感器、M2M終端、傳感器網關等，主要功能是識別對象、采集信息，與人體結構中皮膚和五官作用類型。感知層解決的是人類世界和物理世界的數據獲取問題

網絡層

用于傳遞信息和處理信息。網絡層包括通信網絡與互聯網的融合網絡、網絡管理中心、信息中心和智能處理中心等。網絡層將感知層獲取的信息進行傳遞和處理，類似于人體結構中的神經中樞和大腦。網絡層解決的是傳輸和預處理感知層所獲取數據的問題

應用層

實現廣泛智能化，應用層是物聯網于行業專業技術的速度融合，結合行業需求實現行業智能化，這類似于人們的社會分工，物聯網應用層利用結果分析處理的感知數據，為用戶提供豐富的特定服務。應用層解決的是信息處理和人機交互的問題

層次式架構案例分析

電子商務網站

PetShop 2.0（圖13-16）中可以看到，并沒有明顯數據訪問層設計。這樣的設計雖然提高了數據訪問的性能，但也同時導致了業務邏輯層于數據訪問層的職責混亂

PetShop 3.0（圖13-15） 糾正了此前層次不明的問題，將數據訪問邏輯作為單獨的一層獨立出來

PetShop 4.0 （無圖）基本延續了3.0的結構，但在性能上作了一定的改進，引入了緩存和異步處理機制，同時又充分利用了ASP.NET 2.0新功能MemberShip

可以看到（圖13-19），在數據訪問層中，完全采用了“面向接口編程”思想。抽象出來的IDAL模塊，脫離了與具體數據庫的依賴，從而使得整個數據訪問層有利于數據庫遷移。DALFactory模塊專門管理DAL對象的創建，便于業務邏輯層訪問。SQLServerDAL和OracleDAL模塊均實現IDAL模塊的接口，其中包含的邏輯就是對數據庫的Select、Insert、Update、Delete操作。因為數據庫類型的不同，對數據庫的操作也有所不同，代碼也因此有所區別

此外，抽象出來的IDAL模塊，除了解除了向下的依賴之外，對于其上的業務邏輯層同樣僅存在弱依賴關系，如圖13-20

圖13-20中，BLL是業務邏輯層的核心模塊，它包含了整個系統的核心業務。在業務邏輯層中，不能直接訪問數據庫，而必須通過數據訪問層。注意，13-20中對數據訪問業務的調用是通過接口模塊IDAL來完成的。與具體的數據訪問邏輯無關，則層與層之間的關系是松散耦合的。如果此時需要修改數據訪問層的實現，只要不涉及IDAL的接口定義，那么業務邏輯層就不會受到任何影響。畢竟，具體實現的SQLServerDAL和OracalDAL根本就與業務邏輯層沒有半點關系

基于物聯網架構的小票系統

云原生架構設計

架構內涵

云原生架構是基于云原生技術的一組架構原則和設計模式的集合，旨在將云應用中的非業務代碼部分進行最大化的剝離，從而讓云設施接管應用中原有的大量非功能性（如彈性、韌性、安全、可觀測性、灰度等），使業務不再有非功能性業務中斷困擾的同時，具備輕量、敏捷、高度自動化的特點

云原生的代碼通常包括三部分：業務代碼、三方軟件、處理非功能特性的代碼。從業務代碼中剝離大量非功能性特性（不會是所有，比如易用性還不能剝離）到IasS和PaaS中

具備云原生架構的應用可以最大程度利用云服務和提升軟件交付能力，進一步加快軟件開發。其特點包括：代碼結構發生巨大變化、非功能性特性大量委托、高度自動化的軟件交付

架構原則

原則	說明
服務化原則	拆分為微服務架構、小服務架構，分別迭代
彈性原則	系統的不是規模可以隨著業務量的變化而自動伸縮
可觀測原則	通過日志、鏈路跟蹤和度量等手段
韌性原則	當軟件所依賴的軟硬件組件出現各種異常時，軟件表現出來的抵御能力
所有過程自動化原則	一方面標準化企業內部軟件交付過程，另一方面在標準化的基礎上進行自動化，通過配置數據自描述和面向終態的交付過程
零信任原則	默認情況下不應該信任網絡內部和外部是任何人/設備/系統，需要基于認證和授權重構訪問控制的信任基礎，以身份為中心
架構持續演進原則	云原生架構本身也必須是一個具備持續演進能力的架構

主要架構模式

架構	說明
服務化架構模式	典型模式是微服務和小服務模式。通過服務化架構，把代碼模塊關系和部署關系進行分離，每個接口可以部署不同數量的實例，單獨擴縮容，從而使得整體的部署更經濟
Mesh化架構模式	把中間件框架（如RPC、緩存、異步消息等）從業務進程中分離，讓中間件SDK與業務代碼進一步解耦，從而使得中間件升級對業務進程沒有影響。分離后在業務進程中保留很”薄“的Client部分
Serverless模式	將”部署“這個動作從運維中”收走“，使開發者不用關心應用運行地點、操作系統、網絡配置、CPU性能等，也就是把應用的整個運行都委托給云
存儲計算分離模式	在云環境中，推薦把各類暫態數據（如session）、結構化和非結構化持久數據都采用云服務來保存，從而實現存儲計算分離
分布式事務模式	大顆粒度的業務需要訪問多個微服務，必然帶來分布式事務問題，否則數據就會出現不一致。架構師需要根據不同的場景選擇合適的分布式事務模式
可觀測架構	可觀測架構包括Logging、Tracing、Metrics三個方面，其中Logging提供多個級別的詳細信息跟蹤，由應用開發者主動提供；Tracing提供一個請求從前端到后端的完整調用鏈路跟蹤，對于分布式場景尤其有用；Mestrics則提供對系統量化的多維度量
事件驅動架構	本質上是一種應用/組件間的集成架構模式。可用于服務解耦、增強服務韌性、數據變化通知等場景中

相關技術

容器技術

容器作為標準化軟件單元，它將應用及其所有依賴項打包，使應用不再受環境限制，在不同計算環境間快速、可靠的運行

容器技術，企業可以充分發揮云計算彈性優勢，降低運維成本

Kubernetes已經成為容器編排的事實標準，被廣泛用于自動部署，擴展和管理容器化應用。

Kubernetes提供了分布式應用管理的核心能力，包括：資源調度、應用部署與管理、自動修復、服務發現于負載均衡、彈性伸縮、聲明式API、可擴展性架構、可移植性

云原生微服務

微服務模式將后端單體應用拆分為松耦合的多個子應用，每個子應用負責一組子功能。這些子應用稱為”微服務“，多個”微服務“共同形成了一個物理獨立但邏輯完整的分布式微服務體系。這些微服務相對獨立，通過解耦語法、測試于部署流程，提高整體迭代效率

微服務設計約束

1. 微服務個體約束：功能在業務域劃分上應是相互獨立的，低耦合、單一職責
2. 微服務于微服務之間的橫向關系：主要從服務的可發現性和可交互性處理服務間的橫向關系，一般需要服務注冊中心
3. 微服務于數據層之間的縱向關系：在微服務領域，提供數據存儲隔離原則，即數據是微服務的私有資產，對于數據的訪問都必須通過當前微服務提供的API來訪問
4. 全局視角下的微服務分布式約束：故障發現時效性和根因精確性始終是開發運維人員的核心訴求

主要微服務技術

技術	說明
Apache Dubbo	源于阿里巴巴的一款開源高性能RPC框架，特性包括基于透明接口的RPC、智能負載均衡、自動服務注冊和發現、可擴展性高、運行時流量路由于可視化的服務治理
Spring Cloud	作為開發者的主要微服務選擇之一，為開發者提供了分布式系統需要的配置管理、服務發現、斷路器、智能路由、微代理、控制總線、一次性Token、全局鎖、決策競選、分布式會話于集群狀態管理等能力和開發工具
Eclipse MicroProfile	作為Java微服務開發的基礎編程模型，它致力于定義企業Java微服務規范，MicroProfile提供指標、API文檔、運行狀況檢查、容錯于分布式跟蹤等能力，使用它創建的云原生微服務開源自由地部署在任何地方，包括服務網絡架構
Tars	是騰訊將其內部使用的微服務框架，包括一整套開發框架于管理平臺，兼顧多語言、易用性、高性能于服務治理，理念是讓開發更聚焦業務邏輯，讓運維更高效
SOFStack	是由螞蟻金服開源的一套用于快速構建金融級分布式架構的中間件，也是在金融場景里的最佳實踐
DAPR	分布式運行時是微軟推出的一種可移植性、無服務的、事件驅動的運行時，它使開發人員開源輕松構建彈性，無狀態和有狀態微服務，這些服務運行在云和邊緣上，并包含多種語言和開發框架

無服務器技術（Serverless）

因為屏蔽了服務器和各種運維復雜度，讓開發人員開源將更多精力用于業務邏輯設計與實現，而逐漸成為云原生主流技術之一。

Serverless計算包含以下特征

1. 全托管的計算服務：客戶只需要編寫代碼構建應用，無需關注同質化的、負擔繁重的基于服務器等基礎設施的開發、運維、安全、高可用等工作
2. 通用性：結合BaaSAPI的能力，能夠支撐云上所有重要類型的應用
3. 自動彈性伸縮：讓用戶無需為資源使用提前進行容量規劃
4. 按量計費：讓企業使用成本得有效降低，無需為閑置資源付費

函數計算（FaaS）是Serverless中最具代表性的產品形態。通過把應用邏輯拆分多個函數，每個函數都通過事件驅動的方式觸發執行

無服務器技術關注點（云廠商關注的）：計算資源彈性調度、負載均衡和流控、安全性

服務網格（ServiceMesh）

服務網格（ServiceMesh）是分布式應用在微服務軟件架構之上發展起來的新技術，指在將那些微服務間的連接、安全、流量控制和可觀測等通用功能下沉為平臺基礎設施，實現應用于平臺基礎設置的解耦。這個解耦意味著開發者無需關注微服務相關治理問題而聚焦于業務邏輯本身，提升應用開發效率并加速業務探索和創新

在這架構圖中，服務A調用服務B的所有請求，都被其下服務代理截獲，代理服務A完成到服務B的服務發現、熔斷、限流等策略，而這些策略的總控是在控制平面（ControlPlane）上配置

云原生架構案例分析

某旅行公司云原生改造

面臨問題：公司主題由兩個公司合并，技術體系不同，需要整合為一體；節假日高并發流量

第一階段：某旅行技術團隊為了提高集群資源利用率，降低資源使用成本。利用云原生思維重構部分技術體系，將多套舊有系統合并、收攏到一套云原生應用為核心的私有云平臺上，同時將IDC、物理網絡、虛擬網絡、技術資源、存儲資源等通過IaaS、PaaS等，實現虛擬化封裝、切割、再投產的自動化流程

隨著服務器集群規模擴大，部分機器開始頻繁出現故障。此時，保障服務穩定性成了第二階段改造的首要任務

第二階段：基于公有云、私有云的離線專屬云集群等新型動態計算環境，某旅行公司的技術團隊幫助業務構建和運行具有彈性的云原生應用，促進業務團隊開始使用聲明式API，同時通過不可變基礎設施、服務網格和容器服務，來構建容錯性號、易于管理和觀察的應用系統，并結合平臺可靠的自動化恢復、彈性計算來完成整個服務穩定性的提升

第三階段：通過基礎組件、服務的云原生改造、服務依賴梳理和定義等方式，使用應用不再需要考慮底層資源、機房、運行時間和供應商等因素。此外，還利用標準的云原生應用模型，實現了服務的跨地域、跨自動化災備、自動部署、并向云原生場景下的DevOps演進

架構如如下：

某汽車公司數字化轉型

戰略性容器云平臺：通過平臺實現對某App、二手車、在線支付、優惠券等核心互聯網應用承載。以多租戶的形式提供彈性計算、數據持久化、應用發布等面向敏捷業務服務，并實現高水平資源隔離。標準化交付部署，快速實現業務擴展，滿足彈性要求。

數字混合云交付：采用私有云+公有云的混合交付模式，按照服務的敏態/穩態特性和管控要求劃分部署，靈活調度公有云資源來滿足臨時突發或短期高TPS業務支撐的需求

深度融合微服務治理體系：實現架構的革新和能力沉淀，逐步形成支撐數字化應用的業務中臺

某快遞公司核心業務系統云原生改造

某快遞公司核心業務系統原架構基于Vmware+Oracle數據庫進行搭建。隨著搬遷上阿里云，架構全面轉型為基于 Kubernetes的云原生架構體系

通過引入云原生數據庫、應用容器化、微服務改造技術，得到如下云架構：

基礎設施：全部計算資源取自阿里云的神龍服務器

流量接入：阿里云提供兩套流量接入，一套是面向公網請求，另一套是服務內部調用

基于Kubernetes打造的云原生PaaS平臺明顯突出，每個應用都再Kubernetes上創建單獨的一個Namespace，應用于應用之間實現資源隔離

現實Kubernetes集群采用阿里云托管版容器服務，免去了運維Master節點的工作，只需要定制Worker節點上線及下線流程即可

某電商業務云原生改造

• 通過容器化部署，利用阿里云容器服務的快速彈性應對大促時的資源快速擴容

• 提前接入鏈路跟蹤產品，用于對分布式下復雜服務調用進行跟蹤，對異常服務進行定位，幫助客戶再測試和生產中快速定位問題并修復，降低對業務的影響

• 使用阿里云性能測試服務（PTS）進行壓測，利用秒級流量拉起、真實地理位置流量等功能，以最真實的互聯網流量進行壓測，確保業務上線后穩定運營

• 采集壓測數據，解析系統強弱依賴關系，關鍵瓶頸點，對關鍵業務接口、關鍵第三方調用、數據庫慢調用、系統整體負載等進行限流保護

• 配合阿里云服務團隊，在大促前進行ECS/RDS/安全等產品擴容、鏈路跟蹤、緩存/連接池預熱、監控大屏制作、后端資源保障演練等，幫助大促平穩進行

面向服務架構設計

SOA概述

在面向服務的體系結構（SOA）中，服務的概念有了延伸，泛指系統對外提供的功能集

從應用的角度定義，可以認為SOA是一種應用框架，它著眼于日常的業務應用，并將它們劃分為單獨的業務功能和流程，即所謂的服務。SOA使用戶可以構建、部署和整合這些服務，且無需依賴應用程序及其運行平臺，從而提高業務流程的靈活性

從軟件的基本原理定義，可以認為SOA設施一個組件模型，它將應用程序的不同功能單元（稱為服務）通過這些服務之間定義良好的接口和契約聯系起來。接口是采用中立的方式進行定義的，它應該獨立于實現服務的硬件平臺、操作系統和編程語言

業務流程是指為了實現某種業務目的行為所進行的流程或一系列動作

BPEL：面向Web服務的業務流程執行語言，是一種使用Web服務定義的執行業務流程的語言。使用BPEL，用戶可以通過結合、編排和協調Web服務自上而下地實現面向服務的體系結構。BPEL目前用于整合現有的Web Service，將現有的Web Services按照要求的業務流程整理成一個新的Web Services，在這個基礎上，形成一個外界看來和單個Service一樣的Service

SOA的微服務化發展

SOA架構向更細顆粒度、更通用化程序發展，就成了所謂的微服務了

SOA與微服務區別如下

1. 微服務相比SOA更加精細，微服務更多地以獨立的進程的方式存在，相互之間并無影響
2. 微服務提高了接口方式更加通用化，例如HTTP RESTful方式，各種終端都可以調用，無關語言、平臺限制
3. 微服務更傾向于分布式去中心化的部署方式，在互聯網業務場景下更適合

SOA架構是一個面向服務的架構，可將視為組件模型，其將系統整體拆分為多個獨立的功能模型，模塊之間通過調用接口進行交互，有效整合了應用系統的各項業務功能，系統各個模塊之間是松耦合的。SOA架構以企業服務總線鏈接各個子系統，是集中式的技術架構，應用服務之間相互依賴導致部署復雜，應用之間交互使用遠程通信，降低了響應速度

微服務架構是SOA的進一步優化，去除了ESB企業服務總線，是一個真正意義上去中心化的分布式架構。其降低了微服務之間的耦合程度，不同的微服務采用不同的數據庫技術，服務獨立，數據源唯一，應用極易擴展和維護，同時降低了系統復雜性

SOA參考架構

典型的以服務為中心的企業集成架構如下圖所示，采用”關注點分離“的方法規劃企業集中的各種架構元素，同時從服務視角規劃每種架構元素提供的服務，以及服務如何被組合在一起完成某種類型的集成，可分為六大類

1. 開發服務（Development Services）：貫徹整個軟件開發生命周期的開發平臺
2. 業務創新和優化服務（Business Innovation and Optimization Services）：用于監控業務系統運行時服務的業務性能，采取適應變化的市場
3. 控制服務（Control Service）：包括實現人、流程和信息集成的服務，以執行這些集成邏輯的能力
4. 連接服務（Connectivity Services）：通過提供企業服務總線提供分布在各種架構元素中服務間的連接性
5. 業務邏輯服務（Business Logic Service）：包括用于實現業務邏輯的服務和執行業務邏輯的能力
6. IT服務管理（IT Services Management）：支持業務系統運行的各種基礎設施管理能力或服務

開發服務

開發環境和根據中為不同開發者的角色提供的功能被稱為開發服務。

根據開發過程中開發者和職責不同，有如下4類服務：建模服務、設計服務、實現服務、測試服務

業務創新和優化服務

以業務性能管理（BPM）技術為核心提供業務事件發布、收集和關鍵業務指標監控能力。

包括以下服務

1. 公共事件框架服務：通過一個公共事件框架提供IT和業務事件的激發、存儲和分類等
2. 采集服務：通過基于策略的過濾和相關性分析檢測感興趣的服務
3. 監控服務：通過事件于監控上下文的映射，計算和管理業務流程的關鍵性能指標

控制服務

• 數據整合（信息服務）：提供集成數據的能力。

  目前主要包括如下集中信息服務：聯邦服務（不同類型數據聚合）、復制服務（遠程數據本地訪問）、轉換服務（格式轉換）、搜索服務

• 流程整合（流程服務）：完成業務流程集成。

  包括：編排服務（預定義流程順序）、事務服務（保證ACID）、人工服務（人工活動集成到流程中）

• 數據訪問整合（交互服務）：實現用戶訪問集成

  包括：交付服務（運行時交互框架）、體驗服務、資源服務（運行時交互組件的管理）

連接服務

連接服務由稱為企業服務總線ESB，基本特征如下

• 描述服務的元數據和服務注冊管理
• 在服務請求者和提供者之間傳遞數據，以及對這些數據進行轉換的能力，并支持由實踐中總結出來的一些模式如同步模式、異步模式等
• 發現、路由、匹配和選擇的能力，以支持服務之間的動態交互，解耦服務請求者和服務提供者
• 高級一些的能力，包括對安全的支持、服務質量保證、可管理型和負載平衡等

業務邏輯服務

• 整合已有應用（應用和信息服務服務）：實現對已有應用和信息的集成。

  主要有兩類服務服務，包括：可接入服務、事件發現服務

• 整合新開發的應用（業務應用服務）：實現新應用集成，主要有三類業務應用服務

  包括：組件服務（可重用）、核心服務（運行時）、接口服務

• 整合客戶和業務伙伴（伙伴服務）：提供于企業外部的B2B的集成能力

  包括：社區服務、文檔服務、協議服務

IT服務管理

為業務流程和服務提供安全、高效和健康的運行環境

包括：安全和目錄服務、系統管理和虛擬化服務

SOA主要協議和規范

Web服務最基本協議包括UDDI、WSDL和SOAP，通過它們，可以提供直接而又簡單的Web Service支持如圖

UDDI（統一描述、發現和集成協議）：是一個廣泛的、開放的行業計劃。它使得商業實體能夠彼此發現；定義它們怎樣在Internet上相互作用，并在一個全球的注冊體系架構中共享信息

WSDL（Web 服務描述語言）：是一個用來描述Web服務和說明如何與Web服務通信的XML語言。

可描述三個基本屬性：服務做什么、如何訪問服務、服務位于何處

SOAP：在分散或分布式的環境中交換信息和簡單的協議，是一個基于XML的協議。

它包括4個部分：SOAP封裝，定義了一個描述消息中的內容是說明，是誰發送的，誰應當接收并處理它以及如何處理它們的框架；SOAP編碼規則，用于表示應用程序需要使用的數據類型和實例；SOAP RPC表示遠程過程調用和應答協定；SOAP綁定是使用底層協議交換信息

SOA的設計標準和原則

SOA設計標準要求

• 文檔標準化：XML文檔，Web描述語言

• 通信協議標準：用消息進行通信，消息使用XML Schema來定義

• 應用程序統一登記與集成：通過扮演目錄列表角色的登記處來維護，UDDI是標準

• 服務質量（Qos）：每項SOA服務都有一個與之相關的服務質量。Qos的一些關鍵元素有安全需求（例如認證和授權）、可靠通信以及誰能調用服務的策略。

  其服務和標準包括：

  • 可靠性：”僅且僅僅傳送一次“、”最多傳送一次“、”重復消息過濾“ 和 ”保證消息傳送“等特性消息的發送和確認
  • 安全性：主要包括認證交換、消息完整性和消息保密
  • 策略：服務提供者有時候會要求服務消費者與某種策略通信
  • 控制：在SOA中，進程使用一組離散的服務創建的，BPEL4WS或者WSBPEL是用來控制這些服務的語言
  • 管理：讓系統管理員管理所有，運行在多環境下的服務和管理系統

SOA設計原則

原則	說明
無狀態	以避免請求者依賴于服務提供者的狀態
單一實例	避免功能冗余
明確定義的接口	使用者依賴服務規約調用服務，所以服務定義必須長時間穩定，一旦公布，不能隨意更改；服務定義盡可能明確，減少使用者的不適當使用；不要讓使用者看到服務內部私有數據
自包含和模塊化	服務封裝了那些在業務上穩定、重復出現的活動和組件，實現服務的功能實體是完全獨立自主的，獨立進行部署、版本控制、自我管理和恢復
粗粒度	服務數量不應該太大，依靠消息交互而不是遠程過程調用（RPC），通常消息量比較大，但是服務之間的交互頻度較低
服務之間的耦合性	服務使用者看到的是服務的接口，其位置、實現技術和當前狀態等對使用者是不可見的，服務私有數據對服務使用者是不可見的
重用能力	服務應該是可以重用的
互操作性、兼容和策略聲明	為了確保服務規約的全面和明確，策略成為一個越來越重要的方面。這可以是技術相關的內容，例如一個服務對安全性方面的要求；也可以是跟業務有關的語義方面的內容，例如需要滿足的費用或者服務級別方面的要求，這些策略對于服務交互時是非常重要的

SOA的設計模式

服務注冊表模式

1. 服務注冊：應用開發者，也叫服務提供者，向注冊表公布它們的功能
2. 服務位置：也就是服務應用開發者，幫助它們查詢注冊服務，尋找符合自身要求的服務
3. 服務綁定：服務的消費者利用檢索到的服務合同來開發代碼，開發的代碼將于注冊的服務綁定、調用注冊的服務以及于它們實現互動

企業服務總線模式

由中間件技術實現的支持面向服務架構的基礎軟件平臺，支持異構環境中的服務以基于消息和事件驅動模式的交互，并且具有適當的服務質量和可管理性

一個典型的ESB環境中組件之間的交互過程是：首先由服務請求者觸發一個交互過程，產生一個服務請求消息，并將該消息按照ESB的要求標準化，然后標準化的消息被發送給服務總線。ESB根據請求消息中的服務名或者接口名進行目的組件查找，將消息轉發至目的組件，并最終將處理結果逆向返回給服務請求者。這種交互過程不再是點對點的直接交互模式，而是由事件驅動的消息交互模式。

ESB的核心功能如下：

1. 提供透明性的消息路由和尋址服務
2. 提供服務注冊和命名的管理功能
3. 支持多種消息傳遞泛型（如請求/響應、發布/訂閱等）
4. 支持多種可以廣泛使用的傳輸協議
5. 支持多種數據格式及其相互轉換
6. 提供日志和監控功能

微服務模式

微服務模式不再強調傳統SOA架構里面比較重的ESB（企業服務總線），同時SOA的思想接入到單個業務系統內部實現真正組件化

微服務模式特點：復雜應用解耦、獨立、技術選型靈活、容錯、松耦合易擴展

常見的微服務設計模式：

1. 聚合器微服務：聚合器調用多個微服務實現系統應用程序所需要功能，具體有兩種形式，一種是將檢索到的數據信息進行處理并直接展示；另外一種是對獲取數據信息業務增加業務邏輯處理后，再進一步發布成一個新的微服務作為一個更高層次的組合微服務，相當于從服務消費者轉換成服務提供者
2. 鏈式微服務：客戶端或服務在收到請求后，會返回一個經過合并處理的響應，服務之間形成一條調用鏈
3. 數據共享微服務：當服務之間存在強耦合關系時，可能存在多個微服務共享緩存于數據庫存儲的現象
4. 異步消息傳遞微服務：消息隊列將消息寫入一個消息隊列重，實現業務邏輯以異步方式運行，從而加快系統響應速度

微服務架構的問題與挑戰：微服務架構分布式特點帶來的復雜性；微服務架構的分區數據庫體系，不同服務擁有不同數據庫；增加了測試的復雜性；在大規模應用部署重，在監控、管理、分發及擴容等方面，微服務也存在著巨大挑戰

SOA的構建和實施

構建注意問題

1. 原有系統架構重的集成需求：當SOA架構師遇到一個十分復雜的企業系統時，首先考慮的應該是如何重用已有的投資而部署替換遺留系統。集成類型包括應用集成的需求，終端用戶界面集成的需求，流程集成的需求以及已有系統信息集成的需求
2. 服務粒度的控制以及無狀態服務的設計：SOA系統中服務的構建有兩點需要特別注意的地方；首先是對于服務顆粒度的控制，另外就是對于無狀態服務的設計

實施過程

從以下三個方面選擇SOA最佳的解決方案：盡量選擇進行全局規劃的方案、選擇是充分考慮企業自身的需求、從平臺實施等技術方面進行考察

業務流程分析過程

1. 獎勵服務模型
   • 自頂向下分解法：從業務著手進行分析，選擇端到端的業務流程進行逐層分解至業務活動
   • 業務目標分析法：通過關鍵性能指標分析來驗證已有服務候選者以及發現遺漏的服務候選者
   • 自底向上分析法：利用已有資產來實現服務
2. 建立業務流程
   • 建立業務對象：業務對象是對數據進行檢索和處理的組件，是簡單的真實世界的軟件抽象
   • 建立服務接口
   • 建立業務流程：流程是指定的活動順序，包含明確確定的用于提供業務值的輸入和輸出

嵌入式系統架構設計

典型架構

嵌入式系統的典型架構可以概括為兩種模式，即層次化模式架構和遞歸模式架構

層次化模式架構

位于高層的抽象概念與底層的更加具體的概念之間存在著依賴關系，主要思想如下：

1. 當一個系統存在高層次的抽象，這些抽象的表現是一個個的抽象概念，而這些抽象概念需要具體的底層概念進行實現時，就可采用層次化模式。
2. 分層模式結構只包含了一個主要的元素（域包）和它的接口，以及用來說明模式結構的約束條件
3. 層次化模式可以分兩種：封閉型和開放型。
   1. 封閉型：一層中的對象只能調用同一層或下層的對象提供的方法
   2. 開放型：一層中的對象可以調用同一層或低于該層的任意一層的對象提供的方法

遞歸模式架構

遞歸模式解決的問題是，需要將一個非常復雜的系統進行分解，而且還有確保分解過程是可擴展的，即只要有必要，該分解過程就可以持續下去

在創建這種模式實例時，通常使用兩種相反的工作流程

1. 自頂向下：自頂向下的工作流從系統層級開始并標識結構對象，這些對象提供實現協作的服務。在實時系統和嵌入式系統種，大多數情況下是基于某個標準方法，將系統分成一個個子系統。當開發人員逐步降低抽象層級，向下推進時，容易確保開發者的工作沒有偏離用例種的所規定的需求。
2. 自底向上：自底向上專注于域的構造–首先確定域中的關鍵類和關系。這種方法之所以可行是因為開發者以往有豐富的開發經驗，并能將其他領域獲得的知識映射到當前開發所在的域中。通過這種方法，最終開發者會到達子系統級的抽象。

嵌入式操作系統（EOS）

嵌入式操作系統是指嵌入式系統的操作系統。通常包括與硬件相關的底層驅動軟件、系統內核、設備驅動接口、通信協議、圖形界面、標準化瀏覽器等。

嵌入式操作系統特點：可裁剪性、可移植性、強實時性、強緊湊性、高質量代碼、強定制性、標準接口、強穩定性、弱交互性、強確定性、操作簡潔方便、較強的硬件適應性、可固化性。

從嵌入式操作系統體系架構看，主要存在4種架構：整體結構、層次結構、客戶/服務器結構和面向對象結構。

整體結構也稱為模塊結構或無序結構，它是基于結構化程序設計的一種軟件設計方法，其架構如下圖：

內核

內核是操作系統的核心部分，它管理著系統的各種資源。內核可以看成連接應用程序和硬件的一座橋梁，是直接運行在硬件上的最基礎的軟件實體。目前從內核架構來劃分，可分為宏內核（即單體內核）和微內核。

任務管理

任務管理是嵌入式操作系統最基本功能之一，這里的任務（task）是指嵌入式操作系統調度的最小單位，類似于一般操作系統進程或線程的概念

任務協同

操作系統任務之間一般存在以下關系：相互獨立、競爭、同步、通信。要實現多任務間的協同工作，操作系統必須提供任務間的通信手段。

通常通信方式包括：

方式	說明
共享內存	數據的簡單共享。多任務訪問同一地址空間
信號量	基本的互斥和同步。最優，是現操作系統主要手段，任務間最快速通信
消息隊列	同一CPU內多任務間消息傳遞。類似于緩沖區的對象，像一個管道接收發送者消息等待接收者讀取。
Socket和遠程調用	任務間透明的網絡通信，不同計算機之間通信。
Signal（信號）	用于異常處理。通知進程發生了異步事件，是對中斷機制的一種模擬。

實時系統

在實時系統的任務調度中，存在大量的實時調度方法，大致可以概述為主要三種劃分，即離線和在線調度（在運行前還是運行時獲得調度信息）、搶占和非搶占調度（能否打斷正在運行的任務）、靜態和動態調度（在設計時還是運行時確定任務優先級）等。

典型的強實時調度算法

算法	邏輯
最早截至時間優先（Earliest Deadline First，EDF）算法	根據任務的開始截至時間來確定任務的優先級，截止時間越早，其優先級越高
最低松弛度優先（Least Laxity First，LLF）算法	根據任務緊急（或松弛）的程度，來確定任務的優先級。任務的緊急程度越高，該任務被賦予的優先級越高，以使之優先執行。松弛度（又叫富裕度）即進程的富裕時間。
單調速率調度算法（Rate Monotonic Scheduling，RMS）算法	是一種靜態優先級調度算法，是經典的周期性任務調度算法。RMS的基本思想是任務的優先級于它的周期表現為單調函數的關系，任務的周期越短，優先級越高；任務周期越長，優先級越低。

嵌入式數據庫系統

與傳統數據庫相比，嵌入式數據庫系統有以下幾個主要特點：嵌入式、實時性、移動性、伸縮性。

嵌入式操作系統按存儲位置的不同分為三類：基于內存方式、基于文件方式、基于網絡方式。

基于內存的數據庫系統（MMDB）

基于內存的數據庫系統是實時系統和數據庫系統的有機結合。內存數據庫是支持實時事務的最佳技術，其本質特征是以其“主拷貝0”或”工作版本“常駐內存，即活動事務只與實時內存數據庫的內存拷貝打交道。

典型產品是eXtremeDB數據庫。主要特點如下：

• 最小化持持久數據所必需的資源（對內存資源消耗減到最小）
• 保存極小的必要堆空間（某些配置上eXtremeDB只需要不到1KB的堆空間）
• 維持極小的代碼體積
• 通過緊密的集成持久存儲和宿主應用程序語言消除額外的代碼層
• 提供對動態數據結構的本地支持（如變長字符串、鏈表和樹）

基于文件的數據庫（FDB）

基于文件的數據庫（FDB）系統就是以文件方式存儲數據庫數據，即數據按照一定格式存儲在磁盤種。使用時由應用程序通過相應的驅動程序甚至直接對數據文件進行讀寫。

典型產品是SQLite。它是由公共接口、編譯系統、虛擬機和后端四個子系統組成，主要特點如下：

• 開源的、內存式的關系型數據庫
• 數據庫服務就在你的數據庫應用種，其好處不需要網絡配置和管理，也不需要通過設置數據源服務數據庫服務器
• 數據庫的服務與客戶端運行在同一進程中，減少網絡訪問的消耗，簡化數據庫管理，部署容易

基于網絡的數據庫（NDB）

基于網絡的數據庫（NDB）是基于手機4G/5G的移動通信基礎之上的數據庫系統，在邏輯上可以把嵌入式設備看作遠程服務器的一個客戶端。實際上，嵌入式網絡數據庫是把功能強大的遠程數據庫映射到本地數據庫，使嵌入式設備訪問遠程數據庫就像訪問本地數據庫一樣方便。嵌入式網絡數據庫主要由三部分組成：客戶端、通信協議和遠程服務器。

典型如 百度云相冊同步、各品牌手機廠商的云存儲空間

嵌入式數據庫

嵌入式數據庫架構

嵌入式數據庫不需要數據庫驅動程序，直接將數據庫的庫文件鏈接到應用程序中。應用程序通過API訪問數據庫，而不是TCP/IP。因此，嵌入式數據庫的部署是與應用程序在一起的

服務器數據庫架構

數據庫客戶端通常通過數據庫驅動程序如JDBC、ODBC等訪問數據庫服務器，數據庫服務器再操作數據文件。數據庫服務是一種客戶端服務器模式，客戶端和服務器是完全兩個獨立的進程。它們可以分別位于不同的計算機甚至網絡中。客戶端和服務器通過TCP/IP就像通信。這種模式將數據與應用程序分離，便于對數據訪問的控制和管理。

嵌入式數據庫有其自身的特殊需要，它應具備的功能包括以下4點：

1. 足夠高校的數據存儲機制
2. 數據安全控制（鎖機制）
3. 實時事務管理機制
4. 數據庫恢復機制（歷史數據存儲）

服務器數據庫和嵌入式數據庫對比

1. 數據庫服務器通常允許非開發人員對數據庫進行操作，而嵌入式數據庫中通常只允許應用程序對其進行訪問和控制
2. 數據庫服務器將數據與程序分離，便于對數據庫訪問的控制。而嵌入式數據庫則將數據的訪問控制完全交給應用程序，由應用程序來進行控制。
3. 數據庫服務器需要獨立的安裝、部署和管理，而嵌入式數據庫通常和應用程序一起發布，不需要單獨的部署一個數據庫服務器，具有程序便攜性的特點。

嵌入式數據庫的開發

嵌入式數據庫一般劃分為：數據庫運行處理、數據庫存取、數據管理、數據庫維護和數據庫定義等功能

在嵌入式環境下開發實時數據庫需要特別解決以下幾個設計問題：

1. 存儲空間管理模塊：嵌入式實時數據庫系統由于采用了內存緩存的技術，必然要設計嵌入式操作系統的內存管理。系統運行時，由該模塊通過實時OS像系統授權內存緩沖區，作為共享的內存數據區使用。之后，將歷史數據中的初始化數據調入內存區對這些空白內存進行初始化。
2. 數據安全性、完整性控制模塊
3. 事務并發控制模塊：在實時數據庫中的封鎖粒度通常選擇一張關系表為一個得。
4. 實時數據轉存儲模塊：該模塊實現的功能是將實時數據存儲為歷史數據，通常由該模塊先將歷史數據保存在內存緩沖區中，緩沖區滿時才一次性寫入磁盤；讀歷史數據時，先從緩沖區內取數據，取不到數據時進行文件的讀寫。
5. 運行日志管理模塊：日志文件可以用來進行事務故障恢復和系統故障恢復

嵌入式中間件

嵌入式中間件是在嵌入式系統處于嵌入式應用和操作系統之間層次的中間軟件，其主要作用是對嵌入式應用屏蔽底層操作系統的異構性，常見功能有網絡通信、內存管理和數據處理等

中間件=平臺+通信。中間件的特點：通用性、異構新、分布性、協議規范性、接口標準化。

具體到嵌入式中間件而言，它還應提供對下列環境支持：

1. 網絡化：支持移動、無線環境的分布應用，適應多種設備特性以及不斷變化的網絡環境
2. 支持媒體應用：適應不斷變化的訪問流量和帶寬約束
3. QoS質量品質：在分布式嵌入式實時環境下，適應強QoS的分布應用和軟硬件約束
4. 適應性：能夠適應未來確定的應用要求

通用中間件大致存在以下分類：

1. 企業服務總線中間件：ESB是一種開放的、基于標準的分布式同步/異步信息傳遞中間件
2. 事務處理監控器：為發生在對象間的事務處理提供監控功能，以保證操作成功
3. 分布式計算環境：指創建運行在不同平臺上的分布式應用程序所需的一組技術服務
4. 遠程過程調用：指客戶端向服務器發送關于運行某程序的請求時所需的標準
5. 對象請求代理：為用戶提供與其他分布式網絡環境中對象通信的接口
6. 數據庫服務中間件：支持用戶訪問各種操作系統或應用程序中的數據庫
7. 消息傳遞：電子郵件系統是該類中間件的其中之一
8. 基于XML的中間件：XML允許開發人員為實現Internet中交換結構化信息而創建文檔

嵌入式系統軟件架構設計方法

基于架構的軟件設計（ABSD）

基于架構的軟件設計（ABSD）方法是架構驅動，強調由業務、質量和功能需要的組合驅動架構設計。它強調采用視角和視圖來描述軟件架構，采用用例和質量屬性場景來描述需求。

ABSD模型把整個基于體系結構的軟件過程劃 分為體系結構需求、設計、文檔化、復審、實現和演化6個子 過程，如圖7-2所示。

1. 架構需要：重在掌握標識構建的三步驟，如圖7-3
2. 架構設計：將需求階段是標識構建映射成構件，進行分析，如圖7-4
3. 架構（體系結構）文檔化：主要產出兩種文檔，即架構（體系結構）規格說明，測試架構（體系結構）需求的質量設計說明書。文檔是至關重要的的，是所有人員通信的手段，關系開發的成敗。
4. 架構復審：由外部人員（獨立于開發組織之外的人，如用戶代表和領域專家等）參加復審，復審架構是否滿足需要，質量問題，構件劃分合理性等。若復審不通過，則返回架構設計階段進行重新設計、文檔化，再復審
5. 架構實現：用實體來顯示出架構。實現構件，構件組裝成系統，如圖7-5
6. 架構演化：對架構進行改變，按需求增刪構件，使架構可復用，如果7-6

屬性驅動的軟件設計（ADD）

屬性驅動的軟件設計（ADD）是把一組質量屬性場景作為輸入，利用對質量屬性實現于架構設計之間的關系了解（如體系結構風格、質量戰術等）對軟件架構進行設計的一種方法

采用ADD方法進行軟件開發時，需要經歷評審、選擇驅動因子、選擇系統元素、選擇設計概念、實體化元素和定義接口、草擬視圖和分析評價等七個階段，如圖所示：

步驟一：評審輸入。確保設計流程的輸入是可用且正確的。確認設計目的是符合設計的類型。如果是設計一個已有的系統，還需要分析已經存在的架構設計的輸入存在是否合理。

步驟二：通過選擇驅動因子（架構）建立迭代目標。根據適應的開發模型去選擇設計的回合。一個設計回合需要在一系列的設計迭代中進行，每一個迭代著重完成一個目標，特別是滿足驅動因子的目標。

步驟三：選擇一個或多個系統元素來細化。選取可滿足驅動因子需要的一個或者多個架構結構。

步驟四：選擇一個或者多個設計概念來細化。從常用的架構設計模式中選取一種或多種設計概念，對選中的驅動因子進行細化。

步驟五：實例化架構元素、分配職責和定義接口。選擇號了一個或者多個設計概念后，就要求做另一個設計決策了，包括所選擇的實例化元素的設計概念。比如，如果選擇分層，就需要決定分多少層。

步驟六：草擬視圖和記錄設計決策。將上述活動的結構用文字或圖的方式記錄或繪制出來。

步驟七：分析當前設計、評審迭代目標、實現設計目的。到本步驟，應該說已經創建號了部分設計，可以得到這個迭代設計建立的目標。在這個確定的目標前提下，可以得到項目利用相關的認同，避免否定，導致返工。

實時系統設計方法（DARTS）

實時系統設計方法（DARTS）主要是將實時系統分解多個并發任務，并定義這些任務之間的接口。提供一些分解規則和一套處理并發任務的設計步驟，還提供一套把實時系統建造成并發任務的標準和定義并發任務間接口的指南。

DARTS方法由以下5個部分組成

1. 用實時結構化分析方法（RTSA）開發規范：本階段要開發系統環境圖（SCD）和狀態轉換圖（STD）。
2. 將系統劃分為多個并發任務：任務結構化標準應用于數據流/控制流圖層次事件合中的葉子節點上。初步任務架構圖（TAD）可以顯示使用任務結構化標準確定的任務
3. 定義任務接口：通過分析在上一階段確認的任務間的數據/控制流接口可以定義任務間的接口。任務間的數據流被映射為松耦合的或緊密耦合的消息接口。事件流被映射為事件信號。數據存儲被映射為信息隱藏模塊。這個階段應該完成事件約束分析。
4. 設計每個任務：每個任務都代表一個順序程序的執行。在這個階段要定義各模塊的功能以及于其他模塊之間的接口。此外還要設計各個模塊的內部結構。
5. 設計過程成果：RTSA規范、任務結構規范（定義每個并發任務功能及接口）、任務分解（定義每個任務分解為模塊的過程以及模塊的功能接口詳細設計）。

實時結構化分析和設計方法（RTSAD）

RTSAD（實時結構化分析和設計方法）是DARTS方法的起源，是對傳統結構化分析和設計方法的補充擴展，專門用于開發實時系統。

實時結構化分析（RTSA）主要對傳統的結構化分析方法擴充了行為建模部分，它通過狀態轉換圖（STD）刻畫系統的行為特征，并利用控制轉換于數據流圖集成在一起。

實時結構化設計（RTSD）是利用內聚和耦合原則進行程序設計的一種方法，它通過任務和變化兩種策略將RTSA的分析結構DFD/CFD轉換為程序結構圖。

任務結構化標準可以為設計人員將實時系統分解為并發任務的時候提供幫助。這些標準是從設計并發系統所積累的經驗中得到的啟發。確定任務過程中主要考慮的問題是系統內部功能的并發特性。信息隱藏作為封裝數據存儲的標準來使用。信息隱藏模塊用于信息數據存儲和狀態轉換表的內容和表示。

RTSAD設計方法使用任務架構圖來顯示系統分解為并發任務的過程，以及采用信息、事件和信息隱藏模塊形式的任務間接口。

DARTS開發方法的主要優勢

• 強調把系統分解成并發的任務，并提供了確認這些任務的標準。
• 提供了詳細的定義任務間接口的指南。
• 強調了用任務架構圖（STD）的重要性，這在實時系統的設計中也非常重要。
• 提供了從RTSA規格到實時設計的轉換。

DARTS開發方法的不足

• 用結構化的設計方法把任務創建成了程序模塊，而并非完全用IHM來封裝數據存儲。
• 如果RTSA階段的工作沒作好，創建任務就非常困難

嵌入式 系統軟件架構案例分析

鴻蒙操作系統架構案例分析

鴻蒙（HarmonyOS）整體采用分層的層次化設計，從下向上依次為：內核層、系統服務層、框架層和應用層。

系統功能按照”系統“=>”子系統“=>”功能/模塊“逐級展開，在多設備部署場景下，支持根據實際需要裁剪某些非必要的子系統或功能/模塊。

1. 內核層：主要由內核子系統和驅動子系統組成

   內核子系統：HarmonyOS采用多內核設計，支持針對不同資源受限設備用合適的OS內核。內核抽象層通過屏蔽多內核差異，對上層提供基礎的內核能力。

   驅動子系統：提供統一外設訪問能力和驅動開發、管理框架。

2. 系統服務層：是HarmonyOS的核心能力集合，通過框架層對應程序提供服務。

   系統基本能力子系統集：為分布式應用在HarmonyOS多設備上的運行、調度、遷移等操作提供了基礎能力。

   基礎軟件服務子系統集：為HarmonyOS提供公共的、通用的軟件服務。

   增強軟件服務子系統集：為HarmonyOS提供針對不同設備的、差異化的能力增強型軟件服務。

   硬件服務子系統集：為HarmonyOS提供硬件服務。

3. 框架層：為HarmonyOS的應用程序提供了Java/C/C++/JS等多語言的用戶程序框架和Ability框架，以及各種軟硬件服務對外開放的多語言框架API，同時采用HarmonyOS的設備提供了C/C++/JS等多語言的框架API，不同設備支持的API于系統的組件化采集程度相關。

4. 應用層：包括系統應用和第三方非系統應用。HarmonyOS的應用由一個或多個FA（Feature Ability）或PA（Particle Ability）組成。其中，FA有UI界面，提供于用戶交互的能力；而PA無UI界面，提供后臺運行任務的能力以及統一的數據訪問抽象。

鴻蒙操作系統架構4個技術特性

1. 分布式架構首次用于終端OS，實現跨終端無縫協同體驗。
2. 確定時延引擎和高性能IPC技術實現系統天生流程。
3. 基于微內核架構重塑終端設備可信安全。
4. 通過統一IDE支撐一次開發，多端部署，實現跨終端生態共享。

在鴻蒙架構中，重點關注于分布式架構所帶來的優勢，主要體系在下面四個方面

1. 分布式軟總線：是多種終端設備的統一基座，為設備之間的互聯互通提供了統一的分布式通信能力。
2. 分布式設備虛擬化平臺：可以實現不同設備的資源融合、設備管理、數據處理、多種設備共同形成一個超級虛擬終端。針對不同類型的任務，為用戶匹配并選擇能力合適的執行硬件。
3. 分布式數據管理：基于分布式軟總線能力，實現應用程序數據和用戶數據的分布式管理。用戶數據不再于單一物理設備綁定，業務邏輯于數據存儲分離，應用跨設備運行時數據無縫銜接。
4. 分布式任務調度：構建統一的分布式服務管理（發現、同步、注冊、調用）機制，支持對跨設備的應用進行遠程啟動、遠程調用、遠程連接以及遷移等操作，選擇合適的設備運行分布式任務。

鴻蒙架構的安全性

鴻蒙架構的系統安全性主要體現在搭載HarmonyOS的分布式終端上，可以保證”正確的人，通過正確的設備，正確的使用數據“。這里通過”分布式多端協同身份認證“來保證”正確的人“通過，通過”在分布式終端上構筑可信運行環境“來保證”正確的設備“，通過”分布式數據在終端流動的過程種，對數據進行分類分級管理“來保證”準確的使用數據“

面向安全攸關系統的跨領域GENESYS系統架構案例分析

GENESYS是一種跨領域的通用嵌入式架構平臺，主要解決了嵌入式系統面臨的三方面挑戰：復雜性管理挑戰（采用消息交換方式提高軟硬件抽象級別）、系統健壯性挑戰（設計故障的隔離框架）、能量有效使用挑戰（采用綜合化資源管理方法）。

GENESYS整個架構包括兩類構成系統：即構件和基礎平臺。基礎平臺提供了一種”腰“型核心服務和大量用于實現系統構件的可選服務的最小集合。

GENESYS架構主要提供了三組服務，即領域無關服務、領域專用服務和應用專用服務（包括中間件）如圖所示

1. 核心服務：是強制性的，是GENESYS架構實例的一部分。核心服務應該包含那些可構造較高級服務或者為了維持該結構性質而不可缺少的服務，它是系統服務中的最小集。
2. 選擇服務：是在核心服務之上構造的。它是一種需要時可以擴展的開放式的集合。
3. 領域專用服務：是領域特有的選擇服務子集加上待開放的領域特征的特點服務組合。

GENESYS架構的重要思想是分離計算于通信，將計算構件和通信設施作為獨立構件進行設計

GENESYS的通信設施構件是基于消息傳輸的風格。構件中的基本交往機制是多播單向消息的交換。消息在發送時刻發出，在某個稍后的時刻到達接收者哪里。每一個消息有專門標識的發送者和若干給接收者。

GENESYS架構將構件分為四類：硬件構件和軟件構件、系統構件和應用構件。

• 硬件構件的功能使用硬件被預先確定，因此不能修改。
• 在軟件構件中，將加載在軟件構件上的軟件稱為作業。將作業分配給適當的可以執行該作業的硬件單元就創建了新的構件。
• 系統構件是提供某些構件服務的構件。系統構件可以廣泛重用在許多不同的應用場景中
• 應用設計者只考慮應用構件的開發

基于GENESYS架構的四類消息構件接口：

• 鏈接接口（LIF）：LIF提供了構件與構件之間基于消息的操作服務，它是構件的綜合接口。
• 局部接口（LI）：LI是構件鏈接到外部環境的接口，它建立了構件和局部環境之間的連接關系。
• 技術無關接口（TII）：TII是指用于系統運行需要的配置或管理資源的接口，它屬于非功能屬性范疇。
• 技術相關的接口（TDI）：TDI是指用于查看構件內部、觀察構件的內部變量的接口，如構件診斷

GENESYS定義了三級的集成，即芯片級（Chip Level）、設備級（Device Level）和系統級（System Level）。芯片級的構件是IP核，IP核間可以通過NoC（Network of Chip）相互連接；設備級的構件是芯片，芯片間可以由內部通信芯片相互連接。一個設備可以是在互聯網上的一個可尋址實體，也可以是一個IP地址；系統級的構件是設備，它們是可以由有線或無線通信服務相互連接。

通信系統架構設計

通信系統網絡架構

當今，通信網絡從大的方面主要包括局域網、廣域網、移動通信網等網絡形式。不同的網絡會采用不同的技術進行網絡搭建

局域網

即計算機局部區域網絡，是一種為單一機構所擁有的專用計算機網絡。

特點：覆蓋地理分為小，通常限定在相對獨立的范圍內。低誤碼率，可靠性高；通常為單一部門或單位所有；支持多種傳輸介質支持實時應用。就網絡拓撲圖而言，有總線型、環型、星型、樹型等型式。從傳輸介質來說，包含有線局域網和無線局域網

局域網已從早期只提供二層交換功能的簡單網絡發展到如今不僅提供二層交互功能，還提供三層路由功能的復雜網絡。局域網也稱園區網。以下給出局域網的幾種典型架構風格。

單核心架構

通常由一臺核心二層或三層交換設備充當網絡的核心設備，通過若干平臺接入交換設備將用戶設備（如用戶計算機、智能設備等）連接到網絡中，此類局域網可通過連接核心網交換機設備與廣域網之間的互聯路由設備（邊界路由或防火墻）接入廣域網，實現業務跨局域網的訪問

特點：

1. 核心交換設備通常采用二層、三層及以上交換機
2. 接入交換設備采用二層交換機，僅實現二層數據鏈路轉發
3. 核心交換機設備和接入設備之間可采用100M/GE/10GE等以太網連接

優點：網絡結構簡單，可節省設備投資。需要使用局域網的部門接入較為方便，直接通過接入交換設備連接至核心交換設備空閑接口即可

缺點：網絡地理范圍受限，要求使用局域網的部門分布較為緊湊；核心網絡交換設備存在單點故障，容易導致網絡整體和局部失效；網絡擴展能力有限；在局域網接入交換機設備較多的情況下，對核心交換機設備的端口密度要求高

雙核心架構

通常是指核心交換設備通常采用三層以上交換機。核心交換設備和接入設備之間可采用100M/GE/10GE等以太網連接，網絡內劃分VLAN時，各VLAN之間訪問需要通過兩臺核心交換設備來完成。網絡中僅核心交換設備具有路由功能，接入設備僅提供二層轉發功能

特點：核心交換設備之間互聯，實現網關保護或負載均衡。需要使用局域網的部門接入較為方便，直接通過接入交換設備連接至核心交換設備空閑接口即可

環型架構

是由多臺核心交換機設備連接稱雙PRP動態彈性分組環，構建網絡的核心。核心交換設備通常采用三層或以上交換機提供業務轉發功能，此網絡通過與環上交換設備互聯的邊界路由設備接入廣域網

特點：典型環型局域網網絡內各VLAN之間通過RPR環實現互訪。通過RPR組建大規模局域網時，多環之間只能通過業務接口互通，不能實現網絡直接互通。環型局域網設備投資比單核心局域網的高。核心路由冗余設計實施難度較高，且容器形成環路

層次局域網架構

由核心層交換設備、匯聚層交換設備和接入層交換設備，以及用戶設備等組成

廣域網

屬于多級網絡，通常由骨干網、分布網、接入網組成。在網絡規模較小時，可僅由骨干網和接入網組成。通常，在大型網絡構建中，通過廣域網將分布在各地域的局域網互連起來，形成一個大的網絡。以下給出不同形式的廣域網構建模型以及各自的特點

單核心廣域網

通常由一個核心路由設備和各局域網組成。核心路由設備采用三層及以上交換機。網絡內部各局域網之間訪問需要通過核心路由器設備。

雙核心廣域網

通常由兩臺核心路由設備和各局域網組成。其主要特征是路由設備通常采用三層及以上交換機。核心路由之間實現網關保護或負載均衡。各局域網訪問核心局域網，以及它們相互訪問可多條路徑選擇，可靠性更高，路由層面可實現熱切換，提供業務連續性訪問能力

環型廣域網

通常就是采用三臺以上核心路由器設備構成路由環路，用以連接各局域網，實現廣域網業務互訪。核心路由設備之間具備網關保護或負載均衡機制，同時具備環路控制功能。各局域網訪問核心局域網，或相互訪問，有多條路徑可選擇，可靠性更高，路由層面可實現無縫熱切，保證業務訪問連續性

半冗余廣域網

是由多臺核心路由連接各局域網而形成的。其中任意核心路由設備至少存在兩條以上連接至其他路由設備的鏈路。如何如何兩個核心路由設備之間均存在鏈接，則屬于半冗余廣域網特例，全冗余廣域網

對等子域廣域網

是通過將廣域網的路由設備劃分成兩個獨立的子域，每個子域路由設備采用半冗余方式互連。兩個子域之間通過一條或多條鏈路互連，對等子域中任何路由設備都可接入局域網。對等子域廣域網的主要特點是對等子域之間的互訪是以對等子域之間互連鏈路為主。對等子域之間可以做到路由總或明細路由條目匹配，路由控制靈活。通常，子域之間鏈路帶寬應高于子域內鏈路帶寬。

層次子域廣域網

是將大型廣域網路由設備劃分成多個較為獨立的子域，每個子域內路由設備采用半冗余方式互連，多個子域之間存在層次關系，高層次子域連接多個低層次子域。層次子域中任何路由設備都可以接入局域網。

移動通信網網絡架構

5GS（5GSystem）在移動終端用戶（UE）提供服務時通常需要DN（Data Network）網絡，各式各樣的上網、語言、AR/VR、工業控制和無人駕駛等5GS中UPF網元作為DN的接入點。5GS和DN之間通過5GS定義的N6接口互連。5GS和DN之間是一種路由關系。

從UE通過5GS接入DN的方式存在兩種模式，透明模式和非透明模式

透明模式

5GS通過UPF的N6接口直接連至運營商特定的IP網絡，任何通過防火墻或代理服務器連接至DN（外部IP網絡），如Internet等

此模式下5GS至少為UE提供一個基本ISP服務。對于5GS而言，它只須提供基本的隧道Qos流服務即可。UE訪問某個Intranet網絡時，UE級別的配置僅在UE和Intranet網絡之間獨立完成，這對5GS而言是透明的

非透明模式

5GS直接接入Intranet/ISP，或通過其他IP網絡（如Internet）接入Intranet/ISP。

如5GS通過Internet方式接入Intranet/ISP，通常需要在UPF和Intranet/ISP之間建立專用隧道來轉發UE訪問Intranet/ISP的業務。UE被指派屬于Intranet/ISP地址空間的IP地址。此地址用于UE業務的UPF、Intranet/ISP中轉發。

5G網絡的邊緣計算架構（MEC）

5G網絡的邊緣計算（MEC）架構，支持在靠近終端用戶UE的移動網絡邊緣部署5G UPF網元，結合在移動網絡邊緣部署邊緣計算平臺（MEP），為垂直行業提供諸如以時間敏感、高帶寬為特征的業務就近分流服務

運營商自有應用或第三方AF通過5GS提供的能力開放功能網元MEF，觸發5G網絡為邊緣應用動態地生成本地分流策略，由PCF將這些策略配置給相關SMF，SMF根據終端用戶位置信息或用戶移動后發生的位置變化信息動態實現UPF（即移動邊緣云中部署的UPF）在用戶會話中插入或移除，以及對這些UPF分流規則的動態配置，達到用戶訪問所需業務的極佳效果

軟件定義網絡（SDN）

軟件定義網絡（Software Defined Network SDN），SND利用分層的思想，將網絡分為控制層和數據層

控制層：包括可編程控制器，具有網絡控制邏輯的中心，掌握網絡的全局信息，方便運營商或網絡管理人員配置網絡和部署新協議等

數據層：包括啞交換機（與傳統二級交換機不同，專指用于轉發數據的設備），僅提供簡單的數據轉發功能，可以快速處理匹配的數據包

兩層之間采用開放的統一接口（如OpenFlow等）進行交互。通過此接口控制器向轉發設備（如交換機等）下發統一標準的轉發規則，轉發設備僅需按照這些規則執行相應動作即可

由下至上分為數據平面、控制平面和應用平面

數據平面：由網絡轉發設備（如通常由通用硬件構成）組成，網絡轉發設備之間通過由不同規則形成的SDN數據通路連接起來

控制平面：包含了邏輯上為中心的SDN控制器，它掌握著網絡全局信息，負責轉發設備的各種轉發規則的下發

應用平面：包含各種基于SDN的網絡應用

以控制為邏輯中心，南向接口負責與數據平面進行通信，北向接口負責與應用平面進行通信，東西接口負責多控制器之間的通信

網絡構建關鍵技術

網絡的高可用性是一個系統級的概念。對于一個網絡來說，它由網絡元素（或網絡部件），按照一定的連接模型連接在一起而構成。因此，網絡可用性包括網絡部件、網絡連接模型以及有關網絡協議等方面的可靠性

1. 網絡部件：是組成網絡的基本要素，典型代表有各種交換機、路由器等網絡設備。網絡部件的高可用性是網絡高可用性的關鍵。包括硬件結構和軟件系統。硬件可用性通過冗余、熱備等保證；軟件可用性通過異常保護、數據冗余等保證；
2. 網絡連接模型：除了網絡部件本身的高可用性外，網絡物理拓撲連接形成也影響網絡的可用性程度。這就涉及到串并聯的可靠性計算
3. 網絡協議及配置：高可用性離不開運行于網絡中的路由、鏈路檢測等協議，可以部署鏈路檢測協議發現故障

網絡構建和設計方法

網絡需求分析

網絡需求分析是網絡構建及開發過程的起始環節，也是極其重要的階段。在該階段，可盡早明確客戶使用網絡的真實用途或痛點，以便為后續能夠構建和設計出更貼近客戶真實訴求的網絡打下堅實基礎。需求分析過程，主要圍繞以下幾個方面開展：業務需求、用戶需求、應用需求、計算機平臺需求和網絡需求。最終形成約束后續網絡設計的網絡需求規格說明書。

網絡技術遴選和設計

網絡遴選工作是通信系統設計中關鍵的一項工作，根據計劃實施的網絡建設要求，遴選工作通常分為局域網、廣域網和路由協議的選擇。

1. 局域網技術遴選：生成樹協議（STP）、虛擬局域網、無線局域網、線路冗余設計、交換設備功能的合理使用、服務器冗余設計。
2. 廣域網技術遴選：遠程接入技術、廣域網互聯技術
3. 地址規劃模型：地址分配應遵循以下原則
   • 使用結構化網絡層編址模型，即對地址進行層次化的規劃
   • 通過中心授權機構管理地址，比如由組織的IT部門為網絡層編址提供一個全局模型。根據網絡的核心、匯聚、接入層次化結構，為組織的各個區域、分支機構等進行地址規劃
   • 編址授權下發，即由地址授權管理中心，將編址授權給分支機構來進行地址規劃
   • 為終端用戶設備指派動態地址，即對于頻繁變更位置、移動性角度的用戶分配動態地址
   • 私有地址合理使用，使用私有地址的用戶在訪問外部網絡，需要進行地址轉換（NAT）
4. 路由協議選擇
   • 路由協議類型的選擇：路由協議選擇主要包括距離矢量協議和鏈路狀態協議
   • 路由選擇協議度量值的合理設計
   • 路由選擇協議順序的合理指定
   • 層次化于非層次化路由選擇協議
   • 內部與外部路由選擇協議
   • 分類與無類路由選擇協議
   • 靜態路由指定
5. 層次化網絡模型設計：核心層、匯聚層、接入層
6. 網絡高可用設計方法：提高網絡可靠性、縮短網絡恢復時間

網絡安全

1. 防火墻
2. VPN：虛擬專用網絡
3. 訪問控制技術：主題依據控制策略或權限對客體本身或其資源實施的不同授權訪問
4. 網絡安全隔離：是在網絡運行過程中將網絡攻擊隔離和可信網絡之外，同時保證可信網絡內信息不被外泄
5. 網絡安全協議：SSL、SET、HTTP等
6. 網絡安全審計：是對網絡的脆弱性進行測試評估和分析，最大限度保障業務的安全正常運行的一切行為和手段

綠色網絡設計原則

1. 標準化：在設計之初就應考慮解決方案標準化，整體架構標準化可大幅度減少轉換設備，從而大大降低了能耗
2. 集成化：k額使得整個網絡系統的通信設備數量盡可能降低，通過減少設備總量、降低設備使用所需要資源（空間、機架、線纜、人力等），來實現節能減排目標
3. 虛擬化：是一種網絡資源可以靈活調配、按需使用的重要途徑
4. 智能化：一方面可以降低人力投入從而降低TCO，達到律師環保目的；另一方面智能化方案可以通過智能處理直接降低資源的占用，實現綠色設計

通信網絡構建案例分析

高可用網絡構建分析

1. 計入層高可用設計。特性如下

   • 使用冗余引擎和冗余電源獲得系統冗余，為關鍵用戶群提高高可靠性
   • 與具備冗余系統的匯聚層采用雙歸屬連接，獲得默認網關冗余，支持在匯聚層的主備交換機間快速實現故障切換
   • 通過鏈路匯聚提供帶寬利用率，同時降低復雜度
   • 通過配置802.1x，動態ARP檢查及IP源地址保護等功能增加安全性，有效防止非法訪問

2. 網絡匯聚層高可用設計。匯聚層到核心層間采用OSPF等動態路由協議實現路由層面高可用保障。

   典型連接方式有兩種：

   組網模式一為三角形連接方式，從匯聚層到核心層具有全冗余鏈路和轉發路徑；

   組網模型二為矩形連接方式，從匯聚層到核心層為非全冗余鏈路，當主鏈路發生故障時，需要通過路由協議計算獲得從匯聚到核心的其他路徑。

   可見，組網模型一（即三角形連接方式）的故障收斂時間較小，不足的是，三角形連接方式要占用更多設備端口，建網成本較高

3. 網絡核心層高可用設計。從系統冗余性角度，應考慮部署雙核心或多核心設備，以主備或負荷分擔方式工作

5G網絡應用

5G網絡在智能電網中的應用如圖所示

通過5G網絡將種類繁多數據巨大的設備，如電網智能感知設備（傳統電源、新能源電源等），電網中的輸變電網設備、配電設備等，用戶電表、電動汽車等連接到物聯網（IoT）平臺中，由IoT平臺進行電網各個環節的數據采集和智能分析，從而為電網的高級應用（輸電業務、配電業務、綜合能源管理等業務部門）的科學決策提供有力的支撐

安全架構設計

安全機構概述

對于信息系統來說，威脅可以是針對物理環境、通信鏈路、網絡系統、操作系統、應用系統以及管理系統等方面。

• 物理安全威脅：是指對系統所用設備的威脅，如自然災害、電源故障等

• 通信鏈路安全威脅：是指通過技術手段竊取互聯網信息，對網絡形成嚴重的安全威脅

• 網絡安全威脅：是指通過技術手段竊取互聯網信息，對網絡形成嚴重的安全威脅

• 操作系統安全威脅：是指定對系統平臺中的軟件或硬件芯片中植入威脅，如“木馬”和“陷阱門”、BIOS的萬能密碼

• 應用系統安全威脅：是指對網絡服務或用戶業務系統安全的威脅

• 管理系統安全威脅：是指由于人員管理上的疏忽而引發人為的安全漏洞，如認為的通過拷貝、拍照、抄錄等手段盜取計算機信息

具體常見的安全威脅

1. 信息泄露：信息被泄露或者透露給某個非授權的實體。

2. 破壞信息的完整性：數據被非授權地進行增刪、修改或破壞而受到損失。

3. 拒絕服務：對信息或其他資源的合法訪問被無條件的阻止。

4. 非法使用（非授權訪問）：某一資源被某個非授權的人或非授權的方式使用。

5. 竊聽：用各種可能的合法或非法的手段竊取系統中的信息資源和敏感信息。

6. 業務流分析：通過對系統進行長期監聽，利用統計分析對諸如通信頻度、通信的信息流向、通信總量的變化等態勢進行研究，從而發現有價值的信息和規律。

7. 假冒：通過欺騙通信系統（或用戶）達到非法用戶冒充成為 合法用戶，或者特權小的用戶冒充成特權大的用戶的目的。黑客大多是采用假冒進行攻擊。

8. 旁路控制：攻擊者利用系統的安全缺陷或安全性上的脆弱之處獲得非授權的權利或特權。

9. 授權侵犯：被授權以某一目的使用某一系統或資源的某個人，卻將此權限用于其他非授權的目的，也稱作“內部攻擊”。

10. 特洛伊木馬：軟件中含有一個察覺不出或者無害的程序段，當它執行時，會破壞用戶的安全。

11. 陷阱門：在某個系統或某個部件中設置了“機關”，使得當提供特定的輸入數據時，允許違反安全策略。

12. 抵賴：這是一種來自用戶的攻擊，例如，否認增加曾經發布過的某條消息、偽造一份對方來信等。

13. 重放：所截獲的某次合法的通信數據備份，出于非法的目的而被重新發送。

14. 計算機病毒：所謂計算機病毒，是一種計算機系統運行過程中能夠實現和侵害的功能程序。

    一種病毒通常含有兩個功能：

    1. 一種功能是對其他程序產生“感染”
    2. 另外一種或者是引發損壞功能或者是一種植入攻擊的能力

15. 人員瀆職：一個授權的人為了錢或利用、或由于粗心，將信息泄露給一個非授權的人。

16. 媒體廢棄：信息被從廢棄的磁盤或打印過的存儲介質中獲得。

17. 物理入侵：入侵者通過繞過物理控制而獲得對系統的訪問。

18. 竊取：重要的安全物品，如令牌或身份卡被盜。

19. 業務欺騙：某一偽系統或系統部件欺騙合法用戶或系統自愿的放棄敏感信息。

安全架構

安全架構是架構面向安全性方面上的一種細分，通常的產品安全架構、安全技術體系架構和審計架構可以組成三道安全防線。

1. 產品安全架構：構建產品安全質量屬性的主要組成部分以及它們之間的隔離。產品安全架構的目標是如何在不依賴外部防御系統的情況下，從源頭打造自身安全的產品。
2. 安全技術體系架構：構建安全技術體系的主要組成部分以及它們之間的關系。安全技術體系架構的任務是構建通用的安全技術基礎設施，包括安全基礎設施、安全工具和技術、安全組件與支持系統等，系統性地增強各產品的安全防御能力。
3. 審計架構：獨立的審計部門或其所能提供的風險發現能力，審計的范圍主要包括安全風險在內的所有風險。

安全模型

信息系統的安全目標是控制和管理主體（含用戶和進程）對客體（含數據和程序）的訪問。

安全模型是準確地描述安全的重要方面及其系統行為的關系，安全策略是從安全角度為系統整體和構成它的組件提出基本的目標。安全模型提供了實現目標應該做什么，不應該做什么，具有實踐指導意義，它給出了策略的形式。如下圖是模型的分類：

狀態機模型

狀態機模型描述了一種無論處于何種狀態都是安全的系統。它是用狀態語言將安全系統描述成抽象的狀態機，用狀態變量表述系統的狀態，用轉換規則描述變量的變化的過程。

狀態機模型中一個狀態是處于系統的特定時刻的一個快照。如果該狀態所有方面滿足安全策略的要求，則稱此狀態是安全的；一個安全狀態模型系統，總是從一個安全狀態啟動，并且在所有遷移中保存安全狀態，只允許主體以和安全策略相一致的安全方式訪問資源。

Bell-LaPadula模型（BLP）

Bell-LaPadula模型使用主體、客體、訪問操作（讀、寫、讀/寫）以及安全級別這些概念，當主體和客體位于不同的安全級別時，主體對客體存在一定的訪問限制。通過該模型可保證信息不被不安全的主體訪問。

Bell-LaPadula模型的安全規則如下：

1. 簡單安全規則：安全級別低的主體不能讀取安全級別高的客體（No Read Up），只能下讀。
2. 星屬性安全規則：安全級別高的主體不能往低級別的客體寫（No Write Down），只能上寫。
3. 強星屬性安全規則：不允許對另一級進行讀寫。
4. 自主安全規則：使用訪問控制矩陣來定義說明自由存取控制。其存取控制體系在內容相關和上下問相關。

Biba模型（Biba）

Biba模型不關心信息機密性和安全級別，因此它的訪問控制不是建立在安全級別上，而是建立在完整性級別上。

完整性的三個目標：保護數據不被未授權用戶更改；保護數據不被授權用戶越權修改（未授權更改）；維持數據內部和外部的一致性。

!

Biba模型能夠防止數據從低完整性級別流向高完整性級別，其安全規則如下：

1. 星完整性規則：表示完整性級別低的主體不能對完整性級別高的客體寫數據，只能下寫。
2. 簡單完整性規則：表示完整性級別高的主體不能從完整性級別低的客體讀取數據，只能上讀。
3. 調用屬性規則：表示一個完整性級別低的主體不能從級別高的客體調用程序或服務。

Clark-Wilson模型（CWM）

Clark-Wilson模型是一種將完整性目標、策略和機制融為一體的模型。為了體現用戶完整性，CWM提出職責隔離目標；為了保證數據完整性，CWM提出應用相關的完整性驗證進程；為了建立過程完整性，CWM定義了對于編號過程的應用相關驗證。

1. 需要進行完整性保護的客體稱之未CDOI，不需要進行完整性保護的客體稱之未UDI。
2. 完整性驗證過程（IVP）：確認限制數據項處于一種有效狀態，如果IVP檢驗CDI符合完整性越蘇，則系統處于一個有效狀態。
3. 轉換過程（TP）：將數據項從一種有效狀態改變至另一種有效狀態。

CWM的主要特征是：

1. 采用Subject/Program/Object三元素的組成方式。Subject要訪問Object只能通過Program進行。
2. 權限分離原則，將要害概念分為2個或多個Subject完成，防止已授權用戶進行未授權的修改
3. 要求具有審計能力

Chinese Wall模型

Chinese Wall模型（又名Brew and Nash模型）是應用在多邊安全系統中的安全模型。也就是說，是指通過行政規定和劃分、內部監控、IT系統等手段防止各部門之間出現有損客戶利益的利益沖突事件。

Chinese Wall模型的安全策略的基礎是客戶訪問的信息不會與當前它們可支配的信息產生沖突。在投資銀行中，一個銀行會同時擁有多個互為競爭者的客戶，一個銀行家可能為一個客戶工作，但他可以訪問所有客戶的信息。因此，應當制止該銀行家訪問其他客戶的數據。銀行家可以選擇為誰工作（DAC），一旦選定，他就只能為該客戶工作（MAC）。

Chinese Wall模型的訪問客體控制的安全規則如下：

1. 與主體曾經訪問過的信息屬于同一公司數據集合的信息，即墻內信息可以訪問
2. 屬于一個完全不同的利益沖突組的可以訪問
3. 主體能夠對一個客體進行寫的前提是主體未對任何屬于其他公司數據集進行過訪問

定理1：一個主體一旦訪問過一個客體，則該主體只能訪問位于同一公司數據集的客體或在不同利益組的客體。

定理2：在一個利益沖突組中，一個主體最多只能訪問一個公司數據集。

系統安全體系架構規劃框架

安全技術體系架構是對組織機構信息技術系統的安全體系結構的整體描述。安全技術體系架構的目標是建立可持續改進的安全技術體系架構的能力。

根據網絡中風險威脅存在實體劃分出5個層次的實體對象：應用、存儲、主機、網絡和物理。

信息系統安全體系主要是由技術體系、組織機構體系和管理體系三部分共同構成的。

技術體系是全面提供信息安全保護的技術保障系統，該體系由物理安全技術和系統安全技術兩大類構成。

組織體系是信息系統的組織保障系統，由機構、崗位和人事三個模塊構成。

管理體系由法律管理、制度管理和培訓管理三部分組成。

1. 信息系統安全規劃依托企業信息化戰略規劃

   信息系統安全規劃的目標應該與企業信息化的目標是一致的，而且應該比企業信息化的目標更具體明確、更貼近安全。

2. 信息系統安全規劃需要圍繞技術安全、管理安全、組織安全考慮

   規劃的內容基本上應該涵蓋：確定信息系統安全的任務、目標、戰略以及戰略部門和戰略人員，并在此基礎上指定出物理安全、網絡安全、系統安全、運營安全、人員安全的信息系統安全的總體規劃。

3. 信息系統安全規劃以信息系統與信息資源的安全保護為核心

   規劃工作需要圍繞著信息系統與信息資源的開發、利用和保護工作進行，要包括藍圖、現狀、需求和措施4個方面。

   1. 對信息系統與信息資源需要從信息化建設的藍圖入手，知道企業信息化發展策略的總體目標和各階段的實施目標，制定出信息系統安全的發展目標。
   2. 對企業的信息化工作現狀進行的整體的、綜合、全面的分析，找出過去工作中的優勢與不足。
   3. 根據信息化建設的目標提出未來幾年的需求，這個需求最好可以分解成若干個小方面，以便于今后實施于落實。
   4. 要明確在實施工作階段的具體措施于方法，提高規劃工作的執行力度

信息安全整體架構設計

信息系統安全設計重點考慮兩個方面：系統安全保障體系，信息安全體系結構

1. 系統安全保障體系：是由安全服務、協議層和系統單元等三各層面組成，且每個層都涵蓋了安全管理的內容。

   系統安全保障體系設計工作主要考慮以下幾點：

   1. 安全區域策略的確定：根據安全區域的劃分，主管部門指定針對性的安全策略。
   2. 統一配置和管理防病毒系統：主管部門應當建立整體防御策略，以實現統一的配置和管理。
   3. 網絡安全管理：加強網絡安全管理，制定有關規章制度。

2. 信息安全體系架構：具體在安全控制系統。

   我們可以從下面5個方面開展分析和設計工作：

   1. 物理安全：保證計算機信息系統各種設備的物理安全是保障整個網絡系統安全的前提。包括環節安全、設備安全、媒體安全等
   2. 系統安全：主要是指對信息系統組成中各部件的安全要求。系統安全是系統整體安全的基礎。他主要包括：網絡結構安全、操作系統安全和應用系統安全。
   3. 網絡安全：是整個安全解決方案的關鍵。它主要包括：訪問控制、通信保密、入侵檢測、網絡安全掃描系統和防病毒等。
   4. 應用安全：主要是指多個用戶使用網絡系統時，對共享資源和信息存儲操作所帶來的安全問題。它主要包括資源共享和信息存儲兩個方面。
   5. 安全管理：主要體系在三個方面。其一是指定健全的安全管理體制；其而是構建安全管理平臺；其三是增強人員的安全防范意識。

WPDRRC模型

WPDRRC（Waring/Protect/Detect/React/Restore/Counterattack）模型有6個環節和3大要素。

6個環節包括：預警、保護、檢測、響應、恢復和反擊，它們具有較強的時序性和動態性，能夠較好地反映出信息系統安全保障體系的預警能力、保護能力、檢測能力、響應能力、恢復能力和反擊能力。

3大要素包括：人員、策略和技術。人員是核心，策略是橋梁，技術是保證，落實在WPDRRC的6個環節的各個方面，將安全策略預警策略變為安全現實。

• W：預警主要是指利用遠程安全評估系統提供的模擬攻擊技術來檢查系統存在的、可能被利用的薄弱環節，收集和測試網絡于信息的安全風險所在，并以直觀的方式進行報告，提供解決方案的建議，在經過分析后，分解網絡的風險變化趨勢和嚴重風險點，從而有效降低網絡的總體風險，保護關鍵業務和數據。
• P：防護通常是通過采用成熟的信息安全技術以及方法來實現網絡于信息的安全。主要內容有加密機制，數字簽名機制，訪問控制機制，認證機制，信息隱藏和防護墻技術等。
• D：檢測通過檢測和監控網絡以及系統，來發現新的威脅和弱點，強制執行安全策略。在這個過程中采用入侵檢測、惡意代碼過濾等技術，形成動態檢測的制度，獎勵報告協調機制，提供安全檢測的實時性，主要內容有入侵檢測、惡意代碼過濾等技術，形成動態檢測的制度，獎勵報告協調機制，提高檢測的實時性。主要內容有入侵檢測，系統脆弱性檢測，數據完整性檢測和攻擊性檢測等。
• R：響應是指在檢測到安全漏洞和安全事件之后必須及時做出正確的響應，從而把系統調整到安全狀態。為此需要相應的報警、跟蹤、處理系統，其中處理包括了封堵、隔離、報告等能力。主要內容有應急策略、應急機制、應急手段、入侵過程分析和安全狀態評估等。
• R：恢復災年恢復系統是當前網絡、數據、服務受到黑客攻擊并遭到破壞或影響后，通過必要技術手段，在盡可能端的時間內使系統恢復正常。主要內容有容錯、冗余、備份、替換、修復和恢復等。
• C：反擊是指采用一切可能的高新技術手段，偵察、提取計算機犯罪分子的作案線索于犯罪證據，形成強有力的取證能力和依法打擊手段。

一種面向企業的安全控制系統安全架構

網絡安全體系架構設計

OSI定義了7層協議，其中除第5層（會話層）外，每一層均能提供相應的安全服務。實際上，最適合配置安全服務的是在物理層、網絡層、運輸層及應用層上，其他層都不宜配置安全服務。

OSI定義分層多點安全技術體系架構，也稱為深度防御安全技術體系架構，它通過以下三種方式將防御能力分布至整個信息系統中

1. 多點技術防御：在對手可以從內部或外部多點攻擊一個目標的前提下，多點技術防御通過對網絡和基礎設施、邊界、計算環節這三個防御核心區的防御達到抵御所有方式的攻擊目的。
2. 分層技術防御：即使最好的可得到的信息保障產品也有弱點，其最終結果將使對手能夠找到一個可探查的脆弱性，一個有效的措施是在對手的目標間使用多個防御機制。
3. 支撐性基礎設施：為網絡、邊界合計計算環境中信息保障機制運行基礎的支撐性基礎設施，包括公鑰基礎設施以及檢測和響應基礎設施。

OSI的5類安全服務

OSI開放系統互連安全體系的5類安全服務包括鑒別、訪問控制、數據機密性、數據完整性和抗依賴性。

鑒別

鑒別（Authentication）的基本目標是防止其他實體占用和獨立操作被鑒別實體的身份。鑒別有兩種重要的背景關系，一是實體由授權者來代表，申請者于驗證者之間存在著特定的通信關系（如實體鑒別）；二是實體為驗證者提供數據項來源。

鑒別服務分為以下階段：

1. 在安裝階段：定義授權鑒別信息和驗證鑒別信息。
2. 修改鑒別信息階段：實體或管理者申請鑒別信息和驗證鑒別信息變更（如修改口令）。
3. 在分發階段：為了驗證交換鑒別信息，把驗證鑒別信息分發到各實體（如申請者或驗證者）以供使用。
4. 在獲取階段：申請者或驗證者可得到為鑒別實例生成特定交換鑒別信息所需的信息，通過于可信第三方進行交互或鑒別實體間的信息交互可得到交換鑒別信息。
5. 在傳送階段：在申請者于驗證者之間傳送交換鑒別信息。
6. 在驗證階段：有驗證鑒別信息核對交換鑒別信息。
7. 在停活階段：將建立一種狀態，使得一起被鑒別的實體暫時不能被鑒別。
8. 在重新激活階段：使在停活階段建立的狀態將被終止。
9. 在取消安裝階段：實體從實體集合中被拆除。

訪問控制

訪問控制（Access Control）決定開放系統環境中允許使用那些資源、在什么地方合適阻止未授權訪問的過程。

ACI（訪問控制信息）是由于訪問控制目的的任何信息，其中包括上下文信息。ADI（訪問判決信息）是在做出一個特定的訪問控制判決時可供ADF使用的部分（或全部）ACI。

ADF（訪問控制判決功能）是一種特定功能，它通過對訪問請求、ADI以及該訪問請求的上下文使用訪問控制策略規則而做出訪問控制判決。AEF（訪問控制實施功能）確保只有對目標允許的訪問才有發起者執行。

涉及訪問控制的發起者、AEF、ADF和目標

數據機密性

數據的機密性可以依賴于所駐留的傳輸的媒體。因此，存儲數據的機密性能通過使用隱藏數據語義（如加密）或將數據分片的機制來保證。數據在傳輸中的機密性能通過禁止訪問的機制、通過隱藏數據語義的機制或通過分散數據的機制得以保障（如跳頻等）。

具體機制包括：通過禁止訪問提供機密性、通過加密提供機密性、通過數據填充、虛假事件等。

數據完整性

對于不同的媒體，數據完整性保護機制是有區別的，可概括為以下兩種情況。

1. 阻止對媒體訪問的機制。包括物理隔離的不受干擾的信道、路由控制、訪問控制。
2. 用以探測對數據或數據項序列的非授權修改的機制。未授權修改包括未授權數據創建、數據刪除以及數據重復。而相應的完整性機制包括密封、數字簽名、數據重復（作為對抗其他類型違規的手段）、密碼變換結合的數字指紋和消息序列號

抗依賴性

抵抗依賴服務包括證據生成、驗證和記錄，以及在解決糾紛時隨時進行的證據恢復和再次驗證。

框架所描述的抵抗依賴服務的目的是提供有關特定事件或行為的證據。

抵抗依賴由4個獨立的階段組成：證據生成；證據傳輸、存儲及恢復；證據驗證和解決糾紛。

數據庫系統的安全設計

數據庫完整性是指數據庫中數據的準確性和相容性。數據庫完整性由各種各樣的完整性約束來保證，因此可以說數據庫完整性設計就是數據庫完整性約束的設計。數據庫完整性約束可以通過DBMS或應用程序來實現，基于DBMS的完整性約束作為模式的一部分存入數據庫中。

在實施數據庫完整性設計時，需要把握以下基本原則：

1. 根據數據庫完整性約束的類型確定其實現的系統層次和方式。并提前考慮對系統性能的影響。一般情況下，靜態約束應盡量包含在數據庫模式中，而動態約束由應用程序實現。
2. 實體完整性約束、引用完整性約束是關系數據庫最重要的完整性約束，在不影響系統性能的前提下需盡量應用。用一定的時間和空間來換取系統的易用性是值得的。
3. 要慎用目前主流的DBMS都支持的觸發器功能，一方面由于觸發器性能開銷較大；另一方面，觸發器的多級觸發難以控制，容易發送錯誤，非不可時，最好使用Before型語句觸發器。
4. 在需要分析階段就必須制定完整性約束的命名規范，盡量使用有意義的英文單詞、縮寫詞、表名、列名及下劃線等組合，使其易于識別和記憶。
5. 要根據業務規則對數據庫完整性進行細致的測試，以盡早排除隱含的完整性約束間的沖突和對性能的影響。
6. 要有專職的數據庫設計小組，自始至終負責數據庫的分析、設計、測試、實施及早期維護。
7. 應采用合適的CASE工具來降低數據庫設計各階段的工作量。

數據庫完整性的作用：

1. 數據庫的完整性約束能夠防止合法用戶使用數據庫時向數據庫中添加不合語義的數據。
2. 利用基于DBMS的完整性控制機制來實現業務規則，易于定義，容易理解，而且可以降低應用程序的復雜性，提高應用程序的運行效率。
3. 合理的數據庫完整性設計，能夠同時兼顧數據庫的完整性和系統的效能。
4. 在用軟件的功能測試中，完善數據庫完整性有助于盡早發現應用軟件的錯誤。
5. 數據庫完整性約束可分為6類：列級靜態約束、元組級靜態約束、關系級靜態約束、列級動態約束、元組級動態約束和關系級動態約束。

一個號的數據庫完整性設計，首先需要在需求分析階段確定通過數據庫完整性約束實現的業務規則。

然后再充分了解特定DBMS提供的完整性控制機制的基礎上，依據整個系統的體系結構和性能要求，遵照數據庫世界方法和應用軟件設計方法，合理選擇每個業務規則的實現方式。

最好，認真測試，排插隱含的約束沖突和性能問題。

系統架構的脆弱性分析

脆弱性分析主要是分析信息系統中產生脆弱性的根源、脆弱性可能造成的影響、如何利用脆弱性進行攻擊、如何修補脆弱性、如何防止脆弱性被利用、如何探測目標系統的脆弱性、如何預測新的脆弱性的存在等一系列問題。

從計算角度而言，漏洞的來源主要有以下幾個方面：軟件設計時的瑕疵、軟件實現中的弱點、軟件本身的瑕疵、系統和網絡的錯誤配置。

軟件脆弱性特點

軟件脆弱性有其自身的特點，主要包括4個方面：

1. 脆弱性是軟件系統中隱藏的一個弱點，本身不會引起危害，但被利用后產生嚴重的安全后果。
2. 再軟件開放過程中，自覺或不自覺的引入的邏輯錯誤是大多數脆弱性的根本來源。
3. 與具體的系統環境密切相關，系統環境的如何差異都有可能導致不同的脆弱性問題。
4. 舊的脆弱性得到修補或糾正的同時可能引入新的脆弱性，因此脆弱性問題會長期存在。

軟件脆弱性的生命周期

脆弱性的引入階段（引入軟件脆弱性的原因）：

1. 輸入驗證碼錯誤。
2. 權限檢查錯誤。
3. 操作序列化錯誤。
4. 邊界檢查出錯誤。
5. 軟件設計時的缺陷。
6. 其他錯誤

產生破壞效果階段：

1. 非法執行代碼。
2. 非法修改目標對象。
3. 訪問數據對象。
4. 拒絕服務攻擊。

修補階段：

1. 刪除偽造實體（如IP偽造、名字偽造等）。
2. 增加新的實體。
3. 寫該實體不正確的位置。
4. 其他情況。

脆弱性分析

軟件脆弱性分析可從三個方面考慮：

1. 分析軟件故障現象：分析故障的技術本質、總結脆弱性模式。
2. 分析軟件開發：發現安全管理和技術的薄弱環節，提高軟件安全性。
3. 分析軟件使用：發現其脆弱性，采取相應措施，避免脆弱性轉化為安全故障。

軟件脆弱性分析首先要明確分析對象，脆弱性分析對象分為兩類：脆弱性數據和軟件系統。

由于軟件本身具有自身性質和特點，針對軟件的脆弱性分析，我們也需要考慮軟件本身的各種特點。主要考慮軟件結構和實現技術兩方面。

典型的軟件架構脆弱性

分層架構的脆弱性

1. 層間的脆弱性：一旦某個底層發生錯誤，那么整個程序將會無法正常運行。
2. 層間通信的脆弱性：將系統隔離為多個相對獨立的層，這就要求再層與層之間引入通信機制。本來“直來直去”的操作現要層層傳遞，勢必造成性能下降

C/S架構的脆弱性

1. 客戶端軟件的脆弱性：因為在用戶計算機上安裝了客戶端軟件，所以整個系統就面臨著程序被分析、數據被截取的安全隱患。
2. 網絡開放性的脆弱性：目前很多傳統的C/S系統還是采用二層結構，也就是所有客戶端直接讀取服務器端中的數據，在客戶端包含了數據的用戶名、密碼等致命的信息，這樣會給系統帶來安全隱患。
3. 網絡協議的脆弱性：C/S架構不便于隨時與用戶交流（主要是不便于數據包共享），且C/S架構軟件在保護數據安全性方面有著先天的弊端。由于C/S架構軟件的數據分布性特性，客戶端所發生的火災、盜搶、地震、病毒等都將成為可怕的數據殺手。

B/S架構的脆弱性

系統如果使用HTTP協議，B/S架構相對C/S架構而言更容易被病毒入侵，雖然最新HTTP協議在安全方面有所提升，但是還是弱于C/S。

事件驅動架構的脆弱性

1. 組件的脆弱性：組件削弱了自身對系統的控制能力，一個組件觸發事件，并不能確定響應該事件的其他組件及各組建的執行順序。
2. 組件間交換數據的脆弱性：組件不能 很好的解決數據交換問題，事件觸發時，一個組件有可能需要將參數傳遞給另一個組件，而數據量很大的時候，如何有效傳遞是一個脆弱性問題。
3. 組件間邏輯關系的脆弱性：事件架構使系統中各組件的邏輯關系變得更加復雜。
4. 事件驅動容易進入死循環：這是由編程邏輯決定的。
5. 高并發的脆弱性：雖然事件驅動可以實現有效利用CPU資源，但是存在高并發事件處理造成的系統響應問題，而且，高并發容易導致系統數據不正確、丟失數據等現象。
6. 固定流程的脆弱性：因為事件驅動的可響應流程基本都是固定的，如果操作不當，容易引發安全問題。

MVC架構的脆弱性

1. MVC架構的復雜性帶來的脆弱性：MVC架構增加了系統結構和實現的復雜性。比如一個簡單的界面如果嚴格遵循MVC方式，使得模型、視圖與控制器分離，會增加結構性的復雜性，并可能產生過多的更新操作，降低運行效率。
2. 視圖與控制器間緊密連接的脆弱性：視圖與控制器是相互分離但確是聯系緊密的部件，沒有控制器的存在，視圖應用是很有限的。反之亦然，這樣就妨礙它們的獨立重用。
3. 視圖對模型數據的低效率訪問的脆弱性：依據模型操作接口不同，視圖可能需要多次調用才能獲得足夠的顯示數據，對未變化數據的不必要的頻繁訪問也將損害操作性能。

微內核架構的脆弱性

1. 微內核架構難以進行良好的整體優化：由于微內核系統的核心只實現了基本的系統操作，這樣內核以外的外部程序之間的獨立運行使得系統難以進行良好的整體優化。
2. 微內核系統的進程通信開銷也較單一內核系統要大的多：從整體上看，在當前硬件條件下，微內核在效率上的損失小于其在架構上獲得的收益。
3. 通信損失率高：微內核把系統分為各個小的功能模塊，從而降低了設計難度，系統的維護與修改也容易，但通信帶來的效率損失的一個問題。

微服務架構的脆弱性

1. 開發人員需要處理分布式系統的復雜結構。
2. 開發人員要設計服務之間的通信機制，通過寫代碼來處理消息傳遞中速度過慢或者不可用等局部實效問題。
3. 服務管理的復雜性，在生產環境追蹤要管理多個不同的服務實例，這意味著開發團隊需要全局統籌。

安全架構設計案例分析

電子商務系統的安全性設計

認證、授權和審計（AAA）是運行于寬帶網絡接入服務器上的客戶端程序。AAA提供了一個用來對認證、授權和審計三種安全功能進行配置的一致的框架，實際上是對網絡安全的一種管理。

RADIUS服務器負載接收用戶的連接請求，完成驗證并把用戶所需的配置信息返回給BAS建立連接，從而可以獲得訪問其他網絡的權限是，BAS就起到了認證用戶的作用。BAS負責把用戶之間的驗證信息傳遞通過密鑰的參與來完成。用戶密碼加密以后才能在網上傳遞，以避免用戶的密碼不再安全的網絡上被竊取。

高性能的RADIUS軟件架構核心如圖所示：

RADIUS軟件架構分為三個層面：協議邏輯層、業務邏輯層和數據邏輯層。

協議邏輯層：主要實現RFC框架中的內容，處理網絡通信協議的建立、通信和停止方面的工作。在軟件功能上這部分主要相當于一個轉發引擎，起到分發到不同的協議處理過程中，這一層的功能起到了協議與業務處理的分層處理的作用。

業務邏輯層：是RADIUS軟件架構設計的核心部分，協議處理進程主要是對轉發引擎發來的包進行初步分析，并根據包的內容進一步分發到不同的業務邏輯處理進程。業務邏輯進程分為認證、計費和授權三種類型，不同的業務邏輯進程可以接收不同協議進程之間的信息并進行處理。轉發進程與協議進程之間采用共享內存的方法，實現進程之間的通信。協議進程與業務邏輯處理進程之間采用進程加線程的實現方法。

數據邏輯層：需要對來自業務邏輯處理線程統一管理與處理數據庫代理池的數據，有數據庫代理池統一連接數據庫，以減少對數據庫系統的壓力。

基于混合云的工業安全架構設計

下圖給出了大型企業采用混合云技術的安全生產管理系統的架構，企業由多個跨區域的智能工廠和公司總部組成，公司總部負責相關業務的管理、協調和統計分析，而每個智能工廠負責智能產品設計與制造。智能工廠內部采用私有云實現產品設計、數據共享和生產集成等，公司總部與智能工廠間采用公有云實現智能工廠間、智能工廠與公司總部間的業務管理、協調和統計分析等。

整個安全生產管理系統架構由四層組成：

設備層：主要指用于智能工廠生產產品所需的相關設備。

控制層：主要是指智能工廠生產產品所需建立的一套自動化控制系統，控制智能設備完成生產工作。

設計/管理層：指智能工廠各種開發、業務控制和數據管理功能的集合，實現數據集成與應用。

應用層：主要是指在云計算平臺上進行信息處理。

大數據架構設計

大數據處理系統架構分析

大數據帶來的三大挑戰：

1. 如何利用信息技術手段處理非結構化和半結構化數據。
2. 如何探索大數據復雜性、不確定性特征描述的刻畫方法及大數據的系統建模。
3. 數據異構性與決策異構性的關系對大數據知識發現于管理決策的影響。

大數據處理系統架構特征：

1. 魯棒性和容錯性
2. 低延遲讀取和更新能力
3. 橫向擴容
4. 通用性
5. 延展性
6. 即席查詢能力
7. 最少維護能力
8. 可調試性

Lambda架構

Lambda架構設計目的在于提供異構能滿足大數據系統關鍵特性的架構，包括高容錯、低延遲、可擴展等。其整合離線計算與實時計算，融合不可變、讀寫分離和復雜性隔離等原則。Lambda是用于同時處理離線和實時數據的，可容錯的，可擴展的分布式系統。它具備強魯棒性，提供低延遲和持續更新。

Lambda架構應用場景：機器學習、物聯網、流處理。

如圖所示，Lambda架構分三層：批處理層、加速層和服務層。

1. 批處理層（Batch Layer）：存儲數據集，Batch Layer在數據集上預先計算查詢函數，并構建查詢所對應的VIew。Batch Layer可以很好地處理離線數據，但有很多場景數據不斷實時生成，并且需要實時查詢處理。Speed Layer正是用來處理增量的實時數據。
2. 加速層（Speed Layer）：Batch Layer處理的是全體數據集，而Speed Layer處理的是最近的增量數據流。Speed Layer為了效率，在接收到新的數據后會不斷更新Real-time View，而Batch Layer是根據全體離線數據集直接得到Batch VIew。
3. 服務層（Serving Layer）：Serving Layer用于合并Baatch View和Real-time View種的結果數據集到最終數據集。用于響應用戶的查詢請求。

如圖所示，這這種Lambda架構實現種，Hadoop（HDFS）用于存儲主數據集，Spark（或Storm）可構成速度層（Speed Layer），HBase（或Cassandra）作為服務層，有Hive創建可查詢的視圖。

Hadoop：是被設計成適合運行在通用硬件上的分布式文件系統。HDFS是一個具有高度容錯性的系統，能提供高吞吐量的數據訪問，非常適合大規模數據集上的應用。HDFS放寬了一些約束，以達到流式讀取文件系統數據的目的。

Apache Spark：是專為大規模數據處理而設計的快速通用的計算引擎。Spark中間輸出結果可以保存在內存中，從而不需要讀取HDFS，因此Spark能更好地適用于數據挖掘與機器學習等需要迭代的Map Reduce算法。

HBase-Haoop Database：是一個高可靠性、高性能，可伸縮的分布式存儲系統，利用HBase技術可在廉價PCServer上搭建大規模結構化存儲集群。

Lambda架構的優缺點：

優點：容錯性號、查詢靈活度高、易伸縮、易擴展。

缺點：全場景覆蓋帶來的編碼開銷。針對具體場景重新離線訓練一遍益處不大。重新部署和遷移成本很高。

事件朔源（Event Sourcing）與Lambda架構

Event Sourcing本質上是一種數據持久化的方式，其由三個核心觀點構成：

1. 整個系統以事件驅動，所有業務都由事件驅動來完成。
2. 事件是核心，系統的數據以事件為基礎，事件要保存在某種存儲上。
3. 業務數據知識一些由事件產生的視圖，不一定要保存到數據庫中

Lambda架構中數據集的存儲使用的概念與Event Sourcing中的思想完全一致，二者都是在使用統一的數據模型對數據處理事件本身進行定義。這樣在發生錯誤的適合，能夠通過模型找到錯誤發生的原因，對這一事件進行重新以丟棄錯誤信息，恢復到系統應該的正確狀態，以此實現了系統的容錯性。

CQRS月Lambda架構

CQRS架構分離了對數據進行的讀操作和寫操作。其將能改變數據模型狀態的命令和模型狀態的查詢操作實現了分離。這是領域驅動設計的一個架構模式，主要用來解決數據庫報表的輸出處理方式。

Lambda架構中，數據的修改通過批處理和流處理實現，通過寫操作將數據轉換成查詢時所對應的View。在Lambda架構中，對數據進行查詢時，實際上是通過讀取View直接得到的接口，讀出所需的內容。這實際是一種形式的讀寫分離。

Kappa架構

Kappa架構原理就是，在Lambda的基礎上進行了優化，輸出了Batch Layer的架構，將數據通道以消息隊列進行替代。因此對應Kappa架構來說，依舊以流處理為主，但是數據卻在數據湖層面進行了存儲，當需求進行離線分析或者再次計算的時候，則將數據湖的數據再次經過消息隊列重播一次即可。

如圖所示，輸入數據直接由實時層數據處理引擎對源源不斷數據進行處理，再由服務層的服務后端進行進一步處理以提供上層業務查詢。而中間結果的數據都是需要存儲的，這些數據包括歷史數據與結果數據，統一存儲再存儲介質中。

從使用場景上來看，Kappa架構與Lambda架構，主要兩點區別：

1. Kappe不是Lambda的替代架構，而是簡化版本，Kappa放棄了對批處理的支持，更擅長業務本身為增量數據寫入場景的分析需求。
2. Lambda直接支持批處理，因此更合適對歷史數據分析查詢的場景。

Kappa架構的優點在于將實時和離線代碼統一起來，方便維護而且統一了數據口徑的問題，避免了Lambda架構中與離線數據合并的問題，查詢歷史數據的時候只需要重放存儲的歷史數據即可。

Kappa架構缺點：

1. 消息中間件緩存的數據量和回溯數據有性能瓶頸。通常算法需要過期180天的數據，如果都存在消息中間件，無疑有非常大的壓力。同時，一次性回溯訂正180天級別的數據，對實時計算的資源消耗也非常大。
2. 在實時數據處理時，遇到大量不同的實時流進行關聯式，非常依賴實時計算系統的能力，很可能因為數據流先后順序問題，導致數據丟失。
3. Kappa在拋棄了離線數據處理模塊的時候，同時拋棄了離線計算更加穩定可靠的特點。Lambda雖然保證了離線計算的穩定性，但雙系統維護成本高且兩套代碼帶來的后期運維困難。

Kappa擴展架構

Kappa+

Kappa+是流式數據處理架構，它的核心思想是讓流計算框架直接讀取HDFS里的數據倉庫數據，一并實現實時計算和歷史數據backFll計算，不需要為backFll作業長期保存日志或者把數據拷貝回消息隊列。開發了Apache hudi框架來存儲數據倉庫數據，hudi支持更新、刪除已有parquet數據，也支持增量消費數據更新部分。

如圖所示，將不同來源的數據通過Kafka導入到Hadoop中，通過HDFS來存儲中間數據，再通過saprk對數據進行分析處理，最后交有上層業務進行查詢。

混合分析系統的Kappa架構

Lambad和Kappa機構都還有展示層的困難點，結果視圖如何支持熱點數據查詢分析，一個解決方案是再Kappa基礎上衍生數據分析流程。

在基于使用Kafka+Flink構建Kappa流計算數據架構，針對Kappa架構分析能力不足的問題，再利用Kafa對接組合ElasticSearch實時分析引擎，部分彌補其數據分析能力。但是ElasticSearch也只適合對合理數據的熱點數據進行索引，無法覆蓋所有批處理相關的分析需求，這種呼喚架構某種意義上屬于Kappa和Lambda間的折中方案。

Lambda架構與Kappa架構對比

根據兩種架構對比分析，將業務需求、技術要求、系統復雜度、開發維護成本和歷史數據處理能力作為考慮因素。而計算機開銷雖然存在一定差別，但是相差不是很大，所以不作為考慮因素。

1. 業務需求與技術要求：如果業務對Hadoop、Spark、Storm等關鍵技術有強依賴性，選擇Lambda架構可能比較合適；如果處理數據偏好于流式計算，又依賴Flink計算引擎，那么選擇Kappa架構可能更為合適。
2. 復雜度：如果項目中需要頻繁地對算法模型參數進行修改，Lambda架構需要反復修改兩套代碼，則顯然不如Kappa架構簡單方便。同時如果算法模型支持同時執行批處理和流式計算，或者希望用一份代碼進行數據處理，那么可以選擇Kappa架構。
3. 開發維護成本：Lambda架構需要一定程度的開發為u胡成本，包括兩套系統的開發、部署、測試、維護，適合有足夠經濟、技術和人力資源的開發者。而Kappa架構只需要一套系統。
4. 歷史數據處理能力：有些情況下，項目回頻繁接觸海量數據集進行分析，應該選擇Lambda架構。如果始終使用小規模數據集，流處理系統完全可以使用，則應該選擇Kappa架構。

對比內容	Lambda架構	Kappa架構
復雜度于開發、維護成本	需要維護兩套系統（引擎），復雜度高，開發、維護成本高	只需要維護一套系統（引擎），復雜度低，開發、維護成本低
計算開銷	需要一直運行批處理和實時計算，計算開銷大	必要時進行全量計算，計算開銷相對較小
實時性	滿足實時性	滿足實時性
歷史數據處理能力	批式全量處理，吞吐量大，歷史數據處理能力強	流式全量處理，吞吐量相對較低，歷史數據處理能力相對較弱

大數據架構設計案例分析

Lambda架構再某網奧運中的大數據應用

Lambda架構實時處理層采用增量計算實時數據的方式，可以再集群規模不變的前提下，秒級分析出當日概覽所需要的信息。賽事回顧模塊需要展現自定義時間段內的歷史最高在線人數、逐日播放走勢、直播最高在線人數和點播視頻排行等海量數據的統計信息，由于奧運期間產生的數據通常不需要被經常索引、更新，因此要求采用不可變方式存儲所有的歷史數據，以保證歷史數據的準確性。

Lambda架構的批處理層用不可變存儲模型，不斷的往主數據集后追加新的數據，恰好可以滿足對奧運數據的大規模統計分析要。具體架構如圖：

Lambda架構在某網廣告平臺的應用與演進

某網廣告平臺展示的數據指標包含兩類：曝光類（包括曝光數、點擊數、點擊單價、花費），轉化類（包括轉化下單數、轉化下單金額、轉化付款數、轉化付款金額）。前一類的數據主要由流量方以接口的方式提供（比如對接騰訊廣點通平臺），后一類則是某網特有的數據，通過買家的流量、下單、付款日志算出來。

第一版架構

第一版采用了典型的Lambda架構形式。

第一版的數據處理比較簡單，性能瓶頸再Java服務層。服務層需要關聯兩張Mysql表，查詢過程很復雜，另一方面實時數據只對接了內部的Kafka消息，沒有實時的獲取第三方的曝光、點擊、瀏覽數據。

批處理層：每天凌晨將Kafka中的瀏覽、下單消息同步到HDFS中，再將HDFS中的日志數據解析成Hive表，用Hive SQL/Spark SQL計算出分區的統計結果Hive表。最終將Hive表導出到Mysql中供服務層讀取，另外一方面，曝光、點擊、花費等外部數據指標則是通過定時任務，調用第三方API，每天定時寫入另外一個Mysql表中。

實時處理層：是用Spark streaming持續監聽Kafka中的下單、付款消息，計算出每個追蹤鏈接維度的轉化數據，存儲再redis中

服務層：是一個Java服務，向外提供http接口，Java服務讀取兩種表和一個Redis數據庫的數據

第二版架構

針對第一版兩個問題，在第二版對數據流的結構做了一些修改。在實時處理層做了一個常駐后臺的Python腳本，不斷調用第三方API的小時報表，更新當日的曝光數據表。

完成第二版改動后，Java服務的計算壓力明顯下降，性能瓶頸變成了redis查詢這一塊

由于redis里的實時數據是業務無關的，僅統計了追蹤鏈接維度的聚合數據。每次查詢當日的轉化數據，需要現在Mysql中查詢出廣告和跟蹤鏈接的關系，找出所有的跟蹤鏈接，再查詢出這寫跟蹤鏈接的統計數據做聚合

另一方面，離線計算的過程中涉及多次Mysql和Hive之間導表操作，離線任務的依賴鏈比較長一旦綽綽，恢復離線任務的時間回比較久

第三版架構

考慮到Mysql方便聚合、方便服務層讀取的優點，在第三版中對Lambda架構做了一些改動，在數據層面只維護一張包含所有指標的Mysql表，Mysql表的stday（統計日期）字段作為索引，stday=當天的保存實時數據，stday<當天的保存離線數據

第三版只維護一張Mysql數據統計表，每天的離線任務會生成兩張Hive表，分別包含轉化數據和曝光數據。這兩種Hive表分別更新Mysql表的stday

在實時數據這塊，常駐后臺的Python腳本更新stday=當天的數據的曝光類字段。spark streaming 程序在處理Kafka中的實時下單消息是，不再統計數據到redis，而是請求業務Java服務暴露出來的更新數據接口。在更新數據的接口中，找到當前下單的追蹤鏈接所屬的廣告，更新Mysql中stday=當天的數據的轉化類字段。這樣就把查詢的關聯操作分散在了每條訂單下的處理過程中，解決了實時數據查詢的瓶頸。最終的Java也只需要讀取一個Mysql表，非常簡潔。

某證券公司大數據系統

實時日志分析平臺基于Kappa架構，使用統一的數據處理引擎Flink可實時處理全部數據，并將其存儲到ElasticSearch與OpenTSDB中，實時處理過程如下：

1. 日志采集：即在各應用系統部署采集組件Filebeat，實時采集日志數據并輸出到Kafka緩存。
2. 日志清洗與解析：基于大數據計算集群的Flink計算框架，實時讀取Kafaka中的日志數據解析清洗和解析，提取日志關鍵內容并轉換成指標，以及對指標解析二次加工形成衍生指標。
3. 日志存儲：將解析后的日志數據分類存儲與ElasticSearch日志庫中，各類基于日志的指標存儲于OpenTSDB指標庫中，供前端組件搜索于查詢。
4. 日志監控：通過單獨警告消息隊列來保存監控的消息的有序管理于實時推送。
5. 日志應用：在充分考慮日志搜索作業需求的基礎上，平臺支持搜索欄常用語句保存，選擇日志變量自動形成搜索表達式，以及快速按時間排序過濾、查看日志上下文等功能。

某電商智能決策大數據系統

實時智能決策大數據平臺基于Kappa架構，使用統一數據處理引擎Flink可實時處理數據流數據，并將存儲到Hive于Tair中，以供后續決策服務的使用，實時處理的過程如下：

=

1. 數據采集：B端系統會實時收集用戶的點擊，下單以及廣告的曝光和出價數據并輸出到Kafka緩存。
2. 數據清洗與聚合：基于大數據計算集群Flink計算框架，實時讀取Kafka中的實時流數據，過濾出需要參與計算的字段，根據業務需求，聚合指定時間端的數據并轉換成指標。
3. 數據存儲：將Flink計算得到數據存儲到Hive日志庫中，需要參與模型計算計算的字段存儲到Tair分布式緩存中。
   覽、下單消息同步到HDFS中，再將HDFS中的日志數據解析成Hive表，用Hive SQL/Spark SQL計算出分區的統計結果Hive表。最終將Hive表導出到Mysql中供服務層讀取，另外一方面，曝光、點擊、花費等外部數據指標則是通過定時任務，調用第三方API，每天定時寫入另外一個Mysql表中。

實時處理層：是用Spark streaming持續監聽Kafka中的下單、付款消息，計算出每個追蹤鏈接維度的轉化數據，存儲再redis中

服務層：是一個Java服務，向外提供http接口，Java服務讀取兩種表和一個Redis數據庫的數據

第二版架構

針對第一版兩個問題，在第二版對數據流的結構做了一些修改。在實時處理層做了一個常駐后臺的Python腳本，不斷調用第三方API的小時報表，更新當日的曝光數據表。

完成第二版改動后，Java服務的計算壓力明顯下降，性能瓶頸變成了redis查詢這一塊

由于redis里的實時數據是業務無關的，僅統計了追蹤鏈接維度的聚合數據。每次查詢當日的轉化數據，需要現在Mysql中查詢出廣告和跟蹤鏈接的關系，找出所有的跟蹤鏈接，再查詢出這寫跟蹤鏈接的統計數據做聚合

另一方面，離線計算的過程中涉及多次Mysql和Hive之間導表操作，離線任務的依賴鏈比較長一旦綽綽，恢復離線任務的時間回比較久

第三版架構

考慮到Mysql方便聚合、方便服務層讀取的優點，在第三版中對Lambda架構做了一些改動，在數據層面只維護一張包含所有指標的Mysql表，Mysql表的stday（統計日期）字段作為索引，stday=當天的保存實時數據，stday<當天的保存離線數據

第三版只維護一張Mysql數據統計表，每天的離線任務會生成兩張Hive表，分別包含轉化數據和曝光數據。這兩種Hive表分別更新Mysql表的stday

在實時數據這塊，常駐后臺的Python腳本更新stday=當天的數據的曝光類字段。spark streaming 程序在處理Kafka中的實時下單消息是，不再統計數據到redis，而是請求業務Java服務暴露出來的更新數據接口。在更新數據的接口中，找到當前下單的追蹤鏈接所屬的廣告，更新Mysql中stday=當天的數據的轉化類字段。這樣就把查詢的關聯操作分散在了每條訂單下的處理過程中，解決了實時數據查詢的瓶頸。最終的Java也只需要讀取一個Mysql表，非常簡潔。