单体架构
特点：
- 采用LAMP技术栈。
- 所有功能模块都集成在一个应用程序中。
- 数据库存在单点故障风险。
问题：
- 随着业务增长，应用变得复杂，维护困难。
- 数据库负载过高，扩展性差。
垂直应用架构
特点：
- 将单体应用拆分为多个独立的垂直应用。
- 每个应用有独立的数据库。
图片
垂直应用架构
特点：
- 将单体应用拆分为多个独立的垂直应用。
- 每个应用有独立的数据库。
问题：
- 数据一致性难以保证。
- 应用之间的依赖关系复杂，导致维护成本高。
图片
微服务架构
特点：
- 将垂直应用进一步拆分为更小的微服务。
- 每个微服务独立部署，独立数据库。
- 通过API进行通信。
实践：
- 订单服务化：将订单处理拆分为多个独立的微服务，如查询订单、取消订单、退款等。
- 服务能力开放：通过API网关开放服务能力，构建生态系统。
图片
为什么要这么分呢？
1.分层清晰：
架构图按照功能层次划分，每一层都有明确的职责和边界，确保了系统的模块化 和可维护性。
2.服务独立：
基础服务、聚合服务和流程服务之间的依赖关系明确，每个服务都可以独立开发、部署和扩展，提升了系统的灵活性和可靠性。
3.复用性高：
基础服务提供了最基本的业务功能，聚合服务通过调用基础服务实现更高层次的业务功能，提高了服务的复用性，减少了重复开发工作。
4.面向用户的聚合API服务：
顶层的聚合API服务面向不同的业务线，提供统一的接口，方便前端应用调用。这种设计确保了用户操作的统一性和一致性。
订单服务化
图片
服务模块职责明确，售前、售后、履约、定时任务和公共服务等各自独立，避免了职责混乱，提高了系统的可维护性和扩展性。各个服务模块可以独立开发、部署和扩展，方便根据需求进行调整和优化，提升系统的灵活性。定时任务和公共服务的独立设计，使得系统在高并发和复杂场景下也能保持高可用性，减少了单点故障的风险，通过分层设计，将复杂的业务逻辑分解为多个小的模块，减少了单个模块的负载，提高了整体系统的性能。各个模块独立管理，方便运维和监控，可以快速定位和解决问题，提高系统的运维效率，通过将自营订单服务和第三方订单服务分开设计，支持多种业务模式，方便企业拓展不同的业务渠道。
订单服务化和取消订单相关服务交互
图片
服务能力开放共建生态
图片
微服务整体架构
图片
微服务架构最佳实践
图片
1. 业务驱动原则
- 识别核心业务域，形成基础业务能力：首先要识别和理解业务的核心部分，确保微服务的设计和实现是围绕这些关键业务能力展开的。
- 根据业务定位、范围、边界进行服务的划分：根据业务需求和功能进行合理的服务划分，确保每个微服务有明确的边界和职责。
- 首先关注服务的业务范围，而不是服务的数量、粒度：重点在于服务的功能和作用，而不是追求将系统拆分为尽可能多的小服务。
2. 服务分层原则
- 划分基础、聚合、流程服务：将服务划分为基础服务（提供基本功能）、聚合服务（组合多个基础服务）、流程服务（实现复杂业务流程）。
- 基础服务贴近业务实体，提供业务的基础能力：基础服务直接支持业务实体，提供基本的业务操作和数据管理。
- 聚合服务聚合基本业务场景，满足高一层业务场景并可复用：聚合服务通过组合基础服务，实现更复杂的业务功能，支持更高层次的业务需求。
- 流程服务面向复杂业务流程实现，通过驱动多个聚合/基础服务实现一个完整的业务流程：流程服务负责协调多个服务，完成复杂的业务流程。
3. 服务松耦合原则
- 服务职责单一，一个服务聚焦在特定业务的有限范围内，有助于敏捷开发和独立发布：每个服务应该有明确的职责范围，避免职责过于宽泛，以便独立开发和部署。
- 区分核心业务服务和非主核心业务服务：核心业务服务是系统的关键部分，非主核心业务服务则是辅助性的功能。
- 区分稳定服务和易变服务：将频繁变化的服务和稳定的服务分开管理，减少变化对系统整体的影响。
- 每个服务只能访问自己的数据：服务之间通过API进行通信，避免直接访问其他服务的数据，增强系统的模块化和独立性。
4. 服务独立部署原则
- 服务独立部署，能够独立发布或取消发布：每个服务都可以独立部署，不依赖于其他服务，发布和回滚都非常灵活。
- 服务可水平扩展，并支持单独扩展：服务能够根据需求进行水平扩展，支持弹性伸缩。
- 实现持续集成和自动发布：通过持续集成和自动化工具，实现服务的自动化构建、测试和部署。
- 实现服务的技术和业务监控：对服务的运行状态进行实时监控，确保系统的稳定性和性能。
5. 兼容性原则
- 接口契约先行，提供最新在线服务文档：服务之间的接口要有明确的契约，并提供最新的文档，确保各服务之间的兼容性。
- 服务版本管理，保证向前兼容：通过版本管理，确保新版本的服务能够兼容旧版本，平滑过渡。
