EthanPark的博客

Pipe和Filter模式将执行复杂处理的任务分解为可重复使用的一系列离散元素。这种模式可以提高性能，可扩展性和可重用性，允许执行部署和缩放独立处理的任务元素。问题一个应用程序可能根据其处理的不同的信息需要执行各种复杂的任务。一个简单的，但不灵活的方法就是可以将应用的处理作为一个单独的模块。但是，如果部分相同的处理需要在应用程序的其他地方，这种方法可能会减少代码重构，重用，优化的机会。下图1说明了单

Competing-Consumers模式支持多个并发消费者来处理消费消息队列上接收到的消息。该模式令系统能够并发的处理消息，并且优化吞吐，增加扩展性和可用性，同时平衡工作负载。问题在云环境中运行的程序可能需要处理大量的请求。相对于同步的处理每个请求，通常更常用的技术是由应用将请求通过消息系统来传给其他的服务(消费者服务)，然后由其他的服务来异步处理。该策略能够确保应用中的业务逻辑不会因为请求的处理

Priority Queue模式优先级队列模式：将请求根据优先级进行分流，令高优先级的请求能够比低优先级的请求更快的接收和处理。优先级队列模式对于针对需要根据不同的客户端来实现不同的服务级别的情况下十分实用。问题应用可能会将某些指定的任务代理到一些其他的服务或应用上面。比如，会存在需要执行一些后台处理，或者与其他应用或者服务集成的情况。在云环境中，通常使用消息队列来代理任务和后台的处理。在很多时候，

Event-Sourcing模式使用仅附加存储来记录或描述域中数据所采取的动作，从而记录完整的一系列系列事件，而不是仅存储实体的当前状态。因为存储包含全部的事件，可以用来具体化域对象。Event-Sourcing模式可以简化复杂的域中的任务，避免了数据模型和业务领域的同步和引发的争用问题；增强性能，扩展性，以及响应；为事物数据提供一致性；保留全部的事件执行历史，可以跟踪和实现回滚之类的补偿操作。问题

Materialized-View模式是在要求数据格式不利于查询操作的情况下，根据多个数据仓库的数据生成预生成的视图的一种模式。这种模式可以帮助支持高效的查询和数据提取，提高应用程序的性能。问题在存储数据时，开发人员和数据管理员考虑的第一优先级通常集中在如何存储数据，而不是如何读取数据。所选择的存储格式通常与数据的格式、管理数据大小和数据完整性的要求，以及存储的类型密切相关。例如，使用NoSQL存储

事务隔离通常通过锁定任何对事务中资源的访问来实现的。总的来说，有两种方法针对事务的锁定：乐观锁(Pessimistic locking)和悲观锁(Optimistic locking)悲观锁（Pessimistic locking）悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现

将数据存储为一组水平的数据分区。这种模式可以在存储和访问大量的数据的时候提高可扩展性。场景和问题由单个服务器托管的数据存储可能受到下列限制：存储空间限制。基于大规模云应用所使用的数据仓库，可能会包含海量的数据，并且数据增长速度非常的快。一个服务器通常只提供有限容量的磁盘存储，当然它可能是可以替换现有的磁盘与较大的，或添加进一步磁盘到服务器以增加存储量。但是，该系统将最终达到一个硬件的限制，一味地增

在很多大规模的解决方案中，数据都是分成单独的分区，可以分别进行管理和访问的。而分割数据的策略必须仔细的斟酌才能够最大限度的提高效益，同时最大限度的减少不利影响。数据的分区可以极大的提升可扩展性，降低争用以及优化性能。为何进行数据分区绝大多数的云应用和云服务都会将存储和检索数据作为其业务的一部分。而应用所使用的数据仓库的设计对于系统的性能，吞吐，扩展性都有着非常重要的影响。其中在大规模系统中常用的一种

Health Endpoint Monitoring模式是一种用来监控服务健康状态的模式。Health Endpoint Monitoring模式通过在应用内额外暴露一个可以进行功能检查的接口来实现，可以由外部工具定期访问暴露在外部的端点来检查服务的状态。该模式可以有效验证服务是否可用。问题监控应用的状态通常是一种很好的应用实践。通常来说，也是业务的一个需求。针对一些中间层和共享的服务也同样如此。因

CQRS模式，就是命令和查询责任分离模式。CQRS模式通过使用不同的接口来分离读取数据和更新数据的操作。CQRS模式可以最大化性能，扩展性以及安全性，还会为系统的持续演化提供更多的弹性，防止Update命令在域模型Level发生冲突。问题在传统的数据管理系统中，更新数据以及请求数据的命令是通过数据仓库中的同一类型的实体来执行操作的。这些实体属于关系数据中的表的一列或者几列。通常，在这些系统中，所有的

云应用通常来说，使用的数据很多都是分散的，来自不同的数据仓库。在这种环境下，管理和保持数据一致性是很复杂的，无论是在并发跟可用性上都可能出问题。开发者有的时候就需要为了强一致性而牺牲可用性了。这也就意味着开发者需要需要针对应用最终一致性设计一些切面，并且意识到应用并不是所有的时刻都是完全数据一致的。管理数据一致性每个web应用和服务都会使用到数据。这数据通常被用户和组织来做出商务决策的。因此，保证数

Sagas属于一个错误管理模式，也同时用于控制复杂事务的执行和回滚等。同时，Compensating-Transaction模式的的实现也是也是类似于Sagas策略的，可以对比参考一下。Sagas的最开始的出现是因为一些长时间的事务的实现（最开始的时候仅仅是因为数据内的事务），现在也包括一些跨越多个区域的分布式事务。这些长时间持续的事务无法简单地通过一些典型的ACID模型使用多段提交配合持有锁的方式

在应用中，会将一系列相关的操作定义为一个连续的操作，当其中一个或者多个步骤失败的时候，Compensating-Transaction模式会重置(回滚)这个连续的操作。在云应用中，这些需要保证一致性的操作是较为常见的，正是这些操作构成了复杂的业务处理和工作流。问题云中运行的应用会频繁的修改数据。数据可能会传播到另外一组数据源，但是数据库却可能在不同的地方。为了避免竞争并且增加诸如此类分布式环境的性能

Retry模式能够通过重复之前失败的操作来处理那些在调用远端服务或者网络资源的时候发生的一些可以预期的临时性的错误。Retry模式可以提高应用的稳定性。问题应用中，负责链接其他服务的组件必须要对环境中可能发生的临时性错误十分敏感。这些错误包括瞬间的网络连接丢失，服务的暂时不可用，或者是服务繁忙导致的超时等等。这些错误都属于不需要额外操作就能够自我修复的错误，只需要过了一定的时间延迟再重复之前的失败操

Cache-Aside模式是从数据仓库中将数据加载到缓存中，从而提高访问速度的一种模式。该模式可以有效的提高性能，同时也能一定程度上保证缓存中的数据和数据仓库中的数据的一致性，和同步数据到数据仓库中。问题应用通过缓存来优化针对数据仓库的重复访问。当然，令缓存中的数据永远和数据仓库中数据保持一致是不切实际的。应用中的缓存应该事先一些策略来辅助更新缓存保证数据的一致，当然，也需要检测数据过期等情况来进

Circuit Breaker模式会处理一些需要一定时间来重连远程服务和远端资源的错误。该模式可以提高一个应用的稳定性和弹性。问题在类似于云的分布式环境中，当一个应用需要执行一些访问远程资源或者是远端服务的时候，是很容易碰到一些偶然的错误的，比如说，网络连接速度很慢，超时，或者是资源的过量使用，或者临时资源不再可用等等。这一类的错误通常来说会在短暂的时间内，自动恢复过来。一个健壮的云应用也该能够通过