分类：计算机
- oa-backend-framework项目架构设计 - 启动应用
OA系统的启动原理：OA系统在Web容器上注册了一个Servletweaver.general.InitServer。启动Web容器时，会执行InitServer的init()方法，OA系统就在该方法中启动，执行各种初始化操作。 同理，我们也可以在Web容器中注册一个ServletMyApplicationStartupServlet，实现启动： // 使用@WebServlet注解注册Servlet，可以免于修改web.xml。 // loadOnStartup：取最大整数，确保应用在OA系统启动之后才启动。 // urlPatterns：此Servlet不处理HTTP请求，但注解要求必填，所以这里给一个不会与OA系统冲突的路径即可。 @WebServlet(loadOnStartup = Integer.MAX_VALUE, urlPatterns = "/my") public class MyApplicationStartupServlet extends HttpServlet { @Override public void init() { // 启动应用程序，执行初始化 } } 应用启动时执行的初始化过程： 打印应用logo，类似于Spring Boot，这可以让我们在日志中更显著地看到应用启动。 初始化数据源。 初始化IoC容器。 对OA系统进行配置，例如动态注册免用户身份检查的API路径前缀（unchecksessionurl）。
- oa-backend-framework项目架构设计 - 总体架构
总体思路上，我们要做一个相对独立的后端应用程序。 这个应用具有独立的分层设计，主要分层如下： 业务请求入口： 控制器层：接收来自Web API的业务请求。控制器类会注册到Web容器中。虽然API主要都写在我们的Spring Boot项目中，而不是写在这里（因为很麻烦），但仍然有部分涉及OA系统的API必须写在这里。 流程动作层：接收来自OA系统的执行流程动作的业务请求。流程动作类会注册到OA系统中。 服务层：实现业务服务，是业务逻辑的核心。 数据库层：实现对数据库的读写，支持事务管理。 应用与OA系统运行在同一个JVM中，可以在代码层面与OA系统进行交互。 应用将实现一个开发框架，这个开发框架将做到： 本地运行，方便调试：所有与OA系统非强相关的业务代码，都支持在本地运行，可以在Web容器上运行API，可以通过JUnit运行流程动作。本地运行时，可以方便地通过IDE断点做调试。 打包部署：整个项目可以打成一个jar包，然后整体上传、部署到OA系统中，方便更新和版本控制。 良好封装：框架对与OA系统的交互做良好封装，业务代码完全透明，或只需使用封装后的简单概念和接口，无需自己处理OA系统的复杂细节。 事务控制：一个业务请求（API或流程动作）的所有代码都运行在一个数据库事务中，支持自动提交和回滚。 开发规范：制定合理的开发规范，包括包结构、实体划分、服务粒度等，使业务代码更清晰有序、更可复用、更可维护。 由于本质上仍然是嵌入到OA系统中运行，应用面临如下限制： 部署后仍然要重启OA：必须重启JVM，才能使新代码生效。 三方库有限：应用只能使用OA系统自带的三方库，且必须同版本。为了避免影响OA系统，不允许向OA系统中加入其他三方库或已有三方库的其他版本。
- oa-backend-framework项目架构设计 - 起步
我们的OA系统是泛微的Ecology 9。OA在走流程审批时，经常需要在到达或离开某个流程节点时，将流程中的数据保存到某个位置，或执行其他的业务操作。如果操作很复杂，就需要用代码来实现。OA提供了机制，让我们能写Java代码，部署到OA系统中，然后在流程的指定时机，调用我们的代码。 泛微给了我们这样一个开发框架：一个Java项目，依赖Maven库com.github.liuzhenghui:weaver-ecology-core:9.00.2102.17，这个库提供了Ecology 9的类结构，能编译，但不能本地运行。这个项目主要用来写流程动作和Web API。我们需要按规定在本地写好Java类，编译成class文件，上传到OA服务器中的指定目录，重启OA，然后执行它进行测试。如果要修改，则必须重复上述过程。 这个开发框架存在以下主要问题： 调试困难：不能本地运行，只能在服务器上运行，调试只能靠打印日志。 部署困难：只能逐个上传class文件，不能打包部署。多人、长期各自上传，使得class文件的版本难以控制。更新class文件后，要重启OA才能生效，重启时间很长。这种模式，使得我们不敢多写类，大量的代码挤在一个类中。 缺少封装：业务代码必须直面OA的底层机制，必须手动处理OA的元数据、权限等机制细节，缺少机制文档的情况下很容易出错。每个业务都要重复做这样的处理。 缺少事务控制：多个步骤中间出错时，会导致数据不一致。 缺少开发规范：只提供了与OA交互的基础机制，没有给出合理的程序结构，使得业务代码的组织相当混乱。 近期，我被调入公司新成立的信息部门，负责整个公司内部信息化的技术工作。同时，一个中等规模的独立业务系统需求被提到我们部门，与OA系统强相关。因此，我决定从这里入手，正式开始着手解决已经越来越明显的软件架构问题。 我将发起一个新的软件项目oa-backend-framework，从零开始对其进行架构设计，解决上述问题，积累架构经验，并用这个需求进行实战检验。 为什么不在上述开发框架上修改？已经尝试过了，但该框架与我的设计相差很大，修改势必带来很多冲突，导致两头都做不好。 OA系统本身就有成熟的架构和规范，为什么不遵循之？① 该架构是面向OA系统本身的问题域的，与我们的问题域并不相同；② 我们缺乏足够的文档信息和支持，对其架构和规范知之甚少；③ 基于已经了解到的信息，我们认为，即使遵循之，也无法完全解决上述问题，反而会带来新的麻烦。
- 项目前后期关系算法问题
项目表中存在如下3个字段： 项目编号：当前项目的编号。 前期项目编号：当前项目的所有前期项目的项目编号，包括前期的前期。 后期项目编号：当前项目的所有后期项目的项目编号，包括后期的后期。 数据示例：有A、B、C、D四个项目，关系如下图，存储结构如下表。 前期项目编号 项目编号 后期项目编号 - A B,C,D A B C,D A,B C - A,B D - 需要对系统中现存的项目前后期关系数据做校验、修正、简化、分析。 校验 校验前后期关系数据的完整性、一致性。 算法思想：如果A在B的前期中，则B一定在A的后期中。 # 获取项目列表 projects = ... # 映射表：项目编号 → 项目 map = {project["code"]: project for project in projects} for project in projects: code = project["code"] for previous_code in project["previous_codes"]: if previous_code not in map: print(f"{code} 的前期项目 {previous_code} 不存在") elif code not in map[previous_code]["next_codes"]: print(f"{code} 不在前期项目 {previous_code} 的后期项目中") for next_code in project["next_codes"]: if next_code not in map: print(f"{code} 的后期项目 {next_code} 不存在") elif code not in map[next_code]["previous_codes"]: print(f"{code} 不在后期项目 {next_code} 的前期项目中") 修正 针对校验出的问题，修正办法： 项目编号不存在：可能是项目编号改变了但未同步更新，修正项目编号，修正同步更新机制；如果真的不存在，则确认后删除。 B不在其前期A的后期中：在A的后期中补充B。 A不在其后期B的前期中：在B的前期中补充A。 多次运行校验，直到无错误。 简化 前期、后期字段这么设计，是为了做链接，方便从一个项目跳转到有前后期关系的任意项目，但这给我们分析前后期关系情况带来了麻烦。实际上，项目表中只需要存储项目编号+直接后期项目编号（不包括后期的后期）这两个字段即可，直接前期、所有前期、所有后期都可以通过这两个字段动态计算出来。因此，在校验并修正之后，我们对关系的存储结构做简化。 算法思想：首先确认不存在隔代后期关系，即在A→B→C的场景下，A→C一定是无效的。那么，对于任意一条弧A→B，如果存在顶点P，且同时存在P→A、P→B，则P→B一定是无效的。 # 遍历每一条弧 for project in projects: code = project["code"] for next_code in project["next_codes"]: # 找出同时满足p→code和p→next_code的顶点 for p in projects: if code in p["next_codes"] and next_code in p["next_codes"]: # 删除弧p→next_code p["next_codes"].remove(next_code) 分析 聚类 将有前后期关系的所有项目聚类在一起，构成一个个独立的项目群。 算法思想：求有向图的所有极大连通子图，用并查集实现。 # 项目编号的并查集，简单实现 # 初始每个项目编号是一个集合 disjoint_set = [{project["code"]} for project in projects] for project in projects: code = project["code"] for next_code in project["next_codes"]: # 找出code所在的集合set1 for set1 in disjoint_set: if code in set1: # 找出next_code所在的集合set2 for set2 in disjoint_set: if next_code in set2: # 如果set1不是set2，则合并为一个集合 if set1 is not set2: set1.update(set2) disjoint_set.remove(set2) 算法结束时，并查集中的每个集合就是一个项目群。 图形化 我们希望以图形的方式直观地看到每个项目群中各项目的前后期关系。 Python的networkx+matplotlib库可以实现图（graph）的绘制。绘制时，需要计算顶点的摆放层号，使得绘图结果清晰、美观。 算法思想：对图做拓扑排序，入度为0的顶点被取出的批次，就是顶点的层号。 # 映射表：项目编号 → 项目 project_map = {project["code"]: project for project in projects} # 项目群序号 order = 1 # 遍历项目群 for codes in disjoint_set: # codes表示顶点集合 # 只关注多顶点子图，不关注单顶点子图 if len(codes) > 1: # 弧集合 arcs = [ (code, next_code) for code in codes for next_code in project_map[code]["next_codes"] ] # 映射表：顶点 → 弧尾顶点集合 in_map = {code: set() for code in codes} for arc in arcs: in_map[arc[1]].add(arc[0]) # 映射表：顶点 → 绘图时的层号 layer_map = {} # 拓扑排序，入度为0的顶点被取出的批次，就是层号 layer = 0 while in_map: # 找出入度为0的顶点，得到层号 zero_degree_codes = [ code for code, values in in_map.items() if len(values) == 0 ] for code in zero_degree_codes: layer_map[code] = layer layer += 1 # 删除入度为0的节点 for code in zero_degree_codes: del in_map[code] for values in in_map.values(): values.discard(code) # 绘图 fig, ax = plt.subplots(figsize=(24, 13.5)) graph = nx.DiGraph() graph.add_nodes_from(codes) graph.add_edges_from(arcs) for code in codes: graph.nodes[code]["subset"] = layer_map[code] positions = nx.multipartite_layout(graph) nx.draw_networkx_nodes(graph, positions, ax=ax, node_size=10000) nx.draw_networkx_edges(graph, positions, ax=ax, arrowsize=20, min_target_margin=50) nx.draw_networkx_labels(graph, positions, ax=ax, font_color="white") ax.axis("off") plt.savefig(f"output/项目前后期关系图/{order}.png") plt.close(fig) order += 1 算法缺陷：由于networkx按顺序绘制顶点，因此存在弧交叉、弧穿越顶点的问题，但总体上绘图结果还是很好的。
- OA系统实现复制建模布局
做一个复杂的需求，要求对于同一份建模数据，不同的用户在新建、编辑、查看时使用不同的布局。实现时，先做一个完整的母版布局，然后复制出用户布局并修改。Ecology 9没有提供复制建模布局的功能，因此我们自己实现。 为了避免使OA系统出现未知的问题，我们限定，只允许在同一个模块内，复制一个已存在的布局到另一个已存在的布局。 从接口/formmode/exceldesign/excelLayoutSave.jsp?operation=saveExcel出发，逆向分析OA系统保存建模布局的机制，得出结论，只需复制以下表的数据即可实现复制建模布局： 表 数据内容 复制方式 modehtmllayout 布局自身的信息，例如布局设计、代码块等 update，注意保留布局名称 modeformfield 布局的字段信息，例如是否必填等 先delete再insert，注意复制到显示布局时字段全部变为只读 modefieldattr 布局的字段属性信息，例如计算日期差等 先delete再insert modeformgroup 布局的明细表信息，例如是否允许增行等 先delete再insert，注意复制到显示布局时关闭修改的相关配置 mode_layout_querysql 布局的明细表的固定查询条件 先delete再insert mode_layout_sortfield 布局的明细表的字段排序信息 先delete再insert
- oa-codeblock项目架构设计 - JS文件包含
最近在开发一个非常复杂的需求，代码量巨大，为了清晰起见，必须拆分成多个JS文件，然后有序地组合起来。开发框架目前只支持将代码写在单个JS文件script.js中，因此需要修改。 考虑历史代码兼容性和开发周期，我决定采用一种简单的实现方案：文件包含。类似于C语言中的#include，我们在JS文件中做特殊标记，表明要将另一个JS文件的内容包含进来，然后在构建时用指定JS文件的内容替换这个特殊标记，这样就实现了分开编写、组合运行。 文件包含标记：在JS文件中用如下标记表明要包含哪个JS文件： //#include: A/B/C/xxx.js 解析文件包含： 迭代解析：A包含B，B包含C，通过迭代算法可以实现正确的链式包含。算法：循环检查A中是否还有包含标记，有则对第一个包含标记（B）执行替换，此时，如果替换的内容中带进来了新的包含标记（C），则会在下一次循环中被解析。 防止循环包含：迭代解析的过程中，要记住走过的文件有哪些，一旦发现要包含的文件之前已经走过，就说明出现了循环包含，报错。 动态监听：一个脚本文件现在可以拆分为多个文件，这多个文件又随时可能修改、增加、删除，则对于持续构建模式来说，要监听变化的文件范围是动态的。每次构建一个脚本文件时，都要重新计算并监听涉及的文件。 有了文件包含机制，我们就可以获得以下好处： 将单个复杂的任务分解为多个简单的任务，提高了清晰度、可维护性。 可以实现公共代码，免于复制粘贴，提高了代码复用度。 在OA系统的代码块机制中，多个<script src="...">之间的执行顺序是随机的，通过在同一个文件中控制文件包含的顺序，我们就可以严格控制多个脚本间的执行顺序。 文件包含机制也有其缺点： IDE不识别：标记是我们自己定的，IDE并不知道要包含哪个文件、文件间的顺序等信息，也就无法提供文件跳转、准确的代码提示等功能。 作用域不隔离：文件包含本质上是将代码拼在一起，是同一个作用域，并没有实现真正的JS模块化。编写代码时需要对这一点有清晰的认识，如果需要模块化，则必须自己用IIFE等手段实现。 不太容易理解：我开发的这个非常复杂的需求，其他同事在阅读代码时，不太容易跟踪和理解同一作用域、多层包含下的执行过程。 这些缺点，未来可以通过用Webpack实现真正的JS模块化来解决。
- OA系统前端逆向工程
泛微OA系统Ecology 9的前端程序是经过编译、压缩后的JavaScript文件，为了深入研究其机制细节，我们对其做逆向工程，将压缩的JS代码还原为非压缩的JS代码，并对其进行分析、理解。 建立一个项目oa-frontend-reverse-engineering，将线上的JS文件下载下来，按相同的目录结构放在项目中。然后在本地用nginx做反向代理：如果一个JS文件在项目中，则取项目中的，否则取线上的。nginx配置如下： server { listen 80; listen [::]:80; server_name oa-frontend-reverse-engineering; root "<项目目录>"; location / { # 如果本地存在文件，则取本地文件 # 否则，通过反向代理，取OA系统上的文件 try_files $uri $uri/ @reverse_proxy; } location @reverse_proxy { proxy_pass http://<OA系统的IP地址>$request_uri; } } 浏览器通过http://oa-frontend-reverse-engineering/可以正常访问OA系统，其中部分JS文件取自本地，于是，我们不仅可以阅读代码，还可以通过实际执行、断点调试来深入理解细节。 注：后来Chrome系浏览器在DevTools的“源代码”功能中增加了“替换”功能，可以直接用本地JS文件替换指定的线上JS文件，这比做nginx反向代理更简便。以下是阅读、还原压缩的JavaScript代码的方法和经验： 第一步：用代码格式化工具（例如VSCode）将压缩的JS代码格式化为缩进良好的版本。 写注释。 利用编辑器、IDE的重构功能，将变量改为有意义的名字。 利用编辑器、IDE的代码跟踪功能，跳转到相关的上下文。但JS代码由于动态性高，通常难以跳转，转而利用搜索功能，用函数名、特殊字符串等关键信息查找上下文。 在分析过程中，熟悉!0、&&、||、模块化等常见的编译结果模式，理解JS语法原理，还原为对应的正常写法。 断点调试，跟踪执行。 临时改写代码，将某些对象、数据、函数暴露到window上，在控制台中查看、修改、执行之，这对状态存储数据尤其有用。 注意：还原出来的JS文件只允许用于分析，不允许替换线上的JS文件。
- OA系统后端逆向工程
泛微OA系统Ecology 9的后端程序使用Java语言开发，为了深入研究其机制细节，我们对其做逆向工程，将class文件反编译为Java源代码，并对源代码进行分析、理解。 反编译 Ecology 9的class文件都存放在classbean目录中。从服务器上将classbean目录整体下载到本地，然后使用JetBrains IntelliJ IDEA附带的反编译器FernFlower，将classbean目录整体反编译到src目录： java -cp '<IDEA安装目录>\plugins\java-decompiler\lib\java-decompiler.jar' org.jetbrains.java.decompiler.main.decompiler.ConsoleDecompiler -dgs=true .\classbean\ .\src\ 代码分析 反编译出来的源代码并不是原始代码，它的类名、属性名、方法名、字符串等都保留了意义，但所有的方法参数、局部变量都是形如var1、var2的无意义形式，也没有任何注释。 我们建立一个Git仓库oa-backend-reverse-engineering，将反编译出来的源代码放入其中管理，因为我们会在阅读的过程中修改它。我们同时将WEB-INF/lib目录（OA系统的三方库）放入其中，使类库整体完整，以便IDE识别。 以下是阅读、分析反编译出来的Java源代码的方法和经验： 写注释，包括文档注释、行注释等。 利用IDE的重构功能，将局部变量改为有意义的名字。 利用IDE的代码跟踪功能，跳转到相关的上下文。 在浏览器DevTools中提取API路径的关键词，在IDE中搜索，定位到起始执行点。 对最常见的类，如BaseBean、RecordSet，做完整分析，加深理解。 对最常见的架构设计，如命令（command）设计模式，做架构分析，加深理解。 注意：反编译出来的Java源代码只允许用于分析，不允许重新编译后替换线上的class文件。
- OA系统热更新Java类
我们的Java类在OA系统中运行时，如果发现bug，因为白天有大量用户在使用，无法重启JVM，就只能半夜更新代码并重启，故障处理时间很长。经研究，部分bug完全可以在白天通过热更新手段迅速修复。 工具：Arthas（阿里巴巴开源的JVM热更新工具）。 热更新要求：类不能增减字段、方法，只能修改方法的执行过程。 热更新过程： 本地修改Java代码，编译成class文件，上传到OA系统中，覆盖问题class文件（避免下次重启仍加载问题class文件）。 启动Arthas，选择名称为Resin的Java进程（OA系统的Web容器）。Resin进程可能有多个，在Arthas连接到进程后，通过jad com.company.<Tab键>来判断进程中是否有我们的Java类，从而确定是OA系统的进程。 在Arthas中执行命令retransform <class文件的路径>，尝试热更新。如果看到输出success，则成功，否则失败。注意不要使用redefine命令。
- 清除OA系统的表缓存
OA系统在读写数据库时，会对各表维护缓存，以提高性能。实际业务中，我们经常要在OA系统之外写库，此时OA系统中的表缓存可能是陈旧的，这会导致数据不一致。因此，我们需要清除OA系统中指定表的表缓存的功能。OA系统未提供这种功能，我们要自己想办法开发出来。 原理 通过逆向工程分析OA系统的表缓存机制。 RecordSet的executeQuery()和executeUpdate()最终都是执行executeSql()。在executeSql()中，以"select"开头的SQL会先尝试从缓存获取结果，非"select"开头的SQL不会。在未命中缓存的情况下，SQL执行成功后，会调用CacheFactory的refreshCache()更新缓存。 在CacheFactory的refreshCache()中，如果SQL以"select"开头，则调用putCache()更新指定表的缓存的一部分；如果SQL非"select"开头，则调用removeCacheForSql()清除指定表的所有缓存。 那么，想要清除指定表的缓存，就只需要执行一条非"select"开头的、包含指定表名的SQL语句，比如写库SQL，但更安全的办法是执行desc 表名。 实现 实现APIclearTableCache，接收参数tableNames。遍历表名，对每个表名通过RecordSet的executeQuery()执行SQLdesc 表名。