Cloud Design Patterns Book Reading(undone)

目錄

1. the most common problem areas in cloud application development
    1) Availability
    2) Data Management
    3) Design and Implementation
    4) Management and Monitoring 
    5) Messaging
    6) Performance and Scalability
    7) Resiliency
    8) Security

 

1. the most common problem areas in cloud application development

0x1: availability(可用性)

可用性定義了系統正常工作、發揮功能的時間比例。系統的可用性受到以下因素的影響

1. 系統錯誤
2. 基礎設施(例如網路)問題
3. 惡意攻擊
4. 系統負載

對於雲端計算應用來說，它需要向使用者提供"service level agreement (SLA)"，這也意味著雲端計算應用在產品設計和實現的時候需要最大程式的考慮到可用性這個因素

1. Health Endpoint Monitoring Pattern

在雲產品中，通過通過暴露外部工具可以定時訪問的功能檢查介面，這種設計模式可以幫助驗證應用程式和服務是否處於正確執行狀態。但是在雲端計算架構下，健康檢查存在以下幾個風險和挑戰

1. 應用管理員無法後的對應用宿主環境的完全控制權，因為這些是由雲服務運營商提供的，應用管理員只是購買了對應的雲服務，並不擁有"實際的物理資源"的運維許可權
2. 影響雲應用穩定執行的因素有很多，例如
    1) 網路延遲
    2) 底層計算叢集、資料儲存系統的效能和可用性
    3) 網路頻寬

其中任何一個因素都有可能導致雲應用執行異常，為了保證SLA，我們必須對這些因素維度進行定時的健康檢查
基本上來說，一個典型的雲-端健康檢查需要包括

1. 檢查模組: 執行在雲應用中，負責對系統中的各個核心指數進行收集
2. 分析模組: 執行在雲應用中/或者雲端伺服器中，負責對客戶端的各個健康指數進行評估，得出健康狀態

基本上來說，健康檢查可以圍繞以下幾個方面展開

1. 站點監控
    1) HTTP監控: 監控網站返回碼(例如200、404)
    2) PING監控: 網路延時監控
    3) TCP監控
    4) UDP監控
    5) DNS監控: 監控DNS異常、解析延時、DNS汙染惡意解析(防止釣魚攻擊)
    6) SMTP監控
    7) POP3監控
    8) FTP監控
    9) 網頁內容異常監控: 即使返回200，網站的應用程式碼也可能存在code bug，內容監控可以發現這個異常
2. 雲服務監控
    1) 服務響應時間監控
    2) 資料庫可用性、響應時間檢查
3. 自定義監控
    1) 客戶端第三方依賴資源可用性檢查
    2) SSL證書異常監控

Relevant Link:

https://msdn.microsoft.com/en-us/library/dn589789.aspx

2. Queue-based Load Leveling Pattern

在任務(生產者)和服務(消費者)之間使用"快取佇列"可以有效地"平滑"突然到來的重負載，減少雲應用突發crash、或者延時(time out)的風險，提高任務和服務之間的可用性和響應性
對於安全攻防相關的雲產品來說，由於安全事件的突發性、攻擊事件的短時間內大流量的特性，服務端往往會受到短時間內無法提前預測的重負載
在任務(task)和服務(service)之間建立訊息佇列(message queue)可以使生產者和消費者之間以非同步的方式執行，實現瞭解耦，同時，任務(task)也可以採用非延時(no wait)的方式向服務(service)發起請求

這種模式為雲應用帶來了如下好處

1. 提高了可用性: 即使在服務暫時不可用、或者處於效能瓶頸的時候，任務依然可以繼續向佇列中傳送待處理訊息
2. 提供了可擴充套件性: 訊息佇列和服務都可以根據負載情況進行水平擴充套件
3. 降低了成本: 服務的資源投入只要滿足平均負載即可，不需要根據峰值流量進行裝置擴充

Relevant Link:

https://msdn.microsoft.com/en-us/library/dn589783.aspx

3. Throttling Pattern

雲應用的負載往往受到當前活躍使用者、或者雲應用所處業務場景強相關

1. 短時間內受到大量外來攻擊
2. 系統短時間內產生大量系統呼叫服務
3. 在一天中的某些時段，網站會處於繁忙的高負載狀態
4. 月末、凌晨進行的定時CPU、資源密集型計算
5. 應用程式可能會在短時間內出現CPU、記憶體飆高的現象

當處理請求所需要消耗的資源超過系統可用的資源上限的時候，就會發生資源瓶頸，從而導致效能下降甚至crash
一個好的解決思路是: 設定一個虛擬的"資源上限(resources soft limit)"，當到達使用上限的時候，限制(throttle)資源的使用，系統(作業系統、或者執行庫)需要監控資源的使用情況，當處於資源上限邊界的時候，根據不同的策略進行處理

1. 對單個使用者重複對系統對外API呼叫次數子在一個時間段內超過n次的請求，予以拒絕(drop)，使用這種模式，需要雲應用系統中負責資源監控的模組維護一套MAC模式的"資源使用狀態表"(對每個使用者的資源使用狀態進行監控)
2. 當達到資源使用上限極限的時候，選擇性地關閉一些非核心功能模組(即降級)
3. 延遲一些低優先順序的資源操作請求(sleep、或者暫存佇列延遲處理)，當發生這種情況的時候，需要通知請求方，當前系統處於繁忙狀態，可能會有延遲的情況
4. 當達到資源上限的時候，嚮應用傳送SIGNAL訊號(linux下的setrlimit、getrlimit就是這種實現方式)，典型的結果就是kill程式，等待守護程式重啟它

圖中我們可以看到，featureB相對於A、C是低優先順序的，所以在T1~T2這個高負載時間段，選擇了降級的方式，即直接關閉featureB，讓featureC的峰值下移，保證了featureA、featureC能夠正常執行
值得注意的是，自動擴容(autoscaling)技術和節流(throttling)技術可以組合使用，保證雲應用始終處於較高的SLAs狀態，這裡的原則是

1. 節流(throttling)技術能保證在高負載狀態下臨時短時間維持系統的正常執行，例如通過降級的方式
2. 自動擴容(autoscaling)技術可以從根本上解決資源緊張的問題，但是缺點就是自動擴容的響應需要一個時間視窗(time windows)來進行，這個時間視窗正好可以通過節流技術來填補

Relevant Link:

https://msdn.microsoft.com/en-us/library/dn589798.aspx

4. Multiple Datacenter Deployment Guidance

Relevant Link:

https://msdn.microsoft.com/en-us/library/dn589779.aspx
https://msdn.microsoft.com/en-us/library/dn589779.aspx

0x2: Data Management(資料管理)

資料管理是雲應用的關鍵組成部分

1. Cache-aside Pattern: loads data into the cache on demand

在實際需要使用的時候，從底層資料庫中讀取資料到cache快取中，上層應用邏輯只和cache快取打交道，這種模式可以更好的處理快取和底層資料之間的資料一致性和永續性

1. 使用cache快取可以提高針對重複資料訪問的響應效能
2. 當底層資料發生變化時，要有一種機制能及時通知到cache層，將指定的資料標記為髒資料，在下次讀取的時候需要重新從底層資料來源中讀取
3. 當cache層中的資料發生變化時，需要將cache中指定的資料寫回(write through)到底層資料來源中

Relevant Link:

https://msdn.microsoft.com/en-us/library/dn589799.aspx

2. Command and Query Responsibility Segregation (CQRS) Pattern: 讀寫分離
以Mysql Server的主從讀寫分離為例，讀寫分離可以帶來以下好處

1. 物理伺服器增加，負荷增加
2. 主從只負責各自的寫和讀，極大程度的緩解X鎖和S鎖爭用，準備來說，是極大程度地減少(並不能完全杜絕)X和S鎖之間的爭用，即將原本頻繁發生的鎖爭用縮減到了較少次數的鎖爭用
3. 從庫可配置MYISAM引擎，提升查詢效能以及節約系統開銷
4. 從庫同步主庫的資料和主庫直接寫還是有區別的，通過主庫傳送來的binlog恢復資料，但是，最重要區別在於主庫向從庫傳送binlog是非同步的，從庫恢復資料也是非同步的 
5. 讀寫分離適用與讀遠大於寫的場景，如果只有一臺伺服器，當select很多時，update和delete會被這些select訪問中的資料堵塞，等待select結束，併發效能不高 
6. 對於讀操作為主的應用，使用讀寫分離是最好的場景，因為可以確保寫的伺服器壓力更小，而讀又可以接受點時間上的延遲

Relevant Link:

https://msdn.microsoft.com/en-us/library/dn568103.aspx
http://heylinux.com/archives/1004.html
http://blog.csdn.net/justdb/article/details/17331569

3. Event Sourcing Pattern

對於傳統的資料庫CRUD(creat、read、update、delete)操作來說，典型地維護資料的邏輯流程是: 1) read data -> 2) modify date -> 3) lock the origin place of the data -> 4) update data to the origin place
這種方式存在以下幾個問題

1. read操作使用的S鎖(Share lock 共享鎖)，共享鎖允許其他read操作繼續進行，但是不允許X鎖進行
2. update操作使用的X鎖(Exclusion lock 互斥鎖)，互斥鎖是獨佔鎖，不允許任何其他草走
3. 讀和寫、寫和寫之間存在大量的鎖爭用
4. 在沒有第三方操作審計模組的支援下，資料來源上的歷史操作將全部丟失(因為都直接update覆蓋了)

事件源模型(Event Sourcing pattern )使用了另一種方式記錄資料的變化，應用對資料的操作都轉化為一系列的"操作指令序列"，並儲存在一個"遞增(append-only)"的資料庫中。在這種模式下，所有對資料的操作都以一系列操作指令的形式儲存下來
從某種角度來說，這和向量圖的思想是一樣的，向量圖並不記錄影象畫素本身，而是記錄如何繪製這張圖的演算法，而具體的繪製實現由資料獲取者自己完成

這種模式存在以下幾點特點

1. 使用"append-only"方式儲存，沒有update操作，儲存效率可以大幅度提高
2. 事件本身可以抽象為一些列的操作描述符，可以輕量化的儲存
3. 操作指令序列之間可以併發地儲存，由時間來進行序列化，不存在update的併發互斥問題
4. "append-only"為審計系統提供了資料來源

Relevant Link:

https://msdn.microsoft.com/en-us/library/dn589792.aspx

4. Index Table Pattern

大多數關係型資料庫系統都提供了主鍵(primary key)、次主鍵(secondary key)的特性，允許在表中新增多個主鍵，但是在例如NoSQL這種非關係型資料庫中，我們需要通過手工的方式實現多主鍵這個需求。需要明白的是，主鍵(index/key)之所以能夠顯著提高查詢效率，其中的核心就是排序(sort)，通過排序，將低效率的遍歷操作轉化為了高速的演算法搜尋

Relevant Link:

https://msdn.microsoft.com/en-us/library/dn589791.aspx

5. Materialized View Pattern

Generate pre-populated views over the data in one or more data stores when the data is formatted in a way that does not favor the required query operations. This pattern can help to support efficient querying and data extraction, and improve application performance.

Relevant Link:

https://msdn.microsoft.com/en-us/library/dn589782.aspx

6. Sharding Pattern: 水平分表

Relevant Link:

https://msdn.microsoft.com/en-us/library/dn589797.aspx

7. Static Content Hosting Pattern: 靜態化

In most cloud hosting environments it is possible to minimize the requirement for compute instances (for example, to use a smaller instance or fewer instances), by locating some of an application’s resources and static pages in a storage service. The cost for cloud-hosted storage is typically much less than for compute instances.
When hosting some parts of an application in a storage service, the main considerations are related to deployment of the application and to securing resources that are not intended to be available to anonymous users.

client will access this resource directly from the storage service

Relevant Link:

https://msdn.microsoft.com/en-us/library/dn589776.aspx

8. Valet Key Pattern: Oauth Single Sign On

Relevant Link:

https://msdn.microsoft.com/en-us/library/dn568102.aspx

0x3: Design and Implementation

1. Compute Resource Consolidation Pattern

Running tasks in a cloud environment by using a set of dedicated computational units
在雲產品的設計和實現中，常常為了追求功能模組獨立、可擴充套件性等原則，將各個功能模組分離到各個獨立的計算資源單元中

各個計算資源單元使用自己獨有的受控資源，很容易造成資源使用浪費，一個好的解決方案是進行計算單元整合，根據各個計算單元的任務性質、資源處理需求、宣告週期、可擴充套件性等因素進行"Compute Resource Consolidation"

illustrates the lifecycle of a role, and the tasks and resources that it hosts. The tasks are started by the Run method, which then waits for the tasks to complete. The tasks themselves, which implement the business logic of the cloud service, can respond to messages posted to the role through the load balancer.

Relevant Link:

https://msdn.microsoft.com/en-us/library/dn589778.aspx

2. External Configuration Store Pattern

對於傳統的客戶端應用來說，程式執行中所使用到的配置檔案被放置在應用所在檔案目錄中，這會帶來一系列的安全問題

1. 攻擊者可能通過修改本地的配置的檔案來任意改變程式的行為、甚至劫持程式的執行流程
2. 配置檔案中可能包含敏感資訊，例如server IP、資料庫連線帳號密碼

將雲產品的配置檔案從程式安裝包(或者安裝目錄)中移出到一箇中心儲存的服務端進行統一維護，客戶端則定時地從服務端進行增加拉取更新(根據MD5進行判斷，如果沒有變化則不更新)，這種方法可以降低管理維護成本、提供對配置的控制能力、提供產品配置的靈活性

Relevant Link:

https://msdn.microsoft.com/en-us/library/dn589803.aspx

3. Pipes and Filters Pattern

A solution implemented by using pipes and filters

an example applied to the pipeline for the data from Source 1
這種過濾器-管道(模組分解)的設計方式可以使得多執行緒和單執行緒的實現可以以更加細粒度的方式實現

Relevant Link:

https://msdn.microsoft.com/en-us/library/dn568100.aspx

4. Runtime Reconfiguration Pattern: 配置檔案hot reload

在更改配置的時候，不需要重啟應用

Relevant Link:

https://msdn.microsoft.com/en-us/library/dn589785.aspx

0x4: Management and Monitoring

Cloud applications run in in a remote datacenter where you do not have full control of the infrastructure or, in some cases, the operating system. This can make management and monitoring more difficult than an on-premises deployment. Applications must expose runtime information that administrators and operators can use to manage and monitor the system, as well as supporting changing business requirements and customization without requiring the application to be stopped or redeployed.

0x5: Messaging

在分散式架構下的雲端計算應用需要有一個有效的訊息推送和處理基礎設施，理想狀態下，使用非同步的、鬆耦合的訊息傳輸機制是最好的實踐方式，但同時也帶來了很多的挑戰因素，例如: 訊息到達的序列排序、惡意訊息的處理、冪等性等等

1. Competing Consumers Pattern

使用這種訊息快取佇列、訊息中介軟體的最大好處是可以實現"削峰"，雲應用系統可能會在一個很短的時間內受到大流量的負載，但是這個峰值持續時間只佔了總時間的很小一部分，在這種場景下，採取擴容的方式是不合理不經濟的，使用訊息中介軟體可以將峰值流量進行快取，而對於訊息中介軟體來說，需要保證的一個重要因素就是保證訊息處理的"投遞單一性"，即一個訊息只能被一個消費者處理(linux的訊息佇列(message queue)就是一種由作業系統核心實現的訊息投遞元件，可以保證每條訊息至少只被消費一次，由核心實現讀寫鎖)
需要強調的是每條訊息"至少"只被消費一次，因為如果某條訊息投遞後被處理失敗，則需要對這條訊息進行達標，重新進行投遞

 

Relevant Link:

https://msdn.microsoft.com/en-us/library/dn568101.aspx

2. Priority Queue Pattern

對雲應用中使用的訊息佇列(message queue)來說，"first-in、first-out(FIFO 先進先出)"是常用的策略，可以實現的改進是對每條訊息進行"權重配置"，對高權重的訊息進行優先處理

Using a queuing mechanism that supports message prioritization

Using separate message queues for each priority，The application is responsible for posting messages to the appropriate queue. Each queue can have a separate pool of consumers. Higher priority queues can have a larger pool of consumers running on faster hardware than lower priority queues.

Relevant Link:

https://msdn.microsoft.com/en-us/library/dn589794.aspx

3. Scheduler Agent Supervisor Pattern

Coordinate a set of actions across a distributed set of services and other remote resources, attempt to transparently handle faults if any of these actions fail, or undo the effects of the work performed if the system cannot recover from a fault. This pattern can add resiliency to a distributed system by enabling it to recover and retry actions that fail due to transient exceptions, long-lasting faults, and process failures.

Relevant Link:

https://msdn.microsoft.com/en-us/library/dn589780.aspx

0x6: Messaging

Performance is an indication of the responsiveness of a system to execute any action within a given time interval, while scalability is ability of a system either to handle increases in load without impact on performance or for the available resources to be readily increased. Cloud applications typically encounter variable workloads and peaks in activity. Predicting these, especially in a multi-tenant scenario, is almost impossible. Instead, applications should be able to scale out within limits to meet peaks in demand, and scale in when demand decreases. Scalability concerns not just compute instances, but other elements such as data storage, messaging infrastructure, and more.

Relevant Link:

https://msdn.microsoft.com/en-us/library/dn600224.aspx

0x7: Resiliency(彈性)

Resiliency is the ability of a system to gracefully handle and recover from failures. The nature of cloud hosting, where applications are often multi-tenant, use shared platform services, compete for resources and bandwidth, communicate over the Internet, and run on commodity hardware means there is an increased likelihood that both transient and more permanent faults will arise. Detecting failures, and recovering quickly and efficiently, is necessary to maintain resiliency

1. Compensating Transaction Pattern

Undo the work performed by a series of steps, which together define an eventually consistent operation, if one or more of the operations fails. Operations that follow the eventual consistency model are commonly found in cloud-hosted applications that implement complex business processes and workflows.

Relevant Link:

https://msdn.microsoft.com/en-us/library/dn589804.aspx

2. Retry Pattern

Enable an application to handle temporary failures when connecting to a service or network resource by transparently retrying the operation in the expectation that the failure is transient. This pattern can improve the stability of the application.
在雲產品的設計中需要設計透明自動化的重試機制(Retry Mechanism)，總的指導原則如下

1. 如果當前發生的錯誤不是暫時的、且不可能成功的(例如使用者提供的帳號、密碼錯誤導致的連線失敗)，則系統應當將詳細的出錯資訊丟擲，經過包裝(wrap)後給呈現給使用者UI
2. 如果當前發生的錯誤是不常見的，即可能是因為一些極端狀況下產生的錯誤(例如網路不穩定斷開)，這個時候應該立刻啟動重試機制
3. 如果當前發生的錯誤是常見的，例如"伺服器繁忙(server busy)"，這個時候需要等待一定的時間視窗後，再進行重試
4. 要特別注意的是，在因為"server busy"而導致的重試的時候，發起重試的客戶端需要在啟動時間上有一個錯峰，否則可能會因為短時間內發起的大量重試造成對server端的DDOS/CC攻擊
5. 應當設定一個重試次數的上限

Relevant Link:

https://msdn.microsoft.com/en-us/library/dn589788.aspx

0x8: Security

Security is the capability of a system to prevent malicious or accidental actions outside of the designed usage, and to prevent disclosure or loss of information. Cloud applications are exposed on the Internet outside trusted on-premises boundaries, are often open to the public, and may serve untrusted users. Applications must be designed and deployed in a way that protects them from malicious attacks, restricts access to only approved users, and protects sensitive data.

1. Federated Identity Pattern

An overview of federated authentication

Relevant Link:

https://msdn.microsoft.com/en-us/library/dn589790.aspx

2. Gatekeeper Pattern: WAF

Protect applications and services by using a dedicated host instance that acts as a broker between clients and the application or service, validates and sanitizes requests, and passes requests and data between them. This pattern can provide an additional layer of security, and limit the attack surface of the system.

Relevant Link:

https://msdn.microsoft.com/en-us/library/dn589793.aspx

 

Copyright (c) 2014 LittleHann All rights reserved