mirror of
https://github.com/Estom/notes.git
synced 2026-02-03 02:23:31 +08:00
maven
This commit is contained in:
shanghai
208
JavaScript/JavaScript数据类型.md
Normal file
208
JavaScript/JavaScript数据类型.md
Normal file
@@ -0,0 +1,208 @@
|
||||
> 参考教程
|
||||
> * [廖雪峰](https://www.liaoxuefeng.com/wiki/1022910821149312/1023025235359040)
|
||||
> * [W3school](https://www.w3school.com.cn/js/js_intro.asp)
|
||||
> * [菜鸟教程](https://www.runoob.com/js/js-intro.html)
|
||||
|
||||
|
||||
## 1 基本使用
|
||||
|
||||
### 使用方法
|
||||
* 直接嵌入<head></head>标签当中。type属性默认是javascript
|
||||
|
||||
```
|
||||
<head>
|
||||
<script type="text/javacript">
|
||||
|
||||
</script>
|
||||
</head>
|
||||
```
|
||||
* 单独放入js文件当中，通过标签引入
|
||||
```
|
||||
<head>
|
||||
<script src=
|
||||
"/static/js/abc.js">
|
||||
</head>
|
||||
```
|
||||
|
||||
## 2 基本语法
|
||||
|
||||
> 单独语句尽量加分号，自动加分号会导致理解问题。
|
||||
|
||||
|
||||
### 赋值语句
|
||||
```
|
||||
var x = 1;
|
||||
```
|
||||
### 注释语句
|
||||
```
|
||||
//单行注释
|
||||
/* 多行注释
|
||||
多行注释*/
|
||||
```
|
||||
|
||||
## 3 数据类型
|
||||
|
||||
### Number
|
||||
> 不区分证书和浮点数
|
||||
```
|
||||
123//整数
|
||||
-0.45//负数、浮点数
|
||||
1.23e3//科学计数法
|
||||
NaN//不是数字
|
||||
Infinity//无限大
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
### bool值
|
||||
```
|
||||
true;
|
||||
false;
|
||||
```
|
||||
|
||||
### null与undefined
|
||||
```
|
||||
null; \\表示空值，不等于0，不等于''空字符串。
|
||||
undefined;\\未定义，没什么用
|
||||
```
|
||||
|
||||
### 字符串
|
||||
```
|
||||
'hello';
|
||||
"world";
|
||||
"\"\u";//反斜杠转义字符，Unicode字符
|
||||
`h
|
||||
ll
|
||||
o`;//反引号多行字符串
|
||||
```
|
||||
|
||||
### 数组（列表）
|
||||
```
|
||||
[1,2,3.14,'hello',null,true];
|
||||
new Array(1,2,3);
|
||||
var arr =[1,2,3.14,'hello',null,true];
|
||||
arr[0];
|
||||
```
|
||||
### 对象（字典，集合，键值对）
|
||||
|
||||
```
|
||||
var person ={
|
||||
name:'bob',
|
||||
age:20,
|
||||
tags:['js','web'],
|
||||
zipcode:null
|
||||
};
|
||||
```
|
||||
### 变量
|
||||
```
|
||||
var a;//不强调类型
|
||||
var b = 1;
|
||||
```
|
||||
|
||||
## 4 字符串
|
||||
|
||||
### 模板字符串
|
||||
```
|
||||
var name = 'xiaoming';
|
||||
var message= "hello" + "world"+name;//两种字符串拼接的办法，通过加号连接。
|
||||
var message = 'hello world ${name}';//两种字符串拼接的方法，模板字符串
|
||||
```
|
||||
|
||||
### 字符串访问
|
||||
|
||||
```
|
||||
var s = 'Hello,world!';
|
||||
s.length//长度属性，字符串看成对象。
|
||||
s[0]//访问字符，字符串看成列表、集合、数组。
|
||||
s[0]='t';//下标只能访问，不能修改字符串，字符串是不可变的。
|
||||
```
|
||||
|
||||
### 字符串操作
|
||||
```
|
||||
var s='Hello';
|
||||
s.toUpperCase();
|
||||
s.toLowerCase();
|
||||
s.indexOf('lo');//字符串首次出现的位置。
|
||||
s.substring(0,5);//字字符串
|
||||
```
|
||||
|
||||
## 数组
|
||||
|
||||
### 数组访问与修改
|
||||
```
|
||||
var arr = [1,2,3];
|
||||
arr.length;//=3
|
||||
arr.length=6;
|
||||
arr[1]=99;//数组内容与长度均可变。长度变为6
|
||||
```
|
||||
> 如果通过索引赋值时，索引超过了范围，同样会引起Array大小的变化：
|
||||
```
|
||||
var arr = [1, 2, 3];
|
||||
arr[5] = 'x';
|
||||
arr; // arr变为[1, 2, 3, undefined, undefined, 'x']
|
||||
```
|
||||
|
||||
### 数组的操作
|
||||
```
|
||||
var arr = [10,20,'30','xyz'];
|
||||
arr.indexOf(10);
|
||||
arr.slice(0,3);//切片操作
|
||||
arr.push('a','b');//向末尾加入多个元素
|
||||
arr.pop();//去掉最后一个元素
|
||||
arr.unshift('a','b');//向开头加入多个元素
|
||||
arr.shift();//去掉第一个元素并返回。
|
||||
arr.sort();//默认方法排序。
|
||||
arr.reverse();//array 反转
|
||||
arr.splice(2,3,'google',88);//从指定位置开始删除若干元素，然后，添加若干元素。
|
||||
var added = arr.concat([1,2,3]);//连接另一个数组，并返回新的数组
|
||||
arr.join('-');//用指定字符连接数组元素
|
||||
```
|
||||
### 多维数组
|
||||
|
||||
```
|
||||
var arr= [[1,2,3],[400,500,600],'0'];
|
||||
arr[1][1];//=500
|
||||
```
|
||||
|
||||
## 6 对象
|
||||
|
||||
### 对象访问
|
||||
```
|
||||
var xiaoming = {
|
||||
name:'xiaoming',
|
||||
birth:1990,
|
||||
'weight':333
|
||||
};
|
||||
|
||||
xiaoming.name;//'xiaoming'通过点运算符访问。
|
||||
xiaohong['middle-school'];//访问特殊字符的键。只能用下标的方式。
|
||||
```
|
||||
|
||||
### 对象修改
|
||||
|
||||
```
|
||||
var xiaoming = {
|
||||
name: '小明'
|
||||
};
|
||||
xiaoming.age; // undefined
|
||||
xiaoming.age = 18; // 新增一个age属性
|
||||
xiaoming.age; // 18
|
||||
delete xiaoming.age; // 删除age属性
|
||||
xiaoming.age; // undefined
|
||||
delete xiaoming['name']; // 删除name属性
|
||||
xiaoming.name; // undefined
|
||||
delete xiaoming.school; // 删除一个不存在的school属性也不会报错
|
||||
|
||||
'name' in xiaoming;//检查属性是否存在。
|
||||
```
|
||||
|
||||
###
|
||||
|
||||
## 7 运算符
|
||||
> NaN与NaN也不相等。使用isNaN()判断是否为数值类型。
|
||||
```
|
||||
+ - * / %;//基本运算符
|
||||
> < >= <= ==（强制类型转换） ===（包括类型）;//比较运算符
|
||||
! && || ;//逻辑运算符
|
||||
```
|
||||
30
JavaScript/JavaScript程序结构.md
Normal file
30
JavaScript/JavaScript程序结构.md
Normal file
@@ -0,0 +1,30 @@
|
||||
## 1 条件判断
|
||||
|
||||
### if-else
|
||||
```
|
||||
var age = 20;
|
||||
if (age >= 18) { // 如果age >= 18为true，则执行if语句块
|
||||
alert('adult');
|
||||
} else { // 否则执行else语句块
|
||||
alert('teenager');
|
||||
}
|
||||
//else是可选的
|
||||
//如果语句块只有一句话，可以省略大括号。
|
||||
```
|
||||
|
||||
### if-else可以嵌套
|
||||
|
||||
```
|
||||
var age = 3;
|
||||
if (age >= 18) {
|
||||
alert('adult');
|
||||
} else {
|
||||
if (age >= 6) {
|
||||
alert('teenager');
|
||||
} else {
|
||||
alert('kid');
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
31
Python/Python文件理解.md
Normal file
31
Python/Python文件理解.md
Normal file
@@ -0,0 +1,31 @@
|
||||
# Python文件理解
|
||||
|
||||
## 后缀名理解
|
||||
|
||||
### py
|
||||
py就是最基本的源码扩展名。windows下直接双击运行会调用python.exe执行。
|
||||
|
||||
### pyw
|
||||
pyw是另一种源码扩展名，跟py唯一的区别是在windows下双击pyw扩展名的源码会调用pythonw.exe执行源码，这种执行方式不会有命令行窗口。主要用于GUI程序发布时不需要看到控制台信息的情况。
|
||||
|
||||
### pyc
|
||||
在执行python代码时经常会看到同目录下自动生成同名的pyc文件。这是python源码编译后的字节码，一般会在代码执行时自动生成你代码中引用的py文件的pyc文件。这个文件可以直接执行，用文本编辑器打开也看不到源码。
|
||||
|
||||
### pyo
|
||||
pyo是跟pyc类似的优化编码后的文件。
|
||||
|
||||
### pyd
|
||||
pyd并非从python程序生成，而是其他语言写成的可以被python调用的扩展。
|
||||
|
||||
### whl
|
||||
whl格式本质上是一个压缩包，里面包含了py文件，以及经过编译的pyd文件。使得可以在不具备编译环境的情况下，选择合适自己的python环境进行安装。
|
||||
|
||||
## 原理解释
|
||||
1. 编译实现的语言，如：C、C++、Fortran、Pascal、Ada。由编译型语言编写的源程序需要经过编译,汇编和链接才能输出目标代码，然后由机器执行目标代码。目标代码是有机器指令组成，不能独立运行，因为源程序中可能使用了一些汇编程序不能解释引用的库函数，而库函数又不在源程序中，此时还需要链接程序完成外部引用和目标模板调用的链接任务，最后才能输出可执行代码。
|
||||
|
||||
2. 解释型语言，解释器不产生目标机器代码，而是产生中间代码，这种中间代码与机器代码不同，中间代码的解释是由软件支持的，不能直接使用在硬件上。该软件解释器通常会导致执行效率较低，用解释型语言编写的程序是由另一个可以理解中间代码的解释程序执行的。和编译的程序不同的是, 解释程序的任务是逐一将源代码的语句解释成可执行的机器指令，不需要将源程序翻译成目标代码再执行。对于解释型语言，需要一个专门的解释器来执行该程序，每条语句只有在执行是才能被翻译，这种解释型语言每执行一次就翻译一次，因而效率低下。
|
||||
|
||||
3. Java解释器，java很特殊，java是需要编译的，但是没有直接编译成机器语言，而是编译成字节码，然后在Java虚拟机上用解释的方式执行字节码。Python也使用了类似的方式，先将python编译成python字节码，然后由一个专门的python字节码解释器负责解释执行字节码。
|
||||
4. python是一门解释语言，但是出于效率的考虑，提供了一种编译的方法。编译之后就得到pyc文件，存储了字节码。python这点和java很类似，但是java与python不同的是，python是一个解释型的语言，所以编译字节码不是一个强制的操作，事实上，编译是一个自动的过程，一般不会在意它的存在。编译成字节码可以节省加载模块的时间，提高效率。
|
||||
5. 除了效率之外，字节码的形式也增加了反向工程的难度，可以保护源代码。这个只是一定程度上的保护，反编译还是可以的。
|
||||
|
||||
2
Springboot/简介.md
Normal file
2
Springboot/简介.md
Normal file
@@ -0,0 +1,2 @@
|
||||
利用控制反转的核心特性，并通过依赖注入实现控制反转来实现管理对象生命周期容器化，利用面向切面编程进行声明式的事务管理，整合多种持久化技术管理数据访问，提供大量优秀的Web框架方便开发等等。
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 49 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 91 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 69 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 30 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 110 KiB |
@@ -1,18 +0,0 @@
|
||||
# OODA环
|
||||
|
||||
## 1 OODA环结构
|
||||
观察-判断-决策-执行
|
||||
|
||||
|
||||
## 2 过程
|
||||
|
||||
|
||||
* 第一阶段为观察(Observation), 要是通过各种传感设备和网络的运用进行情报收集，例如，预警探测的信息、战场环境的信息、敌方坐标信息等。
|
||||
* 第二阶段为判断(Orientation) ，战场态势瞬息万变、并且有很大的不确定性,判断就是将数据转化为有用的信息,有效、快速地判断结果能够辅助指挥员做出正确的决策，甚至改变战场态势。
|
||||
* 第三阶段为决策(Decision) ，就是指挥员明确制定任务方案、下达作战计划。 决策的迅速形成对战场态势有着决定性意义。
|
||||
* 第四阶段为行动(Action) ， 战场上的行动通常描述为根据上级下达的作战计划采取相应的作战部署，并进行动作行为。
|
||||
|
||||
## 3 改进
|
||||
|
||||
* 第一是在判断阶段引入专家系统，并将专家系统的规则库与数据库相结合。首先先，专家系统能够辅助指挥员在信息处理过程中迅速、精准地做出决策建议。其次，将作战指挥数据库中的数据按照专家系统规则库的规则模式存储,利用作战指挥数据库信息丰富的优势扩充专家系统的判断范围，进而为作战决策提供更为精准的辅助指导。
|
||||
* 第二是对整个系统引入反馈机制，即通过神经网络的自学习能力不断丰富作战指挥数据库。将决策阶段的作战计划和行动阶段的战场实际态势做差值计算得出误差值，将误差值按照一定规则输入神经网络;神经网络通过其自学习功能将本次作战情况输送至判断阶段用于辅助下一次作战决策判断。可以看到，引入反馈机制可将作战情况及时地以某种方式传递给作战指挥数据库，丰富其信量,从而有效缩短辅助判断时间，并提高辅助决策的精准度。
|
||||
@@ -1,68 +0,0 @@
|
||||
# 任务调度
|
||||
|
||||
## 1 概念
|
||||
调度问题研究的是将资源分配给在一定时间内的不同任务，其目的是优化一个或多个目标。
|
||||
|
||||
车间调度问题研究的是根据一定的约束条件，如何合理配置生产过程中的各种资源，合理安排生产加工任务的加工时间、加工顺序等，从而优化一个或多个调度性能指标。
|
||||
|
||||
车间调度问题一般可以简单描述为：《个工件在台机器设备上进行加工，每个工件有道加工工序，在满足约束条件的前提下，对每一合机器寻找合理的加工顺序，从而优化一个或多个调度性能指标。
|
||||
|
||||
|
||||
## 2 车间调度的性能指标分为以下大类：
|
||||
|
||||
### 基于完成时间的性能指标
|
||||
完成时间是指加工完所有工件的所有工序的时间，基于完成时间的性能指标是衡量调度性能的最根本指标，能体现车间的生产效率，也是车间调度研究领域应用最广泛的性能指标，主要包括：
|
||||
* 最大完成时间
|
||||
* 平均完成时间
|
||||
* 最大流经时间
|
||||
* 总流经时间
|
||||
* 加权流经时间
|
||||
* 平均流经时间
|
||||
* 加权平均流经时间
|
||||
### 基于交货期的性能指标
|
||||
交货期是企业签订订单时向客户承诺的交货时间，根据每个工件的完成时间，基于交货期的性能指标主要包括：
|
||||
* 最大提前时间
|
||||
* 最大延迟时间
|
||||
* 平均提前时间
|
||||
* 平均延迟时间
|
||||
* 加权平均提前时间
|
||||
* 加权平均延迟时间
|
||||
### 基于成本的性能指标
|
||||
工件在加工过程中除了上述时间指标外，成本指标也是衡量调度效果的指标之一。除了工件加工成本外，有时还要考虑与工件加工有关的在制品存储、成品存储等的库存成本，同时，当设备机器处于不同的地理位置时，还要考虑工件在机器设备间的物流成本。在准时生产模式中，提前或延迟完工交货对企业都是不利的，都要受到相应的惩罚，所以，还存在与交货期有关的成本。基于成本的性能指标主要包括：
|
||||
* 加工成本
|
||||
* 库存成本
|
||||
* 物流成本
|
||||
* 交货期有关的惩罚成本
|
||||
### 基于机器负荷的指标
|
||||
柔性作业车间调度时，首先要为每道工序选择加工机器，不同的调度方案为工序分配的机器也不同，从而造成每台机器负荷和所有机器总负荷也不同。最大负荷的机器可能成为瓶颈机器，从而影响车间调度优化的质量和设备资源的均衡利用，机器负荷可以作为衡量机器利用率的指标，常用的两个指标为：
|
||||
* 最大机器负荷
|
||||
* 机器总负荷
|
||||
|
||||
### 基于加工质量的指标
|
||||
|
||||
对于具有柔性工艺路线的生产调度，由于机器性能不同，同一工件因选择加工机器的不同，很可能导致其加工质量不同。在客户越来越关注产品质量的要求下，企业在调度时有时还要考虑加工质量这一性能指标
|
||||
* 加工质量
|
||||
|
||||
## 3 当前研究的内容分类
|
||||
### 根据任务工艺路线特点，把车间调度问题分为以下7类：
|
||||
|
||||
柔性作业车间调度问题柔性作业车间调度问题是作业车间调度问题的扩展，每道工序可能可以由多台机器加工。零件各工序的加工设备可能未事先指定且不唯一，工序可在一组相同功能的加工设备中任选一台加工。与作业车间调度问题相比，柔性作业车间调度问题更加接近实际生产情况，同时问题也变得更加复杂。
|
||||
|
||||
### 根据任务到达加工系统的特点，可分为2类：
|
||||
|
||||
动态车间调度：工件依次进入待加工状态，各个加工任务或工件不断进入系统接受加工，完成加工的加工任务或工件又不断离开。同时，考虑零件在加工过程中出现的各种意外情况，这种调度方式要求调度能随时响应车间加工能力的变化，在有突发事件出现后，能立即根据当时的车间加工能力，不断地进行再调度。
|
||||
|
||||
### 根据资源约束数量，车间调度问题可分为类：
|
||||
|
||||
多资源车间调度：同时有两种以上的工件加工所需资源制约着车间的生产能力，这些资源包括机床设备、操作人员、物料运送系统以及其它辅助资源等，多资源车间调度问题是最复杂的一种。
|
||||
|
||||
|
||||
### 按时间特点划分，可分为类：
|
||||
|
||||
确定性调度：工件的加工时间及相关参数为确定的已知量。
|
||||
不确定性调度：工件的加工时间及相关参数为不确定的随机变量。
|
||||
|
||||
### 按优化目标数量划分，可分为类：
|
||||
单目标车间调度：此类车间调度问题仅有一个优化目标。
|
||||
多目标车间调度：此类车间调度问题有两个或两个以上优化目标。对于多目标调度问题，通常没有最优解，需在各个非劣解之间进行平衡择优。
|
||||
|
||||
119
lab/关键技术：协同策略.md
119
lab/关键技术：协同策略.md
@@ -1,119 +0,0 @@
|
||||
> 主要论述这次论文阅读的结果。回答相关的问题。（2000字）
|
||||
|
||||
|
||||
## 1 什么是协同
|
||||
|
||||
### 自组织
|
||||
自组织是一种现象、过程，可以描述为“如果系统在获得空间的、时间的或功能的结构过程中，没有外界干扰，则系统是自组织的。”。自组织理论主要研究复杂的自组织系统的形成与机制。例如一群工人在没有外部命令，依靠相互的默契，工人们协同工作完成产品生成，这个过程成为自组织。
|
||||
|
||||
自组织主要包括耗散结构理论、突变论、协同论。耗散结构理论研究自组织系统与环境之间的无知和能量交换，以及其对自组织系统的影响。突变论研究自组织系统稳定状态的描述与自组织系统在不同稳定状态之间的变换。协同论主要研究了系统内部各个要素之间的协同机制，系统各个要素之间的协同是自组织过程的基础。
|
||||
|
||||
自组织现象具有以下特点：
|
||||
1. 信息共享。系统中个体，掌握全套的规则，能够独立实现所有活动周期。例如每一个细胞都拥有生物体所有的遗传信息DNA。
|
||||
2. 单元自律。系统中的个体，具有独立决策的能力，它能够决定自己下一步的行动。
|
||||
3. 短程通信。每个个体需要与邻近的个体进行通信。每个个体的信息往往是不完整的。
|
||||
4. 微观决策。每个个体的决策关乎本身的行为，而与系统中其他个体的决策无关。所有个体的行为总和决定了系统的宏观行为。
|
||||
5. 并行操作。系统中各个个体的决策与行动是并行的，相互之间不需要按照标准进行排队，决定执行顺序。
|
||||
6. 整体协调。在各个单元并行决策与行动下，系统结构和游戏规则保证了整个系统的协调一致性和稳定性。
|
||||
7. 迭代趋优。自组织系统的宏观调整在反复迭代中不断趋于优化。经常会在平衡态周围波动。
|
||||
|
||||
|
||||
### 协同论
|
||||
协同论主要研究远离平衡态的开放系统，在与外界进行物质和能量交换的情况下，如何通过自己内部个体的协同作用，自发地出现时间、空间和功能上的有序结构。描述了各种系统和现象中从无序向有序转变的共同规律。研究自组织的形成与演化，主要研究个体之间的相互作用机制。
|
||||
|
||||
|
||||
### 自组织理论与协同论的关系
|
||||
|
||||
自组织理论是一种宏观的系统理论。它描述了系统整体表现出来的宏观现象。协同论研究系统中个体之间的作用机制，以及完成自组织的过程。协同论是自组织理论的一部分。
|
||||
|
||||
### 自组织协同的优势
|
||||
|
||||
1. 支持简单扩展。新节点的加入不需要对整体进行调整。
|
||||
2. 个体的简单机制，总体的复杂行为。问题日益复杂化，通过个体的简单规则，实现总体的复杂行为，解决复杂问题。
|
||||
|
||||
|
||||
### Collaboration与Synergy
|
||||
|
||||
在英文中比较严格区分Collaboration与Synergy。Synergy专门指协同论或协同学中的协同，强调复杂系统通过个体之间的协同作用实现自组织过程，产生协同效用。Collaboration指协作，强调多个部门之间合作，协调各自的行为和活动，以达到共同的目标。（这种协作可以是生产链上的先后关系，某一个程序的先后步骤）。在中文，不对协同与协作进行严格区分，协同与协作泛指不同个体之间的合作。
|
||||
|
||||
## 2 协同方案与协同算法
|
||||
|
||||
### 协同方案
|
||||
|
||||
|
||||
|
||||
协同方案主要包括两个方面。
|
||||
|
||||
* 行为协同。主要实现了多个智能体之间的行为一致性。通过交换信息实现一致性控制，使得所有的智能体中知道其他智能体的意图、行为动作，从而不同智能体各个活动之间的协调和情报共享。主要研究智能体之间的通信协议和通信方式。通信协议描述通信的流程（如订阅发布机制，广播机制），通信方式描述了通信的媒介和手段（如以太网通信，WLAN通信等）。另外行为协同还包括群集控制（避免智能体之间产生矛盾）、汇合控制（定义智能体的终止状态）、包含控制、网络控制（搭建智能体之间的通信网络）等。
|
||||
* 任务协同。主要实现了整体任务的分配与分布式执行。将整体的策略，分解为各个子任务，然后分配到各个节点进行执行。各个智能体通过相互协商实现任务的动态分配。
|
||||
|
||||
|
||||
|
||||
行为协同方案主要有一下几种：
|
||||
|
||||
|
||||
* 基于异步通信的一致性控制方案。建立智能体之间的额异步通信机制，实现智能体之间的协同。（通信协议）
|
||||
* 基于事件驱动的一致性控制方案。单个智能体发生了某些事件，影响了总体的情报，驱动各个智能体交换情报进行通信。（通信协议）
|
||||
* 基于订阅发布机制的一致性控制方案。智能体通过订阅临近智能体的情报，实现情报共享和行为协同。（通信协议）
|
||||
* 基于WLAN无线网络实现的一致性控制方案。（通信方式）
|
||||
|
||||
任务协同方案主要有一下几种：
|
||||
|
||||
|
||||
|
||||
任务协同方案主要有以下几种分类：
|
||||
|
||||
* 集中式任务协同。多智能体的协同算法在单个机器上运行。通过信息交互实现任务的分配与部署。可以竞选领导者，也可以指定领导者。
|
||||
* 分布式任务协同。多智能体协同算法在不同的及其上运行。增加了通信的代价。
|
||||
* 分散式任务协同。智能体独立的决策、组织、规划、执行、情报处理能力，通过信息交互实现任务的协同。这个也是自组织过程的一部分。
|
||||
|
||||
### 协同算法
|
||||
|
||||
|
||||
行为协同主要有分布式网络节点间的通信模型实现。任务协同主要有分布式网络节点间的任务部署算法实现。
|
||||
|
||||
任务协同算法：
|
||||
* 分支限界、动态规划
|
||||
* 禁忌搜索、遗传算法
|
||||
* 粒子群算法、蜂群算法等启发式算法。
|
||||
* 市场机制算法（拍卖机制）
|
||||
* 马尔科夫决策过程
|
||||
* 博弈论
|
||||
|
||||
|
||||
## 3 什么是群体智能
|
||||
|
||||
### 概念
|
||||
|
||||
个体通过与群内其它个体的连接、信息交流、沟通,产生群体的智能行为。
|
||||
|
||||
它可以作为任务协同的一个具体实现算法。
|
||||
|
||||
### 特点
|
||||
* 自组织的（self orgnization）
|
||||
* 分布式的（distributed）没有中心的控制与数据。
|
||||
* 个体简单，群体复杂，信息交流。
|
||||
* 可扩充。
|
||||
|
||||
## 4 多源协同探测技术中的协同（本次修改的方向）
|
||||
|
||||
### 协同探测面向的对象
|
||||
不同的网络节点
|
||||
|
||||
### 协同探测实现的目标
|
||||
1. 实现网络节点之间的行为协同，保证情报共享和不同智能体之间的活动协调
|
||||
2. 实现网络节点之间的任务协同，实现网络节点的高效利用，完成动态负载均衡。
|
||||
|
||||
### 协同探测过程的特点
|
||||
|
||||
* 动态任务分配
|
||||
### 协同的具体过程
|
||||
|
||||
* 行为协同，实现网络节点的一致性，包括各个活动之间的协同。
|
||||
* 任务协同，实现网络节点的任务分配。
|
||||
|
||||
### 协同的具体算法
|
||||
|
||||
* 暂定为蜂群算法（应该将这种集中式的任务协同方案，改为分散式的任务协同方案。）
|
||||
|
||||
> 修改原本的文章。（2000字）
|
||||
87
lab/关键词说明.md
87
lab/关键词说明.md
@@ -1,87 +0,0 @@
|
||||
# 关键词
|
||||
* **自组织**
|
||||
* **自适应**
|
||||
* **分布式**
|
||||
* **协同**
|
||||
## 1 自组织
|
||||
|
||||
### 定义
|
||||
一般来说，组织是指系统内的有序结构或这种有序结构的形成过程。从组织的进化形式来看，可以把它分为两类：他组织和自组织。如果一个系统靠外部指令而形成组织，就是他组织；如果不存在外部指令，系统按照相互默契的某种规则，各尽其责而又协调地自动地形成有序结构，就是自组织。
|
||||
|
||||
自组织理论是20世纪60年代末期开始建立并发展起来的一种系统理论。
|
||||
它的研究对象主要是复杂自组织系统（生命系统、社会系统）的形成和发展机制问题，即在一定条件下，系统是如何自动地由无序走向有序，由低级有序走向高级有序的。
|
||||
> 群体智能是一种自组织，因为每一个个体都有自己的行动方式，从而完成组织方式。而不是由群体之外的某个大脑指挥，完成组织过程。
|
||||
|
||||
> 组织是一种向有序转变的过程。是一个熵减得过程。
|
||||
|
||||
### 不同领域对自组织的描述
|
||||
|
||||
* 从系统论的观点来说，"自组织"是指一个系统在内在机制的驱动下，自行从简单向复杂、从粗糙向细致方向发展，不断地提高自身的复杂度和精细度的过程；
|
||||
* 从热力学的观点来说，"自组织"是指一个系统通过与外界交换物质、能量和信息，而不断地降低自身的熵含量，提高其有序度的过程；
|
||||
* 从统计力学的观点来说，"自组织"是指一个系统自发地从最可几状态向几率较低的方向迁移的过程；
|
||||
* 从进化论的观点来说，"自组织"是指一个系统在"遗传"、"变异"和"优胜劣汰"机制的作用下，其组织结构和运行模式不断地自我完善，从而不断提高其对于环境的适应能力的过程。C. R. Darwin的生物进化论的最大功绩就是排除了外因的主宰作用，首次从内在遗传突变的自然选择机制的过程中来解释物种的起源和生物的进化；
|
||||
* 从结构论- 泛进化理论的观点来说，"自组织"是指一个开放系统的结构稳态从低层次系统向高层次系统的构造过程，因系统的物质、能量和信息的量度增加，而形成比如生物系统的分子系统、细胞系统到器官系统乃至生态系统的组织化度增加，基因数量和种类自组织化和基因时空表达调控等导致生物的进化与发育（Evo-Dev）过程。
|
||||
|
||||
### 理论组成
|
||||
|
||||
1. 耗散结构论
|
||||
主要研究系统与环境之间的物质与能量交换关系及其对自组织系统的影响等问题。建立在与环境发生物质、能量交换关系基础上的结构即为耗散结构，如城市、生命等。远离平衡态、系统的开放性、系统内不同要素间存在非线性机制、系统的涨落是耗散结构出现的四个基本条件。远离平衡态，指系统内部各个区域的物质和能量分布是极不平衡的，差距很大。
|
||||
2. 协同论
|
||||
主要研究系统内部各要素之间的协同机制，认为系统各要素之间的协同是自组织过程的基础，系统内各序参量之间的竞争和协同作用是系统产生新结构的直接根源。涨落是由于系统要素的独立运动或在局部产生的各种协同运动以及环境因素的随机干扰，系统的实际状态值总会偏离平均值，这种偏离波动大小的幅度就叫涨落。当系统处在由一种稳态向另一种稳态跃迁时，系统要素间的独立运动和协同运动进入均势阶段时，任一微小的涨落都会迅速被放大为波及整个系统的巨涨落，推动系统进入有序状态。
|
||||
3. 突变论
|
||||
它建立在稳定性理论的基础上，认为突变过程是由一种稳定态经过不稳定态向新的稳定态跃迁的过程，表现在数学上是标志着系统状态的各组参数及其函数值变化的过程。突变论认为，即使是同一过程，对应于同一控制因素临界值，突变仍会产生不同的结果，即可能达到若干不同的新稳态，每个状态都呈现出一定的概率。
|
||||
4. 协同动力论
|
||||
有三大要点：第一，在大量子系统存在的事物内部，在平权输入必要的物质、能量和信息的基础上，须激励竞争，形成影响和相互作用的网络；第二，提倡合作，形成与竞争相抗衡的必要的张力，并不受干扰地让合作的某些优势自发地、自主地形成更大的优势；第三，一旦形成序参量后，要注意序参量的支配不能采取被组织方式进行，应按照体系的自组织过程在序参量支配的规律下组织系统的动力学过程。这可能产生两种有序运动，一种即数量化的水平增长其复杂性和组织程度的演化，另一种则是突变式的组织程度跃升动力学演化。
|
||||
5. 演化路径论
|
||||
它认为：演化的路径具有多样性，有三条路径，一是经过临界点或临界区域的演化路径，演化结局难以预料，小的激励极可能导致大的涨落；二是演化的间断性道路，有大的跌宕和起伏，常出现突然的变化，其间大部分演化路径可以预测，但有些区域或结构点不可预测；三是渐进的演化道路，路径基本可以预测。突变论所利用的形态演化方法（结构化方法）在整体背景上进行自组织演化路径的突变可能性分析，为研究者提供了一个整体观。
|
||||
6. 混沌论
|
||||
它对研究复杂性的非线性方法具有重大贡献。首先，混沌不仅可以出现在简单系统中，而且常常通过简单的规则就能产生混沌。简单系统能够产生复杂行为，复杂系统也能够产生简单行为。分层、分岔、分支、锁定、放大，非线性的发展或演化过程就是这样神奇而不可预测；其次，非线性动力学混沌是内在的，固有的，而不是外加的、外生的。尤其是在管理中的混沌特性决定了“混沌管理”方法的非最优化和不确定性。企业并不追求最优化和最高效率——这是由稳定的管理价值观所决定的；管理过程与结果之间无决定的直接的关系。
|
||||
|
||||
## 2 自适应
|
||||
|
||||
### 概念
|
||||
* **自适应**就是在处理和分析过程中，根据处理数据的数据特征自动调整处理方法、处理顺序、处理参数、边界条件或约束条件，使其与所处理数据的统计分布特征、结构特征相适应，以取得最佳的处理效果的过程。
|
||||
|
||||
* **自适应算法**是根据某个最优准则来设计的。自适应算法所采用的最优准则有最小均方误差(LMS)准则，最小二乘(LS)准则、最大信噪比准则和统计检测准则等。LMS算法和RLS算法由于采用的最优准则不同，因此这两种算法在性能，复杂度等方面均有许多差别。常用的自适应算法有迫零算法，最陡下降算法，LMS算法，RLS算法以及各种盲均衡算法等。
|
||||
|
||||
* **自适应控制**可以看作是一个能根据环境变化智能调节自身特性的反馈控制系统以使系统能按照一些设定的标准工作在最优状态。
|
||||
|
||||
* **自适应系统**是这样一种控制系统，它能够修正自己的特性以适应对象和扰动的动特性的变化。这种自适应控制方法可以做到：在系统运行中，依靠不断采集控制过程信息，确定被控对象的当前实际工作状态，优化性能准则，产生自适应控制规律，从而实时地调整控制器结构或参数，使系统始终自动地工作在最优或次最优的运行状态。
|
||||
|
||||
|
||||
### 特点
|
||||
自适应一般有有一下特点：
|
||||
* 反馈机制，根据运行结果，调整策略。
|
||||
* 动态变化，随着数据集的碰撞，不断递归地优化模型。
|
||||
|
||||
自适应控制所依据的关于模型和扰动的先验知识比较少，需要在系统的运行过程中去不断提取有关模型的信息，使模型逐步完善。
|
||||
|
||||
## 3 分布式
|
||||
|
||||
### 概念
|
||||
在一个分布式系统中，一组独立的计算机展现给用户的是一个统一的整体，就好像是一个系统似的。系统拥有多种通用的物理和逻辑资源，可以动态的分配任务，分散的物理和逻辑资源通过计算机网络实现信息交换。系统中存在一个以全局的方式管理计算机资源的分布式操作系统。
|
||||
|
||||
### 分类
|
||||
|
||||
分布式计算机系统的体系结构可用处理机之间的耦合度为主要标志来加以描述。耦合度是系统模块之间互联的紧密程度，它是数据传输率、响应时间、并行处理能力等性能指标的综合反映，主要取决于所选用体系结构的互联拓扑结构和通信链路的类型。
|
||||
|
||||
* 第一种是面向计算任务的分布并行计算机系统和分布式多用户计算机系统
|
||||
* 第二种是面向管理信息的分布式数据处理系统。
|
||||
* 第三种是面向过程控制的分布式计算机控制系统。
|
||||
|
||||
|
||||
### 特点
|
||||
|
||||
分布式系统是多个处理机通过通信线路互联而构成的松散耦合的系统。从系统中某台处理机来看，其余的处理机和相应的资源都是远程的，只有它自己的资源才是本地的。至今，对分布式系统的定义尚未形成统一的见解。一般认为，分布式系统应具有以下四个特征：
|
||||
* (1)分布性。分布式系统由多台计算机组成，它们在地域上是分散的，可以散布在一个单位、一个城市、一个国家，甚至全球范围内。整个系统的功能是分散在各个节点上实现的，因而分布式系统具有数据处理的分布性。
|
||||
* (2)自治性。分布式系统中的各个节点都包含自己的处理机和内存，各自具有独立的处理数据的功能。通常，彼此在地位上是平等的，无主次之分，既能自治地进行工作，又能利用共享的通信线路来传送信息，协调任务处理。
|
||||
* (3)并行性。一个大的任务可以划分为若干个子任务，分别在不同的主机上执行。
|
||||
* (4)全局性。分布式系统中必须存在一个单一的、全局的进程通信机制，使得任何一个进程都能与其他进程通信，并且不区分本地通信与远程通信。同时，还应当有全局的保护机制。系统中所有机器上有统一的系统调用集合，它们必须适应分布式的环境。在所有CPU上运行同样的内核，使协调工作更加容易。
|
||||
|
||||
### 优点
|
||||
|
||||
* (1)资源共享。若干不同的节点通过通信网络彼此互联，一个节点上的用户可以使用其他节点上的资源，如分布式系统允许设备共享，使众多用户共享昂贵的外部设备，如彩色打印机；允许数据共享，使众多用户访问共用的数据库；可以共享远程文件，使用远程特有的硬件设备（如高速阵列处理器），以及执行其他操作。
|
||||
* (2)加快计算速度。如果一个特定的计算任务可以划分为若干个并行运行的子任务，则可把这些子任务分散到不同的节点上，使它们同时在这些节点上运行，从而加快计算速度。另外，分布式系统具有计算迁移功能，如果某个节点上的负载太重，则可把其中一些作业移到其他节点去执行，从而减轻该节点的负载。这种作业迁移称为负载平衡。
|
||||
* (3)可靠性高。分布式系统具有高可靠性。如果其中某个节点失效了，则其余的节点可以继续操作，整个系统不会因为一个或少数几个节点的故障而全体崩溃。因此，分布式系统有很好的容错性能。
|
||||
系统必须能够检测节点的故障，采取适当的手段，使它从故障中恢复过来。系统确定故障所在的节点后，就不再利用它来提供服务，直至其恢复正常工作。如果失效节点的功能可由其他节点完成，则系统必须保证功能转移的正确实施。当失效节点被恢复或者修复时，系统必须把它平滑地集成到系统中。 [3]
|
||||
* (4)通信方便、快捷。分布式系统中各个节点通过一个通信网络互联在一起。通信网络由通信线路、调制解调器和通信处理器等组成，不同节点的用户可以方便地交换信息。在低层，系统之间利用传递消息的方式进行通信，这类似于单CPU系统中的消息机制。单CPU系统中所有高层的消息传递功能都可以在分布式系统中实现，如文件传递、登录、邮件、Web浏览和远程过程调用( Remote Procedure call，RPC)。 [3]
|
||||
@@ -1,51 +0,0 @@
|
||||
## 1 研究方向
|
||||
> 这些东西都是自己凭空臆想出来的，只是，我觉得面对这个问题，我应该从这些思路去解决，显然不具有科学性。现在要做的是，完成自己的臆想。然后阅读材料，对自己的臆想进行修正。
|
||||
|
||||
> 以后研究的主要方向可能就是这个，关于群体智能在计算机网络自组织利用中的应用方案。而且是基于这个项目完成这一次的研究生毕业设计。
|
||||
|
||||
> 对自组织的理论有浓厚的兴趣。自组织是生物界的典型线性，个体自组织成为种群，细胞自组织成为个体，表现出一种智能的行为。我想这种行为应该也可以应用到机器智能、计算智能上。记得不久前，想过哔哩哔哩共享同步观看视频，满足异地恋的需求，后来就出现了微光。记得之前就想过，用计算机模拟细胞，实现微观简单逻辑生成的高级智能行为，后来就听说了“微智能”（貌似是这个）或者说群体智能。我觉这是冥冥之中的指引。
|
||||
### 主要方向
|
||||
|
||||
* 基于群体智能的
|
||||
* 组织协同方案
|
||||
|
||||
> 使用群体智能的理论，完成自组织与协同方案。
|
||||
|
||||
### 分支技术
|
||||
|
||||
* 群体智能的研究：原理、算法、应用、前沿。
|
||||
* 协同策略的研究：动态平衡、反馈控制、自动扩展。
|
||||
* 节点自组织研究：数学模型的抽象、自组织过程。
|
||||
|
||||
> 大致说明一下，组织的过程，是群体通过某种机制完成内部协调达到平衡的过程。协同的过程，是当组织受到外部刺激后，对外部刺激的共同反应过程。组织的结果是形成静态的结构。协同的结果是完成动态的响应。所以这里做研究的手，应该将组织方案，与协同策略分开研究。
|
||||
|
||||
> 协同与组织的关系：组织包含自组织和他组织。自组织即系统内部的每个个体通过自身的机制，完成整个系统的平衡。自组织达到平衡的过程，成为协同。协同理论是自组织理论的一部分。
|
||||
|
||||
## 2 关键词
|
||||
|
||||
* 计算机
|
||||
* 网络
|
||||
* 组织与节点自组织√
|
||||
* 群体协同
|
||||
* 群体智能
|
||||
* 任务调度与任务分配
|
||||
* 动态负载均衡
|
||||
* 分布式√
|
||||
* 自适应√
|
||||
* 启发式
|
||||
|
||||
> 所以如何检索相关的文献？属于任务分配？负载均衡？群体智能？节点自组织？协同策略？多搜一搜，现在需要科普。
|
||||
|
||||
## 3 关键技术
|
||||
|
||||
### OODA循环
|
||||
|
||||
观察-判断-决策-执行
|
||||
|
||||
|
||||
|
||||
### 任务调度
|
||||
|
||||
### 组织策略
|
||||
|
||||
### 协同策略
|
||||
288
lab/项目支撑：网络探测.md
288
lab/项目支撑：网络探测.md
@@ -1,288 +0,0 @@
|
||||
## 多源异质协同探测策略
|
||||
> 动态多源协同探测策略
|
||||
要求、指标：针对不同目标、不同探测手段，协同探测策略不少于5种。具备内部网络节点自组织和协同分布式执行任务的能力，每个节点负载不超过原本负载的10%
|
||||
|
||||
## 1 任务安排
|
||||
|
||||
13号
|
||||
|
||||
上午：
|
||||
完成已有的研究内容
|
||||
完成任务目标的抽象
|
||||
|
||||
下午：
|
||||
了解多段协同的负载均衡模型
|
||||
思考通用化的负载均衡模型，使用最新技术，考虑当前研究的最优方案。
|
||||
|
||||
晚上：
|
||||
对相关模型的具体了解（至少给出五个多端协同模型）
|
||||
|
||||
14号
|
||||
|
||||
决定采取的多端协同模型
|
||||
结合任务目标进行论述
|
||||
|
||||
15号
|
||||
|
||||
探讨当前方法的合理性。
|
||||
|
||||
- 今天的任务应该首先自己臆想一套垃圾方案，然后去阅读别人的东西进行修改。本子上得东西，尽量多的用自己已经有的知识完善就好了。明天一天进行完善。开始吧，研究生生活。
|
||||
|
||||
## 2 《网络探测技术研究》已经有的研究内容
|
||||
|
||||
### 目标：
|
||||
针对目标内网主动协同探测需求，建立内网自主探测模型；突破设备信息主动收集技术；突破内网限制区域突防技术；研制内网自主探测原型系统，实现目标内网自动化探测。
|
||||
|
||||
### 自主探测模型：
|
||||
* 首先，根据自主探测模型，我们感知目标内网X态势。基于已有的经验我们可以分析出内网中的部分知识，如安防设备、主机的大致类型。
|
||||
利用启发式探测方案生成技术自动生成探测方案。
|
||||
在刚开始受控节点数量比较少的情况下，为保持探测隐蔽性，采用低频的探测手段，根据受控主机操作系统是Windows、Linux、IOS采用不同的收集手段；当受控设备数量到达阈值后，采用分布式策略加速探测。
|
||||
|
||||
* 其次，感知目标可攻破的形式。
|
||||
根据网络关键信息基础设施及相关资产信息包括，如IP地址、资产名称、服务端口、协议名称、操作系统、设备类型、厂商属性、应用组件等，寻找目标设备的弱点，
|
||||
选择武器库中的前锋武器（XSS、应用软件漏洞、操作系统漏洞、网络设备漏洞等）组成攻击方案。
|
||||
针对目标内网X中的隔离区域，首先识别隔离器类型，根据不同隔离器类型，选择DMZ突防、网闸突防、物理隔离突防策略。
|
||||
|
||||
* 最后，根据感知的态势对方案进行评估，选择合适的攻击方案。经过混淆工具对攻击方案进行加密混淆，隐蔽传输至主控服务器ControlHost，再由主控服务器将攻击工具分发给不同受控节点，攻击同一网段的关键设备。在获取其他关键设备权限后，利用控守工具与主控服务器建立控制关系，迭代的向周围其他机器展开提权攻击，逐步完成对内网的探测活动。
|
||||
|
||||
|
||||
### 多手段分布协同探测：
|
||||
|
||||
* 为提升内网探测自动化与自适应能力，研究内网自主探测体系结构与活动模型，根据系统科学及自组织对抗理论自主探测的组成活动划分为决策、组织、信息收集、区域突防、免杀逃逸、数据处理、可用评估共七项活动，并研究活动间的交互模型。自主探测模型是对执行体的运行机理建模，是设计自主探测原型系统的理论框架。
|
||||
|
||||
### 关键技术
|
||||
|
||||
1. 内网自主探测建模技术
|
||||
为提升局域网探测的自动化与自适应能力，研究局域网自主探测体系结构与活动模型，根据系统科学及自组织对抗理论自主渗透的组成活动划分为决策和组织、数据处理、信息收集、区域突防、免杀逃逸和可用评估共七项活动，并研究活动间的交互模型。自主探测模型是对执行体的运行机理建模，是设计自主探测原型系统的理论框架。
|
||||
2. 基于先验知识的启发式方案自生成技术
|
||||
面对多个场景下的探测需求，研究基于先验知识的启发式方案自生成技术，利用先验知识，通过自主决策，结合主动探测与被动探测结合的方式完成探测。先通过已有知识库构建一颗包含探测目标及探测手段的决策树，表示初始方案，通过启发式方法对决策树进行搜索。探测过程中，根据实际结果不断更新决策树，不断迭代生成探测方案。
|
||||
|
||||
## 3 任务说明
|
||||
|
||||
### 关键词
|
||||
|
||||
* 协同、自组织、负载均衡、多端协同、群体协同
|
||||
* 多目标
|
||||
* 柔性作业调度
|
||||
* 动态作业调度
|
||||
|
||||
### 任务目标：网络探测。
|
||||
|
||||
具体任务：
|
||||
|
||||
* 主机探测（主机发现、端口探测、服务和版本探测、操作系统探测）
|
||||
* 拓扑探测（SNMP、ARP、Traceroute、DNS）
|
||||
|
||||
### 任务要求：
|
||||
* 多源异质、群体协同、负载均衡、自组织分布式
|
||||
|
||||
## 4 模型抽象（问题抽象过程）
|
||||
|
||||
### 设备抽象：
|
||||
* 主控服务器、受控设备、网络关键信息基础设施称为节点
|
||||
* 节点属性信息包IP地址、资产名称、服务端口、协议名称、操作系统、设备类型、厂商属性、应用组件
|
||||
* 主机、服务器、交换机等所有的网络设备抽象为网络节点。
|
||||
* 网络节点，包含各种属性信息。（权限、操作系统、协议）
|
||||
* 网络节点，包含实时变化的动态信息，例如当前节点的负载。可以通过属性计算函数进行更新（负载计算函数）
|
||||
* 评估负载1.功能性测试。2. 抗压测试。
|
||||
* 网络节点分为受控节点和非受控节点。受控节点表示能够接受控制节点执行控制任务，非空节点表示待渗透的节点。
|
||||
* 网络节点之间存在各种依赖。使用二维矩阵描述网络节点之间的链接关系。数字表示依赖的类型。依赖的类型包括：直接连接、跨越交换机的链接、跨越路由器的链接、相互之间是否可信。
|
||||
* 由节点组成的网络会随着被控节点的增多逐渐增加。节点之间的依赖关系也会动态更新。
|
||||
* 一个节点也许有并行执行任务的能力。并不代表节点只能执行单一的任务。
|
||||
* 节点上任务的执行应该通过性能控制函数，决定当前并行执行多少任务。节点的负载应该是节点执行能力与任务量的对比。
|
||||
|
||||
### 策略抽象：
|
||||
* 文章中提到的方案：选择前锋武器（XSS、应用软件漏洞、操作系统漏洞、网络设备漏洞等）组成攻击方案。实际上得方案有端口扫描和漏洞提权。
|
||||
* 策略的指定属于外部输入。其他模块会确定攻击的目标，给出攻击的手段，制定攻击的策略。
|
||||
* 每一个策略可以分为多个原子任务，原子任务之间存在依赖。可以构成一个有向无环图。
|
||||
* 每一个策略涉及多个受控节点。需要多个受控节点合作，完成攻击策略，达成攻击目标。
|
||||
* 每个策略执行完成后，需要对策略和子任务进行评估，包括性能评估、有效性评估。这样可以通过对比，得到方案的优劣。
|
||||
|
||||
|
||||
### 任务抽象：
|
||||
* 每一个策略可以分为多个子任务、子过程执行，每个可以单独执行的子过程称为原子任务。原子任务不需要再进行分割，可以由单一节点完成。（如果可以再分则不称为原子任务）
|
||||
* 原子任务之间相互依赖。必须某些任务先完成，某些任务后完成。某些任务的输出是某些任务的输入。任务之间的依赖可以用树表示。任务之间的依赖表示了任务的优先级。
|
||||
* 原子任务之间可以没有相互依赖，比如端口扫描，可以分成十个任务，每个任务扫描各自范围的主机构成总的策略。
|
||||
* 原子任务依赖特定的节点与节点依赖类型
|
||||
* 原子任务具有初始的负载计算方法（负载初始化）
|
||||
* 原子任务具有可迁移性。如果当前节点的负载过高或者不在满足其他动态属性要求时（通过动态属性计算获得），原子任务能够自动迁移到负载相对较低的网络节点。
|
||||
* 任务是不断变换的。旧的原子任务会不断解决，新的原子任务也会不断添加到队列中
|
||||
* 任务应该也有状态。执行中的任务，已经分配的任务。
|
||||
|
||||
|
||||
## 4 任务调度模型（数学模型-动态柔性作业调度模型）
|
||||
> flexible dynamic schduling based on ABC
|
||||
> 解决第3部分提出的问题。
|
||||
|
||||
### 概述
|
||||
原子任务----分配---->受控节点。
|
||||
**实现原子任务在网络节点上得分配工作**。任务调度模型就是任务通过任务调度算法分配到网络节点中。
|
||||
|
||||
### 假设
|
||||
* 内网自主探测模型，已经完成对当前网络的描述，包括主控节点、受控节点、目标节点。
|
||||
* 基于先验知识的启发式方案自生成技术，已经完成攻击策略的描述，攻击策略包括采取的手段与攻击的目标节点。
|
||||
* 假设探测策略、探测任务的具体内容不需要考虑。主要考虑的是如何把探测策略分割成可以在不同节点执行的任务。
|
||||
* 任务一旦开始执行便不能被中断。直到执行完毕。
|
||||
|
||||
### 目标
|
||||
|
||||
> 任务调度模型中，是多目标任务分配。在普通的任务调度模型当中，多目标可能是指：时间成本最低、空间成本最低、调度预算最低等。
|
||||
|
||||
* 节点执行任务的负载均衡P。最大化可控节点利用率，降低任务执行时间。（每个节点都有任务可以做，执行时间最短）min{S^2{L(N)}}}所有节点的负载的方差最小？？？表示波动最小？这也行？让我思考一下。
|
||||
|
||||
### 输入
|
||||
|
||||
* 由攻击策略生成模块，提供攻击策略S。
|
||||
* 由网络分析模块提供网络的节点N和网络节点之间的链接关系Rn(N)
|
||||
|
||||
|
||||
### 约束
|
||||
|
||||
> 在任务调度模型中，存在着多种约束条件。
|
||||
* 任务执行过程中，满足原子任务之间的计算依赖。B(Rt(T))
|
||||
* 任务分配过程中，满足受控节点之间的链接依赖。B(Rn(N))
|
||||
* 任务分配过程中，满足原子任务对受控节点属性的要求。可以是静态的，比如节点的权限、操作系统等。B(q(N)=>p(T))
|
||||
* 任务分配过程中，满足原子任务对受控节点属性的要求。这种属性要求可能是动态变化的，如节点负载，这种动态变化的属性要给出动态属性计算函数。B(q(N)=>p(T))
|
||||
* 节点的运行CPU负载不能超过给定的要求B(performance)>sum{C_i(Q(M(T)=执行中))}
|
||||
|
||||
> 这里应该是模型的概述
|
||||
### 策略的数学模型
|
||||
* S表示所有策略的集合
|
||||
|
||||
### 任务的数学模型
|
||||
* T表示任务的集合
|
||||
* q(T)表示任务相关的属性。任务的属性是不变的。
|
||||
* Rt(T×T)代表任务之间的有向无环图，表示任务之间的依赖。任务依赖由策略分解函数提供。
|
||||
* T=D(S)可以将策略分解称为有相关作用的任务集合。D是策略的分割算法，将一个完成的策略分割成多个不同的子任务，方便放到不同的子节点上执行。
|
||||
* C(T)表示每个任务执行过程中占用CPU的时间
|
||||
|
||||
### 节点的数学模型
|
||||
* N表示节点的集合。
|
||||
* q(N)表示节点相关的属性。属性计算函数，包括静态属性和动态属性。
|
||||
* Rn(N×N)表示节点之间的链接关系图，不同的数值表示两个节点之间不同的链接类型。包括信任连接、直接相连、跨越交换机相连、跨越路由器相连、不信任相连。
|
||||
* Rnt(T,N)表示任务与节点类型之间的依赖关系。
|
||||
* A(T,N)表示任务调度算法，将任务分配到指定的节点上。A(T,N)是任务与节点的映射
|
||||
|
||||
### 执行流程
|
||||
1. 首先初始化策略、任务、节点的数学模型。然后输入外部的所有策略S与节点N包含节点之间Rn(N×N)。
|
||||
2. 然后执行策略分割函数T=D(S)，将策略分为多个不同的原子任务T。同时，形成任务之间的依赖关系Rt(T×T)
|
||||
3. 然后执行A(T,N)任务调度算法，满足所有的约束条件B，得到满足负载平衡的一个分配方案P。
|
||||
4. 执行方案，将方案中的任务放到具体的计算节点上执行。
|
||||
5. 执行过程中，会形成反馈信息，给执行的调用者。包含任务执行结果和任务执行后的状态。
|
||||
6. 执行过程中，任务执行完成后会从任务集合T中消失，并更新R(T)。
|
||||
7. A(T,N)是动态任务调度算法。当任务信息反馈给策略生成模块时，策略生成模块会根据最新反馈的信息，形成新的策略，并交付给任务调度模型。此时重新执行1-6的步骤，直到所有的策略执行完成，并且策略生成模块不再生成新的模块。形成新的任务、加入新的节点。
|
||||
|
||||
### 特点
|
||||
|
||||
* 柔性任务调度。一个任务由多个节点可以执行。一个节点可以执行多个任务。
|
||||
* 动态任务调度。在任务调度中，节点与任务都是动态变化的。受控节点会不断增加，任务执行完成后会剔除，新的任务也会不断被添加到任务调度模型当中。
|
||||
* 负载均衡。利用所有可以利用的节点。平摊任务。每个节点充分利用。
|
||||
* 多目标多约束任务调度。在任务调度中目标应该是任务执行效率最高。但是有一大堆约束条件。负载均衡应该也算任务目标？还是约束条件。
|
||||
|
||||
### 辅助图解
|
||||
|
||||
1. 任务依赖图
|
||||
2. 任务调度模型图
|
||||
3. 任务调度算法图
|
||||
|
||||
|
||||
## 5 任务调度算法（人工蜂群算法）
|
||||
|
||||
### 数学模型
|
||||
> 应该对任务调度模型部分的数学模型进行抽象，添加一下可以用来做任务调度算法的性质或者函数，同时添加任务调度算法本身的数学抽象。
|
||||
|
||||
* F(T)表示每个任务的优先级。用来实现任务调度模型中的任务依赖关系Rt(T)
|
||||
* Q(N)表示任务队列。每一个节点N都维护一个任务队列（或者是优先队列），所有节点上的Q(N)集合，即为任务分配算法形成的最新的任务分配方案P。（也就是说使用Q(N)实现了P的具体描述）
|
||||
* M(T)表示任务的状态。任务状态包含队列中、执行中、执行结束。任务一旦处于执行中，便不能被收回。执行结束后，任务被销毁。
|
||||
* L(T)表示当前节点任务节点的load负载计算函数。具体的计算函数应该后续给出。是否可以由每个任务占用CPU时间与估计的执行时间进行乘积计算？
|
||||
|
||||
### 算法原理
|
||||
|
||||
> 给出了一个实例处理这种问题，大部分研究都是使用粒子群算法的。
|
||||
粒子群算法
|
||||
* 粒子群编码
|
||||
* 适应度函数定义
|
||||
* 速度与位置更新
|
||||
* 惯性权重的调整。
|
||||
|
||||
人工蜂群算法
|
||||
人工蜂群算法就是模拟蜜蜂的采蜜过程而提出的一种新型智能优化算法，它也是由食物源、引领蜂、跟随蜂和侦查蜂组成。
|
||||
|
||||
食物源：食物源即为蜜源。在任何一个优化问题中，问题的可行解都是以一定形式给出的。在人工蜂群算法中，食物源就是待求优化问题的可行解，是人工蜂群算法中所要处理的基本对象。食物源的优劣即可行解的好坏是用蜜源花蜜量的大小即适应度来评价的。
|
||||
引领蜂：引领蜂与食物源的位置相对应，一个食物源对应一个引领蜂。
|
||||
跟随蜂：在蜂巢的招募区内根据引领蜂提供的蜜源信息来选择食物源
|
||||
侦查蜂：侦查蜂是在蜂巢附近寻找新的食物源。
|
||||
|
||||
在人工蜂群算法中，食物源的个数与引领蜂的个数相等；引领蜂的任务是发现食物源信息并以一定的概率与跟随蜂分享；概率的计算即为人工蜂群算法中的选择策略，一般是根据适应度值以轮盘赌的方法计算。
|
||||
在人工蜂群算法中，跟随蜂依据引领蜂传递的信息，在食物源附近搜索新食物源，并进行贪婪选择。若一个食物源在经过次后仍未被更新，则此引领蜂变成侦査蜂，侦查蜂寻找新的食物源代替原来的食物源。
|
||||
|
||||
|
||||
### 算法流程
|
||||
> 给出了粒子群算法的步骤
|
||||
|
||||
* 步骤1 初始化种群规模 NP、最大的迭代次数 Imax、学习因子 c1， c2、惯性权重范围［ωmin， ωmax］等 参数。
|
||||
* 步骤2 在约束范围内，以正态分布的方式初始 化可行粒子，并且随机产生可行粒子的位置和速度， 确定局部最优解 pbest 和全局最优解 gbest。
|
||||
* 步骤3 按式( 6) 计算每个可行粒子的适应度 函数值。
|
||||
* 步骤4 对于每个可行粒子，将其适应度函数值 与局部最优解 pbest 进行比较，如果优于 pbest，则将 当前值设为 pbest。
|
||||
* 步骤5 对于每个可行粒子，将其适应度函数值 与全局最优解 gbest 进行比较，如果优于 gbest，则将 当前值设为 gbest。
|
||||
* 步骤6 根据式( 7) 更新每个粒子的速度。
|
||||
* 步骤7 根据式( 8) 和式( 9) 更新每个粒子的 位置。
|
||||
* 步骤8 如果迭代次数达到最大值 Imax，则转 步骤9，否则转步骤3 继续下一次迭代。
|
||||
* 步骤9 输出局部最优解 pbest 和全局最优解 gbest。
|
||||
|
||||
|
||||
> 给出了人工蜂群算法的步骤
|
||||
|
||||
* 步骤1：初始化种群：初始化各个参数，蜂群总数SN、食物源被采集次数即最大迭代次数MCN及控制参数limit，确定问题搜索范围，并且在搜索范围内随机产生初始解xi(i=1,2,...SN) 。
|
||||
|
||||
* 步骤2：计算并评估每个初始解的适应度。
|
||||
|
||||
* 步骤3：设定循环条件并开始循环
|
||||
|
||||
* 步骤4：引领蜂对解xi按照式（2-3）进行邻域搜索产生新解（食物源）vi，并计算其适应度值；
|
||||
|
||||
* 步骤5：按照式(2-7)进行贪婪选择：如果vi的适应度值优于xi，则利用vi替换xi，将vi作为当前最好的解，否则保留xi不变；
|
||||
|
||||
* 步骤6：根据式(2-4)计算食物源的概率pi；
|
||||
|
||||
* 步骤7：跟随蜂依照概率pi选择解或食物源，按照式(2-3)搜索产生新解（食物源）vi，并计算其适应度。
|
||||
|
||||
* 步骤8：按式(2-7)进行贪婪选择；如果vi的适应度优于xi，则用vi代替xi，将vi作为当前最好解，否则保留xi不变；
|
||||
|
||||
* 步骤9：判断是否有要放弃的解。若有，则侦查蜂按式(2-5)随机产生新解将其替换；
|
||||
|
||||
* 步骤10：记录到目前为止的最优解；
|
||||
|
||||
* 步骤11：判断是否满足循环终止条件，若满足，循环结束，输出最优解，否则返回步骤4继续搜索。
|
||||
|
||||
### 步骤
|
||||
|
||||
* 维护一个节点依赖矩阵
|
||||
* 维护一个任务依赖矩阵（从任务的有向无环图生成树，叶节点优先级最高，根节点优先级最低）
|
||||
* 使用优先队列存储任务节点。（当任务分配时，检验任务依赖是否满足，不满足则任务降级，瓶颈依赖升级）
|
||||
* 使用群体之能算法完成多个节点的优先队列构建。随着执行，各个节点的优先队列会动态变化。优先队列的任务之间会相互迁移。
|
||||
* 优先队列是待执行任务，主控节点会根据节点当前的性能限制分配并行执行的任务数量。
|
||||
|
||||
|
||||
> 关于负载需要说明：负载不是计算资源耗费的量计算。而是通过一个计算机当前执行任务的能力与分配给当前计算机的任务的量的一种关系，能力低，任务多，节点的负载很高。能力低，任务少，节点的负载很低。
|
||||
> 负载均衡是多个节点之间的待分配任务的平衡。性能限制是当前计算节点执行任务量的限制。
|
||||
|
||||
> 通过以上简单的几个步骤，应该就可以实现，负载均衡、性能控制。那么剩下的主要为题就是-------这个所谓的群体智能算法如何任务分配。
|
||||
|
||||
|
||||
## 6 关键技术（给出一些图）
|
||||
|
||||
## 7 技术路线（给出一些图）
|
||||
|
||||
### 任务抽象过程描述
|
||||
首先描述问题的抽象过程。讲整个任务调度模型中的角色分为三种，包括节点、策略、任务。（根据策略、任务、节点的抽闲过程进行描述）描述这是一个怎样的系统
|
||||
|
||||
### 任务调度模型描述
|
||||
本文提出的任务调度模型，以任务执行效率最高为目标。任务调度的目标是在任务依赖的情况下，尽可能最大化利用计算节点，提高执行效率。
|
||||
|
||||
使用任务依赖、节点依赖、任务与节点之间的依赖、节点性能约束等外部约束来分别约束任务调度，要求任务调度方案中的所有任务调度到到节点上满足要求的依赖，
|
||||
|
||||
|
||||
|
||||
### 任务调度算法描述
|
||||
然后介绍任务调度模型的核心。任务调度算法的实现。
|
||||
304
lab/项目申请书修改.md
304
lab/项目申请书修改.md
@@ -1,304 +0,0 @@
|
||||
## 第1版
|
||||
|
||||
### 任务目标
|
||||
要求：针对不同目标、不同探测手段，协同探测策略不少于5种。具备内部网络节点自组织和协同分布式执行任务的能力，每个节点负载不超过原本负载的10%
|
||||
|
||||
### 对任务目标的抽象
|
||||
|
||||
任务目标：网络探测。
|
||||
|
||||
具体任务：
|
||||
主机探测（主机发现、端口探测、服务和版本探测、操作系统探测）
|
||||
拓扑探测（SNMP、ARP、Traceroute、DNS）
|
||||
|
||||
任务要求：
|
||||
多源异质、群体协同、负载均衡、自组织分布式
|
||||
|
||||
|
||||
主机抽象：
|
||||
主控服务器、受控设备、
|
||||
网络关键信息基础设施及相关资产信息包括，如IP地址、资产名称、服务端口、协议名称、操作系统、设备类型、厂商属性、应用组件
|
||||
|
||||
|
||||
策略抽象：
|
||||
选择前锋武器（XSS、应用软件漏洞、操作系统漏洞、网络设备漏洞等）组成攻击方案。
|
||||
|
||||
|
||||
任务抽象：
|
||||
每一个策略可以分为多个子任务、子过程执行，每个可以单独执行的子过程称为最小任务。
|
||||
|
||||
### 当时的思路
|
||||
协同、自组织、负载均衡、多端协同模型
|
||||
|
||||
首先，我不需要建立什么模型。在研究目标、研究内容、关键技术中都已经说明了内网自主探测模型。
|
||||
|
||||
我需要做的是完成这个模型中的一个算法。如何实现模型
|
||||
|
||||
> 参考：项目支撑：网络探测
|
||||
|
||||
## 第5版修改
|
||||
### 修改意见
|
||||
|
||||
要体现不同活动之间协同（决策、组织、情报收集与处理等）、还要体现同类活动、同类任务之间的协同；
|
||||
要论证清楚：
|
||||
1. 策略与决策的关系？
|
||||
2. 策略如何生成？
|
||||
3. 策略如何驱动协同
|
||||
|
||||
### 问题
|
||||
1. 文章的合并出现了问题，我把关键技术和技术路径都改了，但好像没有合并上去。第一张图是多余的。
|
||||
|
||||
2. 有很多奇奇怪该的要求。动态多元协同探测技术。到底应该解决什么问题。在夏老师给我的提的建议中，第一条，是决策、组织、处理等不同活动之间的关系。策略与决策关系，策略如何生成决策。这明显属于决策部分的关系，与处理部分的事情。
|
||||
|
||||
刚开始的时候，只说是实现不同任务的协同，实现负载平衡。所以组织的对象到底是谁。我觉得夏老师给的建议，跟李华成给的说法是完全不一样的。
|
||||
|
||||
所以第一件事，搞明白协同是什么？协同的对象是什么？协同的结果是什么？
|
||||
|
||||
所以这里的 组织活动-----协同 是什么关系。决策与组织有什么关系。协同策略，多余五种，谁跟谁协同啊。。。。。。。。。。。。。
|
||||
|
||||
活动与活动之间的协同策略？
|
||||
任务与任务之间的协同策略？
|
||||
还是经过协同策略生成的协同后的结果？
|
||||
|
||||
3. 而且这个不少于五中，明显是探测策略不少于五种。是组织方案不少于五种吗？
|
||||
|
||||
4. 关于任务部署算法，应该还有更好的叙述方式。可以将探测技术与部署算法结合进行叙述。
|
||||
|
||||
|
||||
|
||||
|
||||
### 问题说明
|
||||
2. 动态多源协同探测技术，解决了组织过程。由决策生成探测方案后，实现探测方案到探测计划的过程。探测策略的具体内容应该有启发式探测方案生成算法决定，意图如何生成为策略，也应该是决策过程决定的。决策与策略的关系也应该是决策部分决定的。协同的对象是活动还是任务？是不同活动之间的协同策略，还是探测方案分解后的探测任务之间的协同策略。
|
||||
|
||||
3. 协同是网络节点按照协同算法分配任务共同完成探测方案的过程。“协同策略不少于五种”是指以下哪种情况：
|
||||
（1）协同算法不少于五种。
|
||||
（2）按照一种协同算法产生的任务部署的结果不少于五种（即协同的结果不少于五种）。
|
||||
|
||||
> 因为整个体系结构具有动态变化的特点，即在任务执行过程中，会形成新的探测方案和探测任务，网络拓扑也会不断发生变化。所以无法在任务一开始执行，就形成一个静态的任务协同方案，任务部署的结果是不断变化的。
|
||||
|
||||
## 第6版修改
|
||||
|
||||
### 修改意见
|
||||
|
||||
要体现不同活动之间协同（决策、组织、情报收集与处理等）、还要体现同类活动、同类任务之间的协同；
|
||||
要论证清楚：
|
||||
1. 策略与决策的关系？
|
||||
2. 策略如何生成？
|
||||
3. 策略如何驱动协同
|
||||
|
||||
|
||||
### 三种关系论述清楚
|
||||
|
||||
1. 多个节点同类活动之间的协同
|
||||
2. 多个节点任务的协同
|
||||
3. 单个节点不同活动的协同
|
||||
|
||||
> 每个节点能够执行所有的活动。对单个节点来说，需要协同内部的所有互动，对多个节点来说，需要协同相同的互动。还有总体任务的分配。
|
||||
|
||||
|
||||
## 第7版修改
|
||||
|
||||
### 修改意见
|
||||
|
||||
抓紧时间开展**基于意图的群体智能的协同机制**研究描述;以意图、策略为输入，基于网络态势生成方案(明确意图、拟制方案、评选方案)，实现方案到计划，并基于态势，实现计划到指令，运用群体智能算法完成指令。该机制要能够完成三种循环，包括不同智能体、多个智能体的协同。
|
||||
参考文献:李肖坚、焦健博士论文。
|
||||
任务:
|
||||
1. 建立模型;
|
||||
2. 设计系统，给出系统结构、E一R图等
|
||||
3. 正月初十左右提交讨论文档。
|
||||
|
||||
|
||||
抓紧时间，谢谢!
|
||||
|
||||
### 论述的思路
|
||||
> 针对具体的活动进行协同论述。
|
||||
1. 方案到计划，协同决策
|
||||
2. 计划到指令，协同组织
|
||||
3. 三个循环描述清楚。
|
||||
4. 多个智能体协同描述清楚。
|
||||
|
||||
> 刚开始的时候，理解的协同就是任务分配。建立模型，使用群体智能算法，完成任务部署过程。后来认为协同包括两个部分，一个是多个智能体之间的行为协同，另一个是多个智能体之间的任务协同，行为协同实现了情报共享和节点一致性，任务协同实现了探测任务的部署。现在认为协同包括三个部分，一个是多智能体任务协同，多智能体某个活动的协同，单智能体不同活动协同。
|
||||
|
||||
## 第8版修改
|
||||
|
||||
### 修改意见
|
||||
1. 一般讲策略是指做什么与不做什么；先做什么、后做什么；而算法是指一件事具体的执行过程，从概念上策略与算法是有区别的。
|
||||
2. 协同机制包括协同策略（从各个协同场景中进行归纳分析）、协统机制的体系与结构（李老师论文与焦健论文）、机制的设计于构造。
|
||||
3. 查一下、研究下机制设计方面的相关文献。
|
||||
|
||||
### 修改思路
|
||||
|
||||
|
||||
1. 首先论证群体智能与多源协同探测技术结合的可行性。介绍自组织的概念、协同论的概念、群体智能的概念、多源协同探测技术的目的。四者之间的关系与如何结合。还要说明协同与协调之间的严格的界限。
|
||||
2. 然后对多源协同探测技术进行说明。协同方案、协同算法、协同控制、协同的结果、协同的条件。给出自己的相关论据。
|
||||
|
||||
|
||||
> 对文章的补充。我觉得应该按照写论文的方式来写。这一个申请书，随便写写先应付过去。从明天开始，考虑论文和PPT怎么构建。首先说，这个问题的研究点主要在哪里？为什么可以这么早开始论文撰写？显然是不可能的。应该是进行文献综述+可行性论证。然后利用PPT将文献综述和可行性论证描述清楚。可行性论证主用来说明，各个名次领域的结合，如何建立模型。模型的技术细节。然后对模型进行实现，然后对模型进行验证。然后对实验结果进行总结。完成论文。注意，在可行性论述中，需要指出建立哪些具体的模型。我觉得，这个多源协同探测技术需要改进。
|
||||
|
||||
> 而且我觉得文章的技术路径，写的太过于详细，不应该写出具体的模型实现的细节，只应该简单论述，群体智能算法如何实现网络节点的任务部署（任务协同）。
|
||||
|
||||
|
||||
### 协同的划分
|
||||
|
||||
两个协同共同构成了协同探测方案。
|
||||
1. 行为协同主要由分布式网络节点间的通信模型实现。
|
||||
2. 任务协同主要有分布式网络节点间的任务部署算法实现。
|
||||
|
||||
协同的分类
|
||||
1. 这里的协同策略可以是基于不同场景的协同：基于事件驱动的？基于任务驱动的？基于决策驱动的？基于行为驱动的？协同过程。
|
||||
2. 也可以是不同形式的协同：集中式协同。分布式协同。分散式协同。
|
||||
3. 也可以是不同机制的协同：黑板、公告板、协同网、发布订阅机制。
|
||||
|
||||
### 文章结构
|
||||
基于群体智能的分布式异构网络自组织协同方案。基于群体智能算法的分布式异构网络协同探测方案
|
||||
|
||||
应该结合自组织协同的理论描述任务过程。论述自组织协同的特点和优势。引出自组织协同的的算法。
|
||||
|
||||
添加专门的协同模块。主要实现节点的一致性。描述每个节点都可以实现各个活动，每个节点之间的活动实现一致性控制。
|
||||
|
||||
也就是说。现在的协同包括行为协同与任务协同两个部分。行为协同负责协同各个节点之间的信息。任务协同，负责完成任务的分配。建立多智能体分布式协同任务分配体系结构。
|
||||
|
||||
## 第9版修改
|
||||
|
||||
### 修改意见
|
||||
1. 建议从同类执行体基于负载、基于执行能力方面的协同、基于态势感知调整方案活动协同、基于意图重新生成方案等方面研究协同决策
|
||||
|
||||
|
||||
### 区分以下概念
|
||||
* 协同机制（博弈论、订阅发布机制、协商机制、贪心机制等）、
|
||||
* 协同策略（基于负载均衡，节点执行能力，时间最优等）、协同体系结构（协同的模型，例如OODA）、
|
||||
* 协同模型（黑板模型、公告板模型、合同网模型）。
|
||||
|
||||
|
||||
### 两种思路
|
||||
我有一点思路了。我本来有两种想法，
|
||||
|
||||
1. 一种是当智能体执行到某一个活动的时候进行不同的协同策略，比如组织部分的协同策略，决策部分的协同策略；
|
||||
2. 另一种是一个协同策略是贯穿所有的活动的，比如基于负载的协同策略，收集负载数据->生成节点的负载情报->重新组织任务的分配->收集负载数据。
|
||||
|
||||
|
||||
按照这个图，应该是选择前边的思路，也就是，当一个智能体，进行不同的活动时，执行不同的协同策略。（我需要把这些活动的名称修改成李化成那个总体模型的名称吗，就是有情报生成、数据处理那些活动。）
|
||||
|
||||
### 研究内容概述
|
||||
> 这个最后修改。
|
||||
为了实现探测活动和任务的协同执行，研究动态多源协同探测技术。建立了动态多源协同探测模型，在异构设备组成的网络环境中，动态组织协调活动的执行，通过基于群体智能的任务部署算法，将探测任务分配到网络节点上，实现任务之间的协同运行。同时在保证网络节点负载较低的前提下，最终实现探测效率最大化。动态多源协同探测策略主要包括基于OODA的活动协同策略、基于节点负载的任务协同策略、基于节点执行能力的动态任务协同策略、基于意图与台式感知的协同决策、基于情报共享的情报协同策略。
|
||||
|
||||
|
||||
### 总体模型
|
||||
> 首先建立模型，对总体的模型进行简单的描述。原本对模型的描述太多了，不太合适。现在要做的就是阅读文献，完成这两部分。包括每个协同的内部描述。尽量在1000字之内解决问题。将自己原先的多源协同探测也作为参考文献。
|
||||
|
||||
动态多源协同探测技术，面向异构设备组成的网络环境，其目标是协调不同活动，完成任务的部署，实现分布式网络节点的动态协同过程，高效利用网络资源完成探测任务。动态多源协同探测技术将外部意图转换为执行方案，部署到网络节点上，完成探测任务，并收集数据、分析情报，为下一次探测活动做准备。
|
||||
|
||||
![给出模型图]()
|
||||
|
||||
模型依赖的环境主要由网络节点及其组成的网络构成。网络节点包括主机、路由器、交换机等网络设备。网络节点具有属性信息，如IP地址、资产名称、开放端口、协议名称等。网络节点具有状态信息，描述节点的运行状态，如节点负载、CPU使用率等，节点状态信息随着探测活动地进行不断发生变化。网络节点可以分为受控节点和非受控节点。网络节点之间连接类型各不相同，可能是直接连接、跨交换机连接、跨路由器连接等。
|
||||
|
||||
模型处理的对象主要包括意图、方案、任务、计划、指令、数据、信息、情报。意图描述了探测的目标，由外部人员给出；方案描述了实现意图的具体手段，由相互关联的任务组成；任务是能够单独执行的一组行为，它是任务部署和执行的最小单位，依赖具有特定属性的网络节点，使用有向无环图表达任务之间的关联；计划将任务与具体的网络节点建立关联，是完成任务部署后输出的结果。指令是在网络节点上进行的操作。数据是指网络节点任务执行后的返回数据，包含了各种日志和文档数据。信息描述了网络节点的属性和状态。情报是通过探测活动获取的节点、节点属性信息、节点状态信息、节点连接信息组成的集合，为探测活动提供了基本的信息基础。
|
||||
|
||||
|
||||
模型进行的活动主要包括决策、组织、执行、处理、情报生成等活动，其中组织活动包含分解、部署、命令三个子活动。决策活动负责将外部的意图转换为具体的探测方案，主要通过启发式方案自动生成技术实现。组织活动负责将方案转换为在不同网络节点上执行的指令，它首先进行分解活动，将方案分解为可以在某个网络节点单独执行的任务，然后通过部署活动，将任务与具体的网络节点建立关联，最后通过命令活动，转换为可以在网络节点上具体执行的指令，其中部署算法是组织活动的核心，采用基于群体智能的任务部署算法。执行活动负责执行当前的指令，进行一系列操作，并返回执行后的数据。处理活动从收集到的数据中提取其中蕴含的各种信息。情报生成活动对当前的信息进行处理，分析网络对抗所需要的信息与知识，包括其中的安全漏洞信息、网络拓扑信息等。
|
||||
|
||||
### 五种策略
|
||||
> 根据图中的描述，当前的五种协同策略打算采用下边的方法。
|
||||
|
||||
在动态多源协同探测模型当中，采用自组织协同方式实现节点之间的协同，每一个网络节点都能独立的实现决策、组织、执行、处理、情报生成等活动，多个网络节点之间通过协同策略，实现整个网络的自组织过程，分布式并行完成总体探测任务。动态多源协同探测策略主要包括基于OODA的活动协同策略、基于节点负载的任务协同策略、基于节点执行能力的动态任务协同策略、基于意图与台式感知的协同决策、基于情报共享的情报协同策略。
|
||||
|
||||
|
||||
|
||||
1. （总体协同：）基于OODA的活动协同策略。实现网络节点所有活动的协同，是总体的协同策略。基于OODA环的作战思想广泛应用于军事对抗中，包括观察、判断、决策、行动四个主要过程，能够通过反馈机制，对决策与行动的结果进行态势感知，反向影响判断过程。基于OODA观点，构建多源协同探测模型，实现决策、组织、探测、数据收集、情报生成活动的协同，主要包括以下三种循环。
|
||||
1. 循环一由<1，2，3，4，5，6，1>构成，是基于意图和情报的方案再生成机制。探测的结果通过数据处理、情报生成，反馈给决策活动，对方案执行效果进行量化，与期望值做差，得到对方案的评价。结合意图与评价驱动下一轮的探测方案生成，直到满足探测意图为止。
|
||||
2. 循环二由<1，2，3，5，6，1>构成，是基于方案和情报的任务再调整机制。探测结果以情报的形式反馈给组织活动，对任务部署的的效果进行评估，基于情报，将方案重新划分为不同的任务，生成新的任务部署方案，并分配给节点执行。
|
||||
3. 循环三由<1，2，3，7，1>构成，是基于情报的感知策略调整机制。探测结果以情报的形式反馈给感知管理活动，感知管理针对特殊的节点和态势生成感知策略。该机制能够获得更全面、更准确的网络情报，基于强化学习的思想，协同数据收集策略。
|
||||
|
||||
2. 基于节点负载的任务协同策略。在组织活动中，实现探测任务的分解与部署，将整体的探测方案分解成有序子任务，基于人工蜂群算法，将任务部署到网络节点上。
|
||||
任务协同策略的核心是任务部署算法，任务部署具有动态性和灵活性的特点，网络节点和探测任务不断发生变化，同一个网络节点可以执行多个任务，同一个任务也有多个可选的网络节点。任务部署时必须满足各种约束条件，符合探测任务的先后顺序关系，满足探测任务对网络节点的属性要求、状态要求和探测节点之间连接类型的要求。
|
||||
基于人工蜂群的任务部署算法的核心思想，是利用蜜蜂寻蜜的过程寻找最优分配方案。任务部署算法的流程如图，根据情报，计算网络节点当前的负载并量化总体的负载均衡状态，作为当前种群的适应度，选取当前最优节点作为食物源；随机分配网络节点的角色，雇佣峰对最优节点周围搜索最优解，跟随峰根据雇佣峰的食物源信息搜索最优解，侦查峰随机搜索最优解，不断重复，直到满足负载均衡的需求。
|
||||
|
||||
（图片）
|
||||
|
||||
1. 基于节点执行能力的动态任务协同策略。在执行活动中，根据节点反馈的实时数据，实现任务的动态调整。通过数据收集、数据处理、情报生成，得到当前的网络节点的状态信息，对网络节点的执行能力进行评估，控制网络节点上探测任务的CPU使用率不能超过给定的阈值（10%）。使用cpulimit工具，限制进程执行过程中的CPU使用率。通过任务部署算法中的角色判定，寻找执行当前任务效益次大的网络节点，并通过推送机制，将任务推送到执行能力更强的节点。
|
||||
|
||||
2. 基于意图与态势感知的协同决策。在决策活动中，通过反馈机制，实现多个节点的动态决策过程。探测方案选择探测手段和探测工具对目标节点进行探测，执行探测任务后，进行数据收集、数据处理、情报生成，根据情报对探测方案的执行效果进行量化，如果判定探测方案失败，将探测工具和探测手段排除在探测集合之外，然后再次生成探测方案。探测方案生成后，每一个网络节点通过方案共享的方式，协商一份探测方案，最终所有的网络节点都有一份相同的探测方案，
|
||||
|
||||
3. 基于情报共享的情报协同策略。在情报生成活动中，当探测任务完成后，生成新的情报，通过情报共享机制，实现网络节点情报的一致性。情报共享机制主要通过相邻网络节点之间的通信实现。基于事件驱动的情报协同策略中，当一个网络节点执行完成某个活动、获取到某些情报后，自身的属性与状态发生变化，通过主动通信的方式，向其周围所有的网络节点，通报自身的属性与状态变化，保证不同网络节点的一致性。基于订阅发布机制的行为协同策略中，当一个节点需要某些情报或者了解其他网络节点的属性与状态信息时，主动向目标网络节点订阅需求的信息，目标网络节点发布信息，从而保证不同网络节点的一致性。基于周期发布的行为协同策略中，所有的网络节点周期性的向其他网络节点广播自己的情报与属性状态信息。
|
||||
|
||||
--------------------------
|
||||
（备份）
|
||||
6. 数据收集活动：基于情报的数据收集协同策略
|
||||
|
||||
|
||||
### 文章结构
|
||||
> 之前的所有问题都没有得到真正的解决。现在需要处理之前所有的问题。
|
||||
1. 给出多源协同探测技术的体系结构图，并对体系结构进行简单的描述。
|
||||
2. 描述体系结构中的是三个循环。
|
||||
3. 描述位于不同位置的五种协同策略。
|
||||
|
||||
|
||||
### 总结（所有的要求）
|
||||
|
||||
1. 需要论述清除三类协同。包括多节点同一个活动、多结点任务分配、单节点不同活动。
|
||||
2. 需要给出模型的体系结构，需要给出五种协同策略。
|
||||
3. 需要论述协同体系结构中的三个循环。
|
||||
|
||||
|
||||
## 第10版修改
|
||||
|
||||
### 修改意见
|
||||
|
||||
针对不同安防等级、不同探测能力、不同探测手段的情况下的协同策略不少于五种。
|
||||
|
||||
### 思路
|
||||
|
||||
完善了项目申请书。
|
||||
由蒋师兄完成了基于安防等级的协同策略。
|
||||
|
||||
|
||||
## 第11版修改
|
||||
|
||||
### 修改意见
|
||||
|
||||
1. 针对问题形成解决方案。每一个协同遵循问题论述、解决方案、解决方案的优点。尽量精炼到五句话以内。遵循这种模式进行撰写。
|
||||
2. 将协同与探测挂钩。分析探测的特点。
|
||||
3. 协同部分与其他部分协同一致。
|
||||
|
||||
|
||||
### 修改思路
|
||||
|
||||
1. 读一遍项目申请书，完成与其他部分的结合，保持内容的一致性。并总结探测的特点，与探测挂钩。
|
||||
2. 修改三种循环的论述。资源调度循环、评估反馈循环、态势感知循环。
|
||||
3. 修改五种协同的内容。 提出新的五种协同。基于反馈机制。
|
||||
|
||||
|
||||
### 步骤。
|
||||
|
||||
1. 阅读资料，整理相关内容。节选其中有用的部分。
|
||||
（包括整个本子、网络资料、上一个项目申请书、两篇论文）
|
||||
|
||||
2. 直接在文章中修改内容。
|
||||
|
||||
### 项目申请书
|
||||
1. 研究内容：主动隐蔽、协同网络探测。内网探测主要目的是获取目标网络中**节点的属性信息**，评**估其安全性**，为接下来对内网系统进行攻击作为铺垫。
|
||||
2. 相关技术：主机探测包括主机发现技术、端口探测技术、服务和版本探测技术、操作系统探测技术、漏洞扫描技术。拓扑探测SNMP拓扑探测、ARP拓扑探测、DNS拓扑探测。攻击检测方法有恶意代码检测、基于主机的应用保护、大数据分析。
|
||||
3. 研究多探测点协同优化机制，建立内网自主探测模型。这一点与自己的部分有关。注意，协同的对象是计算机。
|
||||
|
||||
|
||||
协同探测中的决策活动负责整个探测活动的计划和具体任务。探测收集信息的特殊性，要求方案可以对已知目标，也可以在对未知目标实施收集行动。行动过程通常需要一定的反复执行，才能达到预期的效果。这种特殊性决定了在接收到企图之后，需要予以决策形成方案，并评估，随后组织具体的行动。探测系统在接收决策者发出的企图后，结合先验知识，经过决策过程转换为探测方案。
|
||||
|
||||
先验知识（流量分析的结果）以及具备的知识和手段来生成探测方案。
|
||||
|
||||
|
||||
|
||||
五种策略
|
||||
|
||||
1. 基于反馈机制的活动协同策略
|
||||
2. 基于群体智能的资源协同策略
|
||||
3. 基于评估反馈的方案再调整策略
|
||||
4. 基于知识共享的行为协同策略
|
||||
5. 态势感知协同策略
|
||||
6. 跨安防等级多角色协同策略
|
||||
|
||||
|
||||
如果要讲PPT的话应该是这样：
|
||||
|
||||
1. 首先介绍总体的模型
|
||||
2. 然后依次介绍五种协同策略
|
||||
@@ -1,172 +0,0 @@
|
||||
# 计算机网络自组织利用研究——焦健
|
||||
|
||||
> 首先看完这篇文章
|
||||
> 思考自己能做什么，找到相关的方法，应用到这上边。你已经很慢了，得加快速度了。
|
||||
|
||||
论文的架构说明
|
||||
* 第一章：首先提出了CPN研究过程中出现的**问题描述**
|
||||
* 第二章：然后针对问题，对问题进行抽象，定义相关概念，给出相应的**理论依据**。即**数学抽象**。
|
||||
* 第三章：针对定义的基本概念，结合实际情况，生成**理论模型**。
|
||||
* 第四章：对模型中的**关键技术**进行解读。
|
||||
|
||||
## 1 第一章：总体-提出问题（文章总体介绍，模型总体介绍）
|
||||
* 计算机网络自组织利用CNSE，获取网络对抗情报，完成支撑活动
|
||||
* 活动：决策、组织、数据收集处理、情报生成支撑
|
||||
* 利用体。利用体网络。
|
||||
* 问题：利用体网络共同承担利用任务。
|
||||
* 给出了理论依据与关键技术
|
||||
* 理论依据：
|
||||
* 定义对象
|
||||
* 定义活动
|
||||
* 定义体系结构（活动关系）
|
||||
* 定义描述语言
|
||||
* 关键技术：
|
||||
* 基于产生式推理规则的任务生成和情报生成
|
||||
* 基于蜂群群之行为的任务自部署
|
||||
* 基于框架匹配技术的特征识别
|
||||
* CNO----CNA，CND，CNE。攻击防御与利用有本质区别。
|
||||
* CNE利用，包括，支撑活动与收集活动
|
||||
* 决策与组织模式的理论与技术：阶段性、有序性和周期性
|
||||
* 自组织机制及其算法：自组织是在一定条件下，由于系统内子系统的相互作用，使系统形成具有一定功能和结构的过程。它具有自创生、自复制、自生长和自适应等形式。 对于 CNSOE 来讲，自组织性主要体现在自适应性上。
|
||||
* 自组织的逆向工程方案为了协调系统的复杂行为，不是直接控制系统进化，也不能使系统按照需求进化，但可以通过模拟保证系统的进化最终达到所要求的目标。
|
||||
* 蜂群算法可能是一个不错的思路。寻找对蜂群算法的优化，或者其他的群体智能算法。
|
||||
* 解决了一下问题：（文章解决了以下四个问题）
|
||||
* 需明确计算机网络利用的对象
|
||||
* 界定关于计算机网络利用对象的具体收集活动
|
||||
* 明确关于计算机网络利用对象的行动支撑概念
|
||||
* 明确计算机网络利用的决策和自组织机制（这也是我主要研究的问题）
|
||||
|
||||
|
||||
## 2 第二章：理论依据（体系结构与自动机。）
|
||||
|
||||
### 基本定义
|
||||
* 定义：CNE活动$\varphi$包括：收集活动和支撑活动
|
||||
* 定义：CNSOE活动$\varphi$包括：收集活动、支撑活动、决策活动、组织活动、数据处理活动、情报生成活动。
|
||||
* 定义：CNO对象==目标$t$包括。网络、节点、进程、服务、文件、网络层连接、传输层连接、服务连接。
|
||||
* 定义：节点特征S包括（静态属性）：操作系统内核特征、节点的协议栈特征、进程特征、服务特征、文件特征。
|
||||
* 定义：目标状态r包括（动态属性）：节点运行状态、进程运行状态、服务运行状态、链路运行状态。
|
||||
* 定义：网络情况=特征+状态
|
||||
|
||||
### 活动定义
|
||||
* 定义：行动支撑：支撑活动：获权、传递、激活，及其定义（用来达到CNOSE的活动的支撑）
|
||||
* 定义：数据收集：收集互动：获取活动、预处理活动，及其定义。
|
||||
* 定义：数据处理：信号关联、图像利用、文档翻译、数据格式化。
|
||||
* 定义：情报：目标运行状态、网络拓扑、安全漏洞、对抗手段推论
|
||||
* 定义：情报生成：综合、评估、分析、解释。及其关系组成的耳机和。
|
||||
|
||||
### 决策与组织活动定义（它是一个统筹的活动）
|
||||
* 定义：决策与组织：决策活动负责将企图转换为收集方案。包括理解企图、拟定方案、评估选优。
|
||||
* 定义：决策与组织：组织活动负责将方案部署为自身的计划，根据当前的情报信息将计划中的任务逐一转换为指令。
|
||||
* 定义：意图：目标、期望、手段的三元组。
|
||||
* 定义：使命：具体目标、期望、手段的三元组
|
||||
* 定义：方案：彼此关联的任务的集合。
|
||||
* 定义：任务：任务表示、任务前约束、具体目标、期望、打算采取的手段、任务后约束
|
||||
* 定义：计划：赋予执行主体关联任务的集合，就是将具体的关联任务分配到执行主体上。
|
||||
* 定义：指令：具体目标、有待解决的问题、必须采取的手段、任务后约束的4元组
|
||||
|
||||
* 决策技术：基于规则推理的方案拟定活动。给出一个可能的执行路径。一个可行的方案，决策不考虑评估优选。
|
||||
* 决策活动：理解意图活动、拟定方案活动、优选活动。
|
||||
* 决策活动是企图和情报到方案的映射。
|
||||
* 组织：决策活动给出方案之后，参照活动的需要和当前的目标状态以及利用执行体的能力，生成具体的利用计划，转化为可以交给利用体直接执行的指令，这一过程统称为组织
|
||||
* 组织活动：分配任务活动、下达指令活动组成的集合。及其关系集合构成的二元组。
|
||||
|
||||
### 体系结构定义
|
||||
|
||||
|
||||
|
||||
## 3 第三章：模型（文章中的数学模型）
|
||||
|
||||
* CPN模型。CNP是组成整个CNSOE的最基本单元。方框表示库所，圆圈表示变迁。
|
||||
|
||||
|
||||
|
||||
* CPN模型细节
|
||||
|
||||
|
||||
* CNSOE协同行为模型。CNSOE 系统由多个 SEACN 个体（以下简称利用体）组成，如上一节所述，每个利用体都具有独立的从决策、组织到情报生成的能力。多个利用体在执行完整的方案时，需要利用体之间交换信息，协调行动步骤。对抗体之间的通信使用订阅发布（pub-sub）机制实现，
|
||||
|
||||
|
||||
* 数据收集自动机
|
||||
* 数据处理自动机
|
||||
* 情报生成自动机
|
||||
* 任务生成自动机
|
||||
* 组织行为自动机
|
||||
* DEACN扩散自动机
|
||||
* 网络拓扑双向发现自动机
|
||||
|
||||
|
||||
## 4 第四章：关键技术（涉及到的技术，入手点）
|
||||
|
||||
### 自组织利用机制
|
||||
|
||||
方案生成算法、自部署算法、特征识别算法、情报推理算法。
|
||||
|
||||
### 方案生成算法
|
||||
|
||||
完成决策任务。有目标、期望、手段转换为方案。包括目标分解和任务推理机制。将目标分解为活动所需要的基本目标单位。使用产生式推理获得利用方案。
|
||||
|
||||
在决策过程开始阶段，目标分解后得到由目标、期望和手段组成的谓词表达式，利用谓词公式在决策树中进行推导，自动生成方案。
|
||||
|
||||
反演树遍历算法和基于规则推理的任务区分算法包括消解反演树的生成算法， 用于生成基本目标的利用方案。
|
||||
|
||||
方案生成算法是决策活动的算法，主要完成了意图到方案的转换，并完成了方案的分解，形成了基本的任务。
|
||||
|
||||
### 基于蜂群的自部署算法
|
||||
|
||||
利用方案自动产生之后，每一个负责执行任务的利用体都拥有一份相同的方案。利用体通过个体间协商，使用自部署算法完成对方案到任务的转化，即将原有的方案转化为具体行动计划，按照若干行动计划，派发到每个利用体中。
|
||||
|
||||
行动角色判定算法：对利用角色进行判定，群体只能种的三个角色。
|
||||
|
||||
算法的描述。将利用体划分成不同的角色。首先发现蜂R获取执行目标计划的收益值。部分成为引领峰，部分成为跟随峰，向引领峰靠近，发现更大收益的节点；部分还是发现蜂，继续随机发现可能的最大收益节点。重新判定角色前，需要订阅其他利用体的消息，辅助判定角色。
|
||||
|
||||
|
||||
|
||||
|
||||
任务划分算法：方案中任务的划分。按照目标划分任务。任务目标已知，任务目标未知。
|
||||
|
||||
基于蜂群的自部署算法是组织活动的算法。主要完成了任务的协同执行。每一个利用体保留一份总体的方案。
|
||||
|
||||
|
||||
这里很关键一点。每一个利用体保留一份总体的任务方案，这与自己原来设计的模型，是完全不同，原来的模型中，只有一个大脑保留完整的方案，通过全局动态的智能方式（蜂群算法）进行任务调度，蜂群算法本身具有自组织性，但是在解决任务调度问题的任务调度模型不是分布式的也不具有组织性，它必须由一个大脑统一分配任务。所以不是自组织的。
|
||||
|
||||
### 特征识别算法
|
||||
|
||||
完成数据到信息的转换。主要指目标特征：操作系统类型、进程、服务等信息。
|
||||
### 主要描述语言
|
||||
|
||||
协同描述语言和支撑描述语言。
|
||||
|
||||
协同描述语言的主要功能实现利用体之间的信息共享。
|
||||
支撑描述语言作为支撑活动的一种实例化，完成利用体在网络节点间的移动。
|
||||
|
||||
### 情报推理算法
|
||||
计算机网络利用活动的最终目的在于产生可以为对抗所需要的网络情报。情报中除了信息处理得到的内容外，主要为对抗中关于网络目标的安全漏洞和拓扑，这些内容不能通过简单模式匹配的方式获得，而需要按照一定的规则推理产生，因此引入情报的推理算法
|
||||
|
||||
|
||||
### 拓扑双向发现
|
||||
## 5 思考（明白自己要做的东西，面向的问题）
|
||||
|
||||
* 大论文中的，逆向工程，需要用群体智能算法，优化搜索逻辑的执行。
|
||||
* 大论文中的，蜂群算法，在自组织利用模型中的应用，使用群体智能方法，替换这种方法。
|
||||
* 大论文中的，三个循环，群体智能的应用。你需要知道，这三个循环是什么，怎么样完成循环。
|
||||
* 需要抽象成数学问题，使用群体智能算法，建立数学模型，解决数学问题。
|
||||
* 意图-》方案-》计划-》指令
|
||||
|
||||
|
||||
## 6 思路（用来解决思考中的问题）
|
||||
|
||||
|
||||
|
||||
## 7 启发
|
||||
当你完成以上6部分以后。应该重新认真的阅读一遍论文。然后对“项目支撑：网络探测”篇与“研究方向：群体协同”篇的部分进补充与完善。给出最新的问题描述、数学抽象、模型求解、关键技术。准确的说，这片文章，给出的论文架构非常值得借鉴，同时，这篇论文给出的思考问题的方式也非常值得借鉴。
|
||||
|
||||
以后，无论遇到求解什么问题。无非都是这样。
|
||||
$$
|
||||
问题描述-》数学抽象-》模型求解-》关键技术
|
||||
$$
|
||||
* 问题描述，将面对的主要矛盾，需要解决的主要问题、次要问题进行罗列。给问题划定范围，给问题定界。找到问题的外部输入和输出。通过对问题的论述，明确以上内容。
|
||||
* 数学抽象（理论抽象），一个问题往往与实际的应用场景相关性非常大，应该将问题抽象为具有普遍性的数学问题，然后定义相关的概念，实现对问题本身、问题界限、问题的输入输出、问题对象的数学描述。有了数学描述，就可以查阅相关的文献资料。
|
||||
* 模型求解。可以分为，建立模型与模型求解。通过阅读资料，建立解决问题的数学模型。定义相关的算法、协议、机制。使其能够很好的解决数学问题，达到期望效果。然后对模型进行求解，验证模型的准确性，对模型进行评估。
|
||||
* 关键技术。模型中存在关键的步骤。可以对其进行单独说明。应用的具体方案。一些关键的算法。
|
||||
|
||||
|
||||
48
maven/1简介.md
Normal file
48
maven/1简介.md
Normal file
@@ -0,0 +1,48 @@
|
||||
# maven简介
|
||||
|
||||
> 纯java开源项目。**项目管理工具**，对java项目进行构建、依赖管理。也可以用于构建和管理其他项目（c#,Ruby,Scala)
|
||||
|
||||
> 在上一次做handoop mapreduce的时候，发现了pom文件，然后配置了maven，作为maven工程打开过。但是具体的过程，为啥忘得一干二净，只记得自己曾经对maven的setting文件进行修改，那个时候应该还创建了本地库。但是完全记不清了。
|
||||
|
||||
## 1 maven主要功能
|
||||
|
||||
* 构建
|
||||
* 文档生成
|
||||
* 报告
|
||||
* 依赖
|
||||
* SCMs
|
||||
* 发布
|
||||
* 分发
|
||||
* 邮件列表
|
||||
|
||||
|
||||
## 2 maven项目目录结构
|
||||
| 目录| 目的|
|
||||
|-|-|
|
||||
| ${basedir} |存放pom.xml和所有的子目录|
|
||||
| ${basedir}/src/main/java |项目的java源代码|
|
||||
| ${basedir}/src/main/resources |项目的资源，比如说property文件，springmvc.xml|
|
||||
| ${basedir}/src/test/java |项目的测试类，比如说Junit代码|
|
||||
| ${basedir}/src/test/resources |测试用的资源|
|
||||
| ${basedir}/src/main/webapp/WEB-INF |web应用文件目录，web项目的信息，比如存放web.xml、本地图片、jsp视图页面|
|
||||
| ${basedir}/target |打包输出目录|
|
||||
| ${basedir}/target/classes |编译输出目录|
|
||||
| ${basedir}/target/test-classes |测试编译输出目录|
|
||||
| Test.java |Maven只会自动运行符合该命名规则的测试类|
|
||||
| ~/.m2/repository |Maven默认的本地仓库目录位置|
|
||||
|
||||
|
||||
## 3 maven项目的优势
|
||||
* 基于模型的构建 − Maven能够将任意数量的项目构建到预定义的输出类型中，如 JAR，WAR 或基于项目元数据的分发，而不需要在大多数情况下执行任何脚本。
|
||||
* 项目信息的一致性站点 − 使用与构建过程相同的元数据，Maven 能够生成一个网站或PDF，包括您要添加的任何文档，并添加到关于项目开发状态的标准报告中。
|
||||
* 发布管理和发布单独的输出 − Maven 将不需要额外的配置，就可以与源代码管理系统（如 Subversion 或 Git）集成，并可以基于某个标签管理项目的发布。它也可以将其发布到分发位置供其他项目使用。Maven 能够发布单独的输出，如 JAR，包含其他依赖和文档的归档，或者作为源代码发布。
|
||||
* 向后兼容性 − 您可以很轻松的从旧版本 Maven 的多个模块移植到 Maven 3 中。
|
||||
* 子项目使用父项目依赖时，正常情况子项目应该继承父项目依赖，无需使用版本号
|
||||
* 并行构建 − 编译的速度能普遍提高20 - 50 %。
|
||||
* 更好的错误报告 − Maven 改进了错误报告，它为您提供了 Maven wiki 页面的链接，您可以点击链接查看错误的完整描述。
|
||||
|
||||
## 4 maven名词解释
|
||||
* 项目对象模型POM：，xml文件，项目基本信息，描述项目构建过程，声明项目依赖。
|
||||
* 构件：任何一个依赖、插件或者项目构建输出，都可以称之为构件。
|
||||
* 插件Plugin：maven是依赖插件完成任务的，项目管理工具。
|
||||
* 仓库Repository：maven仓库能够帮我们管理构件
|
||||
931
maven/2maven POM.md
Normal file
931
maven/2maven POM.md
Normal file
@@ -0,0 +1,931 @@
|
||||
## 1 简介
|
||||
|
||||
POM( Project Object Model，项目对象模型 ) 是 Maven 工程的基本工作单元，是一个XML文件，包含了项目的基本信息，用于描述项目如何构建，声明项目依赖，等等。
|
||||
|
||||
pom.xml 项目模型对象文件。POM 中可以指定以下配置：
|
||||
|
||||
* 项目依赖
|
||||
* 插件
|
||||
* 执行目标
|
||||
* 项目构建 profile
|
||||
* 项目版本
|
||||
* 项目开发者列表
|
||||
* 相关邮件列表信息
|
||||
|
||||
## 2 POM 标签大全详解
|
||||
```
|
||||
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
|
||||
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0http://maven.apache.org/maven-v4_0_0.xsd">
|
||||
<!--父项目的坐标。如果项目中没有规定某个元素的值，那么父项目中的对应值即为项目的默认值。 坐标包括group ID，artifact ID和
|
||||
version。 -->
|
||||
<parent>
|
||||
<!--被继承的父项目的构件标识符 -->
|
||||
<artifactId />
|
||||
<!--被继承的父项目的全球唯一标识符 -->
|
||||
<groupId />
|
||||
<!--被继承的父项目的版本 -->
|
||||
<version />
|
||||
<!-- 父项目的pom.xml文件的相对路径。相对路径允许你选择一个不同的路径。默认值是../pom.xml。Maven首先在构建当前项目的地方寻找父项
|
||||
目的pom，其次在文件系统的这个位置（relativePath位置），然后在本地仓库，最后在远程仓库寻找父项目的pom。 -->
|
||||
<relativePath />
|
||||
</parent>
|
||||
<!--声明项目描述符遵循哪一个POM模型版本。模型本身的版本很少改变，虽然如此，但它仍然是必不可少的，这是为了当Maven引入了新的特性或者其他模型变更的时候，确保稳定性。 -->
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
<!--项目的全球唯一标识符，通常使用全限定的包名区分该项目和其他项目。并且构建时生成的路径也是由此生成， 如com.mycompany.app生成的相对路径为：/com/mycompany/app -->
|
||||
<groupId>asia.banseon</groupId>
|
||||
<!-- 构件的标识符，它和group ID一起唯一标识一个构件。换句话说，你不能有两个不同的项目拥有同样的artifact ID和groupID；在某个
|
||||
特定的group ID下，artifact ID也必须是唯一的。构件是项目产生的或使用的一个东西，Maven为项目产生的构件包括：JARs，源 码，二进制发布和WARs等。 -->
|
||||
<artifactId>banseon-maven2</artifactId>
|
||||
<!--项目产生的构件类型，例如jar、war、ear、pom。插件可以创建他们自己的构件类型，所以前面列的不是全部构件类型 -->
|
||||
<packaging>jar</packaging>
|
||||
<!--项目当前版本，格式为:主版本.次版本.增量版本-限定版本号 -->
|
||||
<version>1.0-SNAPSHOT</version>
|
||||
<!--项目的名称, Maven产生的文档用 -->
|
||||
<name>banseon-maven</name>
|
||||
<!--项目主页的URL, Maven产生的文档用 -->
|
||||
<url>http://www.baidu.com/banseon</url>
|
||||
<!-- 项目的详细描述, Maven 产生的文档用。 当这个元素能够用HTML格式描述时（例如，CDATA中的文本会被解析器忽略，就可以包含HTML标
|
||||
签）， 不鼓励使用纯文本描述。如果你需要修改产生的web站点的索引页面，你应该修改你自己的索引页文件，而不是调整这里的文档。 -->
|
||||
<description>A maven project to study maven.</description>
|
||||
<!--描述了这个项目构建环境中的前提条件。 -->
|
||||
<prerequisites>
|
||||
<!--构建该项目或使用该插件所需要的Maven的最低版本 -->
|
||||
<maven />
|
||||
</prerequisites>
|
||||
<!--项目的问题管理系统(Bugzilla, Jira, Scarab,或任何你喜欢的问题管理系统)的名称和URL，本例为 jira -->
|
||||
<issueManagement>
|
||||
<!--问题管理系统（例如jira）的名字， -->
|
||||
<system>jira</system>
|
||||
<!--该项目使用的问题管理系统的URL -->
|
||||
<url>http://jira.baidu.com/banseon</url>
|
||||
</issueManagement>
|
||||
<!--项目持续集成信息 -->
|
||||
<ciManagement>
|
||||
<!--持续集成系统的名字，例如continuum -->
|
||||
<system />
|
||||
<!--该项目使用的持续集成系统的URL（如果持续集成系统有web接口的话）。 -->
|
||||
<url />
|
||||
<!--构建完成时，需要通知的开发者/用户的配置项。包括被通知者信息和通知条件（错误，失败，成功，警告） -->
|
||||
<notifiers>
|
||||
<!--配置一种方式，当构建中断时，以该方式通知用户/开发者 -->
|
||||
<notifier>
|
||||
<!--传送通知的途径 -->
|
||||
<type />
|
||||
<!--发生错误时是否通知 -->
|
||||
<sendOnError />
|
||||
<!--构建失败时是否通知 -->
|
||||
<sendOnFailure />
|
||||
<!--构建成功时是否通知 -->
|
||||
<sendOnSuccess />
|
||||
<!--发生警告时是否通知 -->
|
||||
<sendOnWarning />
|
||||
<!--不赞成使用。通知发送到哪里 -->
|
||||
<address />
|
||||
<!--扩展配置项 -->
|
||||
<configuration />
|
||||
</notifier>
|
||||
</notifiers>
|
||||
</ciManagement>
|
||||
<!--项目创建年份，4位数字。当产生版权信息时需要使用这个值。 -->
|
||||
<inceptionYear />
|
||||
<!--项目相关邮件列表信息 -->
|
||||
<mailingLists>
|
||||
<!--该元素描述了项目相关的所有邮件列表。自动产生的网站引用这些信息。 -->
|
||||
<mailingList>
|
||||
<!--邮件的名称 -->
|
||||
<name>Demo</name>
|
||||
<!--发送邮件的地址或链接，如果是邮件地址，创建文档时，mailto: 链接会被自动创建 -->
|
||||
<post>banseon@126.com</post>
|
||||
<!--订阅邮件的地址或链接，如果是邮件地址，创建文档时，mailto: 链接会被自动创建 -->
|
||||
<subscribe>banseon@126.com</subscribe>
|
||||
<!--取消订阅邮件的地址或链接，如果是邮件地址，创建文档时，mailto: 链接会被自动创建 -->
|
||||
<unsubscribe>banseon@126.com</unsubscribe>
|
||||
<!--你可以浏览邮件信息的URL -->
|
||||
<archive>http:/hi.baidu.com/banseon/demo/dev/</archive>
|
||||
</mailingList>
|
||||
</mailingLists>
|
||||
<!--项目开发者列表 -->
|
||||
<developers>
|
||||
<!--某个项目开发者的信息 -->
|
||||
<developer>
|
||||
<!--SCM里项目开发者的唯一标识符 -->
|
||||
<id>HELLO WORLD</id>
|
||||
<!--项目开发者的全名 -->
|
||||
<name>banseon</name>
|
||||
<!--项目开发者的email -->
|
||||
<email>banseon@126.com</email>
|
||||
<!--项目开发者的主页的URL -->
|
||||
<url />
|
||||
<!--项目开发者在项目中扮演的角色，角色元素描述了各种角色 -->
|
||||
<roles>
|
||||
<role>Project Manager</role>
|
||||
<role>Architect</role>
|
||||
</roles>
|
||||
<!--项目开发者所属组织 -->
|
||||
<organization>demo</organization>
|
||||
<!--项目开发者所属组织的URL -->
|
||||
<organizationUrl>http://hi.baidu.com/banseon</organizationUrl>
|
||||
<!--项目开发者属性，如即时消息如何处理等 -->
|
||||
<properties>
|
||||
<dept>No</dept>
|
||||
</properties>
|
||||
<!--项目开发者所在时区， -11到12范围内的整数。 -->
|
||||
<timezone>-5</timezone>
|
||||
</developer>
|
||||
</developers>
|
||||
<!--项目的其他贡献者列表 -->
|
||||
<contributors>
|
||||
<!--项目的其他贡献者。参见developers/developer元素 -->
|
||||
<contributor>
|
||||
<name />
|
||||
<email />
|
||||
<url />
|
||||
<organization />
|
||||
<organizationUrl />
|
||||
<roles />
|
||||
<timezone />
|
||||
<properties />
|
||||
</contributor>
|
||||
</contributors>
|
||||
<!--该元素描述了项目所有License列表。 应该只列出该项目的license列表，不要列出依赖项目的 license列表。如果列出多个license，用户可以选择它们中的一个而不是接受所有license。 -->
|
||||
<licenses>
|
||||
<!--描述了项目的license，用于生成项目的web站点的license页面，其他一些报表和validation也会用到该元素。 -->
|
||||
<license>
|
||||
<!--license用于法律上的名称 -->
|
||||
<name>Apache 2</name>
|
||||
<!--官方的license正文页面的URL -->
|
||||
<url>http://www.baidu.com/banseon/LICENSE-2.0.txt</url>
|
||||
<!--项目分发的主要方式： repo，可以从Maven库下载 manual， 用户必须手动下载和安装依赖 -->
|
||||
<distribution>repo</distribution>
|
||||
<!--关于license的补充信息 -->
|
||||
<comments>A business-friendly OSS license</comments>
|
||||
</license>
|
||||
</licenses>
|
||||
<!--SCM(Source Control Management)标签允许你配置你的代码库，供Maven web站点和其它插件使用。 -->
|
||||
<scm>
|
||||
<!--SCM的URL,该URL描述了版本库和如何连接到版本库。欲知详情，请看SCMs提供的URL格式和列表。该连接只读。 -->
|
||||
<connection>
|
||||
scm:svn:http://svn.baidu.com/banseon/maven/banseon/banseon-maven2-trunk(dao-trunk)
|
||||
</connection>
|
||||
<!--给开发者使用的，类似connection元素。即该连接不仅仅只读 -->
|
||||
<developerConnection>
|
||||
scm:svn:http://svn.baidu.com/banseon/maven/banseon/dao-trunk
|
||||
</developerConnection>
|
||||
<!--当前代码的标签，在开发阶段默认为HEAD -->
|
||||
<tag />
|
||||
<!--指向项目的可浏览SCM库（例如ViewVC或者Fisheye）的URL。 -->
|
||||
<url>http://svn.baidu.com/banseon</url>
|
||||
</scm>
|
||||
<!--描述项目所属组织的各种属性。Maven产生的文档用 -->
|
||||
<organization>
|
||||
<!--组织的全名 -->
|
||||
<name>demo</name>
|
||||
<!--组织主页的URL -->
|
||||
<url>http://www.baidu.com/banseon</url>
|
||||
</organization>
|
||||
<!--构建项目需要的信息 -->
|
||||
<build>
|
||||
<!--该元素设置了项目源码目录，当构建项目的时候，构建系统会编译目录里的源码。该路径是相对于pom.xml的相对路径。 -->
|
||||
<sourceDirectory />
|
||||
<!--该元素设置了项目脚本源码目录，该目录和源码目录不同：绝大多数情况下，该目录下的内容 会被拷贝到输出目录(因为脚本是被解释的，而不是被编译的)。 -->
|
||||
<scriptSourceDirectory />
|
||||
<!--该元素设置了项目单元测试使用的源码目录，当测试项目的时候，构建系统会编译目录里的源码。该路径是相对于pom.xml的相对路径。 -->
|
||||
<testSourceDirectory />
|
||||
<!--被编译过的应用程序class文件存放的目录。 -->
|
||||
<outputDirectory />
|
||||
<!--被编译过的测试class文件存放的目录。 -->
|
||||
<testOutputDirectory />
|
||||
<!--使用来自该项目的一系列构建扩展 -->
|
||||
<extensions>
|
||||
<!--描述使用到的构建扩展。 -->
|
||||
<extension>
|
||||
<!--构建扩展的groupId -->
|
||||
<groupId />
|
||||
<!--构建扩展的artifactId -->
|
||||
<artifactId />
|
||||
<!--构建扩展的版本 -->
|
||||
<version />
|
||||
</extension>
|
||||
</extensions>
|
||||
<!--当项目没有规定目标（Maven2 叫做阶段）时的默认值 -->
|
||||
<defaultGoal />
|
||||
<!--这个元素描述了项目相关的所有资源路径列表，例如和项目相关的属性文件，这些资源被包含在最终的打包文件里。 -->
|
||||
<resources>
|
||||
<!--这个元素描述了项目相关或测试相关的所有资源路径 -->
|
||||
<resource>
|
||||
<!-- 描述了资源的目标路径。该路径相对target/classes目录（例如${project.build.outputDirectory}）。举个例
|
||||
子，如果你想资源在特定的包里(org.apache.maven.messages)，你就必须该元素设置为org/apache/maven /messages。然而，如果你只是想把资源放到源码目录结构里，就不需要该配置。 -->
|
||||
<targetPath />
|
||||
<!--是否使用参数值代替参数名。参数值取自properties元素或者文件里配置的属性，文件在filters元素里列出。 -->
|
||||
<filtering />
|
||||
<!--描述存放资源的目录，该路径相对POM路径 -->
|
||||
<directory />
|
||||
<!--包含的模式列表，例如**/*.xml. -->
|
||||
<includes />
|
||||
<!--排除的模式列表，例如**/*.xml -->
|
||||
<excludes />
|
||||
</resource>
|
||||
</resources>
|
||||
<!--这个元素描述了单元测试相关的所有资源路径，例如和单元测试相关的属性文件。 -->
|
||||
<testResources>
|
||||
<!--这个元素描述了测试相关的所有资源路径，参见build/resources/resource元素的说明 -->
|
||||
<testResource>
|
||||
<targetPath />
|
||||
<filtering />
|
||||
<directory />
|
||||
<includes />
|
||||
<excludes />
|
||||
</testResource>
|
||||
</testResources>
|
||||
<!--构建产生的所有文件存放的目录 -->
|
||||
<directory />
|
||||
<!--产生的构件的文件名，默认值是${artifactId}-${version}。 -->
|
||||
<finalName />
|
||||
<!--当filtering开关打开时，使用到的过滤器属性文件列表 -->
|
||||
<filters />
|
||||
<!--子项目可以引用的默认插件信息。该插件配置项直到被引用时才会被解析或绑定到生命周期。给定插件的任何本地配置都会覆盖这里的配置 -->
|
||||
<pluginManagement>
|
||||
<!--使用的插件列表 。 -->
|
||||
<plugins>
|
||||
<!--plugin元素包含描述插件所需要的信息。 -->
|
||||
<plugin>
|
||||
<!--插件在仓库里的group ID -->
|
||||
<groupId />
|
||||
<!--插件在仓库里的artifact ID -->
|
||||
<artifactId />
|
||||
<!--被使用的插件的版本（或版本范围） -->
|
||||
<version />
|
||||
<!--是否从该插件下载Maven扩展（例如打包和类型处理器），由于性能原因，只有在真需要下载时，该元素才被设置成enabled。 -->
|
||||
<extensions />
|
||||
<!--在构建生命周期中执行一组目标的配置。每个目标可能有不同的配置。 -->
|
||||
<executions>
|
||||
<!--execution元素包含了插件执行需要的信息 -->
|
||||
<execution>
|
||||
<!--执行目标的标识符，用于标识构建过程中的目标，或者匹配继承过程中需要合并的执行目标 -->
|
||||
<id />
|
||||
<!--绑定了目标的构建生命周期阶段，如果省略，目标会被绑定到源数据里配置的默认阶段 -->
|
||||
<phase />
|
||||
<!--配置的执行目标 -->
|
||||
<goals />
|
||||
<!--配置是否被传播到子POM -->
|
||||
<inherited />
|
||||
<!--作为DOM对象的配置 -->
|
||||
<configuration />
|
||||
</execution>
|
||||
</executions>
|
||||
<!--项目引入插件所需要的额外依赖 -->
|
||||
<dependencies>
|
||||
<!--参见dependencies/dependency元素 -->
|
||||
<dependency>
|
||||
......
|
||||
</dependency>
|
||||
</dependencies>
|
||||
<!--任何配置是否被传播到子项目 -->
|
||||
<inherited />
|
||||
<!--作为DOM对象的配置 -->
|
||||
<configuration />
|
||||
</plugin>
|
||||
</plugins>
|
||||
</pluginManagement>
|
||||
<!--使用的插件列表 -->
|
||||
<plugins>
|
||||
<!--参见build/pluginManagement/plugins/plugin元素 -->
|
||||
<plugin>
|
||||
<groupId />
|
||||
<artifactId />
|
||||
<version />
|
||||
<extensions />
|
||||
<executions>
|
||||
<execution>
|
||||
<id />
|
||||
<phase />
|
||||
<goals />
|
||||
<inherited />
|
||||
<configuration />
|
||||
</execution>
|
||||
</executions>
|
||||
<dependencies>
|
||||
<!--参见dependencies/dependency元素 -->
|
||||
<dependency>
|
||||
......
|
||||
</dependency>
|
||||
</dependencies>
|
||||
<goals />
|
||||
<inherited />
|
||||
<configuration />
|
||||
</plugin>
|
||||
</plugins>
|
||||
</build>
|
||||
<!--在列的项目构建profile，如果被激活，会修改构建处理 -->
|
||||
<profiles>
|
||||
<!--根据环境参数或命令行参数激活某个构建处理 -->
|
||||
<profile>
|
||||
<!--构建配置的唯一标识符。即用于命令行激活，也用于在继承时合并具有相同标识符的profile。 -->
|
||||
<id />
|
||||
<!--自动触发profile的条件逻辑。Activation是profile的开启钥匙。profile的力量来自于它 能够在某些特定的环境中自动使用某些特定的值；这些环境通过activation元素指定。activation元素并不是激活profile的唯一方式。 -->
|
||||
<activation>
|
||||
<!--profile默认是否激活的标志 -->
|
||||
<activeByDefault />
|
||||
<!--当匹配的jdk被检测到，profile被激活。例如，1.4激活JDK1.4，1.4.0_2，而!1.4激活所有版本不是以1.4开头的JDK。 -->
|
||||
<jdk />
|
||||
<!--当匹配的操作系统属性被检测到，profile被激活。os元素可以定义一些操作系统相关的属性。 -->
|
||||
<os>
|
||||
<!--激活profile的操作系统的名字 -->
|
||||
<name>Windows XP</name>
|
||||
<!--激活profile的操作系统所属家族(如 'windows') -->
|
||||
<family>Windows</family>
|
||||
<!--激活profile的操作系统体系结构 -->
|
||||
<arch>x86</arch>
|
||||
<!--激活profile的操作系统版本 -->
|
||||
<version>5.1.2600</version>
|
||||
</os>
|
||||
<!--如果Maven检测到某一个属性（其值可以在POM中通过${名称}引用），其拥有对应的名称和值，Profile就会被激活。如果值 字段是空的，那么存在属性名称字段就会激活profile，否则按区分大小写方式匹配属性值字段 -->
|
||||
<property>
|
||||
<!--激活profile的属性的名称 -->
|
||||
<name>mavenVersion</name>
|
||||
<!--激活profile的属性的值 -->
|
||||
<value>2.0.3</value>
|
||||
</property>
|
||||
<!--提供一个文件名，通过检测该文件的存在或不存在来激活profile。missing检查文件是否存在，如果不存在则激活 profile。另一方面，exists则会检查文件是否存在，如果存在则激活profile。 -->
|
||||
<file>
|
||||
<!--如果指定的文件存在，则激活profile。 -->
|
||||
<exists>/usr/local/hudson/hudson-home/jobs/maven-guide-zh-to-production/workspace/
|
||||
</exists>
|
||||
<!--如果指定的文件不存在，则激活profile。 -->
|
||||
<missing>/usr/local/hudson/hudson-home/jobs/maven-guide-zh-to-production/workspace/
|
||||
</missing>
|
||||
</file>
|
||||
</activation>
|
||||
<!--构建项目所需要的信息。参见build元素 -->
|
||||
<build>
|
||||
<defaultGoal />
|
||||
<resources>
|
||||
<resource>
|
||||
<targetPath />
|
||||
<filtering />
|
||||
<directory />
|
||||
<includes />
|
||||
<excludes />
|
||||
</resource>
|
||||
</resources>
|
||||
<testResources>
|
||||
<testResource>
|
||||
<targetPath />
|
||||
<filtering />
|
||||
<directory />
|
||||
<includes />
|
||||
<excludes />
|
||||
</testResource>
|
||||
</testResources>
|
||||
<directory />
|
||||
<finalName />
|
||||
<filters />
|
||||
<pluginManagement>
|
||||
<plugins>
|
||||
<!--参见build/pluginManagement/plugins/plugin元素 -->
|
||||
<plugin>
|
||||
<groupId />
|
||||
<artifactId />
|
||||
<version />
|
||||
<extensions />
|
||||
<executions>
|
||||
<execution>
|
||||
<id />
|
||||
<phase />
|
||||
<goals />
|
||||
<inherited />
|
||||
<configuration />
|
||||
</execution>
|
||||
</executions>
|
||||
<dependencies>
|
||||
<!--参见dependencies/dependency元素 -->
|
||||
<dependency>
|
||||
......
|
||||
</dependency>
|
||||
</dependencies>
|
||||
<goals />
|
||||
<inherited />
|
||||
<configuration />
|
||||
</plugin>
|
||||
</plugins>
|
||||
</pluginManagement>
|
||||
<plugins>
|
||||
<!--参见build/pluginManagement/plugins/plugin元素 -->
|
||||
<plugin>
|
||||
<groupId />
|
||||
<artifactId />
|
||||
<version />
|
||||
<extensions />
|
||||
<executions>
|
||||
<execution>
|
||||
<id />
|
||||
<phase />
|
||||
<goals />
|
||||
<inherited />
|
||||
<configuration />
|
||||
</execution>
|
||||
</executions>
|
||||
<dependencies>
|
||||
<!--参见dependencies/dependency元素 -->
|
||||
<dependency>
|
||||
......
|
||||
</dependency>
|
||||
</dependencies>
|
||||
<goals />
|
||||
<inherited />
|
||||
<configuration />
|
||||
</plugin>
|
||||
</plugins>
|
||||
</build>
|
||||
<!--模块（有时称作子项目） 被构建成项目的一部分。列出的每个模块元素是指向该模块的目录的相对路径 -->
|
||||
<modules />
|
||||
<!--发现依赖和扩展的远程仓库列表。 -->
|
||||
<repositories>
|
||||
<!--参见repositories/repository元素 -->
|
||||
<repository>
|
||||
<releases>
|
||||
<enabled />
|
||||
<updatePolicy />
|
||||
<checksumPolicy />
|
||||
</releases>
|
||||
<snapshots>
|
||||
<enabled />
|
||||
<updatePolicy />
|
||||
<checksumPolicy />
|
||||
</snapshots>
|
||||
<id />
|
||||
<name />
|
||||
<url />
|
||||
<layout />
|
||||
</repository>
|
||||
</repositories>
|
||||
<!--发现插件的远程仓库列表，这些插件用于构建和报表 -->
|
||||
<pluginRepositories>
|
||||
<!--包含需要连接到远程插件仓库的信息.参见repositories/repository元素 -->
|
||||
<pluginRepository>
|
||||
<releases>
|
||||
<enabled />
|
||||
<updatePolicy />
|
||||
<checksumPolicy />
|
||||
</releases>
|
||||
<snapshots>
|
||||
<enabled />
|
||||
<updatePolicy />
|
||||
<checksumPolicy />
|
||||
</snapshots>
|
||||
<id />
|
||||
<name />
|
||||
<url />
|
||||
<layout />
|
||||
</pluginRepository>
|
||||
</pluginRepositories>
|
||||
<!--该元素描述了项目相关的所有依赖。 这些依赖组成了项目构建过程中的一个个环节。它们自动从项目定义的仓库中下载。要获取更多信息，请看项目依赖机制。 -->
|
||||
<dependencies>
|
||||
<!--参见dependencies/dependency元素 -->
|
||||
<dependency>
|
||||
......
|
||||
</dependency>
|
||||
</dependencies>
|
||||
<!--不赞成使用. 现在Maven忽略该元素. -->
|
||||
<reports />
|
||||
<!--该元素包括使用报表插件产生报表的规范。当用户执行"mvn site"，这些报表就会运行。 在页面导航栏能看到所有报表的链接。参见reporting元素 -->
|
||||
<reporting>
|
||||
......
|
||||
</reporting>
|
||||
<!--参见dependencyManagement元素 -->
|
||||
<dependencyManagement>
|
||||
<dependencies>
|
||||
<!--参见dependencies/dependency元素 -->
|
||||
<dependency>
|
||||
......
|
||||
</dependency>
|
||||
</dependencies>
|
||||
</dependencyManagement>
|
||||
<!--参见distributionManagement元素 -->
|
||||
<distributionManagement>
|
||||
......
|
||||
</distributionManagement>
|
||||
<!--参见properties元素 -->
|
||||
<properties />
|
||||
</profile>
|
||||
</profiles>
|
||||
<!--模块（有时称作子项目） 被构建成项目的一部分。列出的每个模块元素是指向该模块的目录的相对路径 -->
|
||||
<modules />
|
||||
<!--发现依赖和扩展的远程仓库列表。 -->
|
||||
<repositories>
|
||||
<!--包含需要连接到远程仓库的信息 -->
|
||||
<repository>
|
||||
<!--如何处理远程仓库里发布版本的下载 -->
|
||||
<releases>
|
||||
<!--true或者false表示该仓库是否为下载某种类型构件（发布版，快照版）开启。 -->
|
||||
<enabled />
|
||||
<!--该元素指定更新发生的频率。Maven会比较本地POM和远程POM的时间戳。这里的选项是：always（一直），daily（默认，每日），interval：X（这里X是以分钟为单位的时间间隔），或者never（从不）。 -->
|
||||
<updatePolicy />
|
||||
<!--当Maven验证构件校验文件失败时该怎么做：ignore（忽略），fail（失败），或者warn（警告）。 -->
|
||||
<checksumPolicy />
|
||||
</releases>
|
||||
<!-- 如何处理远程仓库里快照版本的下载。有了releases和snapshots这两组配置，POM就可以在每个单独的仓库中，为每种类型的构件采取不同的
|
||||
策略。例如，可能有人会决定只为开发目的开启对快照版本下载的支持。参见repositories/repository/releases元素 -->
|
||||
<snapshots>
|
||||
<enabled />
|
||||
<updatePolicy />
|
||||
<checksumPolicy />
|
||||
</snapshots>
|
||||
<!--远程仓库唯一标识符。可以用来匹配在settings.xml文件里配置的远程仓库 -->
|
||||
<id>banseon-repository-proxy</id>
|
||||
<!--远程仓库名称 -->
|
||||
<name>banseon-repository-proxy</name>
|
||||
<!--远程仓库URL，按protocol://hostname/path形式 -->
|
||||
<url>http://192.168.1.169:9999/repository/</url>
|
||||
<!-- 用于定位和排序构件的仓库布局类型-可以是default（默认）或者legacy（遗留）。Maven 2为其仓库提供了一个默认的布局；然
|
||||
而，Maven 1.x有一种不同的布局。我们可以使用该元素指定布局是default（默认）还是legacy（遗留）。 -->
|
||||
<layout>default</layout>
|
||||
</repository>
|
||||
</repositories>
|
||||
<!--发现插件的远程仓库列表，这些插件用于构建和报表 -->
|
||||
<pluginRepositories>
|
||||
<!--包含需要连接到远程插件仓库的信息.参见repositories/repository元素 -->
|
||||
<pluginRepository>
|
||||
......
|
||||
</pluginRepository>
|
||||
</pluginRepositories>
|
||||
|
||||
|
||||
<!--该元素描述了项目相关的所有依赖。 这些依赖组成了项目构建过程中的一个个环节。它们自动从项目定义的仓库中下载。要获取更多信息，请看项目依赖机制。 -->
|
||||
<dependencies>
|
||||
<dependency>
|
||||
<!--依赖的group ID -->
|
||||
<groupId>org.apache.maven</groupId>
|
||||
<!--依赖的artifact ID -->
|
||||
<artifactId>maven-artifact</artifactId>
|
||||
<!--依赖的版本号。 在Maven 2里, 也可以配置成版本号的范围。 -->
|
||||
<version>3.8.1</version>
|
||||
<!-- 依赖类型，默认类型是jar。它通常表示依赖的文件的扩展名，但也有例外。一个类型可以被映射成另外一个扩展名或分类器。类型经常和使用的打包方式对应，
|
||||
尽管这也有例外。一些类型的例子：jar，war，ejb-client和test-jar。如果设置extensions为 true，就可以在 plugin里定义新的类型。所以前面的类型的例子不完整。 -->
|
||||
<type>jar</type>
|
||||
<!-- 依赖的分类器。分类器可以区分属于同一个POM，但不同构建方式的构件。分类器名被附加到文件名的版本号后面。例如，如果你想要构建两个单独的构件成
|
||||
JAR，一个使用Java 1.4编译器，另一个使用Java 6编译器，你就可以使用分类器来生成两个单独的JAR构件。 -->
|
||||
<classifier></classifier>
|
||||
<!--依赖范围。在项目发布过程中，帮助决定哪些构件被包括进来。欲知详情请参考依赖机制。 - compile ：默认范围，用于编译 - provided：类似于编译，但支持你期待jdk或者容器提供，类似于classpath
|
||||
- runtime: 在执行时需要使用 - test: 用于test任务时使用 - system: 需要外在提供相应的元素。通过systemPath来取得
|
||||
- systemPath: 仅用于范围为system。提供相应的路径 - optional: 当项目自身被依赖时，标注依赖是否传递。用于连续依赖时使用 -->
|
||||
<scope>test</scope>
|
||||
<!--仅供system范围使用。注意，不鼓励使用这个元素，并且在新的版本中该元素可能被覆盖掉。该元素为依赖规定了文件系统上的路径。需要绝对路径而不是相对路径。推荐使用属性匹配绝对路径，例如${java.home}。 -->
|
||||
<systemPath></systemPath>
|
||||
<!--当计算传递依赖时， 从依赖构件列表里，列出被排除的依赖构件集。即告诉maven你只依赖指定的项目，不依赖项目的依赖。此元素主要用于解决版本冲突问题 -->
|
||||
<exclusions>
|
||||
<exclusion>
|
||||
<artifactId>spring-core</artifactId>
|
||||
<groupId>org.springframework</groupId>
|
||||
</exclusion>
|
||||
</exclusions>
|
||||
<!--可选依赖，如果你在项目B中把C依赖声明为可选，你就需要在依赖于B的项目（例如项目A）中显式的引用对C的依赖。可选依赖阻断依赖的传递性。 -->
|
||||
<optional>true</optional>
|
||||
</dependency>
|
||||
</dependencies>
|
||||
<!--不赞成使用. 现在Maven忽略该元素. -->
|
||||
<reports></reports>
|
||||
<!--该元素描述使用报表插件产生报表的规范。当用户执行"mvn site"，这些报表就会运行。 在页面导航栏能看到所有报表的链接。 -->
|
||||
<reporting>
|
||||
<!--true，则，网站不包括默认的报表。这包括"项目信息"菜单中的报表。 -->
|
||||
<excludeDefaults />
|
||||
<!--所有产生的报表存放到哪里。默认值是${project.build.directory}/site。 -->
|
||||
<outputDirectory />
|
||||
<!--使用的报表插件和他们的配置。 -->
|
||||
<plugins>
|
||||
<!--plugin元素包含描述报表插件需要的信息 -->
|
||||
<plugin>
|
||||
<!--报表插件在仓库里的group ID -->
|
||||
<groupId />
|
||||
<!--报表插件在仓库里的artifact ID -->
|
||||
<artifactId />
|
||||
<!--被使用的报表插件的版本（或版本范围） -->
|
||||
<version />
|
||||
<!--任何配置是否被传播到子项目 -->
|
||||
<inherited />
|
||||
<!--报表插件的配置 -->
|
||||
<configuration />
|
||||
<!--一组报表的多重规范，每个规范可能有不同的配置。一个规范（报表集）对应一个执行目标 。例如，有1，2，3，4，5，6，7，8，9个报表。1，2，5构成A报表集，对应一个执行目标。2，5，8构成B报表集，对应另一个执行目标 -->
|
||||
<reportSets>
|
||||
<!--表示报表的一个集合，以及产生该集合的配置 -->
|
||||
<reportSet>
|
||||
<!--报表集合的唯一标识符，POM继承时用到 -->
|
||||
<id />
|
||||
<!--产生报表集合时，被使用的报表的配置 -->
|
||||
<configuration />
|
||||
<!--配置是否被继承到子POMs -->
|
||||
<inherited />
|
||||
<!--这个集合里使用到哪些报表 -->
|
||||
<reports />
|
||||
</reportSet>
|
||||
</reportSets>
|
||||
</plugin>
|
||||
</plugins>
|
||||
</reporting>
|
||||
<!-- 继承自该项目的所有子项目的默认依赖信息。这部分的依赖信息不会被立即解析,而是当子项目声明一个依赖（必须描述group ID和 artifact
|
||||
ID信息），如果group ID和artifact ID以外的一些信息没有描述，则通过group ID和artifact ID 匹配到这里的依赖，并使用这里的依赖信息。 -->
|
||||
<dependencyManagement>
|
||||
<dependencies>
|
||||
<!--参见dependencies/dependency元素 -->
|
||||
<dependency>
|
||||
......
|
||||
</dependency>
|
||||
</dependencies>
|
||||
</dependencyManagement>
|
||||
<!--项目分发信息，在执行mvn deploy后表示要发布的位置。有了这些信息就可以把网站部署到远程服务器或者把构件部署到远程仓库。 -->
|
||||
<distributionManagement>
|
||||
<!--部署项目产生的构件到远程仓库需要的信息 -->
|
||||
<repository>
|
||||
<!--是分配给快照一个唯一的版本号（由时间戳和构建流水号）？还是每次都使用相同的版本号？参见repositories/repository元素 -->
|
||||
<uniqueVersion />
|
||||
<id>banseon-maven2</id>
|
||||
<name>banseon maven2</name>
|
||||
<url>file://${basedir}/target/deploy</url>
|
||||
<layout />
|
||||
</repository>
|
||||
<!--构件的快照部署到哪里？如果没有配置该元素，默认部署到repository元素配置的仓库，参见distributionManagement/repository元素 -->
|
||||
<snapshotRepository>
|
||||
<uniqueVersion />
|
||||
<id>banseon-maven2</id>
|
||||
<name>Banseon-maven2 Snapshot Repository</name>
|
||||
<url>scp://svn.baidu.com/banseon:/usr/local/maven-snapshot</url>
|
||||
<layout />
|
||||
</snapshotRepository>
|
||||
<!--部署项目的网站需要的信息 -->
|
||||
<site>
|
||||
<!--部署位置的唯一标识符，用来匹配站点和settings.xml文件里的配置 -->
|
||||
<id>banseon-site</id>
|
||||
<!--部署位置的名称 -->
|
||||
<name>business api website</name>
|
||||
<!--部署位置的URL，按protocol://hostname/path形式 -->
|
||||
<url>
|
||||
scp://svn.baidu.com/banseon:/var/www/localhost/banseon-web
|
||||
</url>
|
||||
</site>
|
||||
<!--项目下载页面的URL。如果没有该元素，用户应该参考主页。使用该元素的原因是：帮助定位那些不在仓库里的构件（由于license限制）。 -->
|
||||
<downloadUrl />
|
||||
<!--如果构件有了新的group ID和artifact ID（构件移到了新的位置），这里列出构件的重定位信息。 -->
|
||||
<relocation>
|
||||
<!--构件新的group ID -->
|
||||
<groupId />
|
||||
<!--构件新的artifact ID -->
|
||||
<artifactId />
|
||||
<!--构件新的版本号 -->
|
||||
<version />
|
||||
<!--显示给用户的，关于移动的额外信息，例如原因。 -->
|
||||
<message />
|
||||
</relocation>
|
||||
<!-- 给出该构件在远程仓库的状态。不得在本地项目中设置该元素，因为这是工具自动更新的。有效的值有：none（默认），converted（仓库管理员从
|
||||
Maven 1 POM转换过来），partner（直接从伙伴Maven 2仓库同步过来），deployed（从Maven 2实例部 署），verified（被核实时正确的和最终的）。 -->
|
||||
<status />
|
||||
</distributionManagement>
|
||||
<!--以值替代名称，Properties可以在整个POM中使用，也可以作为触发条件（见settings.xml配置文件里activation元素的说明）。格式是<name>value</name>。 -->
|
||||
<properties />
|
||||
</project>
|
||||
```
|
||||
|
||||
## 3 本项目的pom
|
||||
> 有时间对这个进行注释
|
||||
```
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
|
||||
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
<parent>
|
||||
<groupId>org.springframework.boot</groupId>
|
||||
<artifactId>spring-boot-starter-parent</artifactId>
|
||||
<version>2.3.0.RELEASE</version>
|
||||
<relativePath/> <!-- lookup parent from repository -->
|
||||
</parent>
|
||||
<groupId>com.xykj</groupId>
|
||||
<artifactId>wallet-api</artifactId>
|
||||
<version>0.0.1-SNAPSHOT</version>
|
||||
<name>wallet-api</name>
|
||||
<description>浔银电子钱包接口服务</description>
|
||||
|
||||
<properties>
|
||||
<java.version>1.8</java.version>
|
||||
<lombok.version>1.18.12</lombok.version>
|
||||
<mybatis.version>2.1.2</mybatis.version>
|
||||
<swagger.version>2.9.2</swagger.version>
|
||||
<zcloud.version>1.0.0</zcloud.version>
|
||||
<jjwt.version>0.9.1</jjwt.version>
|
||||
<fastjson.version>1.2.68</fastjson.version>
|
||||
<hutool.version>5.3.5</hutool.version>
|
||||
|
||||
</properties>
|
||||
|
||||
<dependencies>
|
||||
<!-- https://mvnrepository.com/artifact/org.springframework.retry/spring-retry -->
|
||||
<dependency>
|
||||
<groupId>org.springframework.retry</groupId>
|
||||
<artifactId>spring-retry</artifactId>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.springframework.boot</groupId>
|
||||
<artifactId>spring-boot-starter-web</artifactId>
|
||||
<exclusions>
|
||||
<exclusion>
|
||||
<groupId>org.springframework.boot</groupId>
|
||||
<artifactId>spring-boot-starter-tomcat</artifactId>
|
||||
</exclusion>
|
||||
</exclusions>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.springframework.boot</groupId>
|
||||
<artifactId>spring-boot-starter-undertow</artifactId>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.springframework.boot</groupId>
|
||||
<artifactId>spring-boot-starter-aop</artifactId>
|
||||
</dependency>
|
||||
|
||||
<!-- https://mvnrepository.com/artifact/org.projectlombok/lombok -->
|
||||
<dependency>
|
||||
<groupId>org.projectlombok</groupId>
|
||||
<artifactId>lombok</artifactId>
|
||||
<version>${lombok.version}</version>
|
||||
<scope>provided</scope>
|
||||
</dependency>
|
||||
|
||||
<!-- https://mvnrepository.com/artifact/cn.hutool/hutool-all -->
|
||||
<dependency>
|
||||
<groupId>cn.hutool</groupId>
|
||||
<artifactId>hutool-all</artifactId>
|
||||
<version>${hutool.version}</version>
|
||||
</dependency>
|
||||
|
||||
<dependency>
|
||||
<groupId>org.springframework.boot</groupId>
|
||||
<artifactId>spring-boot-starter-test</artifactId>
|
||||
<scope>test</scope>
|
||||
<exclusions>
|
||||
<exclusion>
|
||||
<groupId>org.junit.vintage</groupId>
|
||||
<artifactId>junit-vintage-engine</artifactId>
|
||||
</exclusion>
|
||||
</exclusions>
|
||||
</dependency>
|
||||
|
||||
<!--阿里云的短信服务SDK start-->
|
||||
<dependency>
|
||||
<groupId>com.aliyun</groupId>
|
||||
<artifactId>aliyun-java-sdk-core</artifactId>
|
||||
<version>4.5.1</version>
|
||||
</dependency>
|
||||
|
||||
<dependency>
|
||||
<groupId>com.aliyun</groupId>
|
||||
<artifactId>aliyun-java-sdk-dysmsapi</artifactId>
|
||||
<version>2.1.0</version>
|
||||
</dependency>
|
||||
|
||||
<!--阿里云的短信服务SDK end-->
|
||||
<dependency>
|
||||
<groupId>com.alibaba</groupId>
|
||||
<artifactId>fastjson</artifactId>
|
||||
<version>${fastjson.version}</version>
|
||||
</dependency>
|
||||
|
||||
<dependency>
|
||||
<groupId>org.aspectj</groupId>
|
||||
<artifactId>aspectjrt</artifactId>
|
||||
<version>1.9.5</version>
|
||||
</dependency>
|
||||
|
||||
<dependency>
|
||||
<groupId>commons-codec</groupId>
|
||||
<artifactId>commons-codec</artifactId>
|
||||
<version>1.13</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.apache.commons</groupId>
|
||||
<artifactId>commons-lang3</artifactId>
|
||||
<version>3.9</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>commons-io</groupId>
|
||||
<artifactId>commons-io</artifactId>
|
||||
<version>2.0.1</version>
|
||||
</dependency>
|
||||
|
||||
<!--Zcloud依赖-->
|
||||
<!--<dependency>-->
|
||||
<!--<groupId>com.zxw.zcloud</groupId>-->
|
||||
<!--<artifactId>xxljob-boot-starter</artifactId>-->
|
||||
<!--<version>${zcloud.version}</version>-->
|
||||
<!--</dependency>-->
|
||||
|
||||
<dependency>
|
||||
<groupId>com.zxw.zcloud</groupId>
|
||||
<artifactId>db-spring-boot-starter</artifactId>
|
||||
<version>${zcloud.version}</version>
|
||||
</dependency>
|
||||
|
||||
<dependency>
|
||||
<groupId>com.zxw.zcloud</groupId>
|
||||
<artifactId>swagger-spring-boot-starter</artifactId>
|
||||
<version>${zcloud.version}</version>
|
||||
</dependency>
|
||||
|
||||
<dependency>
|
||||
<groupId>com.zxw.zcloud</groupId>
|
||||
<artifactId>cache-spring-boot-starter</artifactId>
|
||||
<version>${zcloud.version}</version>
|
||||
</dependency>
|
||||
|
||||
<dependency>
|
||||
<groupId>com.zxw.zcloud</groupId>
|
||||
<artifactId>license-boot-starter</artifactId>
|
||||
<version>${zcloud.version}</version>
|
||||
</dependency>
|
||||
|
||||
<dependency>
|
||||
<groupId>io.jsonwebtoken</groupId>
|
||||
<artifactId>jjwt</artifactId>
|
||||
<version>${jjwt.version}</version>
|
||||
</dependency>
|
||||
|
||||
<!--微信公众号-->
|
||||
<dependency>
|
||||
<groupId>com.github.binarywang</groupId>
|
||||
<artifactId>weixin-java-mp</artifactId>
|
||||
<version>3.8.0</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>junit</groupId>
|
||||
<artifactId>junit</artifactId>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.springframework.security</groupId>
|
||||
<artifactId>spring-security-core</artifactId>
|
||||
<version>5.2.1.RELEASE</version>
|
||||
</dependency>
|
||||
|
||||
<dependency>
|
||||
<groupId>io.swagger</groupId>
|
||||
<artifactId>swagger-annotations</artifactId>
|
||||
<version>1.5.20</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.xmlunit</groupId>
|
||||
<artifactId>xmlunit-core</artifactId>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.mybatis</groupId>
|
||||
<artifactId>mybatis</artifactId>
|
||||
<version>3.5.5</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.redisson</groupId>
|
||||
<artifactId>redisson</artifactId>
|
||||
<version>3.11.4</version>
|
||||
</dependency>
|
||||
|
||||
</dependencies>
|
||||
|
||||
<build>
|
||||
<plugins>
|
||||
<plugin>
|
||||
<groupId>org.springframework.boot</groupId>
|
||||
<artifactId>spring-boot-maven-plugin</artifactId>
|
||||
</plugin>
|
||||
</plugins>
|
||||
</build>
|
||||
|
||||
<repositories>
|
||||
<!--<repository>-->
|
||||
<!--<id>public</id>-->
|
||||
<!--<name>aliyun nexus</name>-->
|
||||
<!--<url>http://maven.aliyun.com/nexus/content/groups/public/</url>-->
|
||||
<!--<releases>-->
|
||||
<!--<enabled>true</enabled>-->
|
||||
<!--</releases>-->
|
||||
<!--</repository>-->
|
||||
<repository>
|
||||
<id>zclod</id>
|
||||
<name>zcloud nexus</name>
|
||||
<url>http://maven.zoujy.com/repository/zcloud_group/</url>
|
||||
<releases>
|
||||
<enabled>true</enabled>
|
||||
</releases>
|
||||
</repository>
|
||||
</repositories>
|
||||
|
||||
<pluginRepositories>
|
||||
<pluginRepository>
|
||||
<id>public</id>
|
||||
<name>zcloud nexus</name>
|
||||
<url>http://maven.aliyun.com/nexus/content/groups/public/</url>
|
||||
<!--<url>http://maven.zoujy.com/repository/zcloud_group/</url>-->
|
||||
<releases>
|
||||
<enabled>true</enabled>
|
||||
</releases>
|
||||
<snapshots>
|
||||
<enabled>false</enabled>
|
||||
</snapshots>
|
||||
</pluginRepository>
|
||||
</pluginRepositories>
|
||||
</project>
|
||||
|
||||
```
|
||||
167
maven/3maven构建配置文件.md
Normal file
167
maven/3maven构建配置文件.md
Normal file
@@ -0,0 +1,167 @@
|
||||
## 1 配置文件的类型
|
||||
|
||||
* 项目级：定义在项目的POM文件pom.xml中。
|
||||
* 用户级：定义在maven的设置文件xml中（%USER_HOME%.m2/setting.xml)
|
||||
* 全局：定义在Maven全局的设置xml文件中（%M2_HOME%/comf/settings.xml）
|
||||
|
||||
## 配置文件激活
|
||||
|
||||
### 配置文件激活
|
||||
|
||||
profile 可以让我们定义一系列的配置信息，然后指定其激活条件。这样我们就可以定义多个 profile，然后每个 profile 对应不同的激活条件和配置信息，从而达到不同环境使用不同配置信息的效果。
|
||||
|
||||
### 通过maven设置激活配置文件
|
||||
|
||||
通过Maven设置激活配置文件
|
||||
打开 %USER_HOME%/.m2 目录下的 settings.xml 文件，其中 %USER_HOME% 代表用户主目录。如果 setting.xml 文件不存在就直接拷贝 %M2_HOME%/conf/settings.xml 到 .m2 目录，其中 %M2_HOME% 代表 Maven 的安装目录。
|
||||
|
||||
配置 setting.xml 文件，增加 <activeProfiles>属性：
|
||||
```
|
||||
<settings xmlns="http://maven.apache.org/POM/4.0.0"
|
||||
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
|
||||
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
|
||||
http://maven.apache.org/xsd/settings-1.0.0.xsd">
|
||||
...
|
||||
<activeProfiles>
|
||||
<activeProfile>test</activeProfile>
|
||||
</activeProfiles>
|
||||
</settings>
|
||||
```
|
||||
|
||||
### 通过环境变量激活配置文件
|
||||
pom.xml 里面的 \<id> 为 test 的 \<profile> 节点，加入 \<activation> 节点：
|
||||
```
|
||||
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
|
||||
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
<groupId>com.jsoft.test</groupId>
|
||||
<artifactId>testproject</artifactId>
|
||||
<packaging>jar</packaging>
|
||||
<version>0.1-SNAPSHOT</version>
|
||||
<name>testproject</name>
|
||||
<url>http://maven.apache.org</url>
|
||||
<dependencies>
|
||||
<dependency>
|
||||
<groupId>junit</groupId>
|
||||
<artifactId>junit</artifactId>
|
||||
<version>3.8.1</version>
|
||||
<scope>test</scope>
|
||||
</dependency>
|
||||
</dependencies>
|
||||
<profiles>
|
||||
<profile>
|
||||
<id>test</id>
|
||||
<activation>
|
||||
<property>
|
||||
<name>env</name>
|
||||
<value>test</value>
|
||||
</property>
|
||||
</activation>
|
||||
<build>
|
||||
<plugins>
|
||||
<plugin>
|
||||
<groupId>org.apache.maven.plugins</groupId>
|
||||
<artifactId>maven-antrun-plugin</artifactId>
|
||||
<version>1.8</version>
|
||||
<executions>
|
||||
<execution>
|
||||
<phase>test</phase>
|
||||
<goals>
|
||||
<goal>run</goal>
|
||||
</goals>
|
||||
<configuration>
|
||||
<tasks>
|
||||
<echo>Using env.test.properties</echo>
|
||||
<copy file="src/main/resources/env.test.properties" tofile="${project.build.outputDirectory}/env.properties" overwrite="true"/>
|
||||
</tasks>
|
||||
</configuration>
|
||||
</execution>
|
||||
</executions>
|
||||
</plugin>
|
||||
</plugins>
|
||||
</build>
|
||||
</profile>
|
||||
<profile>
|
||||
<id>normal</id>
|
||||
<build>
|
||||
<plugins>
|
||||
<plugin>
|
||||
<groupId>org.apache.maven.plugins</groupId>
|
||||
<artifactId>maven-antrun-plugin</artifactId>
|
||||
<version>1.8</version>
|
||||
<executions>
|
||||
<execution>
|
||||
<phase>test</phase>
|
||||
<goals>
|
||||
<goal>run</goal>
|
||||
</goals>
|
||||
<configuration>
|
||||
<tasks>
|
||||
<echo>Using env.properties</echo>
|
||||
<copy file="src/main/resources/env.properties" tofile="${project.build.outputDirectory}/env.properties" overwrite="true"/>
|
||||
</tasks>
|
||||
</configuration>
|
||||
</execution>
|
||||
</executions>
|
||||
</plugin>
|
||||
</plugins>
|
||||
</build>
|
||||
</profile>
|
||||
<profile>
|
||||
<id>prod</id>
|
||||
<build>
|
||||
<plugins>
|
||||
<plugin>
|
||||
<groupId>org.apache.maven.plugins</groupId>
|
||||
<artifactId>maven-antrun-plugin</artifactId>
|
||||
<version>1.8</version>
|
||||
<executions>
|
||||
<execution>
|
||||
<phase>test</phase>
|
||||
<goals>
|
||||
<goal>run</goal>
|
||||
</goals>
|
||||
<configuration>
|
||||
<tasks>
|
||||
<echo>Using env.prod.properties</echo>
|
||||
<copy file="src/main/resources/env.prod.properties" tofile="${project.build.outputDirectory}/env.properties" overwrite="true"/>
|
||||
</tasks>
|
||||
</configuration>
|
||||
</execution>
|
||||
</executions>
|
||||
</plugin>
|
||||
</plugins>
|
||||
</build>
|
||||
</profile>
|
||||
</profiles>
|
||||
</project>
|
||||
```
|
||||
|
||||
### 通过操作系统激活配置文件
|
||||
activation 元素包含下面的操作系统信息。当系统为 windows XP 时，test Profile 将会被触发。
|
||||
```
|
||||
<profile>
|
||||
<id>test</id>
|
||||
<activation>
|
||||
<os>
|
||||
<name>Windows XP</name>
|
||||
<family>Windows</family>
|
||||
<arch>x86</arch>
|
||||
<version>5.1.2600</version>
|
||||
</os>
|
||||
</activation>
|
||||
</profile>
|
||||
```
|
||||
### 通过文件的存在或者缺失激活配置文件
|
||||
现在使用 activation 元素包含下面的操作系统信息。当 target/generated-sources/axistools/wsdl2java/com/companyname/group 缺失时，test Profile 将会被触发。
|
||||
```
|
||||
<profile>
|
||||
<id>test</id>
|
||||
<activation>
|
||||
<file>
|
||||
<missing>target/generated-sources/axistools/wsdl2java/
|
||||
com/companyname/group</missing>
|
||||
</file>
|
||||
</activation>
|
||||
</profile>
|
||||
```
|
||||
39
maven/4pom生命周期.md
Normal file
39
maven/4pom生命周期.md
Normal file
@@ -0,0 +1,39 @@
|
||||
## 一个普通项目的生命周期
|
||||
|
||||
|
||||
|
||||
| 阶段 |处理 |描述|
|
||||
|-|-|-|-|
|
||||
| 验证 validate |验证项目 |验证项目是否正确且所有必须信息是可用的|
|
||||
| 编译 compile |执行编译 |源代码编译在此阶段完成|
|
||||
| 测试 Test |测试 |使用适当的单元测试框架（例如JUnit）运行测试。|
|
||||
| 包装 package |打包 |创建JAR/WAR包如在 pom.xml 中定义提及的包|
|
||||
| 检查 verify |检查 |对集成测试的结果进行检查，以保证质量达标|
|
||||
| 安装 install |安装 |安装打包的项目到本地仓库，以供其他项目使用|
|
||||
| 部署 deploy |部署 |拷贝最终的工程包到远程仓库中，以共享给其他开发人员和工程|
|
||||
|
||||
## maven项目的三个生命周期
|
||||
|
||||
### clean生命周期：清理项目，包含三个phase。
|
||||
|
||||
1. pre-clean：执行清理前需要完成的工作
|
||||
2. clean：清理上一次构建生成的文件
|
||||
3. post-clean：执行清理后需要完成的工作
|
||||
|
||||
### default生命周期：构建项目，重要的phase如下。
|
||||
|
||||
1. validate：验证工程是否正确，所有需要的资源是否可用。
|
||||
1. compile：编译项目的源代码。
|
||||
1. test：使用合适的单元测试框架来测试已编译的源代码。这些测试不需要已打包和布署。
|
||||
1. Package：把已编译的代码打包成可发布的格式，比如jar。
|
||||
1. integration-test：如有需要，将包处理和发布到一个能够进行集成测试的环境。
|
||||
1. verify：运行所有检查，验证包是否有效且达到质量标准。
|
||||
1. install：把包安装到maven本地仓库，可以被其他工程作为依赖来使用。
|
||||
1. Deploy：在集成或者发布环境下执行，将最终版本的包拷贝到远程的repository，使得其他的开发者或者工程可以共享。
|
||||
|
||||
### site生命周期：建立和发布项目站点，phase如下
|
||||
|
||||
1. pre-site：生成项目站点之前需要完成的工作
|
||||
2. site：生成项目站点文档
|
||||
3. post-site：生成项目站点之后需要完成的工作
|
||||
4. site-deploy：将项目站点发布到服务器
|
||||
94
maven/5maven仓库.md
Normal file
94
maven/5maven仓库.md
Normal file
@@ -0,0 +1,94 @@
|
||||
# maven仓库
|
||||
|
||||
## 1 仓库简介
|
||||
|
||||
仓库是项目中依赖的第三方库。任何一个依赖、插件或者项目构建输出，都可以称之为构件。maven仓库能够帮我们管理构件（比如jar程序）。maven仓库有3中类型，本地、中央、远程。
|
||||
|
||||
## 2 本地仓库
|
||||
|
||||
第一次运行maven仓库时，创建本地仓库。maven所需要的构建都是直接从本地仓库获取的。如果本地仓库没有，会首先尝试从远程仓库下载值本地仓库，然后使用本地仓库的构件。
|
||||
|
||||
默认的本地仓库在%USER_HOME%/.m2/respository。
|
||||
|
||||
可以通过settings.xml自定义存储路径：
|
||||
|
||||
```
|
||||
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
|
||||
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
|
||||
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
|
||||
http://maven.apache.org/xsd/settings-1.0.0.xsd">
|
||||
<localRepository>C:/MyLocalRepository</localRepository>
|
||||
</settings>
|
||||
|
||||
```
|
||||
|
||||
## 3 中央仓库
|
||||
|
||||
maven中央仓库是由maven社区提供的仓库，包含了大量常用的库。中央仓库包含了绝大多数流行的java构件。由maven社区管理，不需要配置，通过网络访问。
|
||||
|
||||
## 4 远程仓库
|
||||
编程人员自己定制的仓库，包含了所需要的代码库。远程仓库使用方法。
|
||||
```
|
||||
<project xmlns="http://maven.apache.org/POM/4.0.0"
|
||||
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
|
||||
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
|
||||
http://maven.apache.org/xsd/maven-4.0.0.xsd">
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
<groupId>com.companyname.projectgroup</groupId>
|
||||
<artifactId>project</artifactId>
|
||||
<version>1.0</version>
|
||||
<dependencies>
|
||||
<dependency>
|
||||
<groupId>com.companyname.common-lib</groupId>
|
||||
<artifactId>common-lib</artifactId>
|
||||
<version>1.0.0</version>
|
||||
</dependency>
|
||||
<dependencies>
|
||||
<repositories>
|
||||
<repository>
|
||||
<id>companyname.lib1</id>
|
||||
<url>http://download.companyname.org/maven2/lib1</url>
|
||||
</repository>
|
||||
<repository>
|
||||
<id>companyname.lib2</id>
|
||||
<url>http://download.companyname.org/maven2/lib2</url>
|
||||
</repository>
|
||||
</repositories>
|
||||
</project>
|
||||
```
|
||||
|
||||
## 5 maven依赖搜索的顺序
|
||||
|
||||
1. 在本地仓库中搜索
|
||||
2. 在中央仓库中搜索下载
|
||||
3. 在远程仓库中搜索下载
|
||||
|
||||
|
||||
## 6 中央仓库镜像
|
||||
修改maven根目录先的conf/setting.xml，添加镜像。
|
||||
```
|
||||
<mirrors>
|
||||
<mirror>
|
||||
<id>alimaven</id>
|
||||
<name>aliyun maven</name>
|
||||
<url>http://maven.aliyun.com/nexus/content/groups/public/</url>
|
||||
<mirrorOf>central</mirrorOf>
|
||||
</mirror>
|
||||
</mirrors>
|
||||
```
|
||||
在工程的pom.xml文件中，添加阿里云作为远程仓库之一。
|
||||
```
|
||||
<repositories>
|
||||
<repository>
|
||||
<id>alimaven</id>
|
||||
<name>aliyun maven</name>
|
||||
<url>http://maven.aliyun.com/nexus/content/groups/public/</url>
|
||||
<releases>
|
||||
<enabled>true</enabled>
|
||||
</releases>
|
||||
<snapshots>
|
||||
<enabled>false</enabled>
|
||||
</snapshots>
|
||||
</repository>
|
||||
</repositories>
|
||||
```
|
||||
64
maven/6maven插件.md
Normal file
64
maven/6maven插件.md
Normal file
@@ -0,0 +1,64 @@
|
||||
## 1 简介
|
||||
|
||||
maven项目包含三个生命周期，每个生命周期包含多个节点。每个节点都是由maven插件实现。例如maven-clean-plugin
|
||||
|
||||
maven实际上是一个依赖插件执行的框架。
|
||||
|
||||
插件提供了一个目标的集合。使用以下语法执行
|
||||
```
|
||||
mvn [plugin-name]:[goal-name]
|
||||
mvn compiler:compile
|
||||
```
|
||||
|
||||
## 2 常用插件
|
||||
|
||||
分为两类
|
||||
* Build plugins
|
||||
* Repoting plugins
|
||||
|
||||
常用插件列表
|
||||
|
||||
* clean 构建之后清理目标文件。删除目标目录。
|
||||
* compiler 编译 Java 源文件。
|
||||
* surefile 运行 JUnit 单元测试。创建测试报告。
|
||||
* jar 从当前工程中构建 JAR 文件。
|
||||
* war 从当前工程中构建 WAR 文件。
|
||||
* javadoc 为工程生成 Javadoc。
|
||||
* antrun 从构建过程的任意一个阶段中运行一个 ant 任务的集合。
|
||||
|
||||
## 3 插件修改方法
|
||||
|
||||
```
|
||||
<project xmlns="http://maven.apache.org/POM/4.0.0"
|
||||
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
|
||||
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
|
||||
http://maven.apache.org/xsd/maven-4.0.0.xsd">
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
<groupId>com.companyname.projectgroup</groupId>
|
||||
<artifactId>project</artifactId>
|
||||
<version>1.0</version>
|
||||
<build>
|
||||
<plugins>
|
||||
<plugin>
|
||||
<groupId>org.apache.maven.plugins</groupId>
|
||||
<artifactId>maven-antrun-plugin</artifactId>
|
||||
<version>1.1</version>
|
||||
<executions>
|
||||
<execution>
|
||||
<id>id.clean</id>
|
||||
<phase>clean</phase>
|
||||
<goals>
|
||||
<goal>run</goal>
|
||||
</goals>
|
||||
<configuration>
|
||||
<tasks>
|
||||
<echo>clean phase</echo>
|
||||
</tasks>
|
||||
</configuration>
|
||||
</execution>
|
||||
</executions>
|
||||
</plugin>
|
||||
</plugins>
|
||||
</build>
|
||||
</project>
|
||||
```
|
||||
43
maven/7maven构建java项目.md
Normal file
43
maven/7maven构建java项目.md
Normal file
@@ -0,0 +1,43 @@
|
||||
## 1 使用原型archetype插件，创建项目。
|
||||
|
||||
```
|
||||
mvn archetype:generate "-DgroupId=com.companyname.bank" "-DartifactId=consumerBanking" "-DarchetypeArtifactId=maven-archetype-quickstart" "-DinteractiveMode=false"
|
||||
```
|
||||
|
||||
> 其目录结构是标准的java目录结构。
|
||||
|
||||
## 2 对maven项目进行编译
|
||||
```
|
||||
mvn clean package
|
||||
```
|
||||
|
||||
## 3 生成项目文档
|
||||
|
||||
添加一下配置
|
||||
```
|
||||
<project>
|
||||
...
|
||||
<build>
|
||||
<pluginManagement>
|
||||
<plugins>
|
||||
<plugin>
|
||||
<groupId>org.apache.maven.plugins</groupId>
|
||||
<artifactId>maven-site-plugin</artifactId>
|
||||
<version>3.3</version>
|
||||
</plugin>
|
||||
<plugin>
|
||||
<groupId>org.apache.maven.plugins</groupId>
|
||||
<artifactId>maven-project-info-reports-plugin</artifactId>
|
||||
<version>2.7</version>
|
||||
</plugin>
|
||||
</plugins>
|
||||
</pluginManagement>
|
||||
</build>
|
||||
...
|
||||
</project>
|
||||
```
|
||||
|
||||
运行文档生成
|
||||
```
|
||||
mvn site
|
||||
```
|
||||
19
maven/8maven引入外部依赖.md
Normal file
19
maven/8maven引入外部依赖.md
Normal file
@@ -0,0 +1,19 @@
|
||||
## 1. 引入外部依赖到项目中
|
||||
在src下创建lib文件夹，用来防止第三方的jar文件。
|
||||
```
|
||||
<dependencies>
|
||||
<!-- 在这里添加你的依赖 -->
|
||||
<dependency>
|
||||
<groupId>ldapjdk</groupId> <!-- 库名称，也可以自定义 -->
|
||||
<artifactId>ldapjdk</artifactId> <!--库名称，也可以自定义-->
|
||||
<version>1.0</version> <!--版本号-->
|
||||
<scope>system</scope> <!--作用域-->
|
||||
<systemPath>${basedir}\src\lib\ldapjdk.jar</systemPath> <!--项目根目录下的lib文件夹下-->
|
||||
</dependency>
|
||||
</dependencies>
|
||||
```
|
||||
|
||||
## 2. 引入外部依赖到本地中
|
||||
|
||||
可以直接下载到当前的mvn本地仓库中。.m2/repository
|
||||
|
||||
1
maven/9maven快照.md
Normal file
1
maven/9maven快照.md
Normal file
@@ -0,0 +1 @@
|
||||
用于快速的模块化的版本迭代。
|
||||
BIN
maven/image/生命周期.png
Normal file
BIN
maven/image/生命周期.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
Reference in New Issue
Block a user