一文搞懂应用架构的3个核心概念

如果你是一名业务开发，你可能要说，我整天就是做CRUD（增删改查），哪里需要了解什么应用架构设计？

经常有人说，程序员 35 岁之后很容易陷入瓶颈，被行业淘汰，我觉得原因其实就在此。

有些朋友在写代码的时候，可能没有太多考虑非功能性的需求、扩展性，只是完成功能，觉得能用就好。做事情的时候，也没有长远的规划，只是把眼前的事情做好就满足了。

我面试过很多大龄候选人，他们的简历长达十几页，项目经历有几十个。然而，细看之下，每个项目只是重复堆砌业务逻辑，缺乏难度递进，能力提升不明显。

这样的人，十年的积累可能与一年的积累无异。这样的人，怎么不会被行业淘汰呢？

随着年龄增长，互联网大环境也越来越卷，架构思维和设计知识是必须要掌握的。

应用架构是什么？

应用架构定义了企业中的应用系统的结构和行为。它不仅仅是搭建几个系统那么简单，更重要的是要考虑这些系统之间的关系，以及它们如何协同工作，以满足业务需要。

通过应用架构，我们可以清晰地识别出支持业务和数据处理所需的应用系统，并实现从业务需求到IT系统的转化。

一个优秀的应用架构，能让系统既稳定，又能灵活扩展和升级，快速应对市场需求变化。

应用架构的设计步骤一般包括：

• 基于业务架构，完成业务到IT系统的转换，识别核心应用服务。
• 划分应用结构，设计应用结构与业务流程，数据的关系。
• 设计应用结构间的交互、集成关系。

应用服务

应用服务在应用架构中起着至关重要的作用，它将系统的核心功能打包，并提供给外部使用，可以视为系统对外的“门面”，用户或其他系统通过调用应用服务来实现特定的业务功能。

从外部视角来看，应用服务通常是带有明确的业务含义，比如下单、支付、查询库存等。这些服务的设计必须紧密围绕业务需求，确保能够高效地支撑业务流程的执行。

应用服务的概念源于SOA和微服务架构的兴起。通过将系统功能拆分为多个独立的服务，可以提高系统的可维护性、可扩展性和灵活性。

应用服务的概念源自于面向服务的架构（SOA）和微服务架构的兴起。通过将系统的功能模块化为多个独立的服务，不仅提升了系统的可维护性，还增强了系统的扩展性和灵活性。每个服务可以独立开发、部署和升级，这样即使业务需求发生变化，也只需调整相关服务，而无需大幅修改整个系统。

面向服务的架构最大的价值就在于它的敏捷性和灵活性。

敏捷性体现在服务可以快速调整，独立演化。灵活性则体现在每个服务都有清晰的业务边界，功能内聚性强，能够单独管理生命周期。

通过服务的组合和编排，系统可以快速响应业务的变化，支持复杂的业务流程，构建起一个既稳固又灵活的技术基础设施。

应用结构

应用结构描述了应用系统内部的层次结构和组织关系，它决定了系统的模块化程度，以及后续的开发和维护难度。

在应用结构设计中，我们通常会把系统抽象为不同的层次。比如，将系统划分为系统级、应用级、模块级和代码级。

这种抽象级别的划分帮助我们在不同层面处理复杂性，确保系统结构清晰且易于维护。如图所示：

• 系统级：关注的是各个系统的整体布局和治理方式，比如各个系统之间的关系，以及它们如何协同工作。
• 应用级：聚焦于各个应用的整体架构，包括应用与其他应用的交互方式，以及各个应用在整个系统中的角色。
• 模块级：对应用内部的进一步细化，它涉及到代码的模块化设计、数据和状态的管理等。通过合理的模块划分，可以提高代码的可维护性、可重用性，减少重复劳动。
• 代码级：关注的是代码本身的结构和实现方式。这一层级的设计直接影响到代码的质量和实现细节。

抽象级别的存在，主要是为了帮助我们更好地管理系统的复杂性。

1.分解复杂度

如果将所有的细节混杂在一起，整个系统将变得难以理解、维护和扩展。通过设置不同的抽象级别，我们可以将系统的复杂性分解到各个层次，每个层次只需关注特定的功能和职责。

这种分层处理方式使开发人员在专注于系统某一部分时，无需过多关注其他部分的细节，从而大大简化了系统的设计和开发过程。

2.团队协作边界清晰

在大型项目中，通常会有多个团队并行开发。如果系统没有明确的边界，各团队之间很容易产生冲突和重复劳动。

通过清晰的抽象级别划分，不同团队可以专注于系统的不同层次或模块，互不干扰。

3.扩展性强

随着业务需求的变化，系统往往需要不断地扩展和升级。如果系统的架构设计没有合理的抽象级别，扩展和升级就会变得异常困难，甚至可能引发系统的全面重构。

而在有抽象级别的系统中，变更往往只需要聚焦在特定的层次上进行，而不会影响整个系统。例如，一次业务改造只影响模块级别，我们可以在不改变系统整体架构的情况下，替换或新增某个模块，以满足新的业务需求。

应用交互

应用交互是指不同应用系统或组件之间的数据交换和通信方式。

在一个复杂的系统中，各个应用并不是孤立存在的，它们往往需要相互协作，才能完成更复杂的业务流程。

应用交互的设计就是为了确保这些系统和组件能够顺畅地“对话”，实现系统整体功能。

应用交互的形式有多种，包括同步调用、异步消息传递、事件驱动等。每种交互方式都有其特定的应用场景和优缺点。

例如，同步调用通常用于那些需要即时响应的场景，用户在前端提交订单后，系统会立即调用订单服务创建订单，这种方式的优点是可以保证请求的实时性，但也要求系统的各个部分在调用时都能正常工作。

相对的，异步消息传递则适用于那些不需要即时响应的场景，比如订单创建后，订单服务可以将订单创建的消息发送到消息队列，而履约服务可以在适当的时候处理这条消息。这种方式的优势在于能够提高系统的解耦性，避免系统在高负载时，因为同步调用导致性能瓶颈。

通过合理的交互设计，系统中的各个部分能够高效协同，减少耦合度，增加系统的灵活性。同时，良好的交互设计还能显著提升系统的性能和容错能力，即使在大流量访问、业务需求复杂的情况下，也依然保持稳定运行。

写在最后

应用架构定义了企业应用系统的结构和行为，强调系统间的关系和协同工作。

通过应用架构，可以识别支持业务和数据处理的系统，实现从业务需求到IT系统的转化。设计步骤包括业务到IT系统的转换、应用结构设计及其交互关系。

应用服务是系统的核心功能模块，源于SOA和微服务架构，提升了系统的可维护性和灵活性。

应用结构则描述了系统的层次结构，帮助管理复杂性，促进团队协作和系统扩展。应用交互设计确保系统组件间的数据交换和通信方式高效，提升系统性能和容错能力。