巨石项目

巨石项目

巨石项目总览

巨石项目中，包含一个汇总型的项目，汇总所有的子模块应用，统一打包成一个war对外发布出去。子模块包含下面的目录结构：

1. 实体层，即传统三层架构中的数据实体。
2. 数据访问层：即传统三层架构中的数据访问层。
3. 业务层：传统项目中的业务层。
4. 视图层：对外提供API接口，进行数据交互。

由于项目使用的是Spring + Spring MVC + Spring Data Jpa，因此为了使得相关配置生效所以声明了如下配置：

1. @EnableJpaRepositories：使用自己定义的Repository而不是Spring Data Jpa中的默认Repository实现

   • basePackages：扫描所有的Repository，使其声明成Bean
   • repositoryFactoryBeanClass：配置自定义的Repository的实现，从而为Repository提供额外的方法
2. ComponentScan：该注解在巨石项目中被标注在WebConfig配置类上，我推测其目的是为了使Spring MVC中的Bean生效，但实际上他使得子模块项目中的所有Bean配置都生效了。

巨石项目基石功能

巨石项目在一开始，想要提供如下功能：

1. 为数据实现一些字段的自动插入：租户ID、创建人、创建人组织、修改时间等等【实现方式为jpa监听审计实现】
2. 想要实现一些动态查询，方便开发者进行开发：因此实现了一些自定的Repository和Service。【但是说句实在的功能很鸡肋，基本没人使用，也因此造成的项目的臃肿】
3. 获取配置属性：他是使用PropertyPlaceholderConfigurer继承类来完成的，而后将其声明为Bean
4. 获取当前登录人：该功能要求在一个请求中，可以随时随地的获取当前登录人的信息，从而完成查询筛选的实现，它采用的是登录成功之后登录之后手动往shiro中的ThreadContext中进行属性设置。需要注意的是，巨石项目在这里强制假定了当前登录人一定是实实在在的人，即包含租户ID，包含组织用户，包含角色权限等等。

巨石项目的演变

巨石项目在演变过程之中出现过如下，“不适”场景：

1. 由于巨石项目是由多个子模块组成，子模块之间不可避免需要进行数据的交互，比如子模块A需要获取子模块B中的一些数据，由于不同模块的开发人员往往不是同一个，并且想要获取数据的一方，又不愿意自己编写代码进行数据的获取（这种方式是正确的，各个子模块应当保持松耦合，另外从底层物理表操作来说，特定数据表只能由特定模块来操作）。在该巨石项目中的做法是通过面向接口的Bean注入，完成方法的调用。（写到这的时候，我认为这种方式是很合理，但是为什么在开发的时候会如此痛苦，并且出现了很多问题呢？）
2. 后来巨石项目又发展成两个巨石项目，即逻辑上划分的前台与后台系统，对于前台系统而言，其一些功能依赖于后台项目的数据，因此由给出的解决办法是通过http远程接口访问来完成的，这种方式同样有一些令人苦恼的地方，比如说两个项目之间接口访问的安全性，接口访问的数据转化（解析中出现异常，解析成特定的实体）。
3. 以两个巨石项目为基础，从而演变成来诸多小巨蛋，之所以叫做小巨蛋，主要由于其项目规模不大，并且可以单独放在一个进程中运行，但是由因为其依赖于巨石项目，因此我称之为小巨蛋。小巨蛋项目中的问题，与两个巨石项目中的问题类似，比如接口访问的安全性、远程调用时异常处理等。

巨石项目中一些分布式问题

1. 接口之间调用的安全性：前台项目需要调用后台受限的接口（限定特定人或者应用才能进行访问）前台的调用者物理身份会是一些物理设备，如电子屏幕，也有可能是与后台用户身份不符合的用户，比如后台用户身份是教师，而前台的用户身份是学生，甚至是校外学生。这里的问题可以描述为越权，在特定业务场景下，我们需要允许一些不合理的用户（不合理用户指，认证不通过）访问我们的特定接口（而不是允许他访问所有接口）。
2. 分布式任务调用：分布式任务调度，巨石项目后期由于发展成两个巨石项目，甚至包含小巨蛋项目，但是由于设计初期没有考虑到分布式结构，所以导致巨石项目中的任务调度进场出现问题。问题描述如下：任务调度在后台进行配置【甚至是使用SQL语句进行初始化】，但是任务的执行逻辑单元在前台，（后台配置，前台执行），因此需要区分，调度任务在哪个单元并且有该单元的调度任务进行配置。其次就是任务逻辑用到的参数需要外部设置。
3. 分布式场景下的日志管理：巨石项目的日志管理，起初我以为是为了开发者服务的进行一些数据排查，然而等功能完全实现之后，发现日志是给用户使用，因此其文本排版很讲究，包含差不多类似这种：A字段修改前：{}, 修改之后：{}. B字段修改前：{}, 修改之后：{}，类似这种，由于使用AOP虽然可以获取到修改前后的值，但是却不能获取中间结果值，因此为了获取中间结果值，只能够入侵他人的代码，使其定制化画自己的日志内容。使用AOP原本是为了不侵入他人的代码完成功能实现，但最终演变这种样子，是我始料未及的。【写道到这里的时候，我很向往那些可以使用ELK技术栈来统计日志的】
4. 分布式场景下用户登录统计：巨石项目的用户登录统计最大的难点就是与原安全认证进行“契合”。首先巨石项目分裂成两个巨石项目，似乎登录处于两个不同应用当中，又因开发leader比较反感在项目中引入分布式组件，比如redis，mq等，所以经常造成在线人数统计个数出现问题。