微服务架构：原理、挑战与设计实践

微服务

介绍

• 定义：微服务是一种去中心化的架构模式，它将单个应用程序拆分成一系列小型服务来开发，每个服务都在自己的进程中运行，有自己的用户界面、数据库和外部协作（开发，测试，部署等），服务之间通过**RPC（远程调用）**进行通信
• 对比单体架构：
  • 解耦性：
    • 单体架构：对一小部分代码的更改，需要将整个单体应用进行重建和部署
    • 微服务架构：很方便地扩展新的服务和重构已有的服务，每个服务可以使用不同的编程语言，由不同的开发团队进行开发（跨职能）
  • 封装性：
    • 单体架构： 语言本身通常缺乏明确发布接口的机制，组件之间的封装性依赖于开发者的文档和自律，容易导致组件之间耦合过紧，封装性被破坏
    • 微服务架构： 通过将服务作为组件、使用远程调用机制，可以更清晰地定义服务边界和接口，从而更好地实现封装性，但远程调用开销较大，服务接口变更成本更高，并且需要进行调用失败时的容错设计
  • 一致性：
    • 单体架构： 通过事务来保证更新多个资源时的数据一致性
    • 微服务架构： 分布式事务实施很困难，因此通过补偿机制保证数据的最终一致性

挑战

• 复杂性：微服务架构的设计和管理比单体架构更复杂
• 服务间通信：协调微服务之间的通信可能具有挑战性
• 数据一致性：跨多个微服务维护数据一致性可能很困难
• 监控：微服务架构的监控和可观察性可能很复杂
• 调试：无法直接在IDE上进行跨服务的debug调试
• 安全性：微服务架构比单体架构更容易受到安全攻击。微服务模型会为您的系统创建多个可能的入口点，每个入口点都可能暴露漏洞

设计

设计代码架构

• 微服务的规模会随着时间的推移而增长，所以提前思考每个服务将提供的所有功能，以及如何相应地构建代码。选择正确的设计模式，并从始至终遵循既定的约定。

确定服务的标准

• 业务需求：作为特定业务功能需求的集合
• 功能自主：服务能够独立运行并执行其预期功能，例如，订单服务可返回上周订单，但不应处理与用户年龄相关的订单查询。不过某些功能确实需跨组件协作，应根据实际场景选择最合适的方案
• 数据实体：每个服务应该围绕一个清晰、独立的数据实体来组织，例如，订单服务就专注于处理订单相关的数据。不同的服务之间虽然可能有关联（比如订单会涉及客户），但这种关联应仅通过“外键”来维护 —— 订单服务只保存一个“客户ID”，而不会复制和保存整个客户的详细信息。
• 数据自治：数据实体必须是原子的（不可再分），即服务不能依赖于其他服务的数据才能正常运行。例如：如果订单服务的所有功能都依赖于客户服务。在这种情况下，最好将订单服务与客户服务合并，因为它们永远不会独立运行。

定义通信模式

• 一对一同步：一个服务调用另一个服务并等待其响应。仅当一个服务依赖另一个服务的响应来完成自身任务并提供响应时，才应使用此模式。不建议服务之间直接通信，因为可能形成“蜘蛛网”式的通信，当某个服务发生变化，将产生连锁反应，应使用中间网关或第三方发现服务进行
• 一对一异步：一个服务调用另一个服务，但不等待其响应即可继续运行。此模式通常使用消息队列来实现
• 发布-订阅/事件驱动：一个服务的某个事件发生后，通知给其他订阅该事件的服务

技术选择

• 编程语言：微服务的去中心化特性使得每个服务可以使用不同的语言开发，因此根据业务特性选择合适的语言开发
• 服务框架：提供快速构建微服务项目的能力，并保证其性能、稳定性和扩展性等
• 配置中心：动态、集中式地管理每个服务的配置
• 注册中心：提供服务注册与发现的功能
• 网关：在请求到达真正的服务之前的处理，如请求路由、安全控制、限流等
• 消息中间件：实现解耦、异步地通信方式

日志记录和监控

• 使用微服务时，建议将所有日志集中在一个地方，记录尽可能多的信息，每个日志中都应始终包含必要的信息，例如时间戳、负责用户、严重性、服务、消息、堆栈跟踪、事件 ID 等。
• 监控会查看指标、检测异常，并从不同角度清晰地呈现服务状态。监控可以在服务基础设施中进行，提供有关计算机、数据库和网络使用情况的信息；也可以在服务本身中进行，提供有关服务流程的信息。**