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

分層架構

·“關註點分離”原則

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

·表現層

·業務層

·持久層

·數據層

·分層架構模式特點：

+結構簡單

+易於組織開發

+便於獨立測試、維護

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

-性能代價

-可擴展性差

面向服務架構

·面向服務架構（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

小結

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

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

軟件架構的演化

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

微服務架構的特點

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

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

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

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

微服務架構的挑戰　　並不是銀彈

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

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

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

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

講課老師的聯系 [email protected]

第四講 軟件架構演化