java平台技术架构分层,分布式架构下为什么要分层[ 技术与架构 ]

前言

分布式架构下如果你的服务没有分层，那么不应该叫分布式架构。有了分层更好的解决服务依赖问题。提高管理效率，开发效率，运维效率

不分层

当只有两个服务的时候，好好看的清楚，当有四个服务相互依赖的时候，已经晕了

当你有更多服务的时候.....你会？想死，

生产者与消费者分层

分生产者与消费者之后，依赖关系更加明确了，管理起来更加简单了。看下图依赖关系是不是很明确了，模块直接基本做了依赖解耦了，也方便业务解耦

生产者与消费者，不是绝对的一一对应的。

这里请问下大家图中的消费者的模块为什么分为用户模块与登录日志模块

生产者不能调用生产者，消费者也不能调用消费者。意思就是同层之间不允许相互调用，一旦相互调用，等于没有分层了。

生产者消费者可以有不同人开发

分层有利于业务演进，分离，解耦,

当系统体量大了怎么办？

曾经经历过一个大型电商项目，业务及其复杂，对高性能，高并发要求极高。实在无法进行拆分了。于是在消费者之上加一层业务层，解决了上述问题。

这个方式是不是有点像中台的模块架构。哈哈。

部署目录规范

不部署在/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

业务架构与基础组建的关系

业务模块应该按需加载基础组建，不写到业务模块里面，也不应该全部依赖。按需加载依赖就行了。