云上应用技术架构 - 从单体到分布式

作者：深蓝

2023-11-20
北京
本文字数：5645 字
阅读完需：约 19 分钟

链接：https://github.com/svc-design/ebooks/

概述

应用架构是一个系统的高级结构。它是关于系统的一系列决策，包括系统的组成部分、这些部分之间的交互，以及对这些部分的引导性指南。这些决策通常是由企业的 IT 团队和关键干系人员共同作出的。

应用架构可以帮助确定一个系统的主要组件（如数据库、服务器、接口等），以及这些组件如何相互作用以完成特定的业务功能。此外，应用架构还可以定义如何将系统划分为不同的部分，以便于开发、测试和后续维护。

应用架构可以采用多种形式，包括单体架构、微服务架构、服务导向架构（SOA）、事件驱动架构等。选择哪种架构取决于多种因素，如项目需求、团队技能、预期的系统负载等。

应用架构是对一个系统如何设计和实现的高层次描述，它为开发团队提供了一个共同的框架，以便于理解整个系统的工作方式。

常见的应用架构

单体架构：在早期的软件开发中，大多数系统都是基于单体架构。所有的业务逻辑都在一个大的应用中，包括用户界面、服务器端的逻辑处理、数据访问等。这样的架构在系统规模较小、需求变化不频繁的情况下，可以简化开发和部署。
前后端分离：随着互联网的发展，用户交互越来越复杂，业务逻辑也越来越丰富。单体架构开始显得力不从心。前后端分离架构应运而生，前端负责用户交互，后端负责业务逻辑和数据处理。这种架构可以让前后端各自专注于自己的领域，提高开发效率。
SOA（服务导向架构）：随着系统规模的进一步扩大和业务需求的复杂化，前后端分离仍然无法满足需求。SOA 架构将系统划分为多个服务，每个服务都有明确的功能，通过网络进行通信。这种架构可以提高系统的可扩展性和复用性。
微服务：微服务是 SOA 架构的一种具体实现方式。它将系统划分为一组小的、独立的服务，每个服务都在各自独立的进程中运行，服务之间通过轻量级的通信机制（如 HTTP RESTful API）进行通信。微服务更加精细化，更加注重服务的自治性。
服务网格：服务网格是一种基础设施层，用于处理服务到服务之间的通信。它在微服务架构中提供了一种透明、统一的方式来连接、保护、监控和管理服务。服务网格通常由一组轻量级的网络代理组成，这些代理与应用程序代码部署在一起，而无需知道其存在。这些代理负责通信的重试、超时、监控、追踪、服务发现、负载均衡等功能。

从单体架构向分布式架构

演变过程：

单体架构：在单体架构中，所有的功能都集成在一个单一的应用中，通过函数调用进行交互。所有的组件运行在同一进程中，共享同一数据库。
前后端分离：随着 Web 应用的复杂性增加，前后端分离成为了一种趋势。前端负责用户交互，后端负责处理业务逻辑。前后端之间通过 API 进行通信，典型的方式是 HTTP/REST 或者 GraphQL。这种架构使前后端可以独立开发和部署。
SOA(Service-Oriented Architecture)：SOA 是一种设计理念，将应用程序的不同功能模块化为独立的服务，这些服务可以通过网络进行通信。SOA 强调业务功能的重用，每个服务都是独立的，可以被多个消费者调用。
微服务：微服务是 SOA 的一种实现模式，它比 SOA 更加细粒度。在微服务架构中，每个服务都是一个小型的、独立部署的应用，它们通过轻量级的通信机制（如 HTTP RESTful API）进行通信。微服务强调服务的自治性和轻量级通信。
服务网格：服务网格是解决微服务中一些常见问题（例如服务发现、负载均衡、故障恢复、指标收集和监控等）的一种方法。它是一种基础设施层，用于处理服务到服务之间的通信。服务网格使得这些功能从应用代码中解耦出来，由基础设施层来处理。

各自的优缺点，解决和引入的问题：

单体架构：优点：开发简单直接，部署简单，适合小型应用。缺点：随着系统复杂度的增加，维护和更新变得困难；缺乏弹性和可扩展性；故障隔离困难；并发处理能力有限。解决问题：对于小型应用，可以快速实现功能。引入问题：随着系统规模的扩大，维护和扩展变得困难。
前后端分离：优点：前后端可以独立开发和部署，提高开发效率。缺点：需要定义清晰的 API 接口，增加了开发复杂性。解决问题：解决了前端和后端开发速度不匹配的问题，提高了开发效率。引入问题：需要维护 API 接口，增加了开发复杂性。
SOA：优点：服务可重用，可独立部署和扩展，提高了系统的灵活性和可扩展性。缺点：服务间通信增加了网络延迟；需要维护服务接口；服务治理复杂。解决问题：解决了单体架构的扩展性问题，提高了系统的灵活性和可扩展性。引入问题：增加了网络延迟，需要进行服务治理。
微服务：优点：服务小而自治，易于开发和维护；可以使用不同的技术栈开发不同的服务；服务可以独立扩展。缺点：微服务之间的通信和协调增加了复杂性；对运维要求高；分布式系统可能会遇到数据一致性、网络延迟等问题。解决问题：解决了 SOA 中服务粒度大的问题，使得服务更加自治，更易于开发和维护。引入问题：微服务之间的通信和协调增加了复杂性，对运维要求高。
服务网格：优点：解耦了业务代码和网络相关的功能，如负载均衡、服务发现、故障恢复、安全等；提供了统一的方式来观察、控制和保护微服务之间的通信。缺点：增加了系统的复杂性；对运维要求高。解决问题：解决了微服务中常见的网络相关问题，如服务发现、负载均衡、故障恢复等。引入问题：增加了系统的复杂性，对运维要求高。

为什么当下分布式应用发展为服务网格

在微服务架构中，应用程序通常被分解为多个独立的服务，这些服务需要通过网络进行通信。随着服务数量的增加，管理和监控这些服务间的通信变得越来越复杂。例如，如何处理服务间的负载均衡、故障恢复、服务发现、安全性、可观察性等问题。传统的方法是在每个服务中实现这些功能，但这会导致大量的代码重复，而且在不同的语言和框架中实现这些功能可能会有所不同。

服务网格的出现就是为了解决这些问题。服务网格是一种基础设施层，它将通信逻辑从应用代码中抽象出来，使开发人员可以专注于业务逻辑，而不是网络通信。通过使用服务网格，开发人员可以利用统一的方式来管理和监控服务间的通信，而无需关心底层的实现细节。

此外，服务网格还提供了一种标准化的方式来处理跨多个服务的策略和配置，例如安全策略、流量路由规则等。这大大简化了分布式系统的管理和运维。

因此，服务网格是目前分布式应用的一个重要解决方案，它可以帮助开发和运维人员更有效地处理微服务架构中的复杂性。