单体架构
电商初期采用单体架构，所有功能集中在一个应用内，代码分层明确（表示层、业务层、数据访问层、DB层）。适合业务简单、团队规模小的场景，但模块依赖模糊，多团队开发易冲突。例如早期淘宝和eBay因代码量庞大面临合并与编译难题。
分布式架构
将系统按业务线拆分为独立应用，通过API协作。降低业务广度复杂度，支持多团队并行开发。但API与业务逻辑耦合，修改易引发连锁反应，且重复建设严重（如淘宝2008年核心代码重复率超1/3）。适合业务耦合度低的场景，如企业内部管理系统。
SOA架构
分为传统与新型两类：
- 传统SOA：通过企业服务总线（ESB）集成异构系统，如eBay用Axis 2封装C++搜索功能为Java服务。
- 新型SOA：抽取通用逻辑（用户、商品等）为共享服务，解决重复建设。淘宝通过服务化提升扩展性与效率，但实现较重。
微服务架构
围绕细粒度业务单元构建独立应用（如航班预订拆分为订票、票价计算等）。特点包括：
- 去中心化，无需ESB，通过HTTP等轻量协议通信；
- 服务自治，团队全生命周期管理；
- 清晰业务边界，技术栈灵活。本质是更细分的分布式架构，强调“哑管道”与“智能终端”。
SOA与微服务架构解析
SOA架构的核心思想
SOA（面向服务架构）通过企业服务总线（ESB）集中管理服务，解决异构系统集成问题。例如eBay通过Java服务封装C++搜索功能，实现跨语言调用。淘宝的共享服务体系（用户、商品等）减少了1/3的代码重复，提升开发效率和系统扩展性。
- 优势：业务封装标准化、独立部署扩展、避免重复开发。
- 局限：ESB中心化设计导致实现复杂度高，落地成本大。
微服务架构的轻量化改进
微服务以去中心化方式拆分业务为独立小单元（如航班预订拆分为订票、票价计算等），每个服务包含端到端功能（UI+逻辑）。
- 关键差异：
- 通信方式：微服务采用HTTP等轻量协议（哑管道），SOA依赖ESB处理协议转换。
- 治理模式：微服务无中心化编排，服务自治（智能终端）。
实践中的调整
理想化的微服务（跨职能团队、端到端业务）常因组织和技术限制调整为以下类型：
- 共享微服务：基础业务（如用户模块）。
- 聚合微服务：流程编排（如订单流程）。
- 系统微服务：中间件封装（如Redis服务）。
依赖与数据同步问题
针对跨服务数据依赖的解决方案：
- 实时调用：适用于低频展示场景（如页面用户信息），需缓存和熔断机制保障性能。
- 数据冗余：高频查询场景（如报表）可异步同步数据，通过事件驱动（如Kafka）保证最终一致性。
- 混合模式：订单服务保存用户ID，通过联合查询或API组合返回完整数据。
架构对比与选型
- SOA：适合遗留系统整合，强调整体治理。
- 微服务：适合快速迭代业务，强调灵活性和技术异构。
- 共存场景：大型系统中可混合使用，如核心模块用SOA，新业务用微服务。
示例代码：微服务HTTP调用
// 使用Spring Cloud Feign调用用户服务@FeignClient(name="user-service")publicinterfaceUserServiceClient{@GetMapping("/users/{id}")UsergetUser(@PathVariable("id")StringuserId);}关键公式：服务拆分评估
服务粒度可通过业务内聚性评估：
[ \text{内聚性} = \frac{\text{模块内交互数}}{\text{模块总交互数}} ]
值越接近1，越适合独立为微服务。
