我是靠谱客的博主 动人帽子,最近开发中收集的这篇文章主要介绍微服务难点:基础数据如何设计,为做到共享,我们这样做第一:传统系统设计第二:微服务中基础数据痛点第三:为做到共享,我们这样做,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

目录

第一:传统系统设计

第二:微服务中基础数据痛点

第三:为做到共享,我们这样做


微服务难点:基础数据如何设计,为做到共享,我们这样做

 

从15年开始接触微服务,到现在20年,小编已经差不多做了4年多,如果算上加班时间的话,那就差不多有6年了。这几年从刚开始的摸索,服务切分,说出来可能不行,刚开始我们尝试过三层结构进行切分,但是不到一周就全部推翻,基于现在的领域设计来做切分,这几年实践起来也非常好。

但是,小编遇到的最大的问题并非技术上或者业务切分上,而是一个毫不起眼的东西,基础数据模块

基础数据模块,并不复杂,无论是数据模型还是业务定向,都不复杂,我们一般设计为独立的模块,用于存放那些基本上都不会动的数据,像国家,城市,数据字典等,但是就这些小东西,刚开始却非常纠结。

 

微服务难点:基础数据如何设计,为做到共享,我们这样做

 

 

第一:传统系统设计

在传统系统中,都是基于单体设计,一个系统加上一个数据库,没啥量的内部系统,就是业务复杂,这时候我们在设计的时候,会直接把基础数据全部放在数据库里面,无论是取数据或者联表查询的时候,都非常方便,这时候不用考虑太多问题。

前台页面根据需要进行添加,删除,更改即可。

 

微服务难点:基础数据如何设计,为做到共享,我们这样做

 

 

第二:微服务中基础数据痛点

微服务来了,这是个非常好的东西,小编不否认,同时也非常赞同。

服务架构设计中,采用领域设计的思想,对业务进行切分,对鉴权进行分离,但是恰恰这个基础数据,要如何设计?成了小编一时的难题,总结起来,需要解决下面4个问题

1、数据共享问题:在基础数据的设计理念上,本质上就是要达到一个目的,基础数据提供给所有的服务使用,数据要做到所有服务共享,如何做?

 

微服务难点:基础数据如何设计,为做到共享,我们这样做

 

 

2、多服务共享问题:几乎所有的企业,都会存在老系统,新系统共存的情况,那此时老系统上面的基础数据如何与新系统实现共享?难道我需要维护很多系统的数据吗?

3、联表查询问题:在基础数据的设计中,存在一种情况,把基础数据独立出来,标准化的API出去给人使用,但此时出现个问题,很多系统在进行联表查询的时候,都需要join基础数据,不同的库,此时非常难。小编遇到过采用join两个库的情况,但是并不赞同,性能上很考验人,那怎么做?

 

微服务难点:基础数据如何设计,为做到共享,我们这样做

 

 

4、前台查询问题:现在基本上都是前后端分离,在前端查询的时候,一般都是经过网关,此时面对着前端上很多的基础数据,有采用json文件做法,有采用直接调用后端服务的做法。

此时我们来分析一下,采用json文件,那此时跟数据库层面的数据形成了两套,维护量起来了,运维工程师要炸。

那采用直接调用后端的基础数据服务呢?网络请求是个问题,毕竟要经过网关,再到基础数据服务,如果不考量网络效能问题,可以考虑这种做法,前端文件做法也可以

这里小编赞同这两种方法,但是有没有更灵活一些的方式?尽可能的减少运维工程师的量,也尽可能减低手动出错的概率?

 

微服务难点:基础数据如何设计,为做到共享,我们这样做

 

 

第三:为做到共享,我们这样做

1、服务隔离数据设计:为做到基础数据共享,还是继续考虑采用独立的数据模块设计,独立数据库加上独立服务,对外提供标准化的AIP,不变。考虑到新老系统的基础数据存在数据差异性,例如数据字段性别这个字段,新系统男是1,女是2;但是老系统刚好相反,男是2,女是1;针对这种情况,我们在设计上引入了服务ID这个隔离标记,这个服务ID是用来标记这些数据是对应哪个系统

2、数据移动化设计:在上面的设计中,很多同学发现了,存在联表查询问题,这里小编想起以前java刚开始兴起的时候,有一句话:一次编译,到处运行。那为了解决这个问题,我们对数据的存量设计进行了优化,叫做数据移动化设计。

在互联网设计中,经常会采用数据缓存,来尽可能避免join所带来的性能损耗,这里的思想一样,用空间换时间每一个业务数据库都会存在不可更改的基础数据表。这里要强调,这些基础数据表的作用:不可更改,只提供联表查询操作

 

微服务难点:基础数据如何设计,为做到共享,我们这样做

 

 

3、数据异步化维护:在采用了数据表缓存到各个业务库后,维护成了一个大问题。这里要借助我们强大的MQ来实现。一个基础数据服务建成后,除了对外提供标准化的API,还提供了一个基础数据接收包。这个基础数据接收包主要就是连接并监听MQ的基础信息,只要基础数据库的数据发生变化,所有业务数据库上的基础数据都会同步到,来避免数据不一致问题。

4、数据缓存化设计:现在前后端分离,前端只做页面展示,最快的方式肯定是请求网络,文件的方式虽然快,但运维是个问题,这时候,我们考虑的时候缓存化设计。在设计中,数据采用redis进行缓存,redis直接与nginx进行连接,这样子,前端在进行请求的时候,直接请求的是redis上的数据,这样子用来解决网络效能问题。这里的方案是默认前端部署在nginx上,如果部署在tomcat上,原理是一致的。

 

微服务难点:基础数据如何设计,为做到共享,我们这样做

 

有关微服务的架构设计许多,小编相信架构是不断演化的,不断根据不同的业务进行改进的。也许今天这套很好,明天那套就更好。

天下合久必分,分久必合,软件架构设计也是一样,理想是美好的,但是现实是骨感的,小编始终相信会有更好的方案,欢迎关注 @溪云阁 ,有什么问题欢迎私信探讨。

 

微服务难点:基础数据如何设计,为做到共享,我们这样做

 

 

--END--

欢迎关注头条号:@溪云阁

最后

以上就是动人帽子为你收集整理的微服务难点:基础数据如何设计,为做到共享,我们这样做第一:传统系统设计第二:微服务中基础数据痛点第三:为做到共享,我们这样做的全部内容,希望文章能够帮你解决微服务难点:基础数据如何设计,为做到共享,我们这样做第一:传统系统设计第二:微服务中基础数据痛点第三:为做到共享,我们这样做所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(35)

评论列表共有 0 条评论

立即
投稿
返回
顶部