# intsmaze

**Repository Path**: kmath/intsmaze

## Basic Information

- **Project Name**: intsmaze
- **Description**: 比较忙，暂时更新。《intsmaze轮子大师》致力于提供中小型系统的脚手架，集成当下最流行的各种技术，基于配置的方式可以在同一类型的技术中灵活切换。 单机可嵌入式LSM架构的no-sql引擎，以磁盘代替内存，最大20万qps, 后端微服务采用Jetty，SpringBoot服务,系统间的交互采用Dubbo，Orm层均用Mybatis； 提供数据库读写分离的多种实现； Resid服务采用多种模式，传统哨兵； 系统解耦采用消息中间件，目前提供两种实现Kafka与RocketMQ; 接入storm的DPRC进行服务支撑,一致性hash算法java代码实现；基于redis的接口幂等通用方案实现；
- **Primary Language**: Java
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 3
- **Created**: 2022-09-17
- **Last Updated**: 2022-09-17

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 项目技术
intsmaze项目不仅仅是一个开发架构，致力于提供大中型系统的脚手架，快速进行业务开发，免去项目集成新技术的时间成本。<br> 
* 基础框架为RBCA用户权限，采用前后端分离开发模式，RBCA模块采用基本的springMVC+mybatis架构；
* 其余后端模块采用jetty服务与SpringBoot服务来满足不同层次的需求；
* 服务间交互采用dubbo的RPC，同时引入了storm的DRPC进行服务的支撑；
* 消息中间件提供kafka与RocketMQ消息中间件，通过配置的方式灵活选择任意中间件，无需侵入源码修改； 
* 源码插桩技术监控每条消息的处理流程；
* hbase存储每条消息的处理流程；
* zookeeper技术提供分布式锁，配置中心，服务发现等功能；
* redis统一session会话管理；
* ClassLoad支持不停机,实时编译加载执行业务类
# 项目背景
intsmaze的项目虽然没有被用于各大生产环境，但是项目的各个技术的设计原型均来源于参与生产的多个系统，RBCA模块借鉴源于累计二十亿保单的保险公司的业务系统，storm流式计算借鉴源于三千万用户的银行业的营销系统，日均交易九百万笔。
### 交流QQ群：
(群内含启动文档文档、技术文档，视频教程下载)最重要的是技术方案的落地原因解释
# 项目架构
![image](https://github.com/intsmaze/intsmaze/raw/master/image/intsmaze1.png)
# 技术博客
http://www.cnblogs.com/intsmaze/

## 子系统功能
| 子系统名称        |   功能介绍  |
| --------  | :----: |
| upms系统        |用户权限系统，该系统负责配置角色，权限，面对的操作者为系统管理员，普通用户与各个业务系统交互，各个业务系统会使用httpclient框架向upms系统发送验证信息，同时会将用户的权限信息与session状态存储于redis中，用户的下一次业务请求会先走redis获取权限信息进行权限判断，当redis中没有获取到再去upms系统中获取权限系统，降低upms系统的负载 。   |

## 系统引入技术

| 功能        | 技术    |  背景介绍  |
| --------   | -----:   | :----: |
| 动态规则引擎        | Groovy&Java动态编译执行     |工作中，遇到部分业务经常动态变化，或者在不发布系统的前提下，对业务规则进行调整。那么可以将这部分业务逻辑改写成Groovy脚本来执行，那么就可以在业务运行过程中动态更改业务规则，达到快速响应。    |
| 客户端一致性Hash        | 提取jedis的一致性Hash算法源码作为通用组件     |数据的请求处理以及落入数据库，均会有热点问题，提取jdesi的一致性Hash算法使得该功能不局限于redis,可以用在mysql分表路由，mysql分库选择上，极大的提高灵活程度。自动识别新增和宕机节点，做到不停机动态扩容。   |
| 接口幂等通用解决方案        | 基于redis的幂等解决方案     |非幂等接口在处理数据前都要进行幂等判断，使用redis+消息的UUID方式来高度抽离判断逻辑，避免无规则定制化的嵌入每一个非幂等接口，保证系统代码架构的可维护性。   |


## LSM架构
![image](https://github.com/intsmaze/intsmaze/raw/master/image/lsm.png)
### LSM最开始的设计思路
1. 一致性hash维护的64个物理文件夹，同时内存中维护64个跳跃表对应。
2. 写入key-value，通过一致性hash确定所属的文件夹，将该数据存储对应的跳跃表，当跳跃表容量达到阈值后，生成一个新的跳跃表替换写入，老的跳跃表数据序列化到对应文件夹的文件中，文件名称递增。
3. 容灾:写入key-value的时候，append方式追加到日志文件中。（抛弃的方案：恢复的时候根据各个物理文件夹下最新的文件与日志文件的差集就是丢失的数据，将这些数据写入内存的跳跃表。）当将跳跃表的数据成功写入磁盘后，删掉对应的日志文件，日志文件也是随着新增一个跳跃表而递增的。
4. 读取key，通过一致性hash确定所属的文件夹，遍历每一个文件，采用布隆算法快速找到对应数据。
5. 一致性hash就和hbase预分区一个原理，哎。
6. 是否需要对每个数据文件做归并合并？
7. 索引的设计

## 动态加载实时编译类
![image](https://github.com/intsmaze/intsmaze/raw/master/image/classload.png)
### 架构来源
在开发cep系统中，遇到某些规则需要用http的协议向远程服务发送请求获取某些结果后，在运用EL表达式进行校验。这个时候，我么需要编写新的java类来支持这一功能，但是编写java类需要重新停机发布，如何解决停机发布的问题就本架构解决方案。 

## 设计原因
不提供单点登录的原因在于，各个公司子系统很多，单点系统都是现成的，本系统就是提供单点系统，现实中各位用户也不会使用，而是需要对该系统进行定制化开发接入公司的单点系统，所以我设计upms的原因是，本架构如果接入公司单点登录，本架构对外就是一个业务系统，只是内部划分为多个类似微服务系统而已，upms负责进行统一的权限校验，业务系统的不同模块可以采用不同的脚手架进行业务的增删改查，可以加快开发速度。

##动态加载实时编译类
了解CEP规则引擎都知道，业务规则变化复杂，不可能面对变化的规则去不停的修改代码上线发布。不同的活动他们的某些逻辑操作可能不同，比如订单满减活动，可能需要额外去调用其他系统的接口获得返回数据，新用户注册获得中，可能需要额外调用其他存储系统获得一些数据进行处理。我们通常利用接口的多态性，创建对应的订单算法类，用户注册算法类，供对应的活动去调用。
如果此时新增了一个活动，这个活动在配置的同时还需要额外调用其他系统，这个时候我们必须编写代码，然后停机发布。
利用多态，反射，类加载，编译等技术实现了新编写的业务类动态上线，不需停机发布。用户只需要在活动中配置该活动使用的算法类的全路径，开发人员将编写编译通过的jave类文件通过web控制台上传到mysql,用户将配置的活动上线后，程序会自动从mysql加载该java类执行编译并通过类加载进jvm中，然后结合反射得到类对象，结合多态的特性使得该类得以调用执行。