目录
从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--
欢迎关注头条号：@溪云阁