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

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

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. 前端哪些数据怎么来呢？

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

   

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

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

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

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

1.4 总结

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

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