Java 周：第四部分：为您的函数构建多层核心

在本系列的早期章节中，我们探讨了建立无服务器项目的基础步骤，包括使用仿真工具设置开发环境以及概述通用多层架构。本节重点介绍针对遵循函数即微服务（FaaM）范式的无服务器系统开发的设计模式实现。\n\n服务粒度的问题随着分布式计算的发展而演变。20 世纪 70 和 80 年代，远程过程调用（RPC）、CORBA 和分布式计算环境（DCE）等早期集成方法出现，但在混合环境中通常受限于可扩展性和灵活性。90 年代中期，面向服务架构（SOA）成为转折点，并通过基于 SOAP 的实现于 2000 年代初获得广泛关注。SOA 革新了软件设计，实现了松耦合服务。2010 年代，REST、事件驱动架构（EDA）和微服务继续发展，但确定服务的理想大小和范围仍是持续挑战。\n\n历史上，SOA 定义了两种主要服务粒度：粗粒度和细粒度。粗粒度服务涵盖广泛的业务能力，而细粒度服务聚焦于狭窄的功能范围。两者均存在挑战；大型粗粒度服务可能变成难以管理的“单体”，而细粒度服务则可能产生大量小型、相互依赖的组件，增加可扩展性、可修改性和安全性的复杂度。面向服务建模框架（SOMF）提供了更细致的分类：原子服务是基本且不可分割的组件，流程有限；复合服务则以层级结构聚合原子或其他复合服务；集群是相关服务的组合，共同协作实现更广泛的解决方案。\n\n将这些概念应用于使用 Serverless Framework 和 AWS Lambda 的无服务器计算领域，涉及三个核心构造：事件、函数和服务。事件触发函数，函数执行特定任务的代码片段。服务封装一组 Lambda 函数及其触发事件和基础设施需求。Serverless Framework 通常建议为每个 CRUD 操作创建单独的 Lambda 函数——例如，User 实体可能对应四个 Lambda 函数。此方法虽简单，但扩展性差：十个实体即产生 40 个函数，每个函数需管理且关联独立的 AWS API Gateway 实例，增加运维负担。\n\n为应对复杂性，提出了函数即微服务（FaaM）模式。每个 Lambda 函数作为一个小型集群，处理多个相关业务能力并在内部路由多个原子事件。例如，不是为每个城市操作创建函数，而是由一个地理位置函数统一管理国家、城市和地区的 CRUD 操作。为防止单体膨胀，每个函数理想管理不超过 7±2 个实体，符合 Miller 定律的认知限制。此设计假设每个函数对其特定数据源负全责。\n\n在 AWS Lambda 中实现 FaaM 需高效路由机制，因为每个 Lambda 函数仅有单一入口处理器。客户端-调度器-服务器模式可通过基于 URI 路径的请求路由实现。例如，HTTP 请求 /movie 应路由至处理电影相关操作的函数。利用此模式，多个逻辑服务（如用户、地理位置和帖子）可共享同一处理器代码，但通过内部路由区分处理，减少 Lambda 函数和 API Gateway 端点数量，简化管理同时保持业务域清晰。\n\n实际中，Serverless Framework 配置可能定义多个服务，多个 HTTP 事件均指向同一处理器——例如，用户服务下的登录、登出和注册端点，地理位置服务下的多个位置端点，以及帖子服务下的电影 CRUD 操作。共享处理器内的路由逻辑根据事件的 URI 和方法调用相应业务逻辑模块。此策略通过避免重复处理器代码提升可维护性，并支持无服务器架构的模块化增长。