模型服务架构

什么是模型

模型就是对数据、业务、约束等的建模，它规定了系统的数据格式，数据结构，甚至是数据约束。DB建表需要模型，增删改查需要模型，数据校验需要模型，数据间依赖关系需要模型，这是一个动态模型软件的核心组件。
一般来说，建模使用XML、JSON、YANG等语言。

模型框架解决问题

1. 解析模型文件，向各应用提供动态模型服务（模型客户端和模型公共api）
2. 根据模型动态更新DB表结构
3. 支持分布式环境
4. 在模型客户端和模型加载服务中，通过流水号持久化，来保证模型一致性（弱）
5. 模型服务端不持久流水号，只缓存，有变更时，和模型加载服务做流水同步
6. MQ服务down掉重启后，模型框架自动重连（发送方和接收方）
7. 客户端和服务端初始化时，启动定时器（不断尝试）发送RESTful请求，防止被请求方未启动
8. 对不同的MQ消息分类处理（加载慢，删除快）
9. 对模型中的国际化信息（i18n）进行服务端缓存，客户端RESTful获取，来减少模型客户端在应用服务的内存消耗

整体架构

服务端架构

客户端架构

类似于服务端中的model-app，完成模型MQ处理，模型更新和存储，流水号持久化等。

存在的问题

1. 单线程执行，多个模型加载时需要排队
2. MQ消息存在丢失可能，比如MQ服务down掉，并未做主动保护（如心跳检查）
3. 加载效率未做测评
4. 模型加载或删除时，“锁”住了整个客户端或服务端的模型访问，未做分离

总结

整个服务4400行代码左右，是我工作以来做的最用心的一个模块。技术上使用了几个经典的设计模型（单例、工厂、命令、模板）等，业务上进行了分治和递归，化繁为简。并且在UT中，做了功能性的FT测试，来保证每一次代码更改的功能正确性。框架中使用了hk2对象注入，UT中在JC手工完成这一功能的前提下，我也做了2次开发，收获颇丰。