用户中心,在我们的概念里面范围比较的广泛,包含了用户信息、账号信息以及租户信息的管理控制,在我们的总体设计里面,如果设计的边界较为紧密,也可以将权限的部分功能RBAC划分进入,当业务剧增的时候,可以将领域划分细一些。
用户服务中心
账号服务中心
租户服务中心
RBAC服务中心
以上服务中心可与i独立部署,也可以采用巨石部署方式,但是领域划分原则不会因此改变。
主要面向相关的用户服务信息
主要面向与相关的账户服务中i性能
账号信息管理
账号认证管理
主要面向与相关的租户概念中i相关,包含:租户隔离机制以及租户控制
租户信息维护:维护租户信息数据、以及相关的租户的有效期或者有效范围的控制管理维护
租户权限控制:租户相关的数据权限隔离机制:比如采用schema级别、表级别、库级别等。
本章我们计划采用Dubbo3的rpc服务调用体系,进行将网关中心和权限安全中心对接我们的用户中心,使得我们的网关中心 -> 安全中心 -> 用户中心
我们采用安全中心作为鉴权处理、用户中心进行信息维护和控制,网关中心作为路由服务以及过滤控制审计等。
首先,我们先进行编写一个服务提供者的配置信息类
@Configuration
@EnableDubbo(scanBasePackages = "xx.xx.xx")
@PropertySource("classpath:/spring/dubbo-provider.properties")
static class ProviderConfiguration {
}
@EnableDubbo
注解将会启用 Spring xx.xx.xx
包 搜索遍历寻找相关的Dubbo注解的所有相关的类
作为服务提供者的实现接口,将会有一个被@DubboService
:进行修饰的接口实现类
@DubboService
public class AnnotatedGreetingService implements GreetingService {
public String sayHello(String name) {
System.out.println("greeting service received: " + name);
return "hello, " + name;
}
}
首先,我们先进行编写一个服务消费端的配置信息类
@Configuration
@EnableDubbo(scanBasePackages = "xx.xx.xx")
@PropertySource("classpath:/spring/dubbo-consumer.properties")
@ComponentScan(value = {"org.apache.dubbo.samples.annotation.action"})
static class ConsumerConfiguration {
}
之后需要采用 @DubboReference
注解进行修饰对应接口,进行注入相关的远程服务的实现类:
@Component("annotatedConsumer")
public class GreetingServiceConsumer {
@DubboReference
private GreetingService greetingService;
...
}
主要面向与用户执行登录的操作控制接口实现机制,通过输入用户信息凭证,使用用户名+密码执行登录操作
主要面向与用户的注册账号功能(新增账号功能)
主要面向与用户的注销账号功能(删除账号功能),并且清除该账号下所有的相关信息
主要获取用户登录后,根据token以及相关的凭证获取相关的用户基本信息模型,作为系统全局的用户信息上下文。
主要用于当密码忘记后,采用系统认证凭证渠道:用户邮箱、手机号进行作为修改密码的凭证
主要采用MybatisPlus框架自带的拦截器机制,在拦截时直接进入注入相关的tenant_id数据值:
核心插件: TenantLineInnerInterceptor
核心处理器:TenantLineHandler-
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)
@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);
}
协议是 RPC 的核心,它规范了数据在网络中的传输内容和格式。除必须的请求、响应数据外,通常还会包含额外控制数据,如单次请求的序列化方式、超时时间、压缩方式和鉴权信息等。
Dubbo3 提供了 Triple(Dubbo3)、Dubbo2 协议,这是 Dubbo 框架的原生协议。除此之外,Dubbo3 也对众多第三方协议进行了集成,并将它们纳入 Dubbo 的编程与服务治理体系, 包括 gRPC、Thrift、JsonRPC、Hessian2、REST 等。以下重点介绍 Triple 与 Dubbo2 协议。
Triple 协议是 Dubbo3 推出的主力协议。Triple 意为第三代,通过 Dubbo1.0/ Dubbo2.0 两代协议的演进,以及云原生带来的技术标准化浪潮,Dubbo3 新协议 Triple 应运而生。
Triple 协议是 Dubbo3 的主力协议,完整兼容 gRPC over HTTP/2,并在协议层面扩展了负载均衡和流量控制相关机制。本文档旨在指导用户正确的使用 Triple 协议。
服务使用的序列化方式,如果为新服务,推荐使用 protobuf 作为默认序列化,在性能和跨语言上的效果都会更好。如果是原有服务想进行协议升级,Triple 协议也已经支持其他序列化方式,如 Hessian / JSON 等。
通过 Dubbo 定义的路由规则,实现对流量分布的控制
流量管理的本质是将请求根据制定好的路由规则分发到应用服务上,如下图所示:
Dubbo提供了支持mesh方式的流量管理策略,可以很容易实现 A/B测试、金丝雀发布、蓝绿发布等能力。
Dubbo将整个流量管理分成VirtualService和DestinationRule两部分。当Consumer接收到一个请求时,会根据VirtualService中定义的DubboRoute和DubboRouteDetail匹配到对应的DubboDestination中的subnet,最后根据DestinationRule中配置的subnet信息中的labels找到对应需要具体路由的Provider集群。其中:
容器化应用程序和微服务的兴起促进了针对负载内容优化技术的发展。 客户端中使用的传统通信协议( 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。