系統架構設計師備考之架構設計實踐知識

1.信息系統架構設計理論與實踐

1.1.基本概念

信息系統架構定義

目前關于信息系統架構較為權威的定義有：
（1）信息系統架構是系統的結構，由軟件元素、元素外部可見屬性和元素間關系組成。
（2）信息系統架構是軟件系統結構、行為和屬性的高級抽象，由系統元素描述、元素間相互作用、元素集成模式及模式約束組成。
（3）信息系統架構是系統的基礎組織，體現為構件、構件間關系、構件和環境間關系、構件設計和演進的原則。
對于定義的理解：
（1）架構是系統的抽象：元素、元素外部可見屬性和元素間關系反映系統的抽象。
（2）架構是結構的組合：結構從功能角度描述元素間關系。
（3）系統必然存在架構：無論是否存在抽象、模型和具體的描述文檔。
（4）架構是元素的集合：元素組成系統，元素外部可見屬性表現系統功能，元素間關系表現系統對外部刺激的響應；從靜態角度，架構關注系統的總體結構（模式）；從動態角度，架構關注系統行為的共同特征。
（5）架構具有基礎特性：架構具有重復性問題的通用解決方案的復用性，架構在系統設計過程中通過設計決策對系統造成深遠影響，這種影響反映架構敏感。
（6）架構隱含設計決策：架構是對關鍵功能和非功能性需求進行設計與決策的最終設計結果。

信息系統架構的影響

影響架構的因素有：
（1）外部干系人：對系統有不同的關注和需求。
（2）內部干系人：知識結構、素質、經驗、技術環境影響需求和設計。
架構對影響因素也具有反作用：
（1）影響外部干系人：業務影響組織結構。
（2）影響內部干系人：架構具有示范性、復用性，提供商機。

1.2.信息系統架構風格與分類

信息系統架構風格

? 數據流體系結構風格：批處理，管道-過濾器。
? 調用/返回體系結構風格：主程序/子程序，面向對象，層次結構。
? 獨立構件體系結構風格：進程通信，事件系統。
? 虛擬機體系結構風格：解釋器，規則系統。
? 倉庫體系結構風格：數據庫，超文本，黑板。

信息系統架構分類

（1）信息系統物理結構包括：①單體應用；②分布式結構。
（2）信息系統邏輯結構如下所述。
1）橫向綜合：將同一管理層次的各個業務職能綜合到一起。
2）縱向綜合：將同一業務的各個管理層次智能綜合到一起。
3）縱橫綜合：將各個業務的各個管理層次統一綜合到一起，主要從信息模型和處理模型兩方面著手，建立公用的數據庫和統一的信息處理系統。

1.3.信息系統常用架構模型

單體應用

單體應用指運行在單臺物理機器上的獨立應用程序。
應用領域就是信息系統領域，也就是以數據處理為核心的系統。

客戶機/服務器

二層C/S（Client/Server）

這是一種胖客戶端，主要是指前臺客戶端 + 后臺數據庫的形式。如圖

三層C/S和B/S（Browser/Server）

1）三層C/S：前臺客戶端+后臺服務端+后臺數據庫，如圖
2）瘦客戶端：前臺界面和業務邏輯處理分離，前臺客戶端僅含前臺界面。
3）三層B/S：Web瀏覽器+Web服務器+后臺數據庫。
B/S 本質是瀏覽器與服務器間采用基于TCP/IP或UDP的HTTP協議。前臺客戶端與后臺服務端通信協議有：TCP/IP 協議，基于 TCP/IP 協議通過 Socket 自定義實現的協議，RPC 協議，CORBA/IIOP 協議，Java RMI 協議，J2EE JMS協議，HTTP協議。

多層C/S和B/S結構

1）多層C/S：是指三層以上的結構，如圖15.4所示。形式是前臺客戶端+后臺服務端+中間件/應用層+數據庫，
其中，中間件/應用層的作用有以下 3 點：①提高并發性能和可伸縮性；②請求轉發，業務邏輯處理；③增加數據安全性。
2）多層B/S：是指三層以上的結構，形式是Web瀏覽器+Web服務器+中間件/應用層+數據庫。

模型-視圖-控制器（Model-View-Controller，MVC）

在 J2EE 架構中，形式是：Web 瀏覽器（View）+ Web 服務器（Controller 也可以是加上中間件/應用層的形式）+數據庫，關于模型層可根據實際情況與MV一起置于Web服務器，或單獨置于應用層。

面向服務架構（SOA）

在SOA中服務的概念是指能提供一組整體功能的獨立應用系統。這個應用系統被去掉任何一層服務，都將不能正常工作。在實踐中，要實現SOA可以借助諸如消息中間件、交易中間件等中間件來實現。SOA的應用模式最典型、最流行的就是Web Service，即兩個互聯網應用之間可以互相向對方開放一些功能模塊、函數、過程等“服務”，然后通過消息機制或遠程過程調用（Remote Procedure Call，RPC）這樣的中間件去調用對方的服務。面向服務架構主要實踐有異構系統集成、同構系統聚合、聯邦架構等。

企業服務總線（ESB）/企業數據總線（EDB）

企業總線是企業應用間信息交換的公共通道，具有如下特征：
? 連接軟件系統，主要提供服務代理功能和服務注冊表。
? 按照協議消息頭進行數據、請求、回復的接收和分發。
? 可以基于消息中間件、事務中間件、CORBA/IIOP協議開發構建。

1.4.企業信息系統總體框架

基本概念

信息系統的架構（Information System Architecture，ISA）是多維度、分層次、高度集成化的模型。

信息系統的架構內容

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

戰略系統

戰略系統是指企業中與戰略制定、高層決策有關的管理活動和計算機輔助系統。戰略系統由企業戰略規劃體系、以計算機為基礎的高層決策支持系統組成。戰略系統是信息系統對企業高層管理者決策支持的能力，也是企業戰略規劃對信息系統建設的影響和要求。企業戰略可以分為長期與短期兩種，長期規劃較為穩定，如調整產品結構。而短期規劃適用于如決定新產品的類型的情況。

業務系統

是指企業中完成一定業務功能的各個部分組成的系統，其中的功能通過一些業務過程來完成，業務過程由一系列相互依賴的業務活動、業務活動先后次序、業務活動執行角色、業務活動處理相關數據組成。業務系統的作用有：①對企業現有業務系統，過程，活動建模；②在企業戰略指導下，采用業務過程重組優化業務過程；③對企業優化業務系統，過程，活動建模；④確定相對穩定數據；⑤以穩定數據為基礎，進行應用系統開發和信息基礎設施建設。

應用系統

應用系統是指信息系統中的應用軟件部分。應用系統包括內部功能和外部界面兩個部分。界面部分是應用系統中相對變化較多的部分，主要由用戶對界面形式要求的變化引起；功能實現部分中，相對來說處理的數據變化較小，而程序的算法和控制結構的變化較多，主要由用戶對應用系統功能需求的變化和對界面形式要求的變化引起。

企業信息基礎設施

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

1.5.信息系統架構設計方法

TOGAF架構框架

TOGAF 是國際權威組織The Open Group（TOG）制訂的企業架構標準框架。TOGAF目標有4個：
（1）節省時間和成本，更有效、合理地利用資源。
（2）實現可觀的投資回報率。
（3）確保從關鍵利益相關方到團隊成員的所有用戶都使用相同的語言。
（4）避免被“鎖定”到企業架構的專有解決方案。
TOGAF的核心思想是模塊化架構，為架構產品提供內容框架，為大型組織開發提供擴展指南，適用于不同架構風格。
TOGAF的組件有架構開發方法、架構開發方法指南和技術、架構內容框架、企業連續序列和工具、架構框架參考模型、架構能力框架。

架構開發方法

架構開發方法（Architecture Development Method，ADM）由一組按照架構領域的架構開發順序而排列成一個環的多個階段所構成。這些階段是：預備、需求管理、架構愿景、業務架構、信息系統架構、技術架構、機會和解決方案、遷移規劃、實施治理、架構變更管理。

信息化內容與模式

信息化包括4個方面的內容：信息網絡體系、信息產業基礎、社會運行環境、效用積累過程。
信息化具有6個要素：開發利用信息資源、建設國家信息網絡、推進信息技術應用、發展信息技術和產業、培育信息化人才、制訂和完善信息化政策。
通常信息化包括了7個平臺：知識管理平臺、日常辦公平臺、信息集成平臺、信息發布平臺、協同工作平臺、公文流轉平臺、企業通信平臺。
信息化也具有9個特征：易用性、健壯性、平臺化、靈活性、擴展性、安全性、門戶化、整合性、移動性。
信息化架構具有兩種模式：
（1）數據導向架構。關注數據模型和數據質量。
（2）流程導向架構。關注端到端流程整合及對流程變化的適應度。

信息化建設生命周期

信息化建設生命周期具體分為：系統規劃、系統分析、系統設計、系統實施、系統運行和維護幾個階段。

信息化工程總體規劃方法

信息化工程總體規劃方法主要有：
（1）關鍵成功因素法（Critical Success Factors，CSF）。關鍵成功因素指的是對企業的成功起關鍵作用的因素。CSF 就是通過分析找出使得企業成功的關鍵因素，然后再圍繞這些關鍵因素來確定系統的需求，并進行規劃。
（2）戰略目標集轉化法（Strategy Set Transformation，SST）。SST 反映了各種人的要求，而且給出了按這種要求的分層，然后轉化為信息系統目標的結構化方法。
（3）企業系統規劃法（Business System Planning，BSP）。BSP 通過自上而下地識別系統目標、企業過程和數據，然后對數據進行分析，自下而上地設計信息系統。

2.層次式架構設計理論與實踐

2.1.層次式體系結構概述

定義

軟件體系結構為軟件系統提供了結構、行為和屬性的高級抽象，由構成系統的元素描述這些元素的相互作用、指導元素集成的模式以及這些模式的約束組成。層次式體系結構設計是一種常見的架構設計方法，它將系統組成為一個層次結構，每一層為上層服務，并作為下層客戶。在一些層次系統中，除了一些精心挑選的輸出函數外，內部的層接口只對相鄰的層可見。層次式體系結構的每一層最多只影響兩層，同時只要給相鄰層提供相同的接口，也允許每層用不同的方法實現，這種方式也為軟件重用提供了強大的支持。

層次式應用的組成

大部分的應用會分成表現層（或稱為展示層）、中間層（或稱為業務層）、訪問層（或稱為持久層）和數據層，如圖

特點與注意事項

采用分層架構設計的一個特點就是關注點分離。每層中的組件只負責本層的邏輯，組件的劃分也很容易明確組件的角色和職責，比較容易開發、測試、管理和維護。層次式體系結構是一個可靠的通用的架構，但是設計時要注意以下兩點：
1）容易成為污水池反模式（Architecture Sinkhole Anti-patter）：請求流簡單地穿過幾個層，每層里面基本沒有做任何業務邏輯，或者做了很少的業務邏輯。比如一些 Java EE 例子，業務邏輯層只是簡單地調用了持久層的接口，本身沒有什么業務邏輯。
2）分層架構可能會讓應用變得龐大。

2.2.表現層框架設計

MVC模式

MVC 是一種軟件設計模式。MVC 把一個應用的輸入、處理、輸出流程按照視圖、控制、模型的方式進行分離，形成了控制器、模型、視圖3個核心模塊。其中：
（1）控制器（Controller）：接受用戶的輸入，并調用模型和視圖去完成用戶的需求。
（2）模型（Model）：應用程序的主體部分，表示業務數據和業務邏輯。
（3）視圖（View）：用戶看到并與之交流的界面。
三者協作關系如圖
使用MVC 模式來設計表現層，可以有以下的優點：
（1）允許多種用戶界面的擴展。
（2）易于維護。
（3）易于構建功能強大的用戶界面。
（4）增加應用的可拓展性、強壯性、靈活性。

MVP模式

在MVP模式中Model提供數據，View負責顯示，Controller/Presenter負責邏輯的處理。MVP不僅僅避免了View和Model之間的耦合，還進一步降低了Presenter對View的依賴。MVP設計模式如圖
使用MVP模式來設計表現層，可以有以下的優點：
（1）模型與視圖完全分離，可以修改視圖而不影響模型。
（2）所有的交互都發生在一個地方—Presenter內部，因此可以更高效地使用模型。
（3）可以將一個Presenter 用于多個視圖，而不需要改變 Presenter 的邏輯。因為視圖的變化總是比模型的變化頻繁。
（4）如果把邏輯放在Presenter中，就可以脫離用戶接口來測試這些邏輯（單元測試）

MVVM模式

MVVM和MVC、MVP類似，主要目的都是為了實現視圖和模型的分離。不同的是MVVM中，View與Model的交互通過ViewModel來實現，也就是View和Model不能直接通信，兩者的通信只能通過ViewModel來實現。ViewModel是MVVM的核心，通過DataBinding實現View與Model之間的雙向綁定，其內容包括數據狀態處理、數據綁定及數據轉換。MVVM流程設計模式如圖

2.3.中間層框架設計

業務邏輯層組件設計

業務邏輯層組件分為接口和實現類兩個部分。接口用于定義業務邏輯組件，定義業務邏輯組件必須實現的方法是整個系統運行的核心。通常按模塊來設計業務邏輯組件，每個模塊設計一個業務邏輯組件，并且每個業務邏輯組件以多個數據訪問對象（Data Access Object，DAO）組件作為基礎，從而實現對外提供系統的業務邏輯服務。

業務邏輯層工作流設計

工作流管理聯盟（Workflow Management Coalition，WFMC）將工作流定義為：業務流程的全部或部分自動化，在此過程中，文檔、信息或任務按照一定的過程規則流轉，實現組織成員間的協調工作以達到業務的整體目標。工作流參考模型如圖

業務邏輯層實體設計

邏輯層實體提供對業務數據及相關功能（在某些設計中）的狀態編程訪問。業務邏輯層實體可以使用具有復雜架構的數據來構建，這種數據通常來自數據庫中的多個相關表。業務邏輯層實體數據可以作為業務過程的部分I/O參數傳遞。業務邏輯層實體是可序列化的，以保持它們的當前狀態。

業務邏輯層框架

業務邏輯框架位于系統架構的中間層，是實現系統功能的核心組件。采用容器的形式，便于系統功能的開發、代碼重用和管理。在業務容器中，業務邏輯是按照 Domain Model-Service-Control思想來實現的。其中：
1）Domain Model?是僅僅包含業務相關的屬性的領域層業務對象。
2）Service?是業務過程實現的組成部分，是應用程序的不同功能單元，通過在這些服務之間定義良好的接口和契約聯系起來。
3）Control 服務控制器，是服務之間的紐帶，不同服務之間的切換就是通過它來實現的。

2.4.數據訪問層設計

數據訪問模式

在線訪問

最常用的方式。訪問占用一個數據庫連接，讀取數據，每個數據庫操作都會通過這個連接不斷地與后臺的數據源進行交互。

Data Access Object

DAO 是標準J2EE 設計模式，這種方式將底層數據訪問操作與高層業務邏輯分離開。一個典型的DAO實現通常會有一個DAO工廠類、一個DAO接口、一個實現了DAO 接口的具體類、數據傳輸對象。

Data Transfer Object

DTO 屬于 EJB 設計模式之一。DTO是一組對象或容器，需要跨越不同的進程或是網絡的邊界來傳輸數據。

離線數據模式

離線數據模式是以數據為中心，數據從數據源獲取之后，將按照某種預定義的結構存放在系統中，成為應用的中心。這種方式對數據的各種操作獨立于各種與后臺數據源之間的連接或是事務。

對象/關系映射

這種方式利用工具或平臺能夠幫助將應用程序中的數據轉換成關系型數據庫中的記錄；或是將關系數據庫中的記錄轉換成應用程序中代碼便于操作的對象。

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

工廠模式定義一個用于創建對象的接口，讓子類決定實例化哪一個類。工廠方法使一個類的實例化延遲到其子類。這里可能會處理對多種數據庫的操作，因此，需要首先定義一個操縱數據庫的接口，然后根據數據庫的不同，由類工廠決定實例化哪個類。

ORM,Hibernate與CMP2.0設計思想

ORM（Object-Relation Mapping）在關系型數據庫和對象之間作一個映射，這樣，在具體操縱數據庫時，就不需要再去和復雜的 SQL 語句打交道，只要像平時操作對象一樣操作即可。Hibernate 是一個功能強大，可以有效地進行數據庫數據到業務對象的 O/R 映射方案。Hibernate 推動了基于普通 Java 對象模型，用于映射底層數據結構的持久對象的開發。

XML Schema

XML Schema 用來描述XML文檔合法結構、內容和限制，提供豐富的數據類型。

事務處理設計

事務必須服從 ISO/IEC 所制定的 ACID 原則。ACID 是原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）和持久性（Durability）的縮寫。
事務的原子性表示事務執行過程中的任何失敗都將導致事務所做的任何修改失效。
一致性表示當事務執行失敗時，所有被該事務影響的數據都應該恢復到事務執行前的狀態。隔離性表示在事務執行過程中對數據的修改，在事務提交之前對其他事務不可見。
持久性表示已提交的數據在事務執行失敗時，數據的狀態都應該正確。

連接對象管理設計

建立一個數據庫連接池，提供一套高效的連接分配、使用策略，保證了數據庫連接的有效復用

2.5.數據架構規劃與設計

數據庫設計與類的設計融合

對類和類之間關系的正確識別是數據模型的關鍵所在。好模型的目標是將工程項目整個生存期內的花費減至最小，同時也會考慮到隨時間的推移系統將可能發生的變化，因而設計時也要考慮能適應這些變化。

數據設計與XML設計融合

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

2.6.物聯網層次架構設計

感知層

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

網絡層

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

應用層

實現廣泛智能化。應用層是物聯網與行業專業技術的深度融合，結合行業需求實現行業智能化，這類似于人們的社會分工。

3.云原生架構設計理論與實踐

3.1.云原生架構內涵

定義

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

特點

（1）代碼結構發生巨大變化：不再需要掌握文件及其分布式處理技術，不再需要掌握各種復雜的網絡技術，簡化讓業務開發變得更敏捷、更快速。
（2）非功能性特性大量委托給云原生架構來解決：比如高可用能力、容災能力、安全特性、可運維性、易用性、可測試性、灰度發布能力等。
（3）高度自動化的軟件交付：基于云原生的自動化軟件交付可以把應用自動部署到成千上萬的節點上。

云原生的原則

?（1）服務化原則：通過服務化架構把不同生命周期的模塊分離出來，分別進行業務迭代。
（2）彈性原則：彈性是指系統的部署規模可以隨著業務量的變化而自動伸縮。
（3）可觀測原則：通過日志、鏈路跟蹤和度量等手段，使得多次服務調用的耗時、返回值和參數都清晰可見。
（4）韌性原則：軟件所依賴的軟硬件組件出現各種異常時，軟件表現出來的抵御能力。
（5）所有過程自動化原則：讓自動化工具理解交付目標和環境差異，實現整個軟件交付和運維的自動化。
（6）零信任原則：不應該信任網絡內部和外部的任何人/設備/系統，需要基于認證和授權重構訪問控制的信任基礎。
（7）架構持續演進原則：架構具備持續演進能力。

主要架構模式

服務化架構模式

要求以應用模塊為顆粒度劃分一個應用軟件，以接口契約（例如IDL）定義彼此業務關系，以標準協議（HTTP、gRPC等）確保彼此的互聯互通，結合領域模型驅動（Domain Driven Design，DDD）、測試動開發（Test Driven Design，TDD）、容器化部署提升每個接口的代碼質量和迭代速度。

Mesh化架構模式

Mesh化架構是把中間件框架（如 RPC、緩存、異步消息等）從業務進程中分離，讓中間件SDK與業務代碼進一步解耦，從而使得中間件升級對業務進程沒有影響，甚至遷移到另外一個平臺的中間件也對業務透明。

Serverless 模式

業務流量到來/業務事件發生時，云會啟動或調度一個已啟動的業務進程進行處理，處理完成后云自動會關閉/調度業務進程，等待下一次觸發。開發者不用關心應用運行地點、操作系統、網絡配置、CPU性能等，將應用的整個運行都委托給云。Serverless模式適合事件驅動的數據計算任務、計算時間短的請求/響應應用、沒有復雜相互調用的長周期任務。

存儲計算分離模式

分布式環境中的 CAP 困難主要是針對有狀態應用，由于一致性（Consistency，C），可用性（Availability，A），分區容錯性（Partition Tolerance，P）三者無法同時滿足，最多滿足其中兩個。所以無狀態應用不存在一致性這個維度，可以獲得很好的可用性和分區容錯性，因而獲得更好的彈性。

分布式事務模式

由于業務需要訪問多個微服務，所以會帶來分布式事務問題，否則數據就會出現不一致。因此架構師需要根據不同的場景選擇合適的分布式事務模式，常用的有：
?XA模式（傳統采用XA模式）：由于XA規范是實現分布式事務處理的標準，通常采用兩階段提交（2 Prepare Commit，2PC）的方法，具有很強的一致性，但是由于需要兩次網絡交互，所以性能差。
基于消息的最終一致性（BASE）：在可用性和一致性相沖突的情況下，為了權衡二者，BASE 提出只要滿足基本可用（BA）和最終一致性（E），接受數據的軟狀態或未確定狀態（S），來優先實現性能，所以這類系統通常具備很高的性能。但正是由于應用的特點，選擇可用性和一致性的妥協方案，導致通用性有限。
TCC模式：采用Try-Confirm-Cancel二階段模式，事務隔離性可控，高效，但需要應用代碼將業務模型拆成二階段，所以對業務侵入性強，設計開發維護等成本很高。
SAGA模式：每個正向事務都對應一個補償事務，若正向事務執行失敗，則會執行補償事務進行回滾。所以開發維護成本高。
開源項目SEATA的AT模式：它將TCC模式中的二階段委托給底層代碼框架，并且取消了行鎖，所以非常高性能且無代碼開發工作量，且可以自動執行回滾操作，但存在一些使用場景限制。

可觀測架構

可觀測架構包括Logging、Tracing、Metrics，其中 Logging 提供多個級別跟蹤，例如INFO/ DEBUG/WARNING/ERROR；Tracing 收集一個請求從前端到后端的訪問日志聚合，形成完整調用鏈路跟蹤；Metrics 則提供對系統量化的多維度度量，包括并發度、耗時、可用時長、容量等。

事件驅動架構

事件驅動架構（Event Driven Architecture，EDA）是一種應用/組件間的集成架構模式。適用于增強服務韌性、數據變化通知、構建開放式接口、事件流處理、命令查詢的責任分離（Command Query Responsibility Segregation，CQRS）把對服務狀態有影響的命令用事件來發起，而對服務狀態沒有影響的查詢才使用同步調用的API接口等。

典型的云原生架構反模式

架構設計有時候需要根據不同的業務場景選擇不同的方式，常見的云原生反模式有：
（1）龐大的單體應用：缺乏依賴隔離，代碼耦合，責任和模塊邊界不清晰，模塊間接口缺乏治理，變更影響擴散，不同模塊間的開發進度和發布時間要求難以協調，一個子模塊不穩定導致整個應用都變慢，擴容時只能整體擴容而不能對達到瓶頸的模塊單獨擴容等。
（2）單體應用“硬拆”為微服務：強行把耦合度高、代碼量少的模塊進行服務化拆分；拆分后服務的數據是緊密耦合的；拆分后成為分布式調用，嚴重影響性能。
（3）缺乏自動化能力的微服務：人均負責模塊數上升，人均工作量增大，也增加了軟件開發成本。

3.2.云原生架構相關技術

容器技術

容器作為標準化軟件基礎單元，它將應用及其所有依賴項打包發布，由于依賴項齊備，應用不再受環境限制，在不同計算環境間快速、可靠地運行。容器部署模式與其他模式的比較如圖

容器編排技術

容器編排技術包括資源調度、應用部署與管理、自動修復、服務發現與負載均衡、彈性伸縮、聲明式API、可擴展性架構、可移植性。

微服務

微服務模式將后端單體應用拆分為松耦合的多個子應用，每個子應用負責一組子功能。這些子應用稱為“微服務”，多個“微服務”共同形成了一個物理獨立但邏輯完整的分布式微服務體系。這些微服務相對獨立，通過解耦研發、測試與部署流程，提高整體迭代效率。微服務設計約束如下：
（1）微服務個體約束：微服務應用的功能在業務領域劃分上應是相互獨立的。
（2）微服務與微服務之間的橫向關系：在合理劃分好微服務間的邊界后，從可發現性和可交互性處理微服務間的橫向關系。可發現性是指當服務A發布和擴/縮容的時候，依賴服務A的服務B在不重新發布的前提下，能夠自動感知到服務A的變化。可交互性是指服務A 采用什么樣的方式可以調用服務B。
（3）微服務與數據層之間的縱向約束：提倡數據存儲隔離（Data Storage Segregation，DSS）原則，對于數據的訪問都必須通過相對應的微服務提供的 API來訪問。
（4）全局視角下的微服務分布式約束：高效運維整個系統，從技術上實現全自動化的CI/CD流水線滿足對開發效率的訴求，并在這個基礎上支持藍綠、金絲雀等不同發布策略，以滿足對業務發布穩定性的訴求。

無服務器技術

無服務器技術的特點：
（1）全托管的計算服務—客戶只需要編寫代碼構建應用，無須關注同質化的、負擔繁重的基于服務器等基礎設施的開發、運維、安全、高可用等工作。
（2）通用性—結合云 BaaS（后端云服務）API 的能力，能夠支撐云上所有重要類型的應用。
（3）自動彈性伸縮—讓用戶無須為資源使用提前進行容量規劃。
（4）按量計費—讓企業的使用成本有效降低，無須為閑置資源付費。無服務器技術的關注點是：計算資源彈性調度（容錯、資源利用率、性能、數據驅動）、負載均衡和流控、安全性。

服務網格

服務網格旨在將那些微服務間的連接、安全、流量控制和可觀測等通用功能下沉為平臺基礎設施，實現應用與平臺基礎設施的解耦。圖17.3展示了服務網格的典型架構。服務A調用服務B的所有請求，都被其下的服務代理截獲，代理服務A完成到服務B 的服務發現、熔斷、限流等策略，而這些策略的總控是在控制平面（Control Plane）

3.3.容器技術

容器作為標準化軟件基礎單元，它將應用及其所有依賴項打包發布，由于依賴項齊備，應用不再受環境限制，在不同計算環境間快速、可靠地運行。容器部署模式與其他模式的比較如圖

4.面向服務架構設計理論與實踐

4.1.SOA的相關概念

SOA的定義

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

業務流程與業務流程執行語言

業務流程是指為了實現某種業務目的行為所進行的流程或一系列動作。使用BPEL，用戶可以通過組合、編排和協調 Web 服務自上而下地實現面向服務的體系結構。BPEL 目前用于整合現有的 Web Services，將現有的 Web Services 按照要求的業務流程整理成為一個新的Web Services，在這個基礎上，形成一個從外界看來和單個Service一樣的Service。

4.2.SOA的發展歷史

發展過程

（1）萌芽階段：這種廣泛使用的XML，允許組織定義文檔的元數據，實現企業內部和企業之間的電子數據交換，規定了服務之間以及服務內部數據交換的格式和結構。
（2）標準化階段：國際標準和規范—簡單對象訪問協議（Simple Object Access Protocol，SOAP）、Web服務描述語言（Web Services Description Language，WSDL）及通用服務發現和集成協議（Universal Description, Discovery and Integration，UDDI）。
（3）成熟應用階段：3個重量級規范—SCA、SDO、WS-Policy。SCA 和SDO 構成了SOA編程模型的基礎，而WS-Policy 建立了SOA 組件之間安全交互的規范。

SOA與微服務的區別

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

4.3.SOA的參考架構

業務邏輯服務

用于實現業務邏輯的服務和執行業務邏輯的能力，其中包括業務應用服務（Business Application Service）、業務伙伴服務（Partner Service）以及應用和信息資產（Application and Information Asset）。

控制服務

包括實現人（People）、流程（Process）和信息（Information）集成的服務，以及執行這些集成邏輯的能力。

連接服務

通過提供企業服務總線，實現分布在各種架構元素中服務間的連接性。

業務創新與優化服務

用于監控業務系統運行時服務的業務性能，并通過及時了解到的業務性能和變化，采取措施適應變化的市場。

開發服務

貫徹整個軟件開發生命周期的開發平臺，從需求分析到建模、設計、開發、測試和維護等全面的工具支持。

IT服務管理

支持業務系統運行的各種基礎設施管理能力或服務，如安全服務、目錄服務、系統管理和資源虛擬化。

4.4.SOA主要協議和規范

UDDI協議

統一描述、發現和集成協議。包含了服務描述與發現的標準規范，它使得商業實體能夠彼此發現；定義它們怎樣在Internet 上互相作用，并在一個全球的注冊體系架構中共享信息。

Web服務描述語言

WSDL是一個用來描述Web服務和說明如何與Web服務通信的XML語言。描述了Web服務的3個基本屬性。
1）服務做些什么—服務所提供的操作（方法）。
2）如何訪問服務—和服務交互的數據格式以及必要協議。
3）服務位于何處—協議相關的地址，如 URL。

SOAP協議

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

REST規范

為了讓不同的軟件或者應用程序在任何網絡環境下都可以進行信息的互相傳遞。微服務對外就是以REST API的形式暴露給調用者。RESTful即REST形式的，是對遵循REST 設計思想同時滿足設計約束的一類架構設計或應用程序的統稱，這一類都可稱為RESTful，可以理解為資源表述性狀態轉移：
1）資源：將互聯網中一切暴露給客戶端的事物都可以看作是一種資源。
2）表述：REST 中用表述描述資源在Web中某一個時間的狀態。
3）狀態轉移：分為兩種，應用狀態—對某個時間內用戶請求會話相關信息的快照，保存在客戶端。資源狀態—在服務端保存，是對某個時間資源請求表述的快照。
4）超鏈接：通過在頁面中嵌入鏈接和其他資源建立聯系。

4.5.SOA設計的標準要求

文檔標準化

SOA服務具有平臺獨立的自我描述XML文檔。Web服務描述語言是用于描述服務的標準語言

通信協議標準

SOA服務用消息進行通信，該消息通常使用XML Schema來定義（也稱作XML Schema Definition，XSD）

應用程序統一登記與集成

在一個企業內部，SOA 服務通過一個扮演目錄列表（Directory Listing）角色的登記處（Registry）來進行維護。應用程序在登記處（Registry）尋找并調用某項服務。統一描述、定義和集成是服務登記的標準。

服務質量（QoS）

1）可靠性：服務消費者和服務提供者之間傳輸文檔時的傳輸特性（且僅僅傳送一次、最多傳送一次、重復消息過濾、保證消息傳送）。
2）安全性：Web 服務安全規范用來保證消息的安全性。
3）策略：服務提供者有時候會要求服務消費者與某種策略通信。例如，服務提供商可能會要求消費者提供 Kerberos安全標示才能取得某項服務。
4）控制：在SOA中，進程是使用一組離散的服務創建的。BPEL4WS或者WSBPEL（Web Service Business Process Execution Language）是用來控制這些服務的語言。
5）管理：針對運行在多種環境下的所有服務，必須有一個統一管理系統，以便系統管理員能夠有效管理。任何根據 WSDM 實現的服務都可以由一個 WSDM 適應（WSDM-compliant）的管理方案來管理。

4.6.SOA的作用與設計原則

主要作用

打破信息孤島，把應用和資源轉換成服務。以及把這些服務變成標準的服務，形成資源的共享。

設計原則

1）無狀態。以避免服務請求者依賴于服務提供者的狀態。
2）單一實例。以高內聚的實現方法，來避免功能冗余。
3）明確定義的接口。服務的接口由 WSDL 定義，用于指明服務的公共接口與其內部專用實現之間的界線。
4）自包含和模塊化。服務封裝了那些在業務上穩定、重復出現的活動和組件，實現服務的功能實體是完全獨立自主的，獨立進行部署、版本控制、自我管理和恢復。
5）粗粒度。服務數量不應該太大，依靠消息交互而不是遠程過程調用（Remote Procedure Call，RPC），通常消息量較大，但是服務之間的交互頻度較低。
6）服務之間的松耦合性。服務使用者看到的是服務的接口，其位置、實現技術和當前狀態等對使用者是不可見的，服務私有數據對服務使用者是不可見的。
7）重用能力。服務應該是可以復用的。
8）互操作性、兼容和策略聲明。為了確保服務規約的全面和明確，利用策略來定義可配置的互操作語義，來描述特定服務的期望、控制其行為。利用策略聲明確保服務期望和語義兼容性方面的完整和明確。

4.7.SOA的設計模式

服務注冊表模式

服務注冊表支持驅動SOA治理的服務合同、策略和元數據的開發、發布和管理。
（1）服務注冊：應用開發者，也叫服務提供者，向注冊表公布它們的功能。
（2）服務位置：也就是服務應用開發者，幫助它們查詢注冊服務，尋找符合自身要求的服務。
（3）服務綁定：服務的消費者利用檢索到的服務合同來開發代碼，開發的代碼將與注冊的服務綁定、調用注冊的服務以及與它們實現互動。

企業服務總線模式

企業服務總線模式提供一種標準的軟件底層架構，各種程序組件能夠以服務單元的方式“插入”到該平臺上運行，并且組件之間能夠以標準的消息通信方式來進行交互。其核心功能如下：
（1）提供位置透明性的消息路由和尋址服務。程序組件之間無須關注對方的路由和尋址。
（2）提供服務注冊和命名的管理功能。
（3）支持多種消息傳遞范型（如請求/響應、發布/訂閱等）。
（4）支持多種可以廣泛使用的傳輸協議。
（5）支持多種數據格式及其相互轉換。
（6）提供日志和監控功能。

微服務模式

微服務架構將一個大型的單個應用或服務拆分成多個微服務，可擴展單個組件而不是整個應用程序堆棧，從而滿足服務等級協議。微服務架構圍繞業務領域將服務進行拆分，每個服務可以獨立進行開發、管理和迭代，彼此之間使用統一接口進行交流，實現了在分散組件中的部署、管理與服務功能，使產品交付變得更加簡單，從而達到有效拆分應用，實現敏捷開發與部署的目的。微服務模式的特點如下：
（1）復雜應用解耦：微服務架構將單一模塊應用分解為多個微服務，同時保持總體功能不變。
（2）獨立：微服務在系統軟件生命周期中是獨立開發、測試及部署的。
（3）技術選型靈活：微服務架構下系統應用的技術選型是去中心化的，每個開發團隊可根據自身應用的業務需求發展狀況選擇合適的體系架構與技術。
（4）容錯：由于各個微服務相互獨立，故障會被隔離在單個服務中，并且系統其他微服務可通過重試、平穩退化等機制實現應用層的容錯，從而提高系統應用的容錯性。
（5）松耦合，易擴展：微服務架構中每個服務之間都是松耦合的，可以根據實際需求實現獨立擴展，體現微服務架構的靈活性。單體應用架構與微服務架構的示意如圖18.4所示。

微服務架構模式方案

微服務架構模式方案主要包括：
（1）聚合器微服務：聚合器充當流程指揮者，調用多個微服務實現系統應用程序所需功能。
（2）鏈式微服務：客戶端或服務在收到請求后，會發生多個服務間的嵌套遞歸調用，返回經過合并處理的響應。
（3）數據共享微服務：該模式適用于在單體架構應用到微服務架構的過渡階段，服務之間允許存在強耦合關系，例如存在多個微服務共享緩存與數據庫存儲的現象。
（4）異步消息傳遞微服務：對于一些不必要以同步方式運行的業務邏輯，可以使用消息隊列代替REST實現請求、響應，加快服務調用的響應速度。

微服務架構面臨的問題與挑戰

（1）服務發現與服務調用鏈跟蹤變得困難。
（2）很難實現傳統數據庫的強一致性，轉而追求最終一致性。

4.8.構建SOA架構時應該注意的問題

原有系統架構中的集成需求

應用程序集成的需求、終端用戶界面集成的需求、流程集成的需求以及已有系統信息集成的需求。

服務粒度的控制以及無狀態服務的設計

1）服務粒度的控制：對于將暴露在整個系統外部的服務推薦使用粗粒度的接口，而相對較細粒度的服務接口通常用于企業系統架構的內部。
2）無狀態服務的設計：SOA系統架構中的具體服務應該都是獨立的、自包含的請求，在實現這些服務的時候不需要前一個請求的狀態，也就是說服務不應該依賴于其他服務的上下文和狀態，即SOA架構中的服務應該是無狀態的服務。

4.9.SOA實施的過程

選擇SOA解決方案

1）盡量選擇能進行全局規劃的方案。
2）選擇時充分考慮企業自身的需求。
3）從平臺、實施等技術方面進行考察。

業務流程分析

1）建立服務模型：自頂向下分解法、業務目標分析法、自底向上分析法。
2）建立業務流程：建立業務對象（實體、過程、事件等業務對象）、建立服務接口、建立服務流程。

5.嵌入式系統架構設計理論與實踐

5.1.嵌入式系統發展歷程

5.2.嵌入式系統硬件

傳統嵌入式系統

傳統嵌入式系統主要硬件包括：
（1）微處理器：微控制器（MCU），微處理器（MPU）
（2）存儲器：RAM、ROM。
（3）總線：內總線，外總線。
（4）定時器/計數器（Timer）。
（5）看門狗（WatchDog）
（6）I/O接口：串口，網絡，USB，JTAG。
（7）外部設備：UART，LED。

嵌入式處理器的分類

嵌入式處理器可以分為：
（1）微處理器（Micro Processor Unit，MPU）。特點是體積小，重量輕，成本低，可靠性高，但技術保密性差。
（2）微控制器（Micro Control Unit，MCU）。特點是單片化，體積小，功耗低，成本低，可靠性更高。
（3）信號處理器（Digital Signal Processor，DSP）。特點是系統結構和指令采用特殊設計，通常采用哈佛結構，編譯效率高，指令執行速度也高。
（4）圖形處理器（Graphics Processing Unit，GPU）。專注于浮點運算，彌補了CPU運算速度不足。
（5）片上系統（System on Chip，SoC）。采用了片內再編程技術，可使片上系統內硬件的功能像軟件一樣通過編程來配置，從而可以實時地進行靈活而方便的修改和開發。

存儲器

（1）隨機存取存儲器（Random Access Memory，RAM）。它的特點是一旦系統斷電，存放在里面的所有數據和程序都會自動清空掉，并且再也無法恢復。根據組成元件的不同，RAM內存又可分為以下18種：①動態隨機存取存儲器（DRAM）；②靜態隨機存取存儲器（SRAM）；③視頻內存（VRAM）；④快速頁切換模式動態隨機存取存儲器（FPM DRAM）；⑤延伸數據輸出動態隨機存取存儲器（EDO DRAM）；⑥爆發式延伸數據輸出動態隨機存取存儲器（BEDO DRAM）；⑦多插槽動態隨機存取存儲器（MDRAM）；⑧窗口隨機存取存儲器（WRAM）；⑨高頻動態隨機存取存儲器（RDRAM）；⑩同步動態隨機存取存儲器（SDRAM）；?同步圖形隨機存取存儲器（SGRAM）；?同步爆發式靜態隨機存取存儲器（SB SRAM）；?管線爆發式靜態隨機存取存儲器（PB SRAM）；?二倍速率同步動態隨機存取存儲器（DDR SDRAM）；?同步鏈環動態隨機存取存儲器（SLDRAM）；?同步緩存動態隨機存取存儲器（CDRAM）；?第二代同步雙倍速率動態隨機存取存儲器（DDRII）；?直接內存總線動態隨機存取存儲器（DRDRAM）。
（2）只讀存儲器（Read Only Memory，ROM）。ROM在元件正常工作的情況下，其中的代碼數據將永久保存，并且不能夠進行修改。ROM一般應用于PC系統程序碼和主機板BIOS上。ROM可以分為以下5種：①掩模型只讀存儲器（MASK ROM）；②可編程只讀存儲器（PROM）；③可擦可編程只讀存儲器（EPROM）；④電可擦可編程只讀存儲器（EEPROM）；⑤快閃存儲器（FlashMemory）。

總線

總線是功能部件間傳輸信息的公共通信干線。總線的拓撲結構有星型、樹狀、環型、總線型和交叉開關型等5種。總線的類型可以按照計算機所傳輸的信息種類、按連接部件進行劃分。
（1）按照計算機所傳輸的信息種類可以分為：數據總線：用于處理器與RAM間傳輸待處理和待存儲的數據。地址總線：用于傳輸RAM中存儲數據的地址。控制總線：用于傳輸處理器控制單元信號到周邊設備。
（2）按連接部件分類。片內總線：內部總線，連接ALU、寄存器、指令部件等芯片內部元件。系統總線：內部總線，又稱板級總線，連接微控制器/處理器，主存，I/O接口。局部總線：內部總線，連接少量組件用于交換數據。通信總線：外部總線，又稱外設總線，連接外部設備或外部系統。

看門狗

看門狗為嵌入式系統提供必需的系統恢復能力，在系統發生軟件問題和程序跑飛時重新啟動系統。它的基本原理是由計數器自動計數，程序定期將其重置，如果系統卡死或程序跑飛，計數器溢出，進入中斷處理，在設定時間間隔內，系統保留狀態后復位重啟。

5.3.嵌入式系統軟件

嵌入式操作系統的定義及特點

嵌入式操作系統（Embedded Operating System，EOS）是指用于嵌入式系統的操作系統。與通用的操作系統相比，嵌入式操作系統具有：可剪裁性，可移植性，強實時性，強緊湊性，高質量代碼，強定制性，標準接口，強穩定性，弱交互性，強確定性，操作簡捷、方便，較強的硬件適應性，可固化性的特點。

嵌入式系統的架構

嵌入式操作系統分為面向控制、通信領域以及面向消費電子產品兩類。嵌入式操作系統的架構如圖

嵌入式操作系統的基本功能

操作系統內核架構

1）宏內核。用于管理用戶程序和硬件間的系統資源，在宏內核中用戶服務和內核服務在同一空間中實現，代碼耦合度非常高，內核的功能組件代碼可以互相調用。
2）微內核。微內核管理所有系統資源，在微內核中用戶服務和內核服務在不同空間中實現，系統結構清晰，代碼量少。

任務管理

任務是嵌入式操作系統調度最小單位，類似于計算機操作系統中進程的概念。
任務有3種工作狀態：
1）執行狀態：任務獲得處理機，程序在處理機中執行。
2）就緒狀態：任務已獲得處理機以外資源，待獲得處理機即可執行。
3）阻塞狀態：執行狀態任務因等待事件發生無法執行而放棄處理機。
嵌入式操作系統大都支持優先級搶占調度算法和時間片輪轉調度算法。在實時系統的任務調度中，存在大量的實時調度方法，大致可以分為：
1）離線調度算法：系統運行前確定調度信息，如時間驅動，確定性，缺乏靈活性。
2）在線調度算法：系統運行中動態獲得調度信息，如優先級驅動，靈活性較大。
3）搶占調度算法：運行任務可能被打斷，更復雜，更耗資源。
4）非搶占調度算法：運行任務不被打斷。
5）靜態調度算法：任務優先級在設計時確定，不變化，簡單，缺乏靈活性。
6）動態調度算法：任務優先級在運行中確定，不斷變化，靈活，耗資源。
實時調度算法中還有強實時調度算法，具體可以分為：
1）最早截止時間優先（Earliest Deadline First，EDF）調度算法：根據任務截止時間確定優先級，截止時間越早，其優先級越高。
2）最低松弛度優先（Least Laxity First，LLF）調度算法：根據任務緊急或松弛程度確定優先級，緊急程度越高，優先級越高。
3）單調速率（Rate Monotonic Scheduling，RMS）調度算法：根據任務周期確定有限期，周期越短，優先級越高。這種算法被認為是最優的。

存儲管理

存儲管理的主要目的是解決多個用戶使用主存的問題，
存儲管理方法主要包括分區、分頁、分段、段頁式存儲管理以及虛擬存儲管理等。

任務間通信

任務間通信管理也是嵌入式操作系統的關鍵功能之一。它主要為操作系統的應用程序提供多種類型的數據傳輸、任務同步/異步操作等手段。

嵌入式數據庫

嵌入式數據庫具有嵌入式、實時性、移動性、伸縮性的特點。嵌入式數據庫可以按照如下方式分類：
（1）按嵌入對象分為：軟件嵌入數據庫、設備嵌入數據庫、內存數據庫。
（2）按系統結構分為：嵌入數據庫、移動數據庫、小型C/S結構數據庫。
（3）按存儲位置分為：①基于內存的數據庫系統：采用內存存儲，屬于實時事務最佳技術；②基于文件的數據庫：以文件方式磁盤存儲，安全性低；③基于網絡的數據庫：遠程服務器存儲，無須解析SQL，支持更多SQL操作，客戶端小，便于代碼重用。

嵌入式數據庫架構

數據庫管理系統與嵌入式數據庫對比見表
（1）基于內存的數據庫系統。典型產品是eXtremeDB 嵌入式數據庫，它具有：最小化資源消耗、保持極小堆空間、維持極小代碼體積、消除額外代碼層、提供動態數據結構本地支持等特點。
（2）基于文件的嵌入式數據庫系統架構。典型產品是SQLite，它的特點是：開源的內嵌式關系型數據庫、集成在程序中，無須配置管理，服務器客戶端同進程，簡化管理，減少網絡開銷、對數據類型有獨特處理。
（3）基于網絡的嵌入式數據庫系統架構。C/S架構的數據庫、B/S架構的數據庫以及云數據庫等都屬于這種類型。

嵌入式數據庫主要功能

除了具有與通用數據庫相似的功能外，嵌入式數據庫還具有的功能包括：足夠高效的數據存儲機制、數據安全控制（鎖機制）、實時事務管理機制、數據庫恢復機制（歷史數據存儲）。

嵌入式中間件

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

嵌入式系統軟件開發環境

嵌入式系統軟件開發環境的特點是：集成開發環境，交叉開發，開放式架構，可擴展性，可操作性，可移植性，可配置性，實時性，可維護性，用戶界面友好。

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

基于架構的軟件設計開發方法

基于架構的軟件設計開發方法（Architecture -Based Software Design，ABSD）。這種方法的詳細內容在后面，這里不再贅述

屬性驅動的軟件設計方法

ADD是把一組質量屬性（可用性、性能、安全性等）場景作為輸入，利用對質量屬性實現與架構設計之間的關系的了解（如體系結構風格、質量戰術等）對軟件架構進行設計的一種方法。這種方法在滿足質量屬性的基礎上建立模塊分解過程，通過輸入質量場景，利用質量屬性戰術實現架構設計。采用ADD方法進行軟件開發時，需要經歷評審、選擇驅動因子、選擇系統元素、選擇設計概念、實體化元素和定義接口、草擬視圖和分析評價等7個階段。

實時系統設計方法

DARTS 基于傳統結構化分析方法，擴展了行為建模部分。
DARTS 方法分為5個部分：用實時結構化分析方法開發系統規范、將系統劃分為多個并發任務、定義任務間接口、設計每個任務、設計過程的成果。
DARTS方法的優勢如下：
1）強調將系統分解為并發任務，并提供確認任務的標準。
2）提供定義任務間接口的指南。
3）強調用任務架構圖的重要性。
4）提供從實時結構化分析規格到實時結構化設計的轉換。
DARTS方法的不足如下：
1）DARTS使用信息隱藏技術封裝數據存儲，封裝性不好。
2）如果實時結構化分析階段完成得不好，那么任務的結構化工作就會更加困難。

5.5.嵌入式系統軟件架構實踐

鴻蒙操作系統

鴻蒙操作系統架構采用了分布式設計理念，實現了分布式軟總線、分布式設備系統的虛擬化、分布式數據管理和分布式任務調度4種分布式能力。
鴻蒙操作系統的架構是一種層次式架構，由內核層、系統服務層、應用框架層、應用層組成，如圖

內核層

內核層采用微內核設計，內核層中的內核抽象層屏蔽多內核差異，對上層提供基礎內核能力，如進程/線程管理、內存管理、文件系統、網絡管理、外設管理等。驅動子系統則提供統一外設訪問能力，驅動開發框架，驅動管理框架。

系統服務層

屬于核心能力集合的部分，為應用程序提供服務。

應用框架層

為應用服務提供多語言用戶程序框架、能力框架，以及各種硬件服務對外開放的API。

應用層

包括系統應用和第三方非系統應用，能夠實現特定的業務功能，支持跨設備調度與分發，為用戶提供一致、高效的應用體驗。
鴻蒙操作系統架構具有4個技術特性：
（1）分布式架構用于終端操作系統，實現跨終端無縫協同體驗。
（2）確定時延引擎和高性能進程間通信技術，實現系統的流暢。
（3）基于微內核架構，重塑終端設備的可信安全。
（4）統一集成開發環境，一次開發，多端部署，實現跨終端生態共享。

面向安全攸關系統的跨領域系統架構

GENESYS 是一種跨領域的通用嵌入式架構平臺。GENESYS采用消息交換方式實現軟硬件構件的抽象級別的提升，使得構件在接口規范基礎上可以被重用，而不需要知道構件的內部實現。
GENESYS 設計了故障或錯誤的隔離框架，構件在瞬態故障引起失效后，可選擇性地重啟和用構件復制來屏蔽瞬態和永久錯誤。同時GENESYS可以減少構件的功率需求或者在不需要時（功率門）完全關閉構件。因此GENESYS的出現解決了復雜性管理、系統健壯性、能量有效使用3個方面的挑戰。
GENESYS架構主要提供了3組服務，即領域無關服務、領域專用服務和應用專用服務（包含中間件），如圖

領域無關服務

包括核心服務和選擇服務，如嵌入式系統中的全局時間和消息傳輸等服務為核心服務。信息安全服務、外部存儲器管理器或者Internet網關服務等屬于選擇服務。

領域專用服務

領域專用服務是由領域特有的服務子集加上待開發領域特征的特定服務組合。GENESYS 架構從硬件、軟件的觀點遵循了面向構件的風格，分離了計算與通信，將計算構件和通信設施作為獨立構件進行設計。GENESYS架構的主要特征及優勢包括：
1）精確的構件定位。具體體現為簡單化、跨領域重用、規模的經濟型、健壯性、可降低系統集成工作量這5個特征。
2）開放性。體現為具有可集成性、可升級性、可擴展性、遺產系統集成、降低成本這5個特征。
3）三級集成。具有芯片級集成、設備級集成、系統級集成的集成。
4）分層的服務。體現具有可重用性、領域定位、工效經濟型的特性。
5）確定的核心。體現在具有及時性、降低復雜性、可測試性、認證、故障掩蔽的特征。
6）標準的互聯集成。體現在對遠程訪問的保護、降低集成工作難度、常規人機交互、具有安全性4個方面。

物聯網操作系統軟件架構

物聯網操作系統至今沒有一個明確的定義。物聯網操作系統通常包括芯片層、終端層、邊緣層、云端層等多個層面內容。物聯網操作系統使用的軟件以及技術主要有：開源物聯網操作系統（FreeRTOS）、公共服務組件（網絡協議、外設支持、可移植操作系統接口 POSIX 等）定制性服務組件有：消息隊列遙測傳輸協議（MQTT），安全超文本傳輸協議（HTTPS），加密消息標準PKCS #11 支持，安全套件等。
物聯網操作系統主要特征有：內核實時性、內核尺寸伸縮性、架構可擴展性、高可靠性、低功耗。

6.通信系統架構設計理論與實踐

6.1.通信系統網絡架構

局域網網絡架構

局域網是單一機構專用計算機的網絡。通常由計算機、交換機、路由器等設備組成。特點是覆蓋地理范圍小、數據傳輸速率高、低誤碼率、可靠性高、支持多種傳輸介質、支持實時應用。局域網按網絡拓撲分類有總線型、環型、星型、樹型、層次型等類型，按傳輸介質分類有有線局域網、無線局域網。
局域網網絡架構有4種類型：

單核心架構

使用單臺核心二層或三層交換設備作為網絡核心。
優點：結構簡單，設備投資節約，接入方便。
缺點：地理范圍受限，核心單點故障，擴展能力有限，接入設備較多時核心端口密度要求高。

雙核心架構

采用兩臺核心三層及以上交換機作為網絡核心。
優點：網絡拓撲結構可靠性高，接入較為方便。
缺點：投資較單核心高，核心端口密度要求較高。

環型架構

采用多臺核心三層及以上交換機組成雙動態彈性分組環（Resilient Packet Ring，RPR），作為網絡核心。
優點：RPR具備自愈保護，節省光纖資源，提供多等級、可靠的QoS服務，有效利用帶寬資源。
缺點：投資較高，路由冗余設計實施難度較高且易形成環路，多環智能通過業務接口互通無法直通。

層次型架構

由核心層、匯聚層、接入層三層交換設備和用戶設備組成層次模型。
1）核心層：負責高速數據轉發。
2）匯聚層：提供充足接口，與接入層間實現互訪控制。
3）接入層：用戶設備接入。
層次型架構的優點：易擴展，分級排查網絡故障便于維護。

廣域網網絡架構

廣域網利用公用分組交換網、無線分組交換網、衛星通信網構建通信子網連接分布的局域網以實現資源子網的共享。廣域網由骨干網、分布網、接入網組成。廣域網網絡架構可以分為：

單核心架構

以單臺核心三層交換設備作為網絡核心。
優點：結構簡單，設備投資節約，局域網互訪效率高，新局域網接入方便。
缺點：核心單點故障，擴展能力欠佳，核心設備端口密度要求較高。

雙核心架構

以兩臺核心三層及以上交換機作為網絡核心。
優點：網絡拓撲結構可靠，路由可熱切換，可靠性高，局域網接入較為方便。
缺點：投資較單核心高，路由冗余設計實施難度較高，核心端口密度要求較高。

環型架構

以多臺核心三層及以上交換機組成路由環路作為網絡核心。
優點：接入方便。
缺點：投資較高，路由冗余設計實施難度較高且易形成環路，核心端口密度要求較高。

半/全冗余架構

以多臺核心路由設備間互連組成網絡核心，如任意核心存在兩條以上到其他核心的鏈路為半冗余架構，如任何兩個核心間均存在鏈路為全冗余架構。
優點：結構靈活，路由靈活，方便擴展，可靠性高。
缺點：結構零散，不便管理，不便排障。

對等子域架構

將半冗余核心劃為兩個獨立子域，子域間通過一條或多條鏈路互連。
優點：路由控制靈活。
缺點：子域間冗余設計實施難度較高，易形成環路或存在非法路由風險，子域互連設備性能要求高。

層次子域架構

半冗余核心劃為多個獨立子域，子域間存在層次關系，高層次子域連接多個低層次子域。
優點：擴展性較好，路由控制靈活。
缺點：子域路由冗余設計實施難度較高，易形成環路或存在非法路由風險，子域互連設備性能要求高。

移動通信網網絡架構

5G 系統為移動終端用戶提供數據網絡互連，數據網絡可以是互聯網、IP媒體子系統、專用網絡。用戶設備通過5G系統接入數據網絡的方式有透明模式和非透明模式。在透明模式下5G系統通過用戶面功能接口接入運營商網絡，然后通過防火墻或者代理連至Internet。非透明模式下，5G系統可以直接或通過其他網絡連接至運營商網絡或Internet。

5G網絡邊緣計算

5G 網絡邊緣計算能為垂直行業提供諸如以時間敏感、高帶寬為特征的業務就近分流服務。一來為用戶提供極佳的服務體驗，二來降低了移動網絡后端處理的壓力

軟件定義網絡

SDN 是一種新型網絡創新架構，核心思想是通過控制與轉發分離，將網絡中交換設備的控制邏輯集中到一個計算設備上，控制面集中管控，提升網絡管理配置能力。

存儲網絡架構

存儲網絡設計磁盤存儲訪問方式：直連式存儲，網絡附加存儲，存儲區域網絡。
（1）直連式存儲（Direct Attached Storage，DAS）：存儲設備通過IDE/ATA/SCSI 接口或光纖通道直接連接到單臺計算機，計算機通過I/O 訪問存儲設備，存儲設備可以是硬盤驅動器、RAID陣列、CD、DVD、磁帶驅動器。
（2）網絡附加存儲（Network Attached Storage，NAS）：存儲設備通過標準的網絡拓撲結構連接到計算機群組，計算機通過IP局域網或廣域網TPC或UDP協議，通過RPC接口訪問NAS存儲設備。
（3）存儲區域網絡（Storage Area Network，SAN）：一種采用網狀通道技術專門為存儲建立的獨立于TCP/IP網絡之外的專用網絡，通過網狀通道交換機連接存儲陣列和服務器。
3種存儲網絡架構的對比見表

6.2.網絡構建關鍵技術

IPv4與IPv6融合組網技術

目前網絡演進還存在較長時間IPv4到IPv6過渡期或IPv4和IPv6 網絡共存期。現階段主要存在3種過渡技術：雙協議棧、隧道技術、網絡地址翻譯技術。
（1）雙協議棧：兩種協議在同一平臺上雙棧共存，同時運行。
（2）隧道技術：包括ISATAP隧道、6to4隧道、over6隧道、6over4隧道。
（3）網絡地址翻譯（Network Address Translator，NAT）技術：將IPv4地址和IPv6地址分別看作內部地址和外部地址，或者相反，以實現地址轉換。

6.3.網絡構建

網絡需求分析

網絡需求分析主要從業務需求、用戶需求、應用需求、計算機平臺需求和網絡需求來進行分析。

網絡技術遴選及設計

網絡技術遴選及設計可以使用生成樹協議、虛擬局域網（VLAN）、無線局域網（WLAN）、線路冗余設計、服務器冗余設計等方式。

廣域網技術遴選

廣域網技術遴選可以采用遠程接入技術、廣域網互連技術，如數字數據網絡（DDN）、同步數字體系（SDH）、多業務傳送平臺（MSTP）、虛擬專用網絡（VPN）等。廣域網性能優化策略有：預留帶寬、利用撥號線路、傳輸數據壓縮、鏈路聚合、數據基于優先級排序、基于協議預留帶寬等方式。

層次化網絡模型設計

層次化設計的優點是能降低成本，充分利用模塊化設備/部件，網絡變化或演化容易。層次化網絡設計一般采用三層模型設計思路：接入層、匯聚層、核心層。每層的特點已經在前面的內容中介紹過了，這里不再贅述。
層次化設計的原則：
（1）控制網絡層次。
（2）從接入層開始，向上分析規劃。
（3）盡量采用模塊化設計。
（4）嚴格控制網絡結構。
（5）嚴格控制層次化結構。

網絡安全控制技術

防火墻

防護墻是網絡間的安全屏障，可以保護本地網絡資源。
防火墻可以允許/拒絕/重定向數據流以及審計進出網絡的訪問或服務。
防火墻的體系有：硬件防火墻、軟件防火墻、嵌入式防火墻。
防火墻的種類有包過濾、應用層網關、代理服務等。

虛擬專用網絡技術

該技術利用公共網絡建立私有專用網絡，具有成本低、接入方便、可擴展性強、管理和控制方便等優點。

訪問控制技術

訪問控制技術主要有：自主訪問控制（DAC）、強制訪問控制（MAC）、基于角色的訪問控制（RBAC）、基于任務的訪問控制（TBAC）和基于對象的訪問控制（OBAC）。

網絡安全隔離

將攻擊隔離在網絡外，保證網絡內信息不外泄。形式有：子網隔離、物理隔離、VLAN隔離、邏輯隔離。

網絡安全協議

網絡安全協議可參考前面的內容，這里不再贅述。

網絡安全審計

網絡安全審計用來測試，評估和分析網絡脆弱性，能夠實現自動響應、數據生成、分析、瀏覽、事件存儲、事件選擇等功能。

綠色網絡設計方法

綠色網絡設計采用精簡設計、重用設計、回收設計的思路。設計原則有：
（1）標準化：減少轉換設備，兼容異構方案。
（2）集成化：減少設備總量，降低資源需求。
（3）虛擬化：靈活調配，按需使用。
（4）智能化：降低人力成本，降低資源占用。

7.安全架構設計理論與實踐

7.1.信息安全面臨的威脅

信息系統安全威脅的來源

威脅可以來源于物理環境、通信鏈路、網絡系統、操作系統、應用系統、管理系統。

網絡與信息安全風險類別

網絡與信息安全風險類別可以分為人為蓄意破壞（被動型攻擊，主動型攻擊）、災害性攻擊、系統故障、人員無意識行為，如圖

常見的安全威脅

常見的威脅主要有：
（1）信息泄露。信息被泄露或透露給某個非授權的實體。
（2）破壞信息的完整性。數據被非授權地進行增刪、修改或破壞而受到損失。
（3）拒絕服務。對信息或其他資源的合法訪問被無條件地阻止。
（4）非法使用（非授權訪問）。某一資源被某個非授權的人或以非授權的方式使用。
（5）竊聽。用各種可能的合法或非法的手段竊取系統中的信息資源和敏感信息。如對通信線路中傳輸的信號進行搭線監聽，或利用通信設備在工作過程中產生的電磁泄漏截取有用信息等。
（6）業務流分析。通過對系統進行長期監聽，利用統計分析方法對諸如通信頻度、通信的信息流向、通信總量的變化等態勢進行研究，從而發現有價值的信息和規律。
（7）假冒。通過欺騙通信系統（或用戶）達到非法用戶冒充成為合法用戶，或者特權小的用戶冒充成為特權大的用戶的目的。黑客大多是采用假冒的方式進行攻擊。
（8）旁路控制。攻擊者利用系統的安全缺陷或安全性上的脆弱之處獲得非授權的權利或特權。如，攻擊者通過各種攻擊手段發現原本應保密，但是卻又暴露出來的一些系統“特性”。利用這些“特性”，攻擊者就可以繞過防線守衛者侵入系統的內部。
（9）授權侵犯。被授權以某一目的使用某一系統或資源的某個人，卻將此權限用于其他非授權的目的，也稱作“內部攻擊”。
（10）特洛伊木馬。軟件中含有一個察覺不出的或者無害的程序段，當它被執行時，會破壞用戶的安全。這種應用程序稱為特洛伊木馬。
（11）陷阱門。在某個系統或某個部件中設置了“機關”，使得當提供特定的輸入數據時，允許違反安全策略。
（12）抵賴。這是一種來自用戶的攻擊，例如，否認自己曾經發布過的某條消息、偽造一份對方來信等。
（13）重放。所截獲的某次合法的通信數據備份，出于非法的目的而被重新發送。
（14）計算機病毒。所謂計算機病毒，是一種在計算機系統運行過程中能夠實現傳染和侵害的功能程序。
（15）人員瀆職。一個授權的人為了錢或利益，或由于粗心，將信息泄露給一個非授權的人。
（16）媒體廢棄。信息被從廢棄的磁盤或打印過的存儲介質中獲得。
（17）物理侵入。侵入者通過繞過物理控制而獲得對系統的訪問。
（18）竊取。重要的安全物品遭到竊取，如令牌或身份卡被盜。
（19）業務欺騙。某一偽系統或系統部件欺騙合法的用戶，或使系統自愿地放棄敏感信息。

7.2.安全體系架構的范圍

安全防線

分別是產品安全架構、安全技術架構、審計架構。

安全架構特性

安全架構應具有：可用性、完整性、機密性的特性。

安全技術架構

安全技術架構主要包括身份鑒別、訪問控制、內容安全、冗余恢復、審計響應、惡意代碼防范、密碼技術。

7.3.安全模型

信息系統安全目標

信息系統安全目標是控制和管理主體對客體的訪問，從而實現：
（1）保護系統可用性。
（2）保護網絡服務連續性。
（3）防范非法非授權訪問。
（4）防范惡意攻擊和破壞。
（5）保護信息傳輸機密性和完整性。
（6）防范病毒侵害。
（7）實現安全管理。

典型安全模型

狀態機模型

一個安全狀態模型系統，總是從一個安全狀態啟動，并且在所有遷移中保持安全狀態，只允許主體以和安全策略相一致的安全方式訪問資源。

BLP模型（Bell-LaPadula Mode）

該模型為數據規劃機密性，依據機密性劃分安全級別，
按安全級別強制訪問控制。BLP模型的基本原理是：
1）安全級別是“機密”的主體訪問安全級別為“絕密”的客體時，主體對客體可寫不可讀。
2）安全級別是“機密”的主體訪問安全級別為“機密”的客體時，主體對客體可寫可讀。
3）安全級別是“機密”的主體訪問安全級別為“秘密”的客體時，主體對客體可讀不可寫。
BLP 模型安全規則：
1）簡單規則：低級別主體讀取高級別客體受限。
2）星型規則：高級別主體寫入低級別客體受限。
3）強星型規則：對不同級別讀寫受限。
4）自主規則：自定義訪問控制矩陣。

Biba 模型

該模型建立在完整性級別上。模型具有完整性的三個目標：保護數據不被未授權用戶更改、保護數據不被授權用戶越權修改（未授權更改）、維持數據內部和外部的一致性。
Biba 模型基本原理：
1）完整性級別為“中完整性”的主體訪問完整性為“高完整性”的客體時，主體對客體可讀不可寫，也不能調用主體的任何程序和服務。
2）完整性級別為“中完整性”的主體訪問完整性為“中完整性”的客體時，主體對客體可讀可寫。
3）當完整性級別為“中完整性”的主體訪問完整性為“低完整性”的客體時，主體對客體可寫不可讀。
Biba 模型可以防止數據從低完整性級別流向高完整性級別，其安全規則如下：
1）星完整性規則。表示完整性級別低的主體不能對完整性級別高的客體寫數據。
2）簡單完整性規則。表示完整性級別高的主體不能從完整性級別低的客體讀取數據。
3）調用屬性規則。表示一個完整性級別低的主體不能從級別高的客體調用程序或服務。

CWM 模型（Clark-Wilson Model）

將完整性目標、策略和機制融為一體，提出職責分離目標，應用完整性驗證過程，實現了成型的事務處理機制，常用于銀行系統。CWM模型具有以下特征：
1）包含主體、程序、客體三元素，主體只能通過程序訪問客體。
2）權限分離原則，功能可分為多主體，防止授權用戶進行未授權修改。
3）具有審計能力。

Chinese Wall 模型

是一種混合策略模型，應用于多邊安全系統，防止多安全域存在潛在的沖突。該模型為投資銀行設計，常見于金融領域。工作原理是通過自主訪問控制（DAC）選擇安全域，通過強制訪問控制（MAC）完成特定安全域內的訪問控制。
Chinese Wall 模型的安全規則：
1）墻內客體可讀取。
2）不同利益沖突組客體可讀取。
3）訪問其他公司客體和其他利益沖突組客體后，主體對客體寫入受限。

7.4.信息安全整體架構設計

WPDRRC信息安全模型

WPDRRC模型包括6個環節：預警（Warning）、保護（Protect）、檢測（Detect）、響應（React）、恢復（Restore）、反擊（Counterattack）；3 個要素：人員、策略、技術。

信息安全體系架構

具體可以從以下5個方面開展安全體系的架構設計工作：
1）物理安全（前提）：包括環境安全、設備安全、媒體安全。
2）系統安全（基礎）：包括網絡結構安全、操作系統安全、應用系統安全。
3）網絡安全（關鍵）：包括訪問控制、通信保密、入侵檢測、網絡安全掃描、防病毒。
4）應用安全：包括資源共享、信息存儲。
5）安全管理：包括健全的體制、管理平臺、人員安全防范意識。

7.5.網絡安全架構設計

OSI/RM信息安全架構

OSI/RM 信息安全架構，如圖
OSI 定義了分層多點的安全技術體系架構，又叫深度防御安全架構，它通過以下3種方式將防御能力分布至整個信息系統中。
1）多點技術防御：通過網絡和基礎設施，邊界防御（流量過濾、控制、如前檢測），計算環境等方式進行防御。
2）分層技術防御：外部和內部邊界使用嵌套防火墻，配合入侵檢測進行防御。
3）支撐性基礎設施：使用公鑰基礎設施以及檢測和響應基礎設施進行防御。

安全服務和安全機制的對應關系

認證框架

認證又叫鑒權，其目的是防止其他實體占用和獨立操作被鑒別實體的身份。
鑒別的方式有：已知的（口令）、擁有的（IC卡，令牌等）、不可變特征（生物特征）、受信第三方鑒別、環境（主機地址）。
鑒別服務階段分為：安裝、修改鑒權信息、分發、獲取、傳送、驗證、停活、重新激活、取消安裝。

訪問控制框架

當發起者請求對目標進行特殊訪問時，訪問控制管制設備（Access Control Enforcement Facilities，AEF）就通知訪問控制決策設備（Access Control Decision Facilities，ADF），ADF 可以根據上下文信息（包括發起者的位置、訪問時間或使用中的特殊通信路徑）以及可能還有以前判決中保留下來的訪問控制決策信息（Access Control Decision Information，ADI）做出允許或禁止發起者試圖對目標進行訪問的判決。

機密性框架

機密性服務目的是確保信息僅僅是對被授權者可用。
機密性機制包括：通過禁止訪問提供機密性、通過加密提供機密性。

完整性框架

完整性服務目的是組織威脅或探測威脅，保護數據及其相關屬性的完整性。
完整性服務分類有：未授權的數據創建、數據創建、數據刪除、數據重放。
完整性機制類型分為阻止媒體訪問與探測非授權修改兩種

抗抵賴框架

抗抵賴服務的目的是提供特定事件或行為的證據。
抗抵賴服務階段分為：證據生成、證據傳輸、存儲及回復、證據驗證、解決糾紛這5個階段。

7.6.數據庫系統安全設計

數據庫完整性設計原則

完整性設計原則具體包括：
（1）依據完整性約束類型設計其實現的系統層次和方式，并考慮性能。
（2）在保障性能的前提下，盡可能應用實體完整性約束和引用完整性約束。
（3）慎用觸發器。
（4）制訂并使用完整性約束命名規范。
（5）測試數據庫完整性，盡早排除沖突和性能隱患。
（6）設有數據庫設計團隊，參與數據庫工程全過程。
（7）使用CASE工具，降低工作量，提高工作效率。

數據庫完整性的作用

數據庫完整性的作用體現在以下幾個方面：
（1）防止不合語義的數據入庫。
（2）降低開發復雜性，提高運行效率。
（3）通過測試盡早發現缺陷。

7.7.系統架構脆弱性分析

系統架構脆弱性組成

系統架構脆弱性包括物理裝備脆弱性、軟件脆弱性、人員管理脆弱性、規章制度脆弱性、安全策略脆弱性等。

典型架構的脆弱性表現

分層架構

分層脆弱性體現在：
1）層間脆弱性：一旦某個底層發生錯誤，那么整個程序將會無法正常運行。
2）層間通信脆弱性：如在面向對象方法中，將會存在大量對象成員方法的調用（消息交互），這種層層傳遞，勢必造成性能的下降。

C/S架構

這種架構的脆弱性有：客戶端脆弱性、網絡開放性脆弱性、網絡協議脆弱性。

B/S架構

如果 B/S架構使用的是HTTP協議，會更容易被病毒入侵。

事件驅動架構

事件驅動架構的脆弱性體現在：組件脆弱性、組件間交換數據的脆弱性、組件間邏輯關系的脆弱性、事件驅動容易死循環、高并發脆弱性、固定流程脆弱性。

MVC架構

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

微內核架構

微內核架構的脆弱性體現在：
1）整體優化脆弱性。微內核系統的核心態只實現了最基本的系統操作，因此內核以外的外部程序之間的獨立運行使得系統難以進行良好的整體優化。
2）進程通信開銷脆弱性。微內核系統的進程間通信開銷也較單一內核系統要大得多。
3）通信損失脆弱性。微內核把系統分為各個小的功能塊，從而降低了設計難度，系統的維護與修改也容易，但帶來的問題是通信效率的損失。

微服務架構

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

7.8.安全架構設計實踐

遠程認證撥號用戶服務

RADIUS 是應用最廣泛的高安全級別認證、授權、審計協議（Authentication，Authorization，Accounting，AAA），具有高性能和高可擴展性，且可用多種協議實現。
RADIUS 通常由協議邏輯層，業務邏輯層和數據邏輯層3層組成層次式架構。
（1）協議邏輯層：起到分發處理功能，相當于轉發引擎。
（2）業務邏輯層：實現認證、授權、審計三種類型業務及其服務進程間的通信。
（3）數據邏輯層：實現統一的數據訪問代理池，降低數據庫依賴，減少數據庫壓力，增強系統的數據庫適應能力。

基于混合云的工業安全生產管理系統

混合云融合了公有云和私有云。在基于混合云的工業安全生產管理系統中，工廠內部的產品設計、數據共享、生產集成使用私有云實現。公有云則用于公司總部與智能工廠間的業務管理、協調和統計分析等。整個生產管理系統架構采用層次式架構，分為設備層、控制層、設計/管理層、應用層，如圖
在設計基于混合云的工業安全生產管理系統時，需要考慮的安全問題有：設備安全、網絡安全、控制安全、應用安全和數據安全。

設備層

包括智能工廠生產用設備，包括智能傳感器、智能儀器儀表、工業機器人、其他生產設備。

控制層

包括智能設備控制用自動控制系統，包括采集與監視控制系統（Supervisory Control and Data Acquisition，SCADA）、分布式控制系統（Distributed Control System，DCS）、現場總線控制系統（Fieldbus Control System，FCS）、可編程控制器（Programmable Logic Controller，PLC）（內置編程程序）、人機接口（Human Machine Interface，HMI），其他現場控制程序。

設計/管理層

包括智能工廠所有控制開發，業務控制和數據管理相關系統及其功能的集合，實現了數據集成和應用，包括制造執行系統（Manufacturing Execution System，MES）（很多企業稱之為生產信息管理系統）、計算機輔助設計/工程/制造 CAD/CAE/CAM、供應鏈管理（Supply Chain Management，SCM）、企業資源規劃（ERP）、客戶關系管理（Customer Relationship Management，CRM）、供應商關系管理（Supplier Relationship Management，SRM）、商業智能分析（Business Intelligence，BI）、產品生命周期管理（Product Life-Cycle Management，PLM）。

應用層

云平臺上的信息處理，包括數據處理與管理、數據與行業應用相結合，如定制業務、協同業務、產品服務。

8.大數據架構設計理論與實踐

8.1.傳統數據處理系統的問題

傳統數據庫的數據過載問題

傳統應用的數據系統架構設計時，應用直接訪問數據庫系統。當用戶訪問量增加時，數據庫無法支撐日益增長的用戶請求的負載，從而導致數據庫服務器無法及時響應用戶請求，出現超時的錯誤。關于這個問題的常用解決方法如下：
（1）增加異步處理隊列，通過工作處理層批量處理異步處理隊列中的數據修改請求。
（2）建立數據庫水平分區，通常建立Key分區，以主鍵/唯一鍵Hash值作為Key。
（3）建立數據庫分片或重新分片，通常專門編寫腳本來自動完成，且要進行充分測試。
（4）引入讀寫分離技術，主數據庫處理寫請求，通過復制機制分發至從數據庫。
（5）引入分庫分表技術，按照業務上下文邊界拆分數據組織結構，拆分單數據庫壓力。

大數據的特點

大數據具有體量大、時效性強的特點，并非構造單調，而是類型多樣；處理大數據時，傳統數據處理系統因數據過載，來源復雜，類型多樣等諸多原因性能低下，需要采用以新式計算架構和智能算法為代表的新技術；大數據的應用重在發掘數據間的相關性，而非傳統邏輯上的因果關系；因此，大數據的目的和價值就在于發現新的知識，洞悉并進行科學決策。現代大數據處理技術，主要分為以下幾種：
（1）基于分布式文件系統Hadoop。
（2）使用Map/Reduce或Spark數據處理技術。
（3）使用Kafka數據傳輸消息隊列及Avro二進制格式。

大數據利用過程

大數據的利用過程分為：采集、清洗、統計和挖掘4個過程。

8.2.大數據處理系統架構分析

大數據處理系統面臨的挑戰

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

大數據處理系統應具有的屬性和特征

魯棒性和容錯性、低延遲、橫向擴展（通過增強機器性能擴展）、通用、可擴展、即席查詢（用戶按照自己的要求進行查詢）、最少維護和可調試。

8.3.典型的大數據架構

Lambda架構

Lambda 架構是一種用于同時處理離線和實時數據的、可容錯的、可擴展的分布式系統，如圖
Lambda 架構的優點：容錯性好，查詢靈活度高，彈性伸縮，易于擴展。
Lambda 架構的缺點：編碼量大，持續處理成本高，重新部署和遷移成本高。
與Lambda架構相似的模式有事件溯源模式、命令查詢職責分離模式。

批處理層

該層核心功能是存儲主數據集，主數據集數據具有原始、不可變、真實的特征。批處理層周期性地將增量數據轉儲至主數據集，并在主數據集上執行批處理，生成批視圖。架構實現方面可以使用Hadoop HDFS或HBase存儲主數據集，再利用Spark或MapReduce執行周期批處理，之后使用MapReduce創建批視圖。

加速層

該層的核心功能是處理增量實時數據，生成實時視圖，快速執行即席查詢。架構實現方面可以使用Hadoop HDFS或HBase存儲實時數據，利用Spark或Storm實現實時數據處理和實時視圖。

服務層

該層的核心功能是響應用戶請求，合并批視圖和實時視圖中的結果數據集得到最終數據集。具體來說就是接收用戶請求，通過索引加速訪問批視圖，直接訪問實時視圖，然后合并兩個視圖的結果數據集生成最終數據集，響應用戶請求。架構實現方面可以使用 HBase 或Cassandra 作為服務層，通過Hive創建可查詢的視圖。

Kappa架構

Kappa 架構是在Lambda架構的基礎上進行了優化，刪除了Batch Layer 的架構，將數據通道以消息隊列進行替代，如圖

實時層

該層核心功能是處理輸入數據，生成實時視圖。具體來說是采用流式處理引擎逐條處理輸入數據，生成實時視圖。架構實現方式是采用Apache Kafka回訪數據，然后采用Flink或Spark Streaming 進行處理。

服務層

該層核心功能是使用實時視圖中的結果數據集響應用戶請求。實踐中使用數據湖中的存儲作為服務層。

Lambda架構與Kappa架構的對比

對于兩種架構設計的選擇可以從以下4個方面考慮，見表

8.4.大數據架構的實踐

大規模視頻網絡

某網采用以 Lambda 架構搭建的大數據平臺處理里約奧運會大規模視頻網絡觀看數據，具體平臺架構設計如圖
對于圖22.6中的數據計算層可以分為離線計算、實時計算、合并計算3個部分。
（1）離線計算部分：用于存儲持續增長的批量離線數據，并且會周期性地使用Spark 和Map/Reduce 進行批處理，將批處理結果更新到批視圖之后使用Impala 或者 Hive 建立數據倉庫，將結果寫入HDFS中。
（2）實時計算部分：采用Spark Streaming，只處理實時增量數據，將處理后的結果更新到實時視圖。
（3）合并計算部分：合并批視圖和實時視圖中的結果，生成最終數據集，將最終數據集寫入HBase 數據庫中用于響應用戶的查詢請求。

廣告平臺

某網基于Lambda架構的廣告平臺，分為批處理層（Batch Layer）、加速層（Speed Layer）、服務層（Serving Layer），如圖22.7 所示
（1）批處理層：每天凌晨將Kafka中瀏覽、下單等消息同步到HDFS中，將HDFS中數據解析為Hive表，然后使用HQL或Spark SQL計算分區統計結果Hive表，將Hive表轉儲到MySQL中作為批視圖。
（2）加速層：使用Spark Streaming實時監聽Kafka下單、付款等消息，計算每個追蹤鏈接維度的實時數據，將實時計算結果存儲在Redis中作為實時視圖。
（3）服務層：采用Java Web服務，對外提供HTTP接口，Java Web服務讀取MySQL批視圖表和Redis 實時視圖表。

公司智能決策大數據系統

某證券公司智能決策大數據系統是一個基于Kappa架構的實時日志分析平臺，如圖22.8所示。
具體的實時處理過程如下：
（1）日志采集：用統一的數據處理引擎Filebeat實時采集日志并推送給Kafka緩存
（2）日志清洗解析：利用基于大數據計算集群的Flink計算框架實時讀取Kafka 消息并進行清洗，解析日志文本轉換成指標。
（3）日志存儲：日志轉儲到ElasticSearch日志庫，指標轉儲到OpenTSDB指標庫。
（4）日志監控：單獨設置告警消息隊列，保持監控消息時序管理和實時推送。

電商智能決策大數據系統

該智能決策大數據平臺基于Kappa架構，使用統一的數據處理引擎Funk可實時處理流數據，并將其存儲到數據倉庫工具Hive與分布式緩存Tair中，以供后續決策服務的使用。如圖22.9所示。
實時處理的過程如下：
（1）數據采集：B 端實時采集用戶點擊、下單、廣告曝光、出價等數據然后推送給 Kafka緩存。
（2）數據清洗聚合：由Flink 實時讀取 Kafka 消息，按需過濾參與業務需求的指標，將聚合時間段的數據轉換成指標。
（3）數據存儲：Flink 將計算結果轉儲至Hive 日志庫，將模型需要的參數轉儲至實時計算數據庫Tair緩存，然后后續決策服務從Tair中獲取數據進行模型訓練。