微服务——服务通信与接口设计
1、微服务之间常见的通信方式有哪些？请对比它们的优缺点。
| 通信方式 | 优点 | 缺点 |
|---|---|---|
| RESTful API | 技术栈无关，兼容性强 易于调试，适合跨平台调用 | 性能较低（基于 HTTP），延迟较大 数据传输量较大 |
| RPC | 高性能，低延迟 传输协议可选，适合实时通信 | 技术栈耦合，需统一语言框架 接口定义较复杂 |
| 消息队列 | 异步处理，解耦服务 支持事件驱动架构 | 延迟不可控 消息可靠性和幂等处理需额外设计 |
| gRPC | 支持多语言 性能高（基于 HTTP/2），支持流式通信 | 学习成本较高 配置复杂，调试工具较少 |
2、在项目中，如何选择微服务之间的通信方式？依据是什么？
- 实时性需求：高实时性选择 RPC 或 gRPC，非实时需求则用 RESTful 或消息队列。
- 兼容性要求：跨平台、跨语言的场景选择 RESTful 或 gRPC，内部系统倾向 RPC。
- 调用频率和数据量：高频低延迟的场景选择 RPC，数据量较大的选择 RESTful 或批处理消息队列。
- 团队技术栈：熟悉的技术优先，减少学习和维护成本。
3、使用 RESTful API 进行微服务通信时，如何设计合理的 API 接口？
- 接口命名：采用资源名和层级结构，例如
/users/{id}/orders表示用户的订单。 - 请求方法：
- GET：获取资源。
- POST：创建资源。
- PUT：更新资源（幂等）。
- DELETE：删除资源。
- 返回值：
- 成功返回标准 HTTP 状态码（200、201 等），失败返回 4xx 或 5xx 状态码。
- 使用 JSON 格式响应数据，包含
data、message和status字段。
- 接口文档：通过工具如 Swagger 或 OpenAPI 提供标准化文档，便于开发和维护。
4、如何对微服务之间的接口进行版本控制？
- URL 版本化：通过 URL 标识版本号，例如
/v1/users和/v2/users。 - 请求头版本化：在 HTTP Header 中指定版本号，例如
Accept: application/vnd.api+json;version=1.0。 - 优先原则：推荐 URL 版本化，直观且便于路由管理。
5、如何确保微服务接口的安全性？
- 认证：
- 使用 OAuth 2.0 或 JWT（JSON Web Token）对用户身份进行验证。
- 配置 API Gateway 进行统一认证管理。
- 授权：基于 RBAC（角色访问控制）或 ABAC（属性访问控制）对用户权限进行验证。
- 数据加密：
- 使用 HTTPS 保障传输安全。
- 对敏感数据进行加密存储与传输。
- 防护机制：
- 限流和熔断：避免恶意请求导致服务崩溃。
- CSRF 防护：在请求中添加防伪令牌（Token）。
- 日志与审计：记录 API 调用日志，便于审计和问题排查。
凡是过去，皆为序章；凡是未来，皆有可期。