这篇文章主要介绍“数据库分布式架构下为什么要分层”，在日常操作中，相信很多人在数据库分布式架构下为什么要分层问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”数据库分布式架构下为什么要分层”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
网站建设、成都网站设计服务团队是一支充满着热情的团队，执着、敏锐、追求更好，是创新互联的标准与要求，同时竭诚为客户提供服务是我们的理念。创新互联把每个网站当做一个产品来开发，精雕细琢，追求一名工匠心中的细致，我们更用心！
前言
分布式架构下如果你的服务没有分层，那么不应该叫分布式架构。有了分层更好的解决服务依赖问题。提高管理效率，开发效率，运维效率
不分层
当只有两个服务的时候，好好看的清楚，当有四个服务相互依赖的时候，已经晕了
当你有更多服务的时候.....你会？想死，
生产者与消费者分层
分生产者与消费者之后，依赖关系更加明确了，管理起来更加简单了。看下图依赖关系是不是很明确了，模块直接基本做了依赖解耦了，也方便业务解耦 
生产者与消费者，不是绝对的一一对应的。
这里请问下大家图中的消费者的模块为什么分为用户模块与登录日志模块
生产者不能调用生产者，消费者也不能调用消费者。意思就是同层之间不允许相互调用，一旦相互调用，等于没有分层了。 
生产者消费者可以有不同人开发
分层有利于业务演进，分离，解耦,
当系统体量大了怎么办？
曾经经历过一个大型电商项目，业务及其复杂，对高性能，高并发要求极高。实在无法进行拆分了。于是在消费者之上加一层业务层，解决了上述问题。 
这个方式是不是有点像中台的模块架构。哈哈。
部署目录规范
不部署在/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
业务架构与基础组建的关系
业务模块应该按需加载基础组建，不写到业务模块里面，也不应该全部依赖。按需加载依赖就行了。
到此，关于“数据库分布式架构下为什么要分层”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！
网页标题：数据库分布式架构下为什么要分层
转载来源：
http://www.cdkjz.cn/article/jdoodp.html
