这篇文章主要介绍“数据库分布式架构下为什么要分层”，在日常操作中，相信很多人在数据库分布式架构下为什么要分层问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”数据库分布式架构下为什么要分层”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
分布式架构下如果你的服务没有分层，那么不应该叫分布式架构。有了分层更好的解决服务依赖问题。提高管理效率，开发效率，运维效率
当只有两个服务的时候，好好看的清楚，当有四个服务相互依赖的时候，已经晕了
当你有更多服务的时候.....你会？想死，
分生产者与消费者之后，依赖关系更加明确了，管理起来更加简单了。看下图依赖关系是不是很明确了，模块直接基本做了依赖解耦了，也方便业务解耦
生产者与消费者，不是绝对的一一对应的。
这里请问下大家图中的消费者的模块为什么分为用户模块与登录日志模块
生产者不能调用生产者，消费者也不能调用消费者。意思就是同层之间不允许相互调用，一旦相互调用，等于没有分层了。 
生产者消费者可以有不同人开发
分层有利于业务演进，分离，解耦,
曾经经历过一个大型电商项目，业务及其复杂，对高性能，高并发要求极高。实在无法进行拆分了。于是在消费者之上加一层业务层，解决了上述问题。
这个方式是不是有点像中台的模块架构。哈哈。
不部署在/home下的用户目录，这样不利于扩展维护等
在/（根） 目录下创建属于自己的目录。分别创建消费者，生产者，业务方三个目录
在对应目录下为服务创建各自的服务名
在服务目录创建log目录用于存放日志，config存放配置文件
. ├── business │ └── user │ ├── config │ └── log ├── consume │ └── user │ ├── config │ └── log └── producer └── user ├── config └── log
entity
entiry子模块里面存放数据库实体类，TDO。（个人不喜欢什么VO，TDO，DDO，项目就那么大，搞那么复杂干什么细节请看这种 博客管理与技术之方法（接口）行参与返回请用实体类）
common
工具模块，只要有两个功能。1. entiry里面实体类，TDO之间的转换。2. 写一些不通用或者工具库里面没有工具方法。当有时间了会把common里面的工具方法，加入到工具库里面。保证common的单一性
service Interface
provider子模块提供的服务接口，由consumers 或者task 调用
provider
服务提供者，只有被consumere或者task调用之外任何服务都不能调用。
consumers
服务消费者，可以被business调用或者直接被外部app调用
service-consumers
consumers子模块提供的服务接口，business 调用
business
业务层
task
定时任务子模块，不应该和provider与consumers 耦合。provider与consumers通常会部署多个，而task绝大部分情况只部署一个。如果与provider何consumers 耦合。你可能需要修改每个的配置，如果忘记修改造成启动多个task或者没有启动task里面的任务，会造成致命的问题。
包路径应该定义为:
com.dome.user.entity
com.dome.user.common
com.dome.user.service
com.dome.user.provider
com.dome.user.consumers
com.dome.user.service-consumers
com.dome.user.business
com.deme.user.task
业务模块应该按需加载基础组建，不写到业务模块里面，也不应该全部依赖。按需加载依赖就行了。
到此，关于“数据库分布式架构下为什么要分层”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注亿速云网站，小编会继续努力为大家带来更多实用的文章！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
