Maven中为我们集成了软件配置管理的（SCM：Software Configuration Management）功能，他可以支持我们常用SVN、CVS等，到现在我使用的1.8.1版本，共支持18个命令：

scm:branch - branch the project（创建项目的分支）
scm:validate - validate the scm information in the pom（校验SCM的配置信息）
scm:add - command to add file（增加一个文件）
scm:unedit - command to stop editing the working copy（停止编辑当前COPY）
scm:export - command to get a fresh exported copy（拉一个全新的分支）
scm:bootstrap - command to checkout and build a project（checkout并编译工程）
scm:changelog - command to show the source code revisions（显示源码版本）
scm:list - command for get the list of project files（列出工程的文件）
scm:checkin - command for commiting changes（提交变更）
scm:checkout - command for getting the source code（获取源码）
scm:status - command for showing the scm status of the working copy（获取本地项目的状态）
scm:update - command for updating the working copy with the latest changes（从服务器获取最新的版本）
scm:diff - command for showing the difference of the working copy with the remote one（比较本地与远程服务器的差异）
scm:update-subprojects - command for updating all projects in a multi project build（更新子项目）
scm:edit - command for starting edit on the working copy（编辑）
scm:tag - command for tagging a certain revision（打标签）

常用命令介绍

而我们常用只有以下这两个命令：
Usage
The SCM Plugin maps a lot of commands to a variety of scm implementations. But there are only 2 frequently used commands:

checkin - 提交变更
update - 从服务器上获取最新的版本

配置及使用

其它的SCM都有自己独特的命令来操作提交变更、或从服务器上获取最新的源吗，如SVN及CVS的操作就很不相同，使用Maven担任的SCM机制，就可以使得SCM的操作变得统一，以下是一个SVN配置示例，将以下的示例配置到pom.xml文件中

<project>
  ...
  <packaging>jar</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>SCM Sample Project</name>
  <url>http://somecompany.com</url>
  <scm>
    <connection>scm:svn:http://somerepository.com/svn_repo/trunk</connection>
    <developerConnection>scm:svn:https://somerepository.com/svn_repo/trunk</developerConnection>
    <url>http://somerepository.com/view.cvs</url>
  </scm>
  ...
</project>

照这样配置好的，现在我们要做提交或者更新，就按如下按行命令
提交：

mvn -Dmessage="<commit_log_here>" scm:checkin

获取最新版本：

mvn scm:update

SCM支持的连接类型

SCM支持两种连接类型：connection 及 developerConnection。
以下是一个连接类型为connection的配置示例：

<project>
  ...
  <build>
    [...]
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-scm-plugin</artifactId>
        <version>1.8.1</version>
        <configuration>
          <connectionType>connection</connectionType>
        </configuration>
      </plugin>
      ...
    </plugins
    ...
  </build>
  ...
</project>

以下是一个连接类型为developerConnection的配置示例：

<project>
  ...
  <build>
    ...
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-scm-plugin</artifactId>
        <version>1.8.1</version>
        <configuration>
          <connectionType>developerConnection</connectionType>
        </configuration>
      </plugin>
      ...
    </plugins
    ...
  </build>
  ...
</project>

Spinnaker 是 Netflix 开源的持续交付平台。Netflix 的服务运行在超过100000个 AWS 云实例上，Spinnaker 用于部署超过95％的 AWS 云实例。

Spinnaker 主要用于降低新部署带来的风险，Netflix 公司并不希望一个新的 Push 影响到主体服务的运作，建立一个新的微服务很简单，难点是不断升级和维护拥有数百万用户的微服务，当出现问题时，还需要快速的回滚，在这篇文章中，将重点介绍 Spinnaker 提供的一些技术和工具。

更加方便的回滚

Spinnaker 最简单的保护措施是在通过红黑（也称为蓝/绿）部署策略部署服务时启用简单回滚。

在 Spinnaker 中创建新的集群时，只需选择 “red/black”部署策略：

这个操作将保持 Spinnaker 中的最后一个集群可用，但是被禁用（即没有流量）。

如果上线时发生什么事情（事故）需要将代码回滚到上一个可用的版本，只需在侧栏中选择 Rollback 操作即可：

回滚对话框将询问你要回滚到哪个禁用的集群：

使用红/黑部署策略可以让回到最后一个已知的可用的版本，如果部署失败或出现问题是可以撤销的。

限制并发执行

Spinnaker 中另一个限制部署风险的策略是它能够限制 Pipeline 的执行。

默认的 Pipeline 一般会修改和部署相同的自动生成的备用的 Pipeline。

Spinnaker 可以配置一次只运行一个 Pipeline：

启用 NOT_STARTED 标志后，只要已经有一个正在运行的 Pipeline，任何新的 Pipeline 都将处于同一个状态，一旦这条 Pipeline 完成，等待的 Pipeline 将启动。

执行部署

我们可以限制 Spinnaker 中特定阶段的执行时间。

限制一个阶段的执行时间有两种可能的用途：

1）只有当有人能够手动干预时

2）在服务器不是采取高峰流量时。

Netflix 在一天中对流量的需求往往是周期性的。人们一般时在晚上下班后回家观看视频。Netflix 确保在流量高峰时间不会触发部署动作。为了让部署过程更加透明，Netflix 将一个名为 SPS（每秒部署，下面会介绍）的度量合并到部署报表中，并突出显示与此度量相关的部署窗口。

禁用Pipeline

如果给定的 Pipeline 产生不正确的输出，或者由于其他系统问题而不能运行，则可以禁用该 Pipeline。

禁用的 Pipeline 将不会自动触发，并且会导致触发它的任何父 Pipeline 失败。

禁用的 Pipeline 不能手动触发，直到再次启用的时候。

检查先决条件

Spinnaker 提供了一个名为 Check Preconditions 的阶段，如果不符合某些要求，将会停止 Pipeline。

第一种形式是检查一个集群的大小:

第二种形式允许指定一个灵活的程序化表达式，称为 Pipeline 表达式。

可以通过运行 Jenkins Job 或 Docker 容器来执行更复杂的检查（例如冒烟测试），这两个阶段在 Spinnaker 中都得到很好的支持。

任何 Spinnarker 阶段可以通过配置 Conditional On Expression 使其成为可选项。这允许添加可由 Pipeline 参数控制的可选阶段，并提供额外的自动质量关卡。

手动判断

Spinnaker 提供了一个 Manual Judgment 的选项，确保运维工程师或 QA 可以轻松完成需要人工的步骤。

当一个 Pipeline 到达人工判断阶段时，它会停下来等待负责人进来并点击 Continue。这可以在需要时进行额外的验证。

手动判断阶段使用 Spinnaker 内置的现有通知机制，因此可以向需要批准流水线的用户发送电子邮件，SMS 或 Slack 通知。

我们也可以指定判断条件。判断条件可以用来决定管道的下一个步骤。在上面的例子中，如果用户选择了输入 Continue，那么后面的步骤将会运行。

通过流水线触发器自动清理

Spinnaker 允许用一条 Pipeline 的结果调用另外的 Pipeline，这样做的一个用途是自动将应用程序的状态恢复到已知的良好状态。

这可以通过设置 Pipeline 自动触发器来完成，该触发器只会运行另一个失败或被取消的 Pipeline。

流量监控

如果不小心摧毁了最后一个好的集群，导致流量中断。流量监控来确保总是提供可用的集群。

在应用程序的配置中设置了一个流量监控。它会告诉你哪些集群将被保护。

现在，当 Pipeline 或人为销毁或禁用受保护群集中的最后一个集群时，他们将看到下面的错误消息或其 Pipeline 执行失败：

自动金丝雀分析

Netflix 采用的先进技术之一是自动金丝雀分析（ACA）。在 ACA 中，实时流量被发送到基线和金丝雀集群对，以查看它们发出的指标是否满足可接受的偏差。ACA 非常擅长捕捉传统单元测试或集成测试无法跟踪的问题。

在 Spinnaker 中建立 Canary 分析阶段非常简单：

首先，定义基线（当前）群集和金丝雀（新代码）群集。

然后选择金丝雀分析的细节并定义可接受的分数，然后运行 Pipeline：

Spinnaker 将启动每个基线和金丝雀集群的一个新实例，并将每 x 分钟产生一个 Canary 得分（在例子中为15）。

成功的金丝雀

金丝雀得分

在 Spinnaker 添加金丝雀分析之前，不同的团队会以不同的方式做金丝雀。 有些会启动新的集群，其他则会重新利用其生产集群中的现有指标。通过 Spinnaker 处理 ACA 的部署，Spinnaker 的用户能够专注于他们需要捕获的分析和指标。还可以确保基线/金丝雀集群提供了最佳的一组可比较的指标。

Canary Analysis 只是一个简单的阶段，可以插入到 Pipeline 中，Spinnaker 鼓励使用这种技术，代码失败的 ACA 是不会进一步部署的。

自动的“Chaos”测试

Chaos 实验

Netflix 的“Chaos Engineering”工程是一个相对较新的实践。这个想法是运行自动控制的实验，确保能够达到预期的回退行为。

Spinnaker 与“Chaos”自动化平台（ChAP）集成，以确保使用“Chaos Engineering”工程实践创建的测试案例作为部署和验证 Pipeline 的一部分运行：

在 Spinnaker 中运行 ChAP 就是要确保”失败转移”行为作为部署过程的一部分进行测试。这种持续不断的测试对于那些本来就处于休眠状态的系统性弱点是至关重要的。

Chaos Monkey

Chaos Monkey V2 与 Spinnaker 深度整合，并支持使用 Spinnaker API。

Spinnaker 还通过托管它的配置来帮助 Chaos Monkey，如果用户没有做好准备，用户可以选择退出这个野蛮的状态。

通过启用 Chaos Monkey，可以确保代码对实例的故障转移具有适应性。其中插入在 Netflix 中做更大规模的故障转移测试，以确保 Netflix 可以生存在 Chaos Monkey 中。

1.作为企业架构师，我们为什么需要构建数据结构？

数据结构主要有以下内容：

1）数据标准不一致

2）数据模型管理混乱

3）深入的性能的问题无法解决

4）SQL语句编写水平不高导致出现严重性能问题

5）开发人员对执行计划收悉

6）上线前缺乏审计

7）相对复杂的数据处理能力欠缺

8）数据质量差需要执行数据质量管理

数据是客户的财富，虽然对于我们开发人员一文不值，在客户那里就是无价之宝，保障数据的完成性，安全性，可靠性，必须要存在数据结构满足8大要求。

2.结合自身，说一下你离架构师有多远，还需要掌握哪些技术？

架构师首先有很多方向，作为架构师必须具有丰富的开发经验，是个技术主管。

因为他必须清楚什么是可以实现的，实现的方式有哪些，相应的难度怎么样，实现出来的系统面对需求变化的适应性等一系列指标。

另外，需要对面向过程、面向对象、面向服务等设计理念有深刻的理解，可以快速的察觉出实现中的问题并提出相应的改进（重构）方案（也就是通常说的反模式）。

这些都需要长期的开发实践才能真正的体会到，单从书本上很难领会到，就算当时理解了也不一定能融会到实践中去。

在技术能力上，软件架构师最重要也是最需要掌握的知识是构件通信机制方面的知识，包括进程内通信（对象访问、函数调用、数据交换、线程同步等）以及进程外（包括跨计算机）的通信（如RMI、DCOM、Web Service）。

在WEB应用大行其道的今天，开发者往往对服务器间的通信关注的比较多，而对进程内的通信较少关注。进程外跨机器通信是构建分布式应用的基石，它是架构设计中的鸟瞰视图；而进程内的通信是模块实现的骨架，它是基石的基石。

如果具体到一个基于.Net企业级架构设计，首先需要的是语言级别的认识，包括.NET的CLR、继承特性、委托和事件处理等。然后是常用解决方案的认识，包括ASP.NET Web Service、.NET Remoting、企业服务组件等。

总之，丰富的开发实践经验有助于避免架构师纸上谈兵式的高来高去，给代码编写人员带来实实在在的可行性。

其次，具有足够的行业业务知识和商业头脑也是很重要的。行业业务知识的足够把握可以给架构师更多的拥抱变化的能力，可以在系统设计的时候留出一些扩展的余地来适应可能来临的需求变化。

有经验的设计人员可能都碰到过这样的事，一厢情愿的保留接口在需求变化中的命中率非常低。也就是说，在系统设计之初为扩展性留下来的系统接口没能在需求变化的洪流中发挥真正的作用，因为需求的变化并没有按照预想的方向进行，到最后还是不得不为变化的业务重新设计系统。

这就是因为对业务知识的理解和对市场或者商业的判断没有达到一个实用的、可以为架构扩展性服务的水平。

再次，架构设计师对人的关注必须提升到架构设计之初来纳入考虑的范围，包括沟通以及对人员素质的判断。软件过程是团队协作共同构建系统的过程，沟通能力是将整个过程中多条开发线粘合在一起的胶水。

大家都应该碰到过事后说“原来是这样啊，我不知道啊”或者某个开发人员突然高声呼喊“为什么这里的数据没有了”之类的。沟通的目的就是尽量避免多条开发线的混乱，让系统构建过程可以有条理的高效进行。

另外，对人的关注还表现在对团队成员的素质判断上，比如哪些开发人员对哪些技术更熟悉，或者哪些开发人员容易拖进度等。只有合理的使用人力资源，让合适的人做合适的事情才能让整个软件过程更加高效。

架构师应时刻注意新软件设计和开发方面的发展情况，并不断探索更有效的新方法、开发语言、设计模式和开发平台不断很快地升级，软件架构师需要吸收这些新技术新知识，并将它们用于软件系统开发工作中。但对新技术的探索应该在一个理性的范围内进行，不能盲目的跟风。

解决方案提供商永远都希望你能使用它提供的最新技术，而且它们在推广自己的解决方案的时候往往是以自己的产品为中心，容易给人错觉。

比如数据库，往往让人觉得它什么都能做，只要有了它其它什么都不重要了。但事实上并不是如此，对于小型应用可以将许多业务逻辑用script的方式放入数据库中，但很少看到大型应用采用这样的做法。

对于新东西需要以一种比较的观点来判断，包括横向的比较和纵向的比较，最后得出一些性能、可移植性以及可升级等指标。另外，新入行的开发人员往往关心新技术动向而忽略了技术的历史，而从DOS时代一路杀过来的开发者就对现在的技术体系有较全面的把握。

3.如果你应聘架构师方面的工作，那么你认为设计架构具体都做些什么呢？

1）:确认需求

在项目开发过程中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须得到架构师的认可。架构师需要和分析人员反复交流，以保证自己完整并准确地理解用户需求。

2）:系统分解

依据用户需求，架构师将系统整体分解为更小的子系统和组件，从而形成不同的逻辑层或服务。随后，架构师会确定各层的接口，层与层相互之间的关系。架构师不仅要对整个系统分层，进行“纵向”分解，还要对同一逻辑层分块，进行“横向”分解。

软件架构师的功力基本体现于此，这是一项相对复杂的工作。

3）:技术选型

架构师通过对系统的一系列的分解，最终形成了软件的整体架构。技术选择主要取决于软件架构。

Web Server运行在Windows上还是Linux上？数据库采用MSSql、Oracle还是Mysql？需要不需要采用MVC或者Spring等轻量级的框架？前端采用富客户端还是瘦客户端方式？类似的工作，都需要在这个阶段提出，并进行评估。

架构师对产品和技术的选型仅仅限于评估，没有决定权，最终的决定权归项目经理。架构师提出的技术方案为项目经理提供了重要的参考信息，项目经理会从项目预算、人力资源、时间进度等实际情况进行权衡，最终进行确认。

4）:制定技术规格说明

架构师在项目开发过程中，是技术权威。他需要协调所有的开发人员，与开发人员一直保持沟通，始终保证开发者依照它的架构意图去实现各项功能。

架构师不仅要保持与开发者的沟通，也需要与项目经理、需求分析员，甚至与最终用户保持沟通。所以，对于架构师来讲，不仅有技术方面的要求，还有人际交流方面的要求。

4.如果在一个成熟的企业里没有你所想象的架构师呢？或者说，架构师这种职业已经死亡或消失了呢？你会怎么定位你的职业？

如果在一个企业里没有架构师，那么我可以推动自己往这个方向努力发展。

如果在这个行业里不存在架构师，我想软件领域开发的软件质量应该也会存在很多问题。

没有架构师或者自己已经从事了架构师这个职位有了危机以后，我想对自己的职位依然做个肯定，因为业务永远会随着客户的需求存在，

既然有客户需求，业务就会产生，有业务产生，那必然少不了技术实现，可以做技术方案指导，都是很好的方向。

在我们使用docker的时候，想查看docker下都有哪些镜像，执行命令：

1. docker images

可结果却给了我们这样的提示：

1. Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.29/images/json: dial unix /var/run/docker.sock: connect: permission denied

告诉我们没有权限，我们就必须在命令前加上sudo，但是这样的话，我们操作docker的时候也太麻烦了，所以我们要想办法去掉这个sudo。

我们拒绝不知所以然的拿来主义，所以要在拿来之后深究一下为什么。

上面说道，连接/var/run/docker.sock的时候，由于没有权限，被拒绝访问了，那么，我们去看一下这个文件的所有者和所属组是什么。

执行：

1. sudo ls –l /var/run/docker.sock

结果显示：

1. srw–rw—- 1 root docker 0 Jul 12 22:41 /var/run/docker.sock

我们看到docker.sock是属于root用户和docker组的，我们使用的用户既不是root也不在docker组。那么问题应该就好解决了，所有者咱不动，因为不知道动了以后会有什么问题，我们把当前登录用户加入到docker组就可以了，执行：

1. sudo gpasswd –a ${USER} docker

这样就加入到了用户组，但是此时group命令获取到的是缓存组的信息，我们执行docker images的话，仍然会报错，我们需要手动切换一次组：

1. newgrp – docker

再次执行：

1. docker images

=========Maven Report Plugin=========
1.源码分析

<artifactId>maven-pmd-plugin</artifactId>

2.代码格式检查

<artifactId>maven-checkstyle-plugin</artifactId>

3.代码相似度检查

<groupId>org.codehaus.mojo</groupId>
<artifactId>simian-maven-plugin</artifactId>

4.格式化统计报告

<groupId>org.codehaus.mojo</groupId>
<artifactId>jdepend-maven-plugin</artifactId>

5.FireBug检查

<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>

6.JavaDoc

<artifactId>maven-javadoc-plugin</artifactId>

7.生成java代码交叉引用和源代码的html格式

<artifactId>maven-jxr-plugin</artifactId>

8.代码覆盖率

<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>

<groupId>org.codehaus.mojo</groupId>
<artifactId>emma-maven-plugin</artifactId>

9.java代码的度量工具

<groupId>org.codehaus.mojo</groupId>
<artifactId>javancss-maven-plugin</artifactId>

10.单元测试报告

<artifactId>maven-surefire-report-plugin</artifactId>

11.TODO检查报告

<groupId>org.codehaus.mojo</groupId>
<artifactId>taglist-maven-plugin</artifactId>

12.项目总报告

<artifactId>maven-project-info-reports-plugin</artifactId>

 

=========Maven Common Plugin=========
1.SCP文件传输

<groupId>com.github.goldin</groupId>
<artifactId>copy-maven-plugin</artifactId>

2.SSH命令

<groupId>com.github.goldin</groupId>
<artifactId>sshexec-maven-plugin</artifactId>

3.Maven Job

<groupId>com.github.goldin</groupId>
<artifactId>jenkins-maven-plugin</artifactId>

4.生成about信息

<groupId>com.github.goldin</groupId>
<artifactId>about-maven-plugin</artifactId>

5.查找重复依赖

<groupId>com.github.goldin</groupId>
<artifactId>duplicates-finder-plugin</artifactId>

6.Maven邮件发送

<groupId>com.github.goldin</groupId>
<artifactId>mail-maven-plugin</artifactId>

7.项目目录查找

<groupId>com.github.goldin</groupId>
<artifactId>find-maven-plugin</artifactId>

8.获取SVN版本

<groupId>com.google.code.maven-svn-revision-number-plugin</groupId>
<artifactId>maven-svn-revision-number-plugin</artifactId>

9.编译C++

<groupId>org.codehaus.mojo</groupId>
<artifactId>native-maven-plugin</artifactId>

10.DDL生成

<groupId>org.codehaus.mojo</groupId>
<artifactId>hibernate3-maven-plugin</artifactId>

11.Eclipse RCP

<groupid>org.sonatype.tycho</groupid>
<artifactid>target-platform-configuration</artifactid>

 

=========Maven Official Plugin=========
1.自动定义打包

<artifactId>maven-assembly-plugin</artifactId>

2.ANT

<artifactId>maven-antrun-plugin</artifactId>

 

=========Maven 全局属性=========
1.源码编码

<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
maven.compile.classpath
maven.runtime.classpath
maven.test.classpath
maven.plugin.classpath

2.ClassPath

maven.compile.classpath
maven.runtime.classpath
maven.test.classpath
maven.plugin.classpath