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

 

转载于:https://www.cnblogs.com/LittleHann/p/4303062.html