2023 聊一聊云原生设计模式系列 - 开篇
引言
在降本增效的行业大环境下，原有业务要面对改造迁移上云的过程。 但云上环境的高动态性、可伸缩性、零信任性，某种程度上物理共享等特点，又给原应用改造适配带来重重困难。
难点主要有三方面：数据管理；应用通信机制的设计；云上部署与构建。
具体来看：
- 数据管理：需要考虑的问题，比如数据存储在哪？怎么存储最经济？数据的访问模式是什么样的？如何保证数据的一致性？如何应对数据的增长？多源异构的数据如何分别选型？
- 云上部署与构建：需要考虑的问题，如何拆分功能到不同的组件中？如何保持部署的一致性、连贯性、简化管理开发的可维护性？如何保证环境的安全，异常攻击的防范？
- 应用通信机制的设计：大型应用往往包含多个组件，多组件之间的通信一般依赖消息机制来进行解耦，以最大化云上的可伸缩性。异步消息投送机制也会带来许多挑战，如消息排序、幂等行和有害消息处理等。
那么，有没有指导性建议可以帮助构建出可靠且可伸缩的安全云原生应用呢？答案自然是有 —— 云原生设计模式。把云原生设计模式来开发和设计应用，不仅可以降低云上应用设计和开发的难度，而且能够使得构建出的应用更加适合云上环境，实现较优投入产出比。
本文参考了多家云厂商提供的最佳实践文档，对一些常见云原生设计模式谈一谈个人的理解和经验。
| 设计模式 | 概述 |
|---|---|
| Asynchronous Request-Reply | row 1 col 2 |
| Choreography | Let each service decide when and how a business operation is processed, instead of depending on a central orchestrator. |
| Claim Check | Split a large message into a claim check and a payload to avoid overwhelming a message bus. |
| Compensating Transaction | Undo the work performed by a series of steps, which together define an eventually consistent operation. |
| Compute Resource Consolidation | 将多个任务或操作合并到单个计算单元 |
| CQRS | 使用独立接口将读取数据的操作与更新数据的操作分离。 |
| Deployment Stamps | 部署应用程序组件的多个独立副本，包括数据存储 |
| Event Sourcing | Use an append-only store to record the full series of events that describe actions taken on data in a domain. |
| Federated Identity | Delegate authentication to an external identity provider. |
| Gatekeeper | 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. |
| Gateway Aggregation | |
| Gateway Offloading | |
| Gateway Routing | |
| Geodes | Deploy backend services into a set of geographical nodes, each of which can service any client request in any region. |
| Health Endpoint Monitoring | Implement functional checks in an application that external tools can access through exposed endpoints at regular intervals. |
| Index Table | Create indexes over the fields in data stores that are frequently referenced by queries. |
| Leader Election | Coordinate the actions performed by a collection of collaborating task instances in a distributed application by electing one instance as the leader that assumes responsibility for managing the other instances. |
| Materialized View | |
| Pipes and Filters | Break down a task that performs complex processing into a series of separate elements that can be reused. |
| Priority Queue | |
| Publisher/Subscriber | |
| Queue-Based Load Leveling | |
| Rate Limit Pattern | |
| Saga | Manage data consistency across microservices in distributed transaction scenarios. A saga is a sequence of transactions that updates each service and publishes a message or event to trigger the next transaction step. |
| Retry | Enable an application to handle anticipated, temporary failures when it tries to connect to a service or network resource by transparently retrying an operation that’s previously failed. |
| Scheduler Agent Supervisor | |
| Sequential Convoy | |
| Sharding | Divide a data store into a set of horizontal partitions or shards. |
| Sidecar | Deploy components of an application into a separate process or container to provide isolation and encapsulation. |
| Static Content Hosting | CDN |
| Strangler Fig | Incrementally migrate a legacy system by gradually replacing specific pieces of functionality with new applications and services. |
| Throttling | Control the consumption of resources used by an instance of an application, an individual tenant, or an entire service. |
| Valet Key | Use a token or key that provides clients with restricted direct access to a specific resource or service. |
| Bulkhead | |
| Cache-Aside |
后面，我将以系列文章的形式,逐个展开的介绍各个模式具体含义、用法以及适用场景。
本系列文章脉络来源:Azure 架构中心-设计模式