概述
在实际项目中，曾遇到过一些关于微服务下的数据库表设计实战经验,在此记录：
系统架构情形:N个微服务，每个微服务访问 1~N个数据库
1.在微服务的架构下，数据字典表应该摆放在哪个库，由于一些数据字典的值会被多个微服务所公用，而在调用微服务获取业务表的列表时，会常常遇到翻译字典的情况，这样就会遇到一个问题，例如：现在有一个企业招聘网站，需要列出所有求职者的简历，而简历上面有性别(男，女) 群体属性(贫困，残疾，扶助)等十几个和数据字典有关的字段，如果这时我的表设计成存放数据字典的key，那么我每次list所有字段的时候就要通过另外的微服务接口去获取相应的翻译字段，当然我可以通过缓存来解决之后的问题，但这种方式显然不是我想要的。这里对于数据字段我们可以采用大表原则来解决问题，由于数据字典一般不会经常改动，而且也不开放给用户随意修改，所以这里可以在业务表中直接存放value而不是key，这样就可以减少表关联或服务接口访问。
2.对于一些用户有可能时常改动的键值对时，发生list翻译时只能通过提早缓存的方式再去遍历(分页后)
最后
以上就是欢呼小熊猫为你收集整理的微服务表设计探讨的全部内容，希望文章能够帮你解决微服务表设计探讨所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。
本图文内容来源于网友提供，作为学习参考使用，或来自网络收集整理，版权属于原作者所有。
发表评论 取消回复