你是否了解这些常用架构？( 二 ) _架构

目前大型互联网公司普遍采用微服务架构，处理用户侧发起的short-lived请求，以支撑超高的QPS 。
事件驱动架构

文章插图
事件驱动架构采用了订阅-发布模型，也叫生产者-消费者模型。生产者负责发布事件到消息队列，消费者订阅消息队列。生产者和消费者互相独立，多个消费者之间也互相独立。
依赖的中间件有 Kafka、RocketMQ、redis Pub/Sub 等。
事件驱动架构下，应用程序可以以非常低的延迟处理大量的数据，在数据采集分析场景下使用非常广泛。比如IoT场景、大型互联网应用的数据收集子系统（日志/埋点数据回收）。
大数据、大计算

文章插图
大数据是目前互联网的标配场景，它的第一步一般是流式地搜集应用日志，清洗后存到分布式存储中，应用到离线场景，或分发到消息队列，用于流式处理。这一点与事件驱动架构有部分重叠。
当我们聊大数据是，通常是说对一个超大数据集进行分片/区，执行并行计算，最终产出分析和报表。数据集大小可能是PB级。
大计算，也叫高性能计算(HPC)，可以在上千核的CPU上并行计算。除了我们熟悉的大数据场景，也应用在图形渲染、流体动力学、金融风险建模、石油勘探、药物设计等领域。
不同架构模式的局限任何架构在设计上都有受到一些限制，比如架构基本元素的形态，以及元素之间允许存在的关系。这些限制本质上是在某种架构下，我们可选的最大集合，它影响甚至间接塑造了架构的最终形态。当应用的构建遵循某种架构模式时，一些好的符合预期的特性也会出现。
上面这段话有点抽象，我们以微服务架构的限制为例：

每个服务承担独立单一的职责
服务之间相互独立
数据只归属于拥有它的服务，服务之间不共享数据的所有权

遵循这些限制之后，系统中的服务就可以独立进行部署。收益时事故隔离、支持频繁更新、可便捷地引入新技术。
在选择某种架构模式之前，我们需要理解架构的底层原则和限制。否则，架构设计只在最表层符合某种架构模式，但无法发挥这种架构模式的潜力。在使用架构过程中，务实很重要，有时候我们可能要放宽一些限制，而不是坚持架构的纯粹。
下面这张表总结了不同的架构模式如何管理依赖，以及适用的业务领域
架构模式
依赖管理
适用业务场景
分层架构
按照子网进行水平分层
传统业务领域，更新频率不高
Web-queue-worker
前后端任务分离，通过异步消息进行解耦
相对简单的业务场景，需要执行一些资源密集型任务
微服务架构
功能/垂直节藕的服务，通过API调用进行通信
比较复杂的业务场景，支持高频率的更新
事件驱动架构
生产者/消费者，每个子系统有独立的数据视图
IoT和实时系统
大数据架构
将一个超大数据集拆分成小的数据块，在之上进行并行计算
批处理和流式处理的数据分析，机器学习模型支持的预测分析
【你是否了解这些常用架构？】大计算架构（高性能计算）
数据被分配到上千核CPU上进行计算
计算密集型的场景，比如模拟系统
不同架构模式面临的挑战vs收益架构的限制使其在某些场景下面临一些挑战，所以在采用这些架构模式时，需要理解其中的利弊权衡。我们需要保证，在我们所在的子领域（场景），叠加场景的限制条件下，架构带来的收益超过要面临的挑战。
下面列出了在选择架构模式时面临的四类挑战：