028-86261949

当前位置:首页 > 技术交流 > 微服务架构-数据字典设计

微服务架构-数据字典设计

2021/02/02 17:49 分类: 技术交流 浏览:0

微服务架构-数据字典设计

1.1 为什么需要数据字典

 在系统中某些选项是几个特定的值的一个或多个,并且随着还可以动态添加。比如支付方式,配送方式等

 

 此时我们应该设计一个数据字典模块,在后台进行管理,然后前台要从后端查询。并且由于我们可能有多个类型,每个类型可能有多个选项。所以,后台数据库表设计就包含数据字典类型或数据字典明细两张表。具体设计如下:

 

  1. 数据字典类字段说明
    1. id 唯一主键。
    2. sn 标识 非常重要,前台就是通过他来查询某一类型的数据字典的。
    3. name 名称,用来显示用的。
  2. 数据字典明细字段说明
    1. id 唯一主键。
    2. name 名称,用来显示用的。
    3. types_id 外键类型id,多个数据字典明细对应一个数据字典类型

 

1.2 单体架构数据字典设计

 正常来说,后端提供通过类型查询明细的接口,前端就可以完成调用并展示,但是由于数据字典数据是经常查询并且很少修改的,所以我们可以给他缓存到redis中提升效率。具体流程如下:

 

1.3 微服务架构数据字典设计

1.3.1 方案1 单独一个微服务并缓存优化

 前端通过网关调用系统中心进而获取到数据字典,并且把数据字典数据缓存到Redis中提升效率。

 

 问题1:每个服务调用系统中心数据字典都是远程调用效率低

 问题2:微服务架构一般都是大型项目,管理的数据字典越变越多,最终很难管理。

1.3.2 方案2 不需要数据字典

 正式基于以上两个问题所以我们不设计数据字典,但是就会产生以下两个问题:

  1.  前端哪些数据怎么来呢?

前端和后端预定好每个选项对应什么值,然后前端直接写死,后端就可以使用枚举来包装具体值。

 

  1.  如果数据有变更怎么办

       如果后面数据字典数据发生改变后,如果有数据字典只需要在后台更改就好,但是现在没有数据字典了。怎么办呢?

       其实由于我们是微服务架构,每个微服务都是独立技术选型、独立开发、独立部署、独立运维的。那么我们只需要修改前后端对应的值,然后对该服务进行独立发布部署而不影响其他微服务。

 

 

小结:所以在微服务架构中直接不使用数据字典,直接前后端写死,如果有变更重新部署发布新版本解决。

1.4 总结

 最终得出结论,在单体架构中项目规模不大,所以数据数据字典的数据不是很多,能使用数据字典,但是最好使用缓存进行优化。

但是在微服务架构中,涉及到远程调用效率低,并且项目规模比较大,管理起来不好管理。直接不使用数据字典,直接前后端写死,如果有变更重新部署发布新版本解决。

#标签:Java,架构,数据,字典