基础服务-用户中心
什么是用户中心？
用户中心，在我们的概念里面范围比较的广泛，包含了用户信息、账号信息以及租户信息的管理控制，在我们的总体设计里面，如果设计的边界较为紧密，也可以将权限的部分功能RBAC划分进入，当业务剧增的时候，可以将领域划分细一些。
用户中心功能范围
- 用户服务中心
- 账号服务中心
- 租户服务中心
- RBAC服务中心
以上服务中心可与i独立部署，也可以采用巨石部署方式，但是领域划分原则不会因此改变。
用户服务中心
主要面向相关的用户服务信息
- 用户基本信息管理
- 用户基本信息检索
- 用户信息扩展功能
账户服务中心
主要面向与相关的账户服务中i性能
- 账号信息管理
- 账号注册功能服务接口
- 账号注销功能服务接口
- 账号状态控制额服务接口（包含账号锁定、账号封锁）
- 账号认证管理
- 用户登录服务i接口
- 用户登出服务接口
- 账号JWT校验认证服务功能
- 账号会化控制机制（包括：会话存储持久化、会话JWT控制机制）
租户服务中心
主要面向与相关的租户概念中i相关，包含：租户隔离机制以及租户控制
- 租户信息维护：维护租户信息数据、以及相关的租户的有效期或者有效范围的控制管理维护
- 租户权限控制：租户相关的数据权限隔离机制：比如采用schema级别、表级别、库级别等。
Dubbo3的RPC技术调用体系
本章我们计划采用Dubbo3的rpc服务调用体系，进行将网关中心和权限安全中心对接我们的用户中心，使得我们的网关中心 -> 安全中心 -> 用户中心
我们采用安全中心作为鉴权处理、用户中心进行信息维护和控制，网关中心作为路由服务以及过滤控制审计等。
用户中心所设计技术内容
Dubbo3的Annotation配置方式进行相关的使用案例
服务端的配置控制
首先，我们先进行编写一个服务提供者的配置信息类
Java
复制代码
@Configuration @EnableDubbo(scanBasePackages = "xx.xx.xx") @PropertySource("classpath:/spring/dubbo-provider.properties") static class ProviderConfiguration { }
@EnableDubbo 注解将会启用 Spring xx.xx.xx 包 搜索遍历寻找相关的Dubbo注解的所有相关的类
定义一个服务提供者的接口
作为服务提供者的实现接口，将会有一个被@DubboService:进行修饰的接口实现类
Java
复制代码
@DubboService public class AnnotatedGreetingService implements GreetingService { public String sayHello(String name) { System.out.println("greeting service received: " + name); return "hello, " + name; } }
消费端的配置控制
首先，我们先进行编写一个服务消费端的配置信息类
Java
复制代码
@Configuration @EnableDubbo(scanBasePackages = "xx.xx.xx") @PropertySource("classpath:/spring/dubbo-consumer.properties") @ComponentScan(value = {"org.apache.dubbo.samples.annotation.action"}) static class ConsumerConfiguration { }
之后需要采用 @DubboReference 注解进行修饰对应接口，进行注入相关的远程服务的实现类:
Java
复制代码
@Component("annotatedConsumer") public class GreetingServiceConsumer { @DubboReference private GreetingService greetingService; ... }
实现开发用户登录功能开发实现以及接口设计·
主要面向与用户执行登录的操作控制接口实现机制，通过输入用户信息凭证，使用用户名+密码执行登录操作
- 主要面向的服务1：用户中心服务，进行用户持久化查询信息
- 主要面向的服务2：安全认证服务，进行SpringSecurity服务的鉴权控制
实现用户注册、注销功能开发实现以及接口定义
- 主要面向与用户的注册账号功能（新增账号功能）
- 主要面向与用户的注销账号功能（删除账号功能），并且清除该账号下所有的相关信息
获取用户登录信息以及忘记密码实现以及接口定义
- 主要获取用户登录后，根据token以及相关的凭证获取相关的用户基本信息模型，作为系统全局的用户信息上下文。
- 主要用于当密码忘记后，采用系统认证凭证渠道：用户邮箱、手机号进行作为修改密码的凭证
- 获取相关的用户邮箱或者手机号，进行发送识别码/验证码
- 根据相干的验证码/识别码进行修改改用户的密码擦偶哦
更新用户个人信息以及接口定义和功能实现
- 主要用于更新账号或者个人的信息数据，一般可以扩展到基本信息，以及相关的扩展信息等
完成相关的重置密码的接口定义及功能实现
- 重置密码操作，一般给予系统管理员，在用户不方便的场景下，直接将用户密码重置为默认的随机密码。
通过MybatisPlus实现多租户操作实现机制，实现数据的租户隔离机制
主要采用MybatisPlus框架自带的拦截器机制，在拦截时直接进入注入相关的tenant_id数据值：
多租户的使用
- 核心插件： TenantLineInnerInterceptor
- 核心处理器：TenantLineHandler-
java
复制代码
public interface TenantLineHandler { /** * 获取租户 ID 值表达式，只支持单个 ID 值 * <p> * * @return 租户 ID 值表达式 */ Expression getTenantId(); /** * 获取租户字段名 * <p> * 默认字段名叫: tenant_id * * @return 租户字段名 */ default String getTenantIdColumn() { return "tenant_id"; } /** * 根据表名判断是否忽略拼接多租户条件 * <p> * 默认都要进行解析并拼接多租户条件 * * @param tableName 表名 * @return 是否忽略, true:表示忽略，false:需要解析并拼接多租户条件 */ default boolean ignoreTable(String tableName) { return false; } }
说明:
多租户 != 权限过滤,不要乱用,租户之间是完全隔离的!!! 启用多租户后所有执行的method的sql都会进行处理. 自写的sql请按规范书写(sql涉及到多个表的每个表都要给别名,特别是 inner join 的要写标准的 inner join)
java
复制代码
@Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); // 如果用了分页插件注意先 add TenantLineInnerInterceptor 再 add PaginationInnerInterceptor // 用了分页插件必须设置 MybatisConfiguration#useDeprecatedExecutor = false // interceptor.addInnerInterceptor(new PaginationInnerInterceptor()); interceptor.addInnerInterceptor(new TenantLineInnerInterceptor( new TenantLineHandler() { // manager_id = 1088248166370832385 // 获取租户 ID 值表达式，只支持单个 ID 值 @Override public Expression getTenantId() { return new LongValue(1088248166370832385L); } // 这是 default 方法,默认返回 false 表示所有表都需要拼多租户条件, // 这里设置 role表不需要该条件 @Override public boolean ignoreTable(String tableName) { if ("role".equals(tableName)) { return true; } return false; } @Override public String getTenantIdColumn() { return "manager_id"; } })); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } @Bean public ConfigurationCustomizer configurationCustomizer() { return configuration -> configuration.setUseDeprecatedExecutor(false); }
介绍相关Triple通信协议的介绍和实现
RPC 协议的选择
协议是 RPC 的核心，它规范了数据在网络中的传输内容和格式。除必须的请求、响应数据外，通常还会包含额外控制数据，如单次请求的序列化方式、超时时间、压缩方式和鉴权信息等。
协议的内容包含三部分
- 数据交换格式： 定义 RPC 的请求和响应对象在网络传输中的字节流内容，也叫作序列化方式
- 协议结构： 定义包含字段列表和各字段语义以及不同字段的排列方式
- 协议通过定义规则、格式和语义来约定数据如何在网络间传输。一次成功的 RPC 需要通信的两端都能够按照协议约定进行网络字节流的读写和对象转换。如果两端对使用的协议不能达成一致，就会出现鸡同鸭讲，无法满足远程通信的需求。
Dubbo3的通信协议
- Dubbo3 提供了 Triple(Dubbo3)、Dubbo2 协议，这是 Dubbo 框架的原生协议。除此之外，Dubbo3 也对众多第三方协议进行了集成，并将它们纳入 Dubbo 的编程与服务治理体系， 包括 gRPC、Thrift、JsonRPC、Hessian2、REST 等。以下重点介绍 Triple 与 Dubbo2 协议。
- Triple 协议是 Dubbo3 推出的主力协议。Triple 意为第三代，通过 Dubbo1.0/ Dubbo2.0 两代协议的演进，以及云原生带来的技术标准化浪潮，Dubbo3 新协议 Triple 应运而生。
Triple 协议
- Triple 协议是 Dubbo3 的主力协议，完整兼容 gRPC over HTTP/2，并在协议层面扩展了负载均衡和流量控制相关机制。本文档旨在指导用户正确的使用 Triple 协议。
- 服务使用的序列化方式，如果为新服务，推荐使用 protobuf 作为默认序列化，在性能和跨语言上的效果都会更好。如果是原有服务想进行协议升级，Triple 协议也已经支持其他序列化方式，如 Hessian / JSON 等。
服务流量管理
通过 Dubbo 定义的路由规则，实现对流量分布的控制
流量管理
流量管理的本质是将请求根据制定好的路由规则分发到应用服务上，如下图所示：
其中：
- 路由规则可以有多个，不同的路由规则之间存在优先级。如：Router(1) -> Router(2) -> …… -> Router(n)
- 一个路由规则可以路由到多个不同的应用服务。如：Router(2)即可以路由到Service(1)也可以路由到Service(2)
- 多个不同的路由规则可以路由到同一个应用服务。如：Router(1)和Router(2)都可以路由到Service(2)
- 路由规则也可以不路由到任何应用服务。如：Router(m)没有路由到任何一个Service上，所有命中Router(m)的请求都会因为没有对应的应用服务处理而导致报错
- 应用服务可以是单个的实例，也可以是一个应用集群。
Dubbo流量管理介绍
Dubbo提供了支持mesh方式的流量管理策略，可以很容易实现 A/B测试、金丝雀发布、蓝绿发布等能力。
Dubbo将整个流量管理分成VirtualService和DestinationRule两部分。当Consumer接收到一个请求时，会根据VirtualService中定义的DubboRoute和DubboRouteDetail匹配到对应的DubboDestination中的subnet，最后根据DestinationRule中配置的subnet信息中的labels找到对应需要具体路由的Provider集群。其中：
- VirtualService主要处理入站流量分流的规则，支持服务级别和方法级别的分流。
- DubboRoute主要解决服务级别的分流问题。同时，还提供的重试机制、超时、故障注入、镜像流量等能力。
- DubboRouteDetail主要解决某个服务中方法级别的分流问题。支持方法名、方法参数、参数个数、参数类型、header等各种维度的分流能力。同时也支持方法级的重试机制、超时、故障注入、镜像流量等能力。
- DubboDestination用来描述路由流量的目标地址，支持host、port、subnet等方式。
- DestinationRule主要处理目标地址规则，可以通过hosts、subnet等方式关联到Provider集群。同时可以通过trafficPolicy来实现负载均衡。
- 这种设计理念很好的解决流量分流和目标地址之间的耦合问题。不仅将配置规则进行了简化有效避免配置冗余的问题，还支持VirtualService和DestinationRule的任意组合，可以非常灵活的支持各种业务使用场景。
兼容 gRPC ，以 HTTP2 作为传输层构建新的协议，也就是 Triple。
容器化应用程序和微服务的兴起促进了针对负载内容优化技术的发展。 客户端中使用的传统通信协议（ RESTFUL或其他基于 HTTP 的自定义协议）难以满足应用在性能、可维护性、扩展性、安全性等方便的需求。一个跨语言、模块化的协议会逐渐成为新的应用开发协议标准。自从 2017 年 gRPC 协议成为 CNCF 的项目后，包括 k8s、etcd 等越来越多的基础设施和业务都开始使用 gRPC 的生态，作为云原生的微服务化框架， Dubbo 的新协议也完美兼容了 gRPC。并且，对于 gRPC 协议中一些不完善的部分， Triple 也将进行增强和补充。
- 性能上: Triple 协议采取了 metadata 和 payload 分离的策略，这样就可以避免中间设备，如网关进行 payload 的解析和反序列化，从而降低响应时间。
- 路由支持上，由于 metadata 支持用户添加自定义 header ，用户可以根据 header 更方便的划分集群或者进行路由，这样发布的时候切流灰度或容灾都有了更高的灵活性。
- 安全性上，支持双向TLS认证（mTLS）等加密传输能力。
- 易用性上，Triple 除了支持原生 gRPC 所推荐的 Protobuf 序列化外，使用通用的方式支持了 Hessian / JSON 等其他序列化，能让用户更方便的升级到 Triple 协议。对原有的 Dubbo 服务而言，修改或增加 Triple 协议 只需要在声明服务的代码块添加一行协议配置即可，改造成本几乎为 0。
