关于java:部分研发设计文档

1. 角色权限模块

1.1 RBAC 概述

RBAC 通过定义角色的权限，并对用户授予某个角色从而来管制用户的权限，实现了用户和权限的逻辑拆散（区别于 ACL 模型），极大中央便了权限的治理

上面在解说之前，先介绍一些名词：

• User（用户）：每个用户都有惟一的 UID 辨认，并被授予不同的角色
• Role（角色）：不同角色具备不同的权限
• Permission（权限）：拜访权限
• 用户 - 角色映射：用户和角色之间的映射关系

• 角色 - 权限映射：角色和权限之间的映射
  

  1.2 以后零碎设计

权限零碎日益简单，需求方提出须要反对多种维度受权

如: 研发部的员工能够拜访 gitlab;java 开发工程师能够拜访跳板机; 杭州的员工能够看到亚运会信息;P6 级别以上能力看到公司利润报表。于是，零碎的受权也变得越来越简单，更有甚者，只有研发部部门的 leader 能够看到以后部门研发部成员的根本信息 …

多 tag 模型权限设计(tag 是反对受权的字段，维度也能够称之为 tag 标签)

因为通常是将某一类权限赋予给用户，故抽离出权限组的概念。权限组是若单个干权限的汇合

以后零碎:

查问权限的逻辑为

1. 依据 employeeId 查问 EmployeeRoleMap 表获取角色汇合 roleIds

select roleIds from EmployeeRoleMap where employeeId = ? 

2. 查问 permission 表获取权限关联：(以后 tag 只有 RoleDimssionKey.ROLE)

select menuUID,menuGroupId from permission where value in [roleIds...] and key = RoleDimssionKey.ROLE

3. 若存在 menuGroupId（权限组 id）, 则查问 menu_group_mapping(权限 - 权限组关联表)获取权限组关联的所有 menuUID

select menuUID,menuGroupId from menu_group_mapping where menuGroupId in [...]

4. 依据 menuUID 查问所有 Menu(若步骤 3 中存在 menuId，累计一起查问)

select * from menu_group_mapping where menuId in [...]

权限组相干逻辑为

权限组配置（经营平台）

商品 spu 绑定有 menuGroup 属性（长期解决方案，前期倡议剥离商品属性，间接绑定对应的 spu 和权限组）

用户购买商品付款胜利后，后盾逻辑会查问出以后 sku 绑定的菜单组，并增加到 permission（tag- 权限关联表）中

insert into permission (KEY=ROLEDIMISSION.ROLEID,value=?,MENUGROUPID=?DATA_BI_MENU_GROUP_ID?)

2.sku 商品价格计算

为了避免薅羊毛，0 元价格商品只能购买一次

2.1 新用户 NoneUpgradeSkuFilter

间接查问 sku 商品价格即可

2.2 降级账号数量 UpgradeAccountSkuFilter

锁定 时长 = 离以后套餐最近的时长 , 账号数量大于以后套餐的账号 的套餐

2.3 降级时长 UpgradeTimeSkuFilter

锁定 账号数量等于以后套餐的账号 的套餐

代码逻辑为

1. 购买时查问 organization_payment_detail 表，确定能够购买的类型。（购买胜利会更新 organization_payment_detail）

organization_payment 为空（新用户）前端显示购买按钮，

organization_payment（过期或已购买状态）前端显示降级时长、降级账号按钮

2. 前端发动查问 sku 申请并携带购买类型参数，后端依据购买类型确定 filter 来进行商品的过滤和价格计算（如 NoneUpgradeSkuFilter、UpgradeAccountSkuFilter、UpgradeTimeSkuFilter）

由对应的购买类型如 UpgradeAccountSkuFilter 负责商品的过滤及价格的计算

计算逻辑为 补差价（理论价格 = 应酬价格 - 差价）

套餐 A 1 个月 10 个 10 元

套餐 B 1 个月 20 个 20 元

套餐 C 1 个月 30 个 30 元

套餐 D 4 个月 10 个 40 元

套餐 E 5 个月 10 个 50 元

1. 路人甲用户 降级账号

case1 假如明天是 09-15 日，09-01 日购买套餐 A

则可降级套餐为 B\C

如 购买 B 套餐价格为（20/30（30-15)）-10/30×15= 5 元 能够简化为须要补 15 天的差价（30-15）x(20/30-10/30)= 5 元，以后（套餐变为 09-15—->09-30 日 20 个账号）

2. 路人甲用户 降级时长

case1 假如明天是 09-15 日,09-01 日购买套餐 A

则可降级套餐为 D\E

购买 D 价格为 40 元 -10 元 /30 天 * 未应用天数 15 天 =（40-10/30×15）=35 元，以后 套餐变为 09-15—->09-15 后 4 个月 10 个账号

购买 E 价格为 50 元 -10 元 /30 天 * 未应用天数 15 天 =（50-10/30×15）=45 元，以后 套餐变为 09-15—->09-15 后 5 个月 10 个账号

3. AD 模块

3.1 AD 域控根底

AD 是 windows 计算机近程登录的账户管理中心，关上近程利用，会为每个数影用户调配独立的办公空间即创立 AD 账号。AD 账号创立是通过 java 调用 powershell 命令行实现的

3.2 连接池

模仿 C3P0 连接池、线程池等原理实现一个能够复用的 powershell 连接池

需要剖析：以后零碎 powershell 次要用于帮助 DDC 机器、AD 相干资源 CRUD 及其他辅助 powershell 命令。因为 AD 域控是连通的，且 powershell 能够近程运行。故咱们冀望部署在 DDC01 机器上的 agent 能够间接管制本机和 app01\addc01 上 powershell 的经营

入参：机器名、script 脚本

Powershell：近程执行、本地执行

IRecycle 可复用对象。id 作为惟一标示，reset 办法重置所有属性

ObjectPool 形象可复用资源池，应用 LinkedBlockingQueue 作为容器，避免多线程并发平安问题

DefaultRecyclePowerShellFactory powershell 连接池
+String getId();
+void reset(); 销毁以后 powershell session 上下文
Remove-Variable * -ErrorAction SilentlyContinue  -Exclude @(...)

DefaultRecyclePowerShell powershell 可复用对象

4.websocket 模块

绝对于传统 HTTP 每次申请 - 应答都须要客户端与服务端建设连贯的模式，WebSocket 是相似 Socket 的 TCP 长连贯通信模式。WebSocket 连贯建设后，后续数据都以帧序列的模式传输。

握手阶段

a. 浏览器、服务器建设 TCP 连贯，三次握手。这是通信的根底，传输管制层，若失败后续都不执行。

b. TCP 连贯胜利后，浏览器通过 HTTP 协定向服务器传送 WebSocket 反对的版本号等信息。（开始前的 HTTP 握手）

c. 服务器收到客户端的握手申请后，同样采纳 HTTP 协定回馈数据。

d. 当收到了连贯胜利的音讯后，通过 TCP 通道进行传输通信。

客户端发送音讯：

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Version: 13

服务端返回音讯：

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

技术选型：

原生 websocket

springboot websocket（轻量级，spring 集成，开发成本小）

Stomp(相似于 spring stream 音讯，springboot websocket 高级协定，前端须要应用 SOCKJS）

Netty SocketIO（轻量级，性能好，前端须要引入 socket.io.js）

spring websocket 次要组件

WebSocketConfigurer websocket 配置类：增加音讯处理器和握手拦截器
void registerWebSocketHandlers(WebSocketHandlerRegistry registry)
如 registry.addHandler(agentWSHandler(), "/api/v1/websocket/dsAgent")
                .setAllowedOrigins("*")
                .addInterceptors(agentWSInterceptor);  

TextWebSocketHandler 文本音讯处理器
void afterConnectionEstablished(WebSocketSession session)连贯建设胜利之后
void handleMessage(WebSocketSession session, WebSocketMessage<?> message) 收到客户端推送的音讯
void afterConnectionClosed(WebSocketSession session, CloseStatus status) 连贯断开之前
  
HandshakeInterceptor 握手拦截器
beforeHandshake(ServerHttpRequest request, ServerHttpResponse response, WebSocketHandler wsHandler, Map<String, Object> attributes) 握手之前。能够做音讯的拦挡逻辑解决

websocketSession 多实例存在以下问题：

A websocket 连贯 app1 服务器，下次申请负载平衡连贯到了 app02 服务器。这个时候服务端须要推送 websocket 音讯

解决方案：形象出 WebsocketSender 专门负责 message 的发送。以后实现为 RocketMqMessageSender

先查看以后服务是否存在符合条件的 websocketSession, 若存在间接发送，若不存在发送到 rocketMq 中期待其余实例拉取生产。（留神死循环问题，不要始终发）

4.1 DSClient-StoreFront

WebsocketConfiguration 配置类配置了两条 websocket 通道：Dsclient 侧、前端侧

Dsclient-storeFront
DsclientHandler  Dsclient 侧 websocket 音讯处理器 /api/v1/websocket/dsClient
ExtractParameterInterceptor 提取 request 中的参数并封装到 websocketSession 中
BinderIdCheckInterceptor 查看是否申请中具备 BinderId 参数

前端侧 -storeFront
WebClientHandler 前端侧 websocket 音讯处理器 /api/v1/websocket/webClient
AuthHttpSessionInterceptor 校验是否登录

WebClientHandler

INIT_BINDER_INFO 服务端返回 binderId 信息
REFRESH_APPLICATION_LIST  服务端转发 Dsagent 触发的 REFRESH_APPLICATION_LIST 工夫
OPEN_APPLICATION 关上利用，转发给 Dsagent
WEB_CLIENT_DIS_CONNECT 前端退出登录，转发给 Dsagent

DsClientHandler

PUSH_LATEST_APPLICATION_INFO 刚连贯时服务端会发送最新的本地利用列表
REPORT_LOCAL_APPLICATION_INFO 上报本地利用详情如装置进度，会触发 REFRESH_APPLICATION_LIST 事件

流程如下：

4.2 DSAgent-AgentManagerWeb

WSConfiguration websocket 配置类，配置 AgentWSHandler 和 AgentWSInterceptor
AgentWSHandler websocket 音讯处理器
AgentWSInterceptor 提取参数封装到 websocketSession 上下文中

Dsagent 侧 -storeFront

AgentWSInterceptor 负责 Dsagent 侧 websocket 握手。为了后续不再传递以后 session 的惟一标识信息，如 sessionId、machineSessionName 等，故在握手胜利时将这部分身份信息间接放入 websocketSession 中，相似 httpHeader 中的 cookie 标示
如
ws://localhost:9071/api/v1/websocket/dsAgent?machineName=machineName&machineSessionId=machineSessionId&userName=userName

AgentWSHandler 负责 Dsagent 音讯解决
MACHINE_SESSION_REPORT:Dsagent 上报会话利用信息
MACHINE_REPORT:Dsagent 上报 system0 机器信息
MACHINE_SESSION_LOGOUT: 经营平台下发。由服务端转发给 Dsagent

流程如下：

session 会话信息上报流程：（非 system0 用户）

1.DsAgent 每 15 秒全量上报以后 session 信息，即 MACHINE_SESSION_REPORT 事件

2. 服务端存储信息到 Redis，过期工夫为 20s

3. 经营平台前端查看会话治理，反对分页查问，含糊查问

4. 经营平台前端点击登记按钮，下发 MACHINE_SESSION_LOGOUT 给 DsAgent

5.Dsagent 收到 MACHINE_SESSION_LOGOUT，会话胜利登记。服务端 webs co ke t 断开清空 redis 中以后 session 会话信息

机器信息上报流程（system0 用户）:DsAgent 每 15 秒上报机器信息（MACHINE_REPORT）, 服务端存储音讯过期工夫为 20s

数据分页小工具：

redis 作为内存数据库 数据须要分页查问，依赖于 SimpleStringCache<T>。SimpleStringCache 会基于 @CacheIndex 注解构建索引 Map

例如：

    @Data
    @Accessors(chain = true)
    static class A{
        @CacheIndex
        private String name;
        @CacheIndex
        private String id;
    }

    public static void main(String[] args) {List<A> list = new ArrayList();
        A haha1 = new A().setName("haha").setId("51");
        A haha2 = new A().setName("shiha").setId("761");
        
        list.add(haha1);
        list.add(haha2);


        SimpleStringCache simpleStringCache = new SimpleStringCache(list);
        List<Map> filter = new ArrayList<>();
        Map map = new HashMap();
        map.put("id", "1");
        map.put("name", "sh");
        filter.add(map);

        simpleStringCache.query(filter).forEach(System.out::println);
    }

simpleStringCache 会构建如下索引 Map 用于疾速定位

Originate:<0,haha1><1,haha2>

IndexMap:

<id,51,[0]><id,761,[1]>

<name,haha,[0]>,<name,shiha,[1]>

{
  "id": [
    {
      "51": "0",
      "761": "1"
    }
  ],
  "name": [
    {
      "haha": "0",
      "shiha": "1"
    }
  ]
}

查问时会根据传入的 List<Map> filter 进行含糊查问

[

{“id”: “1”,

   "name",:"sh"

}

}]

如上述申请会命中 id 索引、name 索引，首先查问 IndexMap 依据 id= 1 含糊查问出【0，1】，依据 name=sh 含糊查问出【1】。and 关系故最终只命中【1】，最初后果去 originData 中查问最终 data 为 <1,haha2>

5. 拓展

5.1 散布式调度问题

目前我的项目中应用自定义 @DistributeTask 注解：通过分布式锁的形式简略躲避了高可用环境下任务调度的并发问题。APP01 执行调度时会应用 Redission 红锁创立一个分布式锁，工作执行完结后开释锁。APP02 工作来长期同样会获取这个分布式锁。

举荐 Xxx-job 解决分布式定时工作

5.2 外部服务鉴权问题

目前外部服务接口鉴权是依赖了公共模块 dsphere-rpc-auth

须要鉴权的外部服务如 dsphere-marketing-platform 须要依赖 dsphere-rpc-auth-service 模块，dsphere-rpc-auth-service 会通过 spring.factories 以 springboot starter 的形式注入一个 HandlerIntecptor, 该 HandlerIntecptor 会拦挡 url 合乎 /api/v1/auth/* 申请，确保申请头 header 中携带 AUTHORIZATION=xxx，否则校验失败。

5.3 remote debug

java 近程 debug 依赖

5.4 线上问题排查

arthas 反编译、动静批改并加载 clas 文件、jvm 调优及 gc 问题剖析

5.5 分布式自增序列 id

依赖于数据库 InnoDB 引擎行锁实现

@Component
@Slf4j
public class SequenceUtil {
    @Autowired
    private SequenceRepo sequenceRepo;

    /**
     * INNODB 引擎默认行锁，能够保障更改不产生失落（只存在以后一个原子性操作）* MVCC 机制 应用以后读 获取最新版本数据
     * @param sequenceEnum
     * @return
     */
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public Integer getId(SequenceEnum sequenceEnum) {sequenceRepo.incrementCounter(sequenceEnum.getPrimaryKeyId());
        int counterByName = sequenceRepo.findCounterById(sequenceEnum.getPrimaryKeyId());
        log.info("id"+counterByName);
        return counterByName;
    }

}

public interface SequenceRepo extends CrudRepository<Sequence, Integer> {@Query(value = "update sequence set counter = counter + 1 where id = (:id)", nativeQuery = true)
    @Modifying
    @Transactional
    int incrementCounter(@Param("id")Integer id);

    @Query(value = "select counter from sequence where id = (:id)", nativeQuery = true)
    int findCounterById(@Param("id")Integer id);

}