microservice场景下多微服务如何维护session及处理跨服务exception

1 跨微服务异常处理 #

• 不需要在两个微服务中复制相同的异常对象。微服务核心设计原则为低耦合高内聚，两边维护相同异常类会造成服务强绑定，严重影响服务的独立迭代能力。
• 正确处理逻辑为所有服务对外暴露的接口遵循统一错误传输协议：上游服务抛出内部异常后，由接口层统一拦截，封装为包含错误码、错误描述、可选扩展信息的通用错误结构返回，HTTP场景下同步搭配对应的4xx/5xx状态码，RPC场景下封装为通用响应DTO传输即可。
• 下游服务接收到错误响应后，仅需按照协议解析字段，再结合自身业务逻辑转换为内部自定义异常处理即可，完全不需要感知上游服务的原生异常定义。
• 通用错误结构示例：

public class CommonErrorResp {
    // 全局唯一错误码
    private String errorCode;
    // 用户可读的错误提示
    private String errorMsg;
    // 可选的扩展信息，用于传递参数校验详情、traceId等内容
    private Map<String, Object> extra;
}

2 多微服务会话维护 #

微服务架构默认优先推荐服务无状态设计，确需维护会话时，主流可落地方案有三类：

• Token透传方案：最常用的轻量方案。用户登录后由统一认证服务签发加密Token（常用JWT实现），Token中可携带用户ID、权限、有效期等非敏感信息，后续所有客户端请求在Header中携带该Token，各个微服务自行完成Token校验和解析即可获取会话信息，无需集中存储，性能开销最低。注意不要在JWT Payload中存储敏感信息，该部分仅做Base64编码未做加密。
• 集中式会话存储：适用于需要支持会话主动失效、存储会话信息较多的场景。所有会话数据统一存储在公共的分布式缓存（一般用Redis）中，用户请求携带唯一SessionId，所有微服务需要获取会话信息时，通过SessionId访问缓存查询即可，需要合理设置会话过期时间避免缓存溢出。
• 网关统一会话解析：适用于微服务数量多、不想重复开发会话校验逻辑的场景。将会话校验逻辑统一收敛到API网关层，网关校验会话通过后，把解析完成的用户ID、角色等核心会话字段放到请求头中透传给下游业务微服务，下游服务直接读取请求头字段即可，大幅减少重复开发量。

不推荐使用传统应用服务器自带的Session复制方案，该方案在微服务节点多、扩缩容频繁的场景下性能损耗极高，一致性也很难保障。

内容的提问来源于stack exchange，提问作者Amit K