第四章 軟件架構演化

第一節 軟件架構定義及演化

分層架構

·「關注點分離」原則

·軟件系統的組件被分紅多個相互不重疊的層次，每一層都有着特定的職能，僅處理本層的邏輯，而並不關心其它層的實現。

·表現層

·業務層

·持久層

·數據層

·分層架構模式特色：

+結構簡單

+易於組織開發

+便於獨立測試、維護

-不易實現特續發佈、部署

-性能代價

-可擴展性差

面向服務架構

·面向服務架構（SOA）

是一個分佈式組件的集合，這些組件爲其它組件提供服務（provider），或者消費其它組件所提供的服務（consumer），而無需知道其它組件的實現細節。

·企業服務總線（ESB）

爲服務間的相互調用提供支持環境，路由服務間的消息，並對消息和數據進行必要的轉換。

·服務編排引擎（Orchestration Engine）

能夠根據預先定義的腳本對服務消費者與服務提供者之間的交互進行指揮。

面向服務架構的特色：

+服務自身高內聚、服務間鬆糊合，最小化開發維護中的相互影響

+良好的互操做性，符合開放標準

+模組化，高重用性

+服務動態識別註冊、調用

-系統複雜性提升

-難以測試驗證

-各獨立服務的演化不可控

面向服務架構實現原則：

·服務解糊：服務之間的關係最小化，只是互相知道接口

·服務契約：服務按照描述文檔所定義的服務契約行事

·服務封裝：除了服務契約所描述內容，服務將對外部隱藏實現邏輯

·服務重用：將邏輯分佈在不一樣的服務中，以提升服務的重用性

·服務組合：一組服務能夠協調工做，組合起來造成定製組合業務需求

·服務自治：服務對所封裝的邏輯具備控制權

·服務無狀態：服務將一個活動所需保存的資訊最小化

構建雲原生應用程序（SaaS）的12要素

1.基準代碼：一份基準代碼，多份部署。基準代碼和應用之間老是保持一一對應的關係。全部部署的基準代碼相同，但每份部署可使用其不一樣的版本。

2.依賴：顯式聲明依賴關係。應用程序必定經過依賴清單，確切地聲明全部依賴項。

3.配置：在環境中存儲配置。將應用的配置存儲於環境變量中。環境變量能夠很是方便地在不一樣的部署間作修改，卻不動一行代碼。

4.後端服務：把後端服務看成附加資源。應用不會區別對待本地或第三方服務。對應用程序而言，兩種都是附加資源。

5.構建，發佈，運行：嚴格區分構建，發佈，運行這三個步驟。

6.進程：以一個或多個無狀態進程運行應用。應用的進程必須無狀態且無共享。

7.端口綁定：經過端口綁定提供服務。應用徹底自我加載而不依賴任何網絡服務器就能夠建立一個面向網絡的服務。

8.併發：經過進程模型進行擴展。開發人員能夠運用這個模型去設計應用架構，將不一樣工做分配給不一樣的進程類型。

9.易處理：快速啓動和優雅終止可最大化健壯性。應用的進程是可支配的，意思是說它們能夠瞬間開啓或中止。

10.開發環境與線上環境等價：儘量保持開發、預發佈、線上環境相同。應用想要作到持續部署就必須縮小本地與線上差別。

11.日誌：把日誌看成事件流。應用自己考慮存儲本身的輸出流。不該該試圖去寫或者管理日誌文件。

12.管理進程：後臺管理任務看成一次性進程運行。一次性管理進程應該和正常的常駐進程使用一樣的環境。

第二節 微服務架構特色

什麼是激服務架構？

-微服務（Microservices）架構風格是一種將一個單一應用程序開發爲一組小型服務的方法，每一個服務運行在本身的進程中，服務間通訊採用輕量級通訊機制，這些服務圍繞業務能力構建並可經過自動部署機制獨立部署。

-微服務架構本質上仍然是一種分佈式架構，也是面向服務架構的一種擴展。

小而自治        分佈式

微服務架構的特色

經過服務組件化

·組件是一個可獨立替換或升級的軟件單元，微服務架構實現組件化的方式是分解成服務。

·服務是一種進程外的組件，它經過Web服務請求或遠程過程湖用（RPC）機制通訊。

·使用服務做爲組件的主要緣由是服務是可獨立部界。

·使用服務做爲組件產生更加明確的組件發佈接口。

·圍繞業務能力組織

·傳統軟件系統開發管理一般聚焦在技術層面，致使UI團隊、服務邏輯團隊、數據庫團隊等的制分，將始終

伴隨跨團隊的溝通、交接和頑算南批等

·微服務採用圍繞業務能力的創分方法來組織服務，實如今服務的業務領域內的寬桂實現，其團隊都是跨職

能的，包括全方位開發技能，如用戶體驗、數據庫、項目管理。

·微服務採用產品開發模式，而非項目模式，開發團隊負責軟件的整個產品週期，持續關注軟件如何幫助用

戶提高業務能力，實現價值交付。

內聚和解耦

·基於微服務構建的系統目標是儘量的解幫和儘量的內聚，他們擁有各自的領域邏輯。

·當系統被劃分紅分離的服務時，可利用領域驅動設計（Domain-Driven Design）的理念，把一個複雜域劇分紅多個限界上下文（Bounded Context），而且晚射出它們之間的關係。

·服務和上下文邊界的肯定有助於澄清和強化分離，實現解糊。

去中心化

·去中心化治理，在構建微服務時能夠有服務本身的技術錢選擇。回句

·服務之間只須要約定接口，而無需關注破此的內部實現；

·一樣，運維只須要知道服務的部署規範。

·去中心化數據存儲，微服務更傾向於讓每一個服務管理本身的數據庫，或者同一數據庫技術的不一樣實例，或徹底不一樣的數據庫系統。

·去中心化數據管理，對跨微服務的數據來講，去中心化責任對管理升級帶來困難，微服務架構強調服務間的無事務協做，須要權衡更大一致性的業務損關與修復錯誤的代價。

基礎設施自動化

·隨着基礎設施的自動化，特別是雲和Web Services等技術的發展，已經下降了構建、部署和運維微服務的操做複雜度。

服務設計

·高可用性

·任可服務調用均可能由於服務是供者不可用而失敗，客戶端必須民可能有效的應對這種失效

·爲每一個單獨的服務設置完善的路控和日誌記錄，有助於對於快速發現不良突發行爲而儘早修復。

·變動與演化

·把組件放在服務中，只需從新部胃修改的服務，能夠在更細粒度上實現頻繁決速的發佈。

·服務的劃分上，系統中不多變動的部分應該和正在輕歷頻新改動的部分放在不一樣的服務裏

（若是不斷地一塊兒改變兩個服務，它們應該被合併）。

微服務架構與傳統架構比較

第三節 微服務架構模式及實現

微服務架構的核心模式

·核心模式即針對採用微服務系統在特定場景下的特定問題，所使用的成熟的架構解決方案集合。

 

·服務註冊與發現

服務消費者獲取服務提供者的機制，以實現二者間的解耦

1.微服務啓動時將本身的地址等信息註冊到服務發現組件

2.服務消費者可從服務發現組件查詢服務提供者的網絡地址和調用接口

3.各個微服務與服務發現組件使用必定機制服務消費者調用服務提供者通訊，如長時間沒法通訊即註銷該實例

4.微服務數量、地址和接口等發生變動時，會從新註冊到服務發現組件，無需人工修改

·API網關

·微服務架構的應用客戶端如何訪問各項服務？

·微服務提供的是細粒度APl，客戶端須要同多項服務進行交互。

·不一樣客戶端須要不一樣的數據。

·不一樣客戶端的性能要求亦有所區別。

·服務實例數量與其位置（地址和端口）會發生動態變化。

·服務的劃分方式會隨時間的推移而改變。

·API網關做爲所有客戶端的單一入口點，能夠針對不一樣客戶端提供出不一樣的APl。

·確保客戶端沒必要關心應用程序的微服務拆分方式。

·確保客戶端不受服務實例位置的影響。

·爲每套客戶端提供最優API。

·下降請求往返次數。。

·將從客戶端調用多項服務的邏輯轉換爲從API網關處調用，以簡化整個客戶端。

·熔斷器

·微服務之間不免存在依賴關係，同時相互之間經過網絡進行通訊，一旦任何服務或網絡出現問題會引發請求失敗，並可能致使級聯故障，將不可用在系統中逐漸放大。

·熔斷器模式

·能夠防止程序不斷地嘗試執行可能會失敗的操做；

·可使程序可以診斷錯誤是否已經修正，進而再次嘗試調用操做。

·熔斷器的實現

·閉合狀態：對程序的請求可以直接引發方法的調用。

·斷開狀態：對程序的請求會當即返回錯誤響應。

·半斷開狀態：容許對程序的必定數量的請求能夠調用服務，如調用成功，可認爲以前致使調用失敗的錯誤已經修正，熔斷器切換到閉合狀態；如調用失敗，則認爲問題仍存在，熔斷器切回到斷開狀態。

微服務架構的實現

·微服務技術選型（輕量級）

·開發服務：Spring Boot

·封裝服務：Docker

·部器服務：Jenkis

·註冊服務：ZooKeeper

·調用服務：Node.js

小結

什麼是軟件架構（體系結構）？

    ·結構，元素（組件），屬性，關係，行爲，原則圍繞業務

軟件架構的演化

    ·單體——分層——面向服務——微服務

微服務架構的特色

·服務顆粒化：服務粒度由業務功能決定，服務間儘量解耦

·責任單一化：單一職責原則，服務內儘量內聚|隔離失敗|

·運行隔離化：服務運行在各自進程中，互不影響

·管理自動化：對服務提供自動化部署與監控預警能力，高效管理

微服務架構的挑戰　　並非銀彈

·運維要求高：微服務數量多，部署與監控要求高

·發佈複雜度：部署環境多樣化，網絡性能、系統容錯、分佈式事務等挑戰

·部署依賴強：服務間相互調用關係複雜，存在部署順序依賴

·通訊成本高：跨進程調用比進程內調用消耗更多的資源

 

講課老師的聯繫 hezhang@nju.edu.cn