📚 课程目录第2章技术选型与架构设计

2. 技术选型与架构设计

在采购合同智能系统从单点功能向全模块协同演进的过程中，技术选型与架构设计是决定系统扩展性、维护成本与交付效率的关键决策点。本章从架构模式对比、核心技术栈选型、分层架构设计三个维度展开，为后续部署实践奠定技术基础。

采购合同系统涉及合同起草、审批流、供应商管理、电子签章、财务对账等多个业务域，各模块的变更频率与扩展需求差异显著。以下从六个关键维度对比两种架构模式：

决策维度	单体架构	微服务架构	采购合同场景建议
模块耦合度	高，代码库统一	低，按业务域拆分	审批流与合同版本管理需解耦
独立部署能力	整体部署，一处改全量发布	按服务独立部署，灰度发布	电子签章服务需高频更新
团队协作效率	单团队维护，合并冲突频繁	多团队并行，接口契约先行	供应商模块与财务模块可由不同团队负责
技术栈灵活性	统一技术栈，迁移成本高	服务级选型，可引入异构技术	OCR识别服务可独立采用Python
运维复杂度	低，单进程管理	高，需服务发现/配置中心/链路追踪	初期可借助Kubernetes降低运维门槛
启动与迭代速度	初期快，规模增长后变慢	初期慢（基础设施搭建），后期稳定	建议MVP阶段用单体，成熟后拆分

决策建议：采购合同智能系统推荐采用渐进式微服务策略——第一阶段以单体架构快速验证核心流程（合同起草+审批），第二阶段按业务边界拆分为6~8个微服务，第三阶段引入事件驱动架构实现全模块协同。

基于企业级应用对稳定性、生态成熟度与团队技术储备的要求，选定以下核心组件：

选型依据：PostgreSQL相比MySQL在JSONB查询性能、窗口函数、并发控制方面更优，适合合同系统中大量动态属性（合同类型、税率、付款条件）的存储与检索场景。

下图展示采购合同智能系统的六层架构，从接入层到基础设施层，每层职责清晰、接口标准化：

在微服务架构下，采购合同核心流程涉及多个服务间的同步与异步交互。下图以“合同创建→审批→签章”主链路为例，展示服务调用关系与数据流向：

常见陷阱：在微服务拆分初期，容易将“合同模板管理”与“合同实例管理”拆为两个独立服务，但实际业务中模板与实例的变更频率高度耦合，强行拆分会导致跨服务事务频繁。建议将模板与实例合并为一个“合同核心域服务”，待业务稳定后再考虑按“读写分离”策略拆分。

分布式事务边界：仅对“合同创建→提交审批”这一强一致性链路使用Seata AT模式；审批通过后的通知、归档等操作采用RocketMQ事务消息+本地事件表实现最终一致性。
合同全文检索：PostgreSQL内置的tsvector全文索引可满足初期500万条以内的合同检索需求；超过该量级再引入Elasticsearch，避免过早增加运维复杂度。
文件存储选型：合同附件与签章文件统一使用MinIO对象存储，通过预签名URL实现前端直传，避免文件流经过应用服务器造成内存压力。
配置管理策略：合同模板的版本号、审批节点超时时间等业务配置放在Nacos配置中心；合同类型、税率等基础数据字典放在PostgreSQL并启用Redis缓存。

架构原则：每个阶段都保持“可回退”能力——Phase 2拆分时保留单体代码分支，若微服务引入的分布式问题超过收益，可快速回退至单体架构。技术选型服务于业务节奏，而非追求技术先进性。