前言：本文旨在简单介绍DS的概述和架构上的设计，对其安装等不做展开介绍。之前了解了一下，很多小伙伴也在使用该产品。我呢，也是到现在公司后才开始接触并使用，对其 “开发” 的还不够深，这里根据官方文档和项目中的实践和大家简单分享。欢迎大家批评指正，敬礼！

一、简介

DS是分布式易扩展的可视化工作流任务调度平台。

Apache DolphinScheduler是一个分布式去中心化，易扩展的可视化DAG工作流任务调度平台。致力于解决数据处理流程中错综复杂的依赖关系，使调度系统在数据处理流程中开箱即用。

二、架构图

三、架构设计

1、名词解释

1.1、DAG：

​ 相信大家对这个次并不陌生，在spark和flink中都有这个定义。在DS中，工作流中的Task任务以有向无环图的形式组装起来，从入度为零的节点进行拓扑遍历，直到无后继节点为止。举例如下图：

1.2、任务类型：

​ 目前支持有SHELL、SQL、SUB_PROCESS(子流程)、PROCEDURE、MR、SPARK、PYTHON、DEPENDENT(依赖)，同时计划支持动态插件扩展，注意：其中子 SUB_PROCESS 也是一个单独的流程定义，是可以单独启动执行的。举例如下图：
注：左侧边栏看大的都是可调度执行的组件，畅用无限~

1.3、调度方式：

​ 系统支持基于 cron 表达式的定时调度和手动调度。

​ 命令类型支持：启动工作流、从当前节点开始执行、恢复被容错的工作流、恢复暂停流程、从失败节点开始执行、补数、定时、重跑、暂停、停止、恢复等待线程。其中 恢复被容错的工作流 和 恢复等待线程 两种命令类型是由调度内部控制使用，外部无法调用。举例如下图：

1.4、依赖：

​ 系统不单单支持 DAG 简单的前驱和后继节点之间的依赖，同时还提供任务依赖节点，支持流程间的自定义任务依赖。说到依赖想重点和兄弟们讨论下这个问题，但是文字表达起来比较费劲，希望各位兄弟可以留言，咱们针对具体问题一起聊聊。

1.5、补数：

​ 补历史数据，支持区间并行和串行两种补数方式

1.6、邮件告警：

​ 支持 SQL任务 查询结果邮件发送，流程实例运行结果邮件告警及容错告警通知

下图：是单独执行任务时进行的相关配置，我个人感觉补数功能是比较牛X的，用好系统时间的变量，造作起来吧（我也是这两天遇到了这样的需求，才 “开发出了这个功能”）。欢迎兄弟们一起讨论。

2、系统架构

2.1、系统架构图

2.2、架构组成、简介

• MasterServer

  MasterServer采用分布式无中心设计理念，MasterServer主要负责 DAG 任务切分、任务提交监控，并同时监听其它MasterServer和WorkerServer的健康状态。 MasterServer服务启动时向Zookeeper注册临时节点，通过监听Zookeeper临时节点变化来进行容错处理。 MasterServer基于netty提供监听服务。

• WorkerServer

  WorkerServer也采用分布式无中心设计理念，WorkerServer主要负责任务的执行和提供日志服务。 WorkerServer服务启动时向Zookeeper注册临时节点，并维持心跳。 WorkerServer基于netty提供监听服务。

• ZooKeeper

  ZooKeeper服务，系统中的MasterServer和WorkerServer节点都通过ZooKeeper来进行集群管理和容错。另外系统还基于ZooKeeper进行事件监听和分布式锁。

• Task Queue

  提供任务队列的操作，目前队列也是基于Zookeeper来实现。由于队列中存的信息较少，不必担心队列里数据过多的情况。

• Alert

  提供告警相关接口，接口主要包括告警两种类型的告警数据的存储、查询和通知功能。其中通知功能又有邮件通知

• API

  API接口层，主要负责处理前端UI层的请求。该服务统一提供RESTful api向外部提供请求服务。 接口包括工作流的创建、定义、查询、修改、发布、下线、手工启动、停止、暂停、恢复、从该节点开始执行等等

• UI

  系统的前端页面，提供系统的各种可视化操作界面

2.3、架构设计思想

一、去中心化vs中心化

中心化思想：

​ 中心化的设计理念比较简单，分布式集群中的节点按照角色分工，大体上分为两种角色：

• Master的角色主要负责任务分发并监督Slave的健康状态，可以动态的将任务均衡到Slave上，以致Slave节点不至于“忙死”或”闲死”的状态。
• Worker的角色主要负责任务的执行工作并维护和Master的心跳，以便Master可以分配任务给Slave。

​ 中心化思想设计存在的问题：

• 一旦Master出现了问题，则群龙无首，整个集群就会崩溃。为了解决这个问题，大多数Master/Slave架构模式都采用了主备Master的设计方案，可以是热备或者冷备，也可以是自动切换或手动切换，而且越来越多的新系统都开始具备自动选举切换Master的能力,以提升系统的可用性。
• 另外一个问题是如果Scheduler在Master上，虽然可以支持一个DAG中不同的任务运行在不同的机器上，但是会产生Master的过负载。如果Scheduler在Slave上，则一个DAG中所有的任务都只能在某一台机器上进行作业提交，则并行任务比较多的时候，Slave的压力可能会比较大。

去中心化思想：

• 在去中心化设计里，通常没有Master/Slave的概念，所有的角色都是一样的，地位是平等的，全球互联网就是一个典型的去中心化的分布式系统，联网的任意节点设备down机，都只会影响很小范围的功能。
• 去中心化设计的核心设计在于整个分布式系统中不存在一个区别于其他节点的”管理者”，因此不存在单点故障问题。但由于不存在” 管理者”节点所以每个节点都需要跟其他节点通信才得到必须要的机器信息，而分布式系统通信的不可靠性，则大大增加了上述功能的实现难度。
• 实际上，真正去中心化的分布式系统并不多见。反而动态中心化分布式系统正在不断涌出。在这种架构下，集群中的管理者是被动态选择出来的，而不是预置的，并且集群在发生故障的时候，集群的节点会自发的举行"会议"来选举新的"管理者"去主持工作。最典型的案例就是ZooKeeper及Go语言实现的Etcd。
• DolphinScheduler的去中心化是Master/Worker注册到Zookeeper中，实现Master集群和Worker集群无中心，并使用Zookeeper分布式锁来选举其中的一台Master或Worker为“管理者”来执行任务。

四、实践

注：这部分的话，我截图给大家展示一下吧，然后配一些文字说明，有感兴趣的小伙伴可以讨论哈。

先来介绍下我们这边大致的设计思路：

​ 按照数仓分层的思想，我们构建出了四个主要的项目。当然还会有一些其他的项目，包括临时需求、多场景取数等等吧。下面来重点看下这四个项目中内容：

1、dw_ods层

​ 看到这个名字，不用说，相信大家也知道是在做什么事了。对喽，就是你们想的那样。我来说下我们这边ODS层的设计吧（可能很乱，见笑了各位大佬）

对了，就是有这么多的ODS库，是不是很酸爽？基于工具的不能全局查找的特性，在不了解表的情况下，再加上运气背的话，可能要翻遍整个ODS的库才能知道你想看的表在哪个库下（哭瞎）~~

这么设计也是历史遗留问题了，很难再改变了。这就是所谓的按照业务系统的划分，在ODS落地时，也做了分库，并且基本是和ODS保持高度一致的。
其实从另外一面看待，这么设计也没什么问题。
也有了解过其他小伙伴们在ODS层的设计，其中有一种是将所有的ODS层表落到一个库下，但是在命名的时候，会按照业务系统进行划分。我个人觉得这两种设计各有利弊吧，不能绝对的说谁好谁坏~
另外还有一点，就是ODS层表的设计，目前我们是采用分区表进行存储的，并定期对历史分区进行删除，以保证存储空间和执行效率。当然也有把ODS层直接进行truncate再进行全量写的~看自己公司的设计理念和习惯了。

来给大家展示下，在DS中的设计：

这两张图非常清晰的展示了我们在ODS层的设计，懂得一眼就明白了，不明白的咱可以留言交流。

2、dw_dwd层

说下DWD的设计，在数仓中将业务流转换为数据流。根据业务过程划分出主题，采用维度建模的方式，将数据进行汇总，采用一些七七八八的手段，尽可能的提高dwd层表的复用性。

​ 在DS中，根据主题表创建不同的工作流：

​ 弊端：等主题慢慢膨胀起来，管理起来比较费劲

​ 好处：各自为战，清晰明了

来看上面图二：

​ 这是我们众多DWD表中的一张，在DS中，设置任务调度时，强依赖了DS中的依赖组件，并将DWD表中涉及到的ODS表增加至依赖中。这样做的好处，是比较精准的把控了每一张DWD表的动向。

3、dw_dws层

DWS层的设计也是比较明确的，基于DWD的层表，在同粒度的情况下，对数据进行汇总，然后形成主题宽表。
我们在设计这层的时候，严格按照数仓设计的规范：DWS层的表只能使用DWD的表进行关联汇总，坚决不允许出现跨层使用的情况。
如果在生产过程中，发现现有模型不能很好的支持业务的输出，会定期对模型进行小范围的重构（增减字段等），以保证模型的复用能力和“活力”。
在DS中，我们也是按照主题宽表进行分工作流设计的，如下图：

如上图二：在DWS中，我们也是按照依赖对工作流进行了设计。DIM层、DWD层都是在执行完毕的情况下，才能继续往下走。
PS：做任务依赖这点DS还是很香的，当然很多同学想用弱依赖来更加完美的配置工作流，但是目前DS貌似不支持，期待新功能早日上线吧。

4、DM层

设计完DWS层算是完成一大半工作了，DM层（或者叫ADS层）基本就是根据实际的报表需求，对数据进行汇总，最终由DM层将数据推到OLAP（目前我们使用的Doris，感兴趣的小伙伴可以一起交流下，哇咔咔~）供业务或者分析师使用。

5、DIM层

对了，差点忘了说，还有比较重要的一层：DIM层，即维度层。
在数仓建设的过程中，严格遵守一致性维度的原则。维度层的表是可以进行跨层使用的，下面展示下我们数仓分层的架构简图：

五、结束语

本文介绍了DS的架构原理和我实际工作中的使用情况，在我们整个数仓项目中，DS起到了至关重要的作用，使得开发效率明显提升，调度任务管理起来也更加清晰。
说一说我在使用过程中的心得吧，我个人个感觉，对调度的设计也是需要画个架构图提前规划的，不然随着需求的增加，项目越来越多，工作流越来越多，管理就变得困难了。提前做好规范，各位开发的小伙伴严格按照规范做事，即使会出圈也不会跑太偏。
本文篇幅有限，有些问题介绍也不是很深入，相信所有使用DS的小伙伴会充分挖掘它的功能，使开发变得更加容易。实际使用的功能还有很多，就不一一介绍了，有兴趣的小伙伴可以一起交流。
好了，此致吧，敬礼了~~睡觉了，晚安！！！

不同分类模型对应关系

TCP/IP协议分层模型有：四层模型、五层模型、七层模型

四层：物理接口层、网络层、传输层、应用层
五层：物理层、数据链路层、网络层、传输层、应用层
七层：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层

不同人员关注的模型不一样

对于大众人员会更关注四层模型，因为物理层和数据链路层都是跟网卡和物理线路有关，会话层、表示层、应用层都属于上层制定协议规则的人员决定。

对于网络设备公司，可能更关注五层协议，因为他们生产的设备要明确区分物理层和数据链路层，物理设备更关注数据的传输，相对不太关注应用层协议定制。

对于制定应用层协议的人员，就要更关注七层协议，选择TCP还是UDP，数据的加解密方式，压缩格式等，SSH、HTTPS这些协议的，就要关注并区分会话层、表示层、应用层负责处理哪些功能。

每层的简述

物理层

涉及物理实体，电缆/光缆传输的是高低电平0/1的比特流。

数据链路层

涉及物理实体，每个网络设备都最少有一个网卡（运营商网络路由器的每个端口是一个网卡），每个网卡有网卡地址也叫硬件地址（英文缩写MAC），数据链路层的协议数据单元数据帧（PDU）的首部信息里面有自身MAC和目的MAC，这也是属于物理层范畴，因为需要涉及具体的物理设备连接。

数据链路层主要有两个功能 ：帧编码和误差纠正控制。帧编码意味着定义一个包含信息频率、位同步、源地址、目标地址以及其他控制信息的数据包。数据链路层协议又被分为两个子层 ：逻辑链路控制（LLC）协议和媒体访问控制（MAC）协议。

在一条物理线路之上，通过一些规程或协议来控制这些数据的传输，以保证被传输数据的正确性。实现这些规程或协议的硬件和软件加到物理线路，这样就构成了数据链路，从数据发送点到数据接收点所经过的传输途径。当采用复用技术时，一条物理链路上可以有多条数据链路。

网络层

逻辑链路的第一层，根据目的IP进行发送，一般都是IP路由转发协议，而它最终会转化到数据链路层。需要使用到链路层的ARP协议，ARP协议可以根据网络层PDU的IP地址获得物理地址，这样就可以使得数据链路层能知道发送到哪个MAC，MAC地址只需要局域网内部唯一就可以正确转发到目的MAC。

网络层用到了路由表，路由表里面存放了路由信息，路由有几个核心参数：目的IP、下一跳IP（要想去到目的IP，需要跳转到的中专IP，因为本机不能直接访问到目的IP，所以需要让下一跳进行转发），路由又分为静态路由和动态路由，静态路由是每条都手工添加，而动态路由表是根据路由发现协议自动采集。RARP可以根据MAC反查IP，可以用于数据链路层的数据包还原成网络层的数据包。（注意：路由是单向的，比如A和B两个机器，A有指向B的路由，而B没有指向A的路由，那么B能收到A发来的包，而B无法发送包给A）

传输层

主要负责向两个主机中进程之间的通信提供服务，目前最广泛就是socket（IP加端口，决定应用程序连接唯一性）。主要实现协议有：TCP、UDP。

注意因为路由是单向的，所以数据包的发送也是单向的，而平时我们称TCP相对UDP是有连接的，实际上TCP就是通信双方，通过三次握手（3个数据包的交互）双方内部维护了一个连接状态的字段，双方通过该状态来判断连接是否有效，一般通过定期发送心跳包的方式，然后等待对方响应心跳包来判断对方是否在线。
正常的断开连接是通过四次握手（4个数据包交互）告知对方关闭连接，4次交互过程中通过不断修改内部维护的那个连接状态字段，直到最终在操作系统撤销Socket资源。

会话层

属于四/五层协议的应用层，是由应用程序网络服务接口控制，控制传输层的连接、断开、重连等。

表示层

属于四/五层协议的应用层，是由应用程序网络服务接口控制，表示层为应用层提供的服务有三项内容：
语法转换：语法转换涉及代码转换和字符集的转换，数据格式的修改、数据结构操作的适配、数据压缩、数据加密等。
语法选择：语法选择是提供初始选择的一种语法和随后修改这种选择的手段。
联接管理：利用会话层提供的服务建立表示联接，管理在这一联接之上的数据运输和同步控制，以及正常或非正常地终止联接。

应用层

属于四/五层协议的应用层，是由应用程序网络服务接口控制，首先确认一点，应用层定义的是应用程序用于请求网络服务的接口，而不是指应用程序本身。应用层主要定义了应用程序能够从网络上请求使用哪种类型的服务，并且规定了在从应用程序接收消息或向应用程序发送消息时，数据所必须采用的格式。

数据包传输过程

每层都有自己的协议数据单元PDU，数据包的传输过程中，每层都会有封包和拆包的过程。

数据包传输调用关系

数据包发送

应用程序调用系统调用，将数据发送给socket
socket检查数据类型，调用相应的send函数
send函数检查socket状态、协议类型，传给传输层
tcp/udp（传输层协议）为这些数据创建数据结构，加入协议头部，比如端口号、检验和，传给下层（网络层）
ip（网络层协议）添加ip头，比如ip地址、检验和
如果数据包大小超过了mtu（最大数据包大小），则分片；ip将这些数据包传给链路层
链路层写到网卡队列
网卡调用响应中断驱动程序，发送到网络

数据包接收

数据包从网络到达网卡，网卡接收帧，放入网卡buffer，在向系统发送中断请求
cpu调用相应中断函数，这些中断处理程序在网卡驱动中
中断处理函数从网卡读入内存，交给链路层
链路层将包放入自己的队列，置软中断标志位
进程调度器看到了标志位，调度相应进程
该进程将包从队列取出，与相应协议匹配，一般为ip协议，再将包传递给该协议接收函数
ip层对包进行错误检测，无错，路由
路由结果，packet被转发或者继续向上层传递
如果发往本机，进入链路层
链路层再进行错误侦测，查找相应端口关联socket，包被放入相应socket接收队列
socket唤醒拥有该socket的进程，进程从系统调用read中返回，将数据拷贝到自己的buffer，返回用户态。

各层协议

OSI:物理层

EIA/TIA-232, EIA/TIA-499, V.35, V.24, RJ45, Ethernet, 802.3, 802.5, FDDI, NRZI, NRZ, B8ZS

数据链路层

Frame Relay, HDLC, PPP, IEEE 802.3/802.2, FDDI, ATM, IEEE 802.5/802.2

网络层

IP，IPX，AppleTalk DDP，【ARP,RARP】

传输层

TCP，UDP，SPX

会话层

RPC,SQL,NFS,NetBIOS,names,AppleTalk,ASP,DECnet,SCP

表示层

TIFF,GIF,JPEG,PICT,ASCII,EBCDIC,encryption,MPEG,MIDI,HTML

应用层

FTP,WWW,Telnet,NFS,SMTP,Gateway,SNMP,HTTP

协议所属分层和解释

TCP

协议类型：传输层
传输控制协议（TCP，Transmission Control Protocol）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793 定义。
TCP旨在适应支持多网络应用的分层协议层次结构。连接到不同但互连的计算机通信网络的主计算机中的成对进程之间依靠TCP提供可靠的通信服务。TCP假设它可以从较低级别的协议获得简单的，可能不可靠的数据报服务。原则上，TCP应该能够在从硬线连接到分组交换或电路交换网络的各种通信系统之上操作。

UDP

协议类型：传输层
Internet 协议集支持一个无连接的传输协议，该协议称为用户数据报协议（UDP，User Datagram Protocol）。UDP 为应用程序提供了一种无需建立连接就可以发送封装的 IP 数据报的方法。
Internet 的传输层有两个主要协议，互为补充。无连接的是 UDP，它除了给应用程序发送数据包功能并允许它们在所需的层次上架构自己的协议之外，几乎没有做什么特别的的事情。面向连接的是 TCP，该协议几乎做了所有的事情。

Telnet

协议类型：应用层，TCP，文本格式
端口23
Telnet协议是TCP/IP协议族中的一员，是Internet远程登录服务的标准协议和主要方式。它为用户提供了在本地计算机上完成远程主机工作的能力。在终端使用者的电脑上使用telnet程序，用它连接到服务器。终端使用者可以在telnet程序中输入命令，这些命令会在服务器上运行，就像直接在服务器的控制台上输入一样。可以在本地就能控制服务器。要开始一个telnet会话，必须输入用户名和密码来登录服务器。Telnet是常用的远程控制Web服务器的方法

SSH

协议类型：应用层，TCP，文本格式，加密
利用SSL加密的命令行协议，端口22

netconf

协议类型：应用层，TCP，文本格式，加密
端口830
通过SSH传输XML格式命令报文

ICMP

协议类型：网络层，文本格式
ICMP协议是一种面向无连接的协议，用于传输出错报告控制信息。它是一个非常重要的协议，它对于网络安全具有极其重要的意义。 它属于网络层协议，主要用于在主机与路由器之间传递控制信息，包括报告错误、交换受限控制和状态信息等。当遇到IP数据无法访问目标、IP路由器无法按当前的传输速率转发数据包等情况时，会自动发送ICMP消息。
ICMP 是 TCP/IP 模型中网络层的重要成员，与 IP 协议、ARP 协议、RARP 协议及 IGMP 协议共同构成 TCP/IP 模型中的网络层。ping 和 tracert是两个常用网络管理命令，ping 用来测试网络可达性，tracert 用来显示到达目的主机的路径。ping和 tracert 都利用 ICMP 协议来实现网络功能，它们是把网络协议应用到日常网络管理的典型实例。

SNMP

协议类型：应用层，UDP，文本格式
简单网络管理协议。
161端口
SNMP 是专门设计用于在 IP 网络管理网络节点（服务器、工作站、路由器、交换机及HUBS等）的一种标准协议，它是一种应用层协议。
SNMP是管理进程（NMS）和代理进程（Agent）之间的通信协议。它规定了在网络环境中对设备进行监视和管理的标准化管理框架、通信的公共语言、相应的安全和访问控制机制。网络管理员使用SNMP功能可以查询设备信息、修改设备的参数值、监控设备状态、自动发现网络故障、生成报告等。
基于TCP/IP互联网的标准协议，传输层协议一般采用UDP。
自动化网络管理。网络管理员可以利用SNMP平台在网络上的节点检索信息、修改信息、发现故障、完成故障诊断、进行容量规划和生成报告。
屏蔽不同设备的物理差异，实现对不同厂商产品的自动化管理。SNMP只提供最基本的功能集，使得管理任务与被管设备的物理特性和实际网络类型相对独立，从而实现对不同厂商设备的管理。
简单的请求—应答方式和主动通告方式相结合，并有超时和重传机制。
报文种类少，报文格式简单，方便解析，易于实现。
SNMPv3版本提供了认证和加密安全机制，以及基于用户和视图的访问控制功能，增强了安全性。

DHCP

协议类型：应用层，UDP，报文结构复杂，最终解析出也是文本格式
DHCP是一个局域网的网络协议，使用UDP协议工作，主要有两个用途：用于内部网或网络服务供应商自动分配IP地址；给用户用于内部网管理员作为对所有计算机作中央管理的手段。

HTTP

协议类型：应用层，TCP，文本格式
HTTP–Hyper Text Transfer Protocol，超文本传输协议，是一种建立在TCP上的无状态连接，整个基本的工作流程是客户端发送一个HTTP请求，说明客户端想要访问的资源和请求的动作，服务端收到请求之后，服务端开始处理请求，并根据请求做出相应的动作访问服务器资源，最后通过发送HTTP响应把结果返回给客户端。其中一个请求的开始到一个响应的结束称为事务，当一个事物结束后还会在服务端添加一条日志条目。

HTTPS

协议类型：应用层，TCP，文本格式，在表示层进行了加解密。

1. https协议需要到ca申请证书或自制证书。

2. http的信息是明文传输，https则是具有安全性的ssl加密。

3. http是直接与TCP进行数据传输，而https是经过一层SSL（OSI表示层），用的端口也不一样，前者是80（需要国内备案），后者是443。

4. http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

syslog

协议类型：应用层，UDP，文本格式
设备系统日志，使用UDP协议，服务端程序监听514端口，设备主动推送上报设备的日志信息。

Trap

协议类型：应用层，UDP，文本格式
简单网络管理协议SNMP（Simple Network Management Protocol）SNMP协定在OSI模型的应用层（第七层）运作，从第一版开始就定义trap为核心PDU报文之一。SNMP代理使用Trap向SNMP管理站发送非请求消息，一般用于描述某一事件的发生。此事件可以是告警、告警恢复、通知等。如接口UP/DOWN，IP地址更改等。
服务端启动监听162端口，设备主动上报trap告警。
重点：syslog是日志信息，trap是告警信息

MPLS

协议类型：网络层和数据链路层之间，2.5层协议

MPLS（多协议标签交换），即多协议标记交换，介于网络层和数据链路层之间，是一种标记（label）机制的包交换技术，通过简单的2层交换来集成IP Routing 的控制。
MPLS在传统的如以太网帧的源MAC地址前增加了32比特的头，其中1-20比特用来标识标签，21-23用来标识优先级，类似于IP头的TOS字段，24比特用来标识是否有标签嵌套。最后8比特为TTL。

1、MPLS是介于2层和3层之间的协议，主要应用在城域网中，作为集客专线、基站等承载VPN技术的关键技术。
2、MPLS利用MPLS标签进行转发，先通过IP单播路由的方式沿途分配好MPLS标签，分配完成后，沿途路由器只需要根据MPLS标签进行转发，比IP查表效率高很多，但是，IP查表虽然是软件实现，但是CPU的性能已经很高，所以，MPLS转发性能优势已经不存在，MPLS优势在于VPN，可以实现高附加值的功能，例如，MPLS VPN FRR,QOS等。
3、MPLS可以用静态分配标签的方式，也可以通过LDP进行动态分发标签。

ARP

协议类型：网络层。
地址解析协议，即ARP（Address Resolution Protocol），是根据IP地址获取物理地址的一个TCP/IP协议。
OSI模型把网络工作分为七层，IP地址在OSI模型的第三层，MAC地址在第二层，彼此不直接打交道。在通过以太网发送IP数据包时，需要先封装第三层（32位IP地址）、第二层（48位MAC地址）的报头，但由于发送时只知道目标IP地址，不知道其MAC地址，又不能跨第二、三层，所以需要使用地址解析协议。使用地址解析协议，可根据网络层IP数据包包头中的IP地址信息解析出目标硬件地址（MAC地址）信息，以保证通信的顺利进行。

RARP

协议类型：网络层。
反向地址解析协议，通过MAC获取IP。

OSPF

协议类型：网络层，路由协议都是网络层
OSPF路由协议是用于网际协议（IP）网络的链路状态路由协议。OSPF协议是一种链路状态协议。每个路由器负责发现、维护与邻居的关系，并将已知的邻居列表和链路费用LSU(Link State Update)报文描述，通过可靠的泛洪与自治系统AS(Autonomous System)内的其他路由器周期性交互，学习到整个自治系统的网络拓扑结构;并通过自治系统边界的路由器注入其他AS的路由信息，从而得到整个Internet的路由信息。每隔一个特定时间或当链路状态发生变化时，重新生成LSA，路由器通过泛洪机制将新LSA通告出去，以便实现路由的实时更新。

ISIS

协议类型：网络层，路由协议都是网络层
ISIS是一个分级的链接状态路由协议，基于DECnet PhaseV 路由算法，实际上与OSPF非常相似，它也使用Hello协议寻找毗邻节点，使用一个传播协议发送链接信息。ISIS可以在不同的子网上操作，包括广播型的LAN、WAN和点到点链路。

LLDP

协议类型：数据链路层
链路层发现协议（Link Layer Discovery Protocol，LLDP）。
网络设备可以通过在本地网络中发送LLDPDU（Link Layer Discovery Protocol Data Unit）来通告其他设备自身的状态。是一种能够使网络中的设备互相发现并通告状态、交互信息的协议。

参考文献

• TCP/IP 七层协议
• TCP/IP协议（一）网络基础知识 网络七层协议
• OSI七层模型的学习-会话层、表示层和应用层
• HTTP请求行、请求头、请求体详解
• 网络数据包发送接收全过程
• TCP通信过程与三次握手和四次握手
• 密码学经典应用之HTTPS工作过程

DDD从入门到精通，系列文章传送地址，请点击本链接。

目录

一、DDD 分层架构与微服务代码模型

二、微服务一级目录结构

三、各层目录结构

四、注意事项

五、领域对象的整理

六、从领域模型到微服务的设计

七、领域层的领域对象

八、应用层的领域对象

九、领域对象与微服务代码对象的映射

---

DDD并没有给出标准的代码模型，因此一千人就会有一千个哈姆雷特，下面代码模型是欧创新老师的思考和实践而来。我们可以作为学习的参考。

一、DDD 分层架构与微服务代码模型

我们参考 DDD 分层架构模型来设计微服务代码模型。没错！微服务代码模型就是依据 DDD 分层架构模型设计出来的。

用户接口层：面向前端提供服务适配，面向资源层提供资源适配。这一层聚集了接口适配相关的功能。

应用层职责：实现服务组合和编排，适应业务流程快速变化的需求。这一层聚集了应用服务和事件相关的功能。

领域层：实现领域的核心业务逻辑。这一层聚集了领域模型的聚合、聚合根、实体、值对象、领域服务和事件等领域对象，以及它们组合所形成的业务能力。

基础层：贯穿所有层，为各层提供基础资源服务。这一层聚集了各种底层资源相关的服务和能力。

二、微服务一级目录结构

按照分层模型分别建立了 interfaces、application、domain 和 infrastructure 四个一级代码目录。

Interfaces（用户接口层）：它主要存放用户接口层与前端交互、展现数据相关的代码。前端应用通过这一层的接口，向应用服务获取展现所需的数据。这一层主要用来处理用户发送的 Restful 请求，解析用户输入的配置文件，并将数据传递给 Application 层。数据的组装、数据传输格式以及 Facade 接口等代码都会放在这一层目录里。

Application（应用层）：它主要存放应用层服务组合和编排相关的代码。应用服务向下基于微服务内的领域服务或外部微服务的应用服务完成服务的编排和组合，向上为用户接口层提供各种应用数据展现支持服务。应用服务和事件等代码会放在这一层目录里。

Domain（领域层）：它主要存放领域层核心业务逻辑相关的代码。领域层可以包含多个聚合代码包，它们共同实现领域模型的核心业务逻辑。聚合以及聚合内的实体、方法、领域服务和事件等代码会放在这一层目录里。

Infrastructure（基础层）：它主要存放基础资源服务相关的代码，为其它各层提供的通用技术能力、三方软件包、数据库服务、配置和基础资源服务的代码都会放在这一层目录里。

三、各层目录结构

1、用户接口层

Interfaces 的代码目录结构有：assembler、dto 和 façade 三类。

Assembler：实现 DTO 与领域对象之间的相互转换和数据交换。一般来说 Assembler 与 DTO 总是一同出现。

Dto：它是数据传输的载体，内部不存在任何业务逻辑，我们可以通过 DTO 把内部的领域对象与外界隔离。

Facade：提供较粗粒度的调用接口，将用户请求委派给一个或多个应用服务进行处理。

2、应用层

Application 的代码目录结构有：event 和 service。

Event（事件）：这层目录主要存放事件相关的代码。它包括两个子目录：publish 和 subscribe。前者主要存放事件发布相关代码，后者主要存放事件订阅相关代码（事件处理相关的核心业务逻辑在领域层实现）。

这里提示一下：虽然应用层和领域层都可以进行事件的发布和处理，但为了实现事件的统一管理，我建议你将微服务内所有事件的发布和订阅的处理都统一放到应用层，事件相关的核心业务逻辑实现放在领域层。通过应用层调用领域层服务，来实现完整的事件发布和订阅处理流程。

Service（应用服务）：这层的服务是应用服务。应用服务会对多个领域服务或外部应用服务进行封装、编排和组合，对外提供粗粒度的服务。应用服务主要实现服务组合和编排，是一段独立的业务逻辑。你可以将所有应用服务放在一个应用服务类里，也可以把一个应用服务设计为一个应用服务类，以防应用服务类代码量过大。

3、领域层

Domain 是由一个或多个聚合包构成，共同实现领域模型的核心业务逻辑。聚合内的代码模型是标准和统一的，包括：entity、event、repository 和 service 四个子目录。

Aggregate（聚合）：它是聚合软件包的根目录，可以根据实际项目的聚合名称命名，比如权限聚合。在聚合内定义聚合根、实体和值对象以及领域服务之间的关系和边界。聚合内实现高内聚的业务逻辑，它的代码可以独立拆分为微服务。

以聚合为单位的代码放在一个包里的主要目的是为了业务内聚，而更大的目的是为了以后微服务之间聚合的重组。聚合之间清晰的代码边界，可以让你轻松地实现以聚合为单位的微服务重组，在微服务架构演进中有着很重要的作用。

Entity（实体）：它存放聚合根、实体、值对象以及工厂模式（Factory）相关代码。实体类采用充血模型，同一实体相关的业务逻辑都在实体类代码中实现。跨实体的业务逻辑代码在领域服务中实现。

Event（事件）：它存放事件实体以及与事件活动相关的业务逻辑代码。

Service（领域服务）：它存放领域服务代码。一个领域服务是多个实体组合出来的一段业务逻辑。你可以将聚合内所有领域服务都放在一个领域服务类中，你也可以把每一个领域服务设计为一个类。如果领域服务内的业务逻辑相对复杂，我建议你将一个领域服务设计为一个领域服务类，避免由于所有领域服务代码都放在一个领域服务类中，而出现代码臃肿的问题。领域服务封装多个实体或方法后向上层提供应用服务调用。

Repository（仓储）：它存放所在聚合的查询或持久化领域对象的代码，通常包括仓储接口和仓储实现方法。为了方便聚合的拆分和组合，我们设定了一个原则：一个聚合对应一个仓储。

特别说明：按照 DDD 分层架构，仓储实现本应该属于基础层代码，但为了在微服务架构演进时，保证代码拆分和重组的便利性，我是把聚合仓储实现的代码放到了聚合包内。这样，如果需求或者设计发生变化导致聚合需要拆分或重组时，我们就可以将包括核心业务逻辑和仓储代码的聚合包整体迁移，轻松实现微服务架构演进。

4、基础层

Infrastructure 的代码目录结构有：config 和 util 两个子目录。

Config：主要存放配置相关代码。

Util：主要存放平台、开发框架、消息、数据库、缓存、文件、总线、网关、第三方类库、通用算法等基础代码，你可以为不同的资源类别建立不同的子目录。

5、代码模型总目录结构

四、注意事项

第一点：聚合之间的代码边界一定要清晰。聚合之间的服务调用和数据关联应该是尽可能的松耦合和低关联，聚合之间的服务调用应该通过上层的应用层组合实现调用，原则上不允许聚合之间直接调用领域服务。这种松耦合的代码关联，在以后业务发展和需求变更时，可以很方便地实现业务功能和聚合代码的重组，在微服务架构演进中将会起到非常重要的作用。

第二点：你一定要有代码分层的概念。写代码时一定要搞清楚代码的职责，将它放在职责对应的代码目录内。应用层代码主要完成服务组合和编排，以及聚合之间的协作，它是很薄的一层，不应该有核心领域逻辑代码。领域层是业务的核心，领域模型的核心逻辑代码一定要在领域层实现。如果将核心领域逻辑代码放到应用层，你的基于 DDD 分层架构模型的微服务慢慢就会演变成传统的三层架构模型了。

有了代码模型架构，接下来就是怎么去细化模型里面的构造了，接下来将会详细讲解如何让领域模型和代码模型保持一致。

五、领域对象的整理

当微服务拆分完成后，我们就要整理事件风暴过程中产生的各个领域对象，比如：聚合、实体、命令和领域事件等内容，将这些领域对象和业务行为记录到下面的表格中。

你可以看到，这张表格里包含了：领域模型、聚合、领域对象和领域类型四个维度。一个领域模型会包含多个聚合，一个聚合包含多个领域对象，每个领域对象都有自己的领域类型。领域类型主要标识领域对象的属性，比如：聚合根、实体、命令和领域事件等类型。

六、从领域模型到微服务的设计

从领域模型到微服务落地，我们还需要做进一步的设计和分析。事件风暴中提取的领域对象，还需要经过用户故事或领域故事分析，以及微服务设计，才能用于微服务系统开发。

这个过程会比事件风暴来的更深入和细致。主要关注内容如下：

• 分析微服务内有哪些服务？

• 服务所在的分层？

• 应用服务由哪些服务组合和编排完成？

• 领域服务包括哪些实体的业务逻辑？

• 采用充血模型的实体有哪些属性和方法？

• 有哪些值对象？

• 哪个实体是聚合根等？

• 最后梳理出所有的领域对象和它们之间的依赖关系，我们会给每个领域对象设计对应的代码对象，定义它们所在的软件包和代码目录。

这个设计过程建议参与的角色有：DDD 专家、架构师、设计人员和开发经理。

七、领域层的领域对象

事件风暴结束时，领域模型聚合内一般会有：聚合、实体、命令和领域事件等领域对象。在完成故事分析和微服务设计后，微服务的聚合内一般会有：聚合、聚合根、实体、值对象、领域事件、领域服务和仓储等领域对象。

1. 设计实体

大多数情况下，领域模型的业务实体与微服务的数据库实体是一一对应的。但某些领域模型的实体在微服务设计时，可能会被设计为多个数据实体，或者实体的某些属性被设计为值对象。

我们分析个人客户时，还需要有地址、电话和银行账号等实体，它们被聚合根引用，不容易在领域建模时发现，我们需要在微服务设计过程中识别和设计出来。

在分层架构里，实体采用充血模型，在实体类内实现实体的全部业务逻辑。这些不同的实体都有自己的方法和业务行为，比如地址实体有新增和修改地址的方法，银行账号实体有新增和修改银行账号的方法。

实体类放在领域层的 Entity 目录结构下。

2. 找出聚合根

聚合根来源于领域模型，在个人客户聚合里，个人客户这个实体是聚合根，它负责管理地址、电话以及银行账号的生命周期。个人客户聚合根通过工厂和仓储模式，实现聚合内地址、银行账号等实体和值对象数据的初始化和持久化。

聚合根是一种特殊的实体，它有自己的属性和方法。聚合根可以实现聚合之间的对象引用，还可以引用聚合内的所有实体。聚合根类放在代码模型的 Entity 目录结构下。聚合根有自己的实现方法，比如生成客户编码，新增和修改客户信息等方法。

3. 设计值对象

根据需要将某些实体的某些属性或属性集设计为值对象。值对象类放在代码模型的 Entity 目录结构下。在个人客户聚合中，客户拥有客户证件类型，它是以枚举值的形式存在，所以将它设计为值对象。

有些领域对象可以设计为值对象，也可以设计为实体，我们需要根据具体情况来分析。如果这个领域对象在其它聚合内维护生命周期，且在它依附的实体对象中只允许整体替换，我们就可以将它设计为值对象。如果这个对象是多条且需要基于它做查询统计，我建议将它设计为实体。

4. 设计领域事件

如果领域模型中领域事件会触发下一步的业务操作，我们就需要设计领域事件。首先确定领域事件发生在微服务内还是微服务之间。然后设计事件实体对象，事件的发布和订阅机制，以及事件的处理机制。判断是否需要引入事件总线或消息中间件。

在个人客户聚合中有客户已创建的领域事件，因此它有客户创建事件这个实体。

领域事件实体和处理类放在领域层的 Event 目录结构下。领域事件的发布和订阅类我建议放在应用层的 Event 目录结构下。

5. 设计领域服务

如果一个业务动作或行为跨多个实体，我们就需要设计领域服务。领域服务通过对多个实体和实体方法进行组合，完成核心业务逻辑。你可以认为领域服务是位于实体方法之上和应用服务之下的一层业务逻辑。

按照严格分层架构层的依赖关系，如果实体的方法需要暴露给应用层，它需要封装成领域服务后才可以被应用服务调用。所以如果有的实体方法需要被前端应用调用，我们会将它封装成领域服务，然后再封装为应用服务。

个人客户聚合根这个实体创建个人客户信息的方法，被封装为创建个人客户信息领域服务。然后再被封装为创建个人客户信息应用服务，向前端应用暴露。

领域服务类放在领域层的 Service 目录结构下。

6. 设计仓储

每一个聚合都有一个仓储，仓储主要用来完成数据查询和持久化操作。仓储包括仓储的接口和仓储实现，通过依赖倒置实现应用业务逻辑与数据库资源逻辑的解耦。

仓储代码放在领域层的 Repository 目录结构下。

八、应用层的领域对象

应用层的主要领域对象是应用服务和事件的发布以及订阅。

在事件风暴或领域故事分析时，我们往往会根据用户或系统发起的命令，来设计服务或实体方法。为了响应这个命令，我们需要分析和记录：

1. 在应用层和领域层分别会发生哪些业务行为；

1. 各层分别需要设计哪些服务或者方法；

1. 这些方法和服务的分层以及领域类型（比如实体方法、领域服务和应用服务等），它们之间的调用和组合的依赖关系。

在严格分层架构模式下，不允许服务的跨层调用，每个服务只能调用它的下一层服务。服务从下到上依次为：实体方法、领域服务和应用服务。

如果需要实现服务的跨层调用，我们应该怎么办？我建议你采用服务逐层封装的方式。

我们看一下上面这张图，服务的封装和调用主要有以下几种方式。

1. 实体方法的封装

实体方法是最底层的原子业务逻辑。如果单一实体的方法需要被跨层调用，你可以将它封装成领域服务，这样封装的领域服务就可以被应用服务调用和编排了。如果它还需要被用户接口层调用，你还需要将这个领域服务封装成应用服务。经过逐层服务封装，实体方法就可以暴露给上面不同的层，实现跨层调用。

封装时服务前面的名字可以保持一致，你可以用 *DomainService 或 *AppService 后缀来区分领域服务或应用服务。

2. 领域服务的组合和封装

领域服务会对多个实体和实体方法进行组合和编排，供应用服务调用。如果它需要暴露给用户接口层，领域服务就需要封装成应用服务。

3. 应用服务的组合和编排

应用服务会对多个领域服务进行组合和编排，暴露给用户接口层，供前端应用调用。

在应用服务组合和编排时，你需要关注一个现象：多个应用服务可能会对多个同样的领域服务重复进行同样业务逻辑的组合和编排。当出现这种情况时，你就需要分析是不是领域服务可以整合了。你可以将这几个不断重复组合的领域服务，合并到一个领域服务中实现。这样既省去了应用服务的反复编排，也实现了服务的演进。这样领域模型将会越来越精炼，更能适应业务的要求。

应用服务类放在应用层 Service 目录结构下。领域事件的发布和订阅类放在应用层 Event 目录结构下。

九、领域对象与微服务代码对象的映射

在完成上面的分析和设计后，我们就可以建立像下图一样的，领域对象与微服务代码对象的映射关系了。

典型的领域模型

个人客户领域模型中的个人客户聚合，就是典型的领域模型，从聚合内可以提取出多个实体和值对象以及它的聚合根。

我们看一下下面这个图，我们对个人客户聚合做了进一步的分析。提取了个人客户表单这个聚合根，形成了客户类型值对象，以及电话、地址、银行账号等实体，为实体方法和服务做了封装和分层，建立了领域对象的关联和依赖关系，还有仓储等设计。关键是这个过程，我们建立了领域对象与微服务代码对象的映射关系。

下面我对表格的各栏做一个简要的说明。

• 层：定义领域对象位于分层架构中的哪一层，比如：接口层、应用层、领域层以及基础层等。

• 领域对象：领域模型中领域对象的具体名称。

• 领域类型：根据 DDD 知识体系定义的领域对象的类型，包括：限界上下文、聚合、聚合根、实体、值对象、领域事件、应用服务、领域服务和仓储服务等领域类型。

• 依赖的领域对象：根据业务对象依赖或分层调用的依赖关系，建立的领域对象的依赖关系，比如：服务调用依赖、关联对象聚合等。

• 包名：代码模型中的包名，对应领域对象所在的软件包。

• 类名：代码模型中的类名，对应领域对象的类名。

• 方法名：代码模型中的方法名，对应领域对象实现或操作的方法名。

最后我们得出的微服务代码结构如下：

非典型领域模型

有些业务场景可能并不能如你所愿，你可能无法设计出典型的领域模型。这类业务中有多个实体，实体之间相互独立，是松耦合的关系，这些实体主要参与分析或者计算，你找不出聚合根，但就业务本身来说它们是高内聚的。而它们所组合的业务与其它聚合是在一个限界上下文内，你也不大可能将它单独设计为一个微服务。

这种业务场景其实很常见。比如，在个人客户领域模型内有客户归并的聚合，它扫描所有客户，按照身份证号码、电话号码等是否重复的业务规则，判断是否是重复的客户，然后对重复的客户进行归并。这种业务场景你就找不到聚合根。

那对于这类非典型模型，我们怎么办？

我们还是可以借鉴聚合的思想，仍然用聚合来定义这部分功能，并采用与典型领域模型同样的分析方法，建立实体的属性和方法，对方法和服务进行封装和分层设计，设计仓储，建立领域对象之间的依赖关系。唯一可惜的就是我们依然找不到聚合根，不过也没关系，除了聚合根管理功能外，我们还可以用 DDD 的其它设计方法。

声明：文章内容是极客时间专栏学习的学习笔记，会做简化或调整，欢迎大家留言和评论。

DDD从入门到精通，系列文章传送地址，请点击本链接https://blog.csdn.net/wanghaiping1993/article/details/125433802