1. 概述

传统大型应用在设计时大多遵循 MVC 的架构,但由于这种模式相对力度较粗,同时在进行 scale-out(横向扩展)时,往往由于不同层次的应用短板形成瓶颈。在云计算的 IaaS、PaaS 等服务出现后,用户可以通过云中的服务能力,来替换 MVC 中的公共组件。同时由于云计算的原生应用(基础组件和设计模式遵循 CDP— 云设计模式的应用)天生具备更好的扩展性、可用性与弹性能力,因此有必要在设计应用系统时借鉴,这里列出的模式就是微软 Azure 平台给应用架构师和开发人员的云中应用建议,由品高云小编翻译制作。

本 CDP 系列文章分为上下两个部分,共 24 个经典的云设计模式,本文是上半部分。

2. 云中的问题区域和概念

2.1 可用性

可用性决定系统正常运行的时间比例,会受系统错误,基础设施问题,恶意攻击以及系统负载的影响。可用性通常用系统正常运行的百分比来衡量。云应用一般会为用户提供服务水平协议(SLA),这一协议意味着云应用必须以最大化可用性的方式来设计和执行。http://aka.ms/Availability-Patterns

2.2 数据管理

作为云应用的关键元素,数据管理影响着大部分的质量属性。由于性能,可扩展性,可用性等原因,数据通常被托管在不同位置的主机上或多个服务器上,这样就带来了一系列的问题与挑战,例如需要维持数据一致性,需要同步不同地区的数据等。http://aka.ms/DataManagement-Patterns

2.3 设计与实现

好的设计包含很多因素,比如保持组件设计与配置的一致性与连贯性,保证可维护性以简化管理和开发,确保可重用性以使组件和子系统可用于其他应用和情形下。在设计与实现阶段所做的决定会极大地影响储存在云端的应用程序和服务的质量和总成本。http://aka.ms/Design-and-Implementation-Patterns

2.4 消息通讯

基于云应用的分布式性质,通常需要一个连接不同组件和服务的消息基础架构,这种连接最好是以松耦合的方式来实现的,这样可以最大化可扩展性。被广泛使用的异步信息通讯有诸多优势,但同时也存在诸多问题,比如信息的排序,有害消息的管理,幂等性等等。http://aka.ms/Messaging-Patterns

2.5 管理与监控

云应用会在你无法完全控制基础架构或者,有些情况下,在无法控制操作系统的远距离数据中心运行。因此,比起本地部署的应用,对这些应用的管理和监控就要难得多。应用程序所曝露的运行时间可以为管理者和运营者所用来管理和监控系统,以及在不停止或重新布局应用的前提下满足不断变化的业务需求。http://aka.ms/Management-and-Monitoring-Patterns

2.6 性能与可扩展性

性能可以反映系统的响应速度与能力,而可扩展性是指能从容处理负载增加的能力,这一能力有时可能通过增加可利用资源来实现。所有的云应用,尤其是在多租户的情况下,通常会遇到工作负载变化以及不可预测的活动高峰等问题,所以这些应用就需要能够在允许的范围内向外扩展以满足需求,也要能够在需求减少的时候内向收缩。可扩展性不仅关乎到计算实例,而且与其它项目如数据存储和信息通讯基础架构等也相关。http://aka.ms/Performance-and-Scalability-Patterns

2.7 弹性

弹性是指系统可从容处理故障和从故障中恢复的能力。在云主机业务中,云应用程序通常为多租户共用,共享平台服务,争夺资源与带宽,通过互联网交流,且在商用硬件上运行。云主机业务的这一性质意味着瞬时故障和永久性故障将更有可能增加。因此,探测故障,快速且有效地从故障中恢复对于保持弹性来说就非常必要了。http://aka.ms/Resiliency-Patterns

2.8 安全性

安全性是指系统防止设计用途以外的恶意或意外行为以及防止信息泄露或丢失的能力。云应用会被曝露在可信内部范围之外的网络上,对公众公开,因而可能为非受信用户所用。云应用的设计与配置必须要能保护程序免受恶意攻击的侵害,只对被认可的用户开放,并能保护敏感数据。http://aka.ms/Security-Patterns

3. 具体设计模式

3.1 缓存预留模式

按需求将数据从数据存储库调入高速缓冲存储器中。这一模式既能改善性能,也有助于维持高速缓冲存储器中的数据与数据存储库中的数据的一致性。

更多信息详见 http://aka.ms/Cache-Aside-Pattern

3.2 事件溯源模式

用只能添加的数据库来记录数据所经历的所有事件而非只是记录数据的当前状态,并用数据库来具象化域对象。在复杂域中,事件溯源可以避免数据模型与业务域的同步,改善性能,可扩展性以及响应能力,保持一致性并提供核查记录以做后期弥补。

更多信息详见 http://aka.ms/Event-Sourcing-Pattern

3.3 领导人选举模式

通过选取一个实例作为领导人来负责管理其它实例的方式来协调在同一分布式应用中协作的所有任务实例的活动。这一模式有助于保证任务实例之间不发生冲突,不争用共享资源,不无意中干扰其它任务实例正在执行的工作。

更多信息详见 http://aka.ms/Leader-Election-Pattern

3.4 运行时间重新配置模式

设计一个无需重新布局或重启就能被重新配置的应用程序,这样有助于维持可用性和最小化故障停机时间。

更多信息详见 http://aka.ms/Runtime-Reconfiguration-Pattern

3.5 断路器模式

在连接到远程服务或资源时,处理需要不同时间量来修正的故障。这一模式可以改善应用程序的稳定性与弹性。

更多信息详见 http://aka.ms/Circuit-Breaker-Pattern

3.6 外部配置存储模式

将配置信息从应用配置包中移出到一个集中地点。这一模式可以使管理和配置数据控制变得更简单,也有助于实现不同应用于应用实例间的配置文件共享。

更多信息详见 http://aka.ms/External-Configuration-Store-Pattern

3.7 实体化视图模式

当数据以不支持所需查询操作的方式被格式化时,在一个或多个数据库中形成数据的预填充视图。这一模式有助于提高查询和数据提取的效率以及改善性能。

更多信息详见 http://aka.ms/Materialized-View-Pattern

3.8 调度代理主管模式

协调一系列分布式服务和其它远程资源的活动,在这些活动失败时试图透明处理故障并在系统无法从这些失败活动中恢复时撤销这些活动的影响。这一模式能让分布式结构恢复或进入因瞬时异常、长期故障以及进程失败的活动。

更多信息详见 http://aka.ms/Scheduler-Agent-Supervisor-Pattern

3.9 事务补偿模式

当一个或多个操作失败时,事务补偿模式可以撤销组成这些操作的一系列步骤的工作。遵循最终一致性模型的操作通常存在于执行复杂的业务程序和工作流程的云端应用中。

更多信息详见 http://aka.ms/Compensating-Transaction-Pattern

3.10 联合身份模式

将验证授权委托给外部身份提供者。这一模式可以简化开发,减少用户管理要求以及改善应用的用户体验。

更多信息详见 http://aka.ms/Federated-Identif-Pattern

3.11 管道过滤器模式

将执行复杂进程的一个任务分解为一系列可被再利用的离散因素。这一模式可通过允许执行进程的任务元素被独立重置或缩放以改善性能,可扩展性与可再用性。

更多信息详见 http://aka.ms/Pipes-and-Filters-Pattern

3.12 分区模式

将一个数据库划分为多个水平部分和分区。这一模式能在储存和读取大量数据时改善可拓展性。

更多信息,详见 http://aka.ms/Sharding-Pattern

相关文章: 微软 Azure 2015 云计算设计模式(下)