服务架构简介：你是否了解这些常用架构？

,我们日常生活中使用很多应用程序，有微信、抖音、王者这种涉及多人联网互动的大型应用，它们以操作系统作为宿主；也有网站、小程序、PWA等借壳的应用。面向用户表现为Android/iOS/Windows/MacOS/浏览器/H5/Terminal 等端上的应用程序，名为 Client。更多情况下，业务的核心逻辑体现在背后看不见的服务，名为 Server。,从普通用户视角跳出来，切换到程序员视角，应用程序可以理解为是M个Client和N个Server的组合。在软件开发过程中，Client/Server的边界如何划分，Server之间如何通信，多个Server如何组织能够保证整个系统按照预期的方式运行，都是服务架构要考虑的问题。,下面我们简单串一下主流的几个服务架构，包括分层架构、client-queue-worker架构、微服务架构、事件驱动架构、大数据、大计算架构，并从四个方面对每个架构进行总结：,,WAF全称Web Application Firewall，就是防火墙,在开发传统企业应用中，分层架构得到了广泛使用。一个应用被划分为多个逻辑功能的层，比如展示层、业务逻辑层和数据访问层。这些分层同时也定义了依赖关系，每个层都只能调用它下面的层。每个层可以是一个独立的模块，整个系统的各个模块可以独立甚至并行开发和测试，交付质量可以得到比较好地保证，所以这是目前最为广泛使用的架构之一。但它也有一些难以解决的问题，尤其体现在产品上线后的变更上。体现在：,分层架构在私有云系统中非常常见，比如一个私有云的解决方案可以设计为：,,这个架构下，用户通过前端Web页面将任务异步发送到后端，协议可以是HTTP或RPC。通常情况下，后端的worker接收任务后，执行一段事件CPU密集型计算，生成结果。,作为对比，分层架构中来自client的请求大都同步到达，请求可以很快得到满足，server端处理完成后同步返回；相反，任务调度架构下，每个请求要得到满足，可能耗费server大量的计算/网络或存储资源，所以异步返回。,在通信方式上，任务调度架构更多地采用类似于队列的方式（不一定真的有一个消息队列，从数据库拉取任务也算）,,如果应用非常复杂，可以采用微服务模式。微服务应用是由很多小且独立的服务组合而成，每个服务都独立实现一套完整的业务能力。服务的关系非常松散，仅通过API进行通信。,每个服务都可以由一个独立的研发团队进行开发，理论上也可以单独部署，不用和其他团队进行太多的协同。因此，微服务架构非常鼓励频繁的更新。一个微服务架构可以非常复杂，它可以由多个分层架构应用和任务调度架构应用组合而成。,由于服务非常多，DevOps的重要性就凸显出来了。如果操作正确的话，这种架构可支持高度灵活的发布节奏、更快的创新和高度的弹性及扩展性。,目前大型互联网公司普遍采用微服务架构，处理用户侧发起的short-lived请求，以支撑超高的QPS。,,事件驱动架构采用了订阅-发布模型，也叫生产者-消费者模型。生产者负责发布事件到消息队列，消费者订阅消息队列。生产者和消费者互相独立，多个消费者之间也互相独立。,依赖的中间件有 Kafka、RocketMQ、Redis Pub/Sub 等。,事件驱动架构下，应用程序可以以非常低的延迟处理大量的数据，在数据采集分析场景下使用非常广泛。比如IoT场景、大型互联网应用的数据收集子系统（日志/埋点数据回收）。,,大数据是目前互联网的标配场景，它的第一步一般是流式地搜集应用日志，清洗后存到分布式存储中，应用到离线场景，或分发到消息队列，用于流式处理。这一点与事件驱动架构有部分重叠。,当我们聊大数据是，通常是说对一个超大数据集进行分片/区，执行并行计算，最终产出分析和报表。数据集大小可能是PB级。,大计算，也叫高性能计算(HPC)，可以在上千核的CPU上并行计算。除了我们熟悉的大数据场景，也应用在图形渲染、流体动力学、金融风险建模、石油勘探、药物设计等领域。,任何架构在设计上都有受到一些限制，比如架构基本元素的形态，以及元素之间允许存在的关系。这些限制本质上是在某种架构下，我们可选的最大集合，它影响甚至间接塑造了架构的最终形态。当应用的构建遵循某种架构模式时，一些好的符合预期的特性也会出现。,上面这段话有点抽象，我们以微服务架构的限制为例：,遵循这些限制之后，系统中的服务就可以独立进行部署。收益时事故隔离、支持频繁更新、可便捷地引入新技术。,在选择某种架构模式之前，我们需要理解架构的底层原则和限制。否则，架构设计只在最表层符合某种架构模式，但无法发挥这种架构模式的潜力。在使用架构过程中，务实很重要，有时候我们可能要放宽一些限制，而不是坚持架构的纯粹。,下面这张表总结了不同的架构模式如何管理依赖，以及适用的业务领域,架构的限制使其在某些场景下面临一些挑战，所以在采用这些架构模式时，需要理解其中的利弊权衡。我们需要保证，在我们所在的子领域（场景），叠加场景的限制条件下，架构带来的收益超过要面临的挑战。,下面列出了在选择架构模式时面临的四类挑战：