01.应用架构的核心概念
01.应用架构的核心概念
如果你是一名业务开发,你可能要说,我整天就是做CRUD(增删改查),哪里需要了解什么应用架构设计?
经常有人说,程序员 35 岁之后很容易陷入瓶颈,被行业淘汰,我觉得原因其实就在此。
有些朋友在写代码的时候,可能没有太多考虑非功能性的需求、扩展性,只是完成功能,觉得能用就好。做事情的时候,也没有长远的规划,只是把眼前的事情做好就满足了。
我面试过很多大龄候选人,他们的简历长达十几页,项目经历有几十个。然而,细看之下,每个项目只是重复堆砌业务逻辑,缺乏难度递进,能力提升不明显。
这样的人,十年的积累可能与一年的积累无异。这样的人,怎么不会被行业淘汰呢?
随着年龄增长,互联网大环境也越来越卷,架构思维和设计知识是必须要掌握的。
应用架构是什么?
应用架构定义了企业中的应用系统的结构和行为。它不仅仅是搭建几个系统那么简单,更重要的是要考虑这些系统之间的关系,以及它们如何协同工作,以满足业务需要。
通过应用架构,我们可以清晰地识别出支持业务和数据处理所需的应用系统,并实现从业务需求到IT系统的转化。
一个优秀的应用架构,能让系统既稳定,又能灵活扩展和升级,快速应对市场需求变化。
应用架构的设计步骤一般包括:
- 基于业务架构,完成业务到IT系统的转换,识别核心应用服务。
- 划分应用结构,设计应用结构与业务流程,数据的关系。
- 设计应用结构间的交互、集成关系。
应用服务
应用服务在应用架构中起着至关重要的作用,它将系统的核心功能打包,并提供给外部使用,可以视为系统对外的“门面”,用户或其他系统通过调用应用服务来实现特定的业务功能。
从外部视角来看,应用服务通常是带有明确的业务含义,比如下单、支付、查询库存等。这些服务的设计必须紧密围绕业务需求,确保能够高效地支撑业务流程的执行。
应用服务的概念源于SOA和微服务架构的兴起。通过将系统功能拆分为多个独立的服务,可以提高系统的可维护性、可扩展性和灵活性。
应用服务的概念源自于面向服务的架构(SOA)和微服务架构的兴起。通过将系统的功能模块化为多个独立的服务,不仅提升了系统的可维护性,还增强了系统的扩展性和灵活性。每个服务可以独立开发、部署和升级,这样即使业务需求发生变化,也只需调整相关服务,而无需大幅修改整个系统。
面向服务的架构最大的价值就在于它的敏捷性和灵活性。
敏捷性体现在服务可以快速调整,独立演化。灵活性则体现在每个服务都有清晰的业务边界,功能内聚性强,能够单独管理生命周期。
通过服务的组合和编排,系统可以快速响应业务的变化,支持复杂的业务流程,构建起一个既稳固又灵活的技术基础设施。
应用结构
应用结构描述了应用系统内部的层次结构和组织关系,它决定了系统的模块化程度,以及后续的开发和维护难度。
在应用结构设计中,我们通常会把系统抽象为不同的层次。比如,将系统划分为系统级、应用级、模块级和代码级。
这种抽象级别的划分帮助我们在不同层面处理复杂性,确保系统结构清晰且易于维护。如图所示:
- **系统级:**关注的是各个系统的整体布局和治理方式,比如各个系统之间的关系,以及它们如何协同工作。
- **应用级:**聚焦于各个应用的整体架构,包括应用与其他应用的交互方式,以及各个应用在整个系统中的角色。
- **模块级:**对应用内部的进一步细化,它涉及到代码的模块化设计、数据和状态的管理等。通过合理的模块划分,可以提高代码的可维护性、可重用性,减少重复劳动。
- **代码级:**关注的是代码本身的结构和实现方式。这一层级的设计直接影响到代码的质量和实现细节。
抽象级别的存在,主要是为了帮助我们更好地管理系统的复杂性。
1.分解复杂度
如果将所有的细节混杂在一起,整个系统将变得难以理解、维护和扩展。通过设置不同的抽象级别,我们可以将系统的复杂性分解到各个层次,每个层次只需关注特定的功能和职责。
这种分层处理方式使开发人员在专注于系统某一部分时,无需过多关注其他部分的细节,从而大大简化了系统的设计和开发过程。
2.团队协作边界清晰
在大型项目中,通常会有多个团队并行开发。如果系统没有明确的边界,各团队之间很容易产生冲突和重复劳动。
通过清晰的抽象级别划分,不同团队可以专注于系统的不同层次或模块,互不干扰。
3.扩展性强
随着业务需求的变化,系统往往需要不断地扩展和升级。如果系统的架构设计没有合理的抽象级别,扩展和升级就会变得异常困难,甚至可能引发系统的全面重构。
而在有抽象级别的系统中,变更往往只需要聚焦在特定的层次上进行,而不会影响整个系统。例如,一次业务改造只影响模块级别,我们可以在不改变系统整体架构的情况下,替换或新增某个模块,以满足新的业务需求。
应用交互
应用交互是指不同应用系统或组件之间的数据交换和通信方式。
在一个复杂的系统中,各个应用并不是孤立存在的,它们往往需要相互协作,才能完成更复杂的业务流程。
应用交互的设计就是为了确保这些系统和组件能够顺畅地“对话”,实现系统整体功能。
应用交互的形式有多种,包括同步调用、异步消息传递、事件驱动等。每种交互方式都有其特定的应用场景和优缺点。
例如,同步调用通常用于那些需要即时响应的场景,用户在前端提交订单后,系统会立即调用订单服务创建订单,这种方式的优点是可以保证请求的实时性,但也要求系统的各个部分在调用时都能正常工作。
相对的,异步消息传递则适用于那些不需要即时响应的场景,比如订单创建后,订单服务可以将订单创建的消息发送到消息队列,而履约服务可以在适当的时候处理这条消息。这种方式的优势在于能够提高系统的解耦性,避免系统在高负载时,因为同步调用导致性能瓶颈。
通过合理的交互设计,系统中的各个部分能够高效协同,减少耦合度,增加系统的灵活性。同时,良好的交互设计还能显著提升系统的性能和容错能力,即使在大流量访问、业务需求复杂的情况下,也依然保持稳定运行。
写在最后
应用架构定义了企业应用系统的结构和行为,强调系统间的关系和协同工作。
通过应用架构,可以识别支持业务和数据处理的系统,实现从业务需求到IT系统的转化。设计步骤包括业务到IT系统的转换、应用结构设计及其交互关系。
应用服务是系统的核心功能模块,源于SOA和微服务架构,提升了系统的可维护性和灵活性。
应用结构则描述了系统的层次结构,帮助管理复杂性,促进团队协作和系统扩展。应用交互设计确保系统组件间的数据交换和通信方式高效,提升系统性能和容错能力。