蝉鸣 CRM 技术架构与交付：单体、微服务、SaaS 与私有化如何选择
架构选择的目标不是服务越多越好，而是在业务边界、运维成本和扩展能力之间取得平衡。
蝉鸣 CRM 后端主工程为 4.1.0，基于 JDK 21、Spring Boot 4.1.1、Spring Cloud 2025.1.3 与 Spring Cloud Alibaba 2025.1.0.0。技术版本重要，但更重要的是请求如何经过边界、模块如何依赖、系统如何被持续交付。
一套代码，两种架构
单体适合低运维成本与快速启动，微服务适合独立扩缩容和服务治理；两种方式应共享业务模型与权限规则。
沿一次请求看系统职责
Vue 3 管理端或自定义页面发起请求后，Gateway 处理统一入口与路由，认证权限体系恢复账号、用户、租户和组织上下文，再进入 CRM、自定义应用、工作流或 AI 等领域服务。领域服务执行规则并访问 MySQL、Redis、Elasticsearch 或对象存储；需要跨服务调用时依赖公共 API 契约，而不是引用对方内部实现。
工程中的 configurations 统一版本与 BOM，components 沉淀 Starter 和公共集成，supports 承载网关、认证、权限、流程、生成器与监控，services 承载 CRM、应用和 AI。依赖从业务向平台与组件收敛，使公共能力可复用，领域实现可独立演进。
单体与微服务不是产品功能差异
单体方式减少注册中心、网络调用和多进程运维成本，适合中小团队、私有环境或业务初期。微服务把 Gateway、认证权限、CRM、AI 等节点独立运行，适合不同负载的扩缩容、团队边界和故障隔离，但需要配置发现、链路追踪、日志聚合与更成熟的发布能力。
选择标准应包括团队运维经验、并发特征、故障影响、部署频率与数据边界。仅因为“微服务更先进”而拆分，会让一次业务修改跨越更多接口和流水线。反过来，当 AI 推理消耗、CRM 交易请求和报表任务资源差异明显时，独立服务能够提供更合理的容量治理。
从源码到可运行环境
Maven 负责依赖治理、测试和 JAR 构建。Docker 将运行时、应用与配置入口固化为镜像，Docker Compose 适合本地联调和中小规模环境。Jenkins 将拉取代码、构建、测试、镜像制作与部署串成可审计流水线；任何测试失败都应阻止进入下一环境。
配置与密钥不写入镜像。Nacos 等配置能力管理环境差异，数据库、缓存、对象存储与搜索地址由部署环境提供。日志、指标和 SkyWalking 调用链帮助定位跨服务问题；备份、恢复演练和升级回滚是私有化交付的一部分，而不只是“把容器启动起来”。
SaaS 与私有化的责任边界
SaaS 适合希望快速启用、持续升级并由服务方承担基础运维的团队。私有化适合数据必须留在自有环境、需要内网集成或深度定制的组织，但客户同时承担基础设施、备份、监控和升级协调责任。两种交付复用同一业务能力，差异主要在运行环境、责任分工和集成边界。
评估时应形成容量、可用性、数据保留、网络、域名证书、备份恢复、监控告警和升级窗口清单。架构设计最终要服务于稳定经营，而不是展示技术名词。
权限设计见多租户与数据权限，系统业务全貌见蝉鸣 CRM 全景介绍。