使用Sonatype Nexus搭建Maven私服后如何添加第三方JAR包？
使用Sonatype Nexus搭建Maven私服后如何添加第三方JAR包？
[摘要：登录Nexus后，面击右边的“Repositories”，表现当前Nexus所治理的Repository， 默许环境下Nexus为我们建立了以下首要的Repository： 1、PublicRepositories，那是一个Repository Group，该Repository Group包括]
登录Nexus后，点击右侧的“Repositories”，显示当前Nexus所管理的Repository，
默认情况下Nexus为我们创建了以下主要的Repository：
1、PublicRepositories，这是一个Repository Group，该Repository &Group包含了多个Repository，其中包含了Releases、Snapshots、ThirdParty和Central。
2、3rd party，该Repository即是存放你公司所购买的第三方软件库的地方，它是一个由Nexus自己维护的一个Repository。&
3、Apache Snapshots，看名字你就应该知道这是个什么样的Repository，这是一个代理Repository，即最终的依赖还是得在Apache官网上去下载，然后缓存在Nexus中。
4、Central，这就是代理Maven Central Repository的Repository。
5、Releases，你自己的项目要发布时，就应该发布在这个Repository，他也是Nexus自己维护的Repository，而不是代理。
6、Snapshots，你自己项目Snapshot的Repository。
这里主要讲解如何使用3rd party上传第三方jar包的方法
在Repository列表中，选中&3rd party，选中artifact upload，如下图所示
选择GAV Defini3ion:
GAV Parameters，Auto Guess 打钩。
在下方输入JAR包对应的Group、Artifact、Version，Packaging选择JAR格式。
点击select Artifact(s) to upload 按钮，选择要上传的JAR包。
怎么使用上传的jar包吧，很简单的，前提是你已经建立了一个maven的项目。含有pom.xml这个文件,在这个文件中添加如下：
感谢关注 Ithao123精品文库频道，是专门为互联网人打造的学习交流平台，全面满足互联网人工作与学习需求，更多互联网资讯尽在 IThao123!
Laravel是一套简洁、优雅的PHP Web开发框架(PHP Web Framework)。它可以让你从面条一样杂乱的代码中解脱出来；它可以帮你构建一个完美的网络APP，而且每行代码都可以简洁、富于表达力。
Hadoop是一个由Apache基金会所开发的分布式系统基础架构。
用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。
Hadoop实现了一个分布式文件系统（Hadoop Distributed File System），简称HDFS。HDFS有高容错性的特点，并且设计用来部署在低廉的（low-cost）硬件上；而且它提供高吞吐量（high throughput）来访问应用程序的数据，适合那些有着超大数据集（large data set）的应用程序。HDFS放宽了（relax）POSIX的要求，可以以流的形式访问（streaming access）文件系统中的数据。
Hadoop的框架最核心的设计就是：HDFS和MapReduce。HDFS为海量的数据提供了存储，则MapReduce为海量的数据提供了计算。
产品设计是互联网产品经理的核心能力，一个好的产品经理一定在产品设计方面有扎实的功底，本专题将从互联网产品设计的几个方面谈谈产品设计
随着国内互联网的发展，产品经理岗位需求大幅增加，在国内，从事产品工作的大部分岗位为产品经理，其实现实中，很多从事产品工作的岗位是不能称为产品经理，主要原因是对产品经理的职责不明确，那产品经理的职责有哪些，本专题将详细介绍产品经理的主要职责
IThao123周刊 上传我的文档
 下载
 收藏
该文档贡献者很忙，什么也没留下。
 下载此文档
正在努力加载中...
nexus仓库配置maven自动打包上传_deploy
下载积分：2000
内容提示：nexus仓库配置maven自动打包上传_deploy
文档格式：DOCX|
浏览次数：781|
上传日期： 21:48:20|
文档星级：
该用户还上传了这些文档
nexus仓库配置maven自动打包上传_deploy
官方公共微信Nexus搭建Maven私服 +maven安装步骤_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
Nexus搭建Maven私服 +maven安装步骤
上传于||文档简介
&&N​e​x​u​s​搭​建​M​a​v​e​n​私​服​ ​+​m​a​v​e​n​安​装​步​骤
阅读已结束，如果下载本文需要使用1下载券
想免费下载本文？
下载文档到电脑，查找使用更方便
还剩19页未读，继续阅读
你可能喜欢一行学Maven(Maven仓库管理器之应用Nexus)&六&gt_割接思维_口试总结之Wind资讯篇__脚本百事通
稍等，加载中……
^_^请注意，有可能下面的2篇文章才是您想要的内容：
一行学Maven(Maven仓库管理器之应用Nexus)&六&gt
口试总结之Wind资讯篇
一行学Maven(Maven仓库管理器之应用Nexus)&六&gt
一起学Maven(Maven仓库管理器之应用Nexus)&六&注：本博文是接着上一章节继续讲解
Nexus-私有仓库的配置
点击左边导航栏的Repositories选项，会显示一个所有仓库及仓库组的列表，Type字段的值有group，hosted，proxy，virtual(在Maven1中使用，这里不需要关心)，如图14所示：
hosted，本地仓库，这个仓库主要是用来存放本地的依赖包，服务于局域网，不访问公网
proxy，代理仓库，用来存放nexus从公网中获取的依赖包，这里有中央仓库，Apache和Codehaus开源网站的依赖包
group，仓库组，用来合并多个hosted/proxy仓库，通常我们配置maven依赖仓库组
比如点击Type为group，如图15所示：
会发现，在Ordered Group Repositories中，有所有hosted和proxy的仓库，而图15中箭头所指的地方有四种类型的仓库，分别是Releases(hosted), Snapshots(hosted),
3rd Party(hosted)，Central(proxy)，而Central指的是中央仓库，不知道大家是否还有印象，在本系列第二章节，曾经提到中央仓库的位置，存在于apache-maven-3.1.1\lib\maven-model-builder-3.1.1.jar中的org\apache\maven\model\pom-4.0.0.xml文件中，定义了中央仓库的位置，配置文件如下所示
………………………………………………………………
&repositories&
&repository&
&id&central&/id&
&name&Central Repository&/name&
&url&http://repo.maven.apache.org/maven2&/url&
&layout&default&/layout&
&snapshots&
&enabled&false&/enabled&
&/snapshots&
&/repository&
&/repositories&
………………………………………………………………
其中url指向了中央仓库的位置http://repo.maven.apache.org/maven2，
而Releases, Snapshots, 3rd Party，主要功能如下：
Releases: 这里存放我们自己项目中发布的构建, 通常是Release版本
Snapshots: 这个仓库非常的有用, 它的目的是让我们可以发布那些非release版本, 非稳定版本, 比如我们在trunk下开发一个项目,在正式release之前你可能需要临时发布一个版本给你的同伴使用, 因为你的同伴正在依赖你的模块开发, 那么这个时候我们就可以发布Snapshot版本到这个仓库, 你的同伴就可以通过简单的命令来获取和使用这个临时版本
3rd Party: 顾名思义, 第三方库, 你可能会问不是有中央仓库来管理第三方库嘛, 没错, 这里的是指可以让你添加自己的第三方库, 比如有些构件在中央仓库是不存在的. 比如你在中央仓库找不到Oracle 的JDBC驱动, 这个时候我们就需要自己添加到3rd party仓库
在settings.xml中配置远程仓库
既然这个group已经包含了四个仓库，那么只要将这个组进行配置，在Maven中就会引用所有在这个组对应的仓库中的依赖包，配置的URL地址为http://localhost:8081/nexus/content/groups/public/。我们可以配置在项目中的user-parent的pom.xml文件中，但此时会有个问题，这样的配置仅仅是对当前的项目有效(user-parent是父文件，其子文件继承)，如果项目有很多，而不需要每个项目都要进行以上设置，也就是只要设置一次，然后本机的项目就会自动从nexus中寻找依赖包，如何做呢？
Maven仓库组
因为Maven在本机中是同一个，所以只要在Maven所对应的settings.xml中进行配置就好，(本博客settings.xml对应的路径为E:\Workspaces\Maven\settings.xml)，配置如下：
…………………………………………
&profiles&
&id&nexusProFile&/id&
&repositories&
&repository&
&id&localNexus&/id&
&name&Nexus Repository&/name&
&url&http://localhost:8081/nexus/content/groups/public/&/url&
&releases&
&enabled&true&/enabled&
&/releases&
&snapshots&
&!-- 此选项默认是关闭的，手动打开 --&
&enabled&true&/enabled&
&/snapshots&
&/repository&
&/repositories&
&/profile&
&/profiles&
&activeProfiles&
&!-- 激活上面的配置 --&
&activeProfile&nexusProFile&/activeProfile&
&/activeProfiles&
…………………………………………
Maven中的profile是一组可选的配置，可以用来设置或者覆盖配置默认值。有了profile，你就可以为不同的环境定制构建。
这个时候，做个试验，可以在user-core的pom.xml中加入以下依赖(这个依赖包并不存在于本地或者Nexus仓库中)&dependency&
&groupId&org.mybatis&/groupId&
&artifactId&mybatis&/artifactId&
&version&3.1.1&/version&
&/dependency&
添加好后进行保存，会发现Eclipse的控制台中有如图16的信息：
这表明，Maven已经从通过Nexus下载依赖包了，而Nexus从中央工厂中进行下载。
接着看图17：
这也验证了Nexus已经将mybatis的依赖包下载到了仓库中。
但此时会有个问题，如果将Nexus服务停止，如图18所示
这个时候在user-core的pom.xml中添加原来没有的依赖配置文件(可以随便找个不存在的jar依赖文件进行测试，这里用使用Spring)
&dependency&
&groupId&org.springframework&/groupId&
&artifactId&spring-core&/artifactId&
&version&3.2.2.RELEASE&/version&
&/dependency&
这个时候在Eclipse中点击保存，会发现如下的信息14-3-7 GMT+0800下午8:29:41: [INFO] Using org.eclipse.m2e.jdt.JarLifecycleMapping lifecycle mapping for MavenProject: com.steven.user:user-core:0.0.1-SNAPSHOT @ E:\Workspaces\STSWorkspace\user-core\pom.xml.
14-3-7 GMT+0800下午8:29:42: [INFO] Number of application's worked threads is 4
14-3-7 GMT+0800下午8:29:44: [INFO] Downloaded http://localhost:8081/nexus/content/groups/public/org/springframework/spring-core/3.2.2.RELEASE/spring-core-3.2.2.RELEASE.pom
14-3-7 GMT+0800下午8:29:44: [INFO] Number of application's worked threads is 4
14-3-7 GMT+0800下午8:29:47: [INFO] Downloading http://repo.maven.apache.org/maven2/org/springframework/spring-core/3.2.2.RELEASE/spring-core-3.2.2.RELEASE.pom
14-3-7 GMT+0800下午8:29:47: [INFO] Downloaded http://repo.maven.apache.org/maven2/org/springframework/spring-core/3.2.2.RELEASE/spring-core-3.2.2.RELEASE.pom
………………………………………………………………………………
首先通过Nexus下载，但服务已经关闭，这个时候仍然可以下载，而且通过中央仓库进行下载。但在项目中，不允许本地仓库直接下载中央仓库的依赖包，这个时候就需要进行对中央仓库进行覆盖，使之只能通过Nexus访问中央仓库，这个时候需要对镜像进行配置。
在settings.xml中配置镜像
首先配置镜像，使得只有通过Nexus才可以访问中央仓库
…………………………………………………………
&id&nexusMirror&/id&
&mirrorOf&*&/mirrorOf&
&name&Human Readable Name for this Mirror.&/name&
&url&http://localhost:8081/nexus/content/groups/public/&/url&
…………………………………………………………
这里的*号代表所有的仓库都是通过这个url地址访问，这个时候可以附加一段配置，原来的中央仓库中snapshots版本的依赖包默认是不可以下载的，但可以通过以下配置进行修改
……………………………………
&/profiles&
……………………………………
&id&centralProFile&/id&
&repositories&
&repository&
&id&central&/id&
&name&Central Repository&/name&
&!--由于配置过镜像，这个url不起作用--&
&url&http://repo.maven.apache.org/maven2&/url&
&layout&default&/layout&
&snapshots&
&!--覆盖中央仓库中的false配置，可以从中央仓库中下载snapshot版本--&
&enabled&true&/enabled&
&/snapshots&
&/repository&
&/repositories&
&/profile&
&/profiles&
&activeProfiles&
&!-- 激活上面的配置 --&
&activeProfile&centralProFile&/activeProfile&
&/activeProfiles&
……………………………………
这样进行保存后，既可生效。
注意：配置文件settings.xml中会默认有相应的mirror和profile的例子，但都是注释掉的，我们在进行以上的改动时候，可以进行对其复制粘贴后进行修改，这样不容易出错。
验证：(此时没有打开nexus服务)
随便找个不存在的jar依赖文件进行测试，
&dependency&
&groupId&org.mortbay.jetty&/groupId&
&artifactId&jetty&/artifactId&
&version&6.1.26&/version&
&/dependency&
跟刚才的步骤一样，但此时保存后，Eclipse控制台中的信息如下所示：14-3-7 GMT+0800下午9:13:58: [INFO] Downloaded http://localhost:8081/nexus/content/groups/public/org/mortbay/jetty/jetty/6.1.25/jetty-6.1.25.pom
14-3-7 GMT+0800下午9:13:58: [INFO] Using org.eclipse.m2e.jdt.JarLifecycleMapping lifecycle mapping for MavenProject: com.steven.user:user-service:0.0.1-SNAPSHOT @ E:\Workspaces\STSWorkspace\user-service\pom.xml.
14-3-7 GMT+0800下午9:13:58: [INFO] Number of application's worked threads is 4
14-3-7 GMT+0800下午9:14:02: [INFO] Using 'UTF-8' encoding to copy filtered resources.
14-3-7 GMT+0800下午9:14:02: [INFO] skip non existing resourceDirectory E:\Workspaces\STSWorkspace\user-service\src\main\resources
14-3-7 GMT+0800下午9:14:02: [INFO] Using 'UTF-8' encoding to copy filtered resources.
14-3-7 GMT+0800下午9:14:02: [INFO] skip non existing resourceDirectory E:\Workspaces\STSWorkspace\user-service\src\test\resources
这里只能通过Nexus下载依赖包，但是由于服务停止，所以下载失败，而如果此时将服务打开
然后在Eclipse中刷新依赖包所在的pom.xml文件，
如果没有任何问题，则在控制台中显示如下信息：
14-3-8 GMT+0800上午12:00:31: [INFO] Downloading http://localhost:8081/nexus/content/groups/public/org/mortbay/jetty/jetty-util/6.1.26/jetty-util-6.1.26.jar
14-3-8 GMT+0800上午12:00:31: [INFO] Downloaded http://localhost:8081/nexus/content/groups/public/org/mortbay/jetty/jetty-util/6.1.26/jetty-util-6.1.26.jar
但此时可能出现以下问题[ERROR] Could not calculate build plan: Plugin org.apache.maven.plugins:maven-resources-plugin:2.5 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-resources-plugin:jar:2.5
原因：这是因为在进行配置后，所有本地仓库的依赖包都将通过nexus私有仓库访问中央仓库进行下载，而此时在加载一些Maven插件的时候，由于一开始本地仓库中已经存在，而私有仓库中没有这些依赖包的索引(就是指在nexus中存在对依赖包的GAV标识)，这个时候就会容易报错。
解决思路：
一开始可以进行对索引更新，具体参照图20所示
这样设置以后, Nexus会自动从远程中央仓库下载索引文件，索引文件很大，需要很久等待时间。
错误信息也有如下所示的提示：
Could not calculate build plan: Failure to transfer org.apache.maven.plugins:maven-surefire-plugin:pom:2.7.1 from http://repo1.maven.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced. Original error: Could not transfer artifact org.apache.maven.plugins:maven-surefire-plugin:pom:2.7.1 from/to central (http://repo1.maven.org/maven2): Access denied to http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.7.1/maven-surefire-plugin-2.7.1.pom.
解决方案：
1.找到maven库目录，进入：\repository\org\apache\maven\plugins\maven-surefire-plugin\2.7.1
2.若2.7.1目录下只有，"maven-surefire-plugin-2.7.1.pom.lastUpdated" 则需要到http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.7.1/，把里面的文件下载下来放到2.7.1文件夹中
3.删除2.7.1下的maven-surefire-plugin-2.7.1.pom.lastUpdated文件。
4.项目右键--&maven--&Update Project即可。
首先关掉Eclipse，停止Nexus运行，然后将本地E:\Workspaces\Maven\repository中所有的依赖包删除，然后启动Nexus，打开Eclipse，这时候将通过Nexus进行下载依赖包到本地仓库中，一般情况可以解决问题，如果还有思路2中的错误信息，则执行思路2。
通过Maven部署项目到Nexus中
当项目已经编写完成，需要部署到Nexus中，这样团队人员可以通过Nexus下载到自己的本地仓库中，比如说，我是编写user-core的模块的，部署到Nexus中，需要以下两个步骤，
1、需要配置user-core的pom.xml文件，定义发布的版本以及发布到Nexus本地库的哪个仓库中，具体如下所示：
………………………………………………………………
&distributionManagement&
&repository&
&id&user-core-release&/id&
&name&user core release&/name&
&url&http://localhost:8081/nexus/content/repositories/releases/&/url&
&/repository&
&snapshotRepository&
&id&user-core-snapshot&/id&
&name&user core snapshot&/name&
&url&http://localhost:8081/nexus/content/repositories/snapshots/&/url&
&/snapshotRepository&
&/distributionManagement&
………………………………………………………………
2、配置本地settings.xml文件，让部署过程中有足够的权限，而Nexus中本来存在的有三个用户，如图21所示：
而部署使用deployment用户，具体的配置如下
………………………………………………………………
&id&user-core-release&/id&
&username&deployment&/username&
&password&deployment123&/password&
&id&user-core-snapshot&/id&
&username&deployment&/username&
&password&deployment123&/password&
………………………………………………………………
完成以上两个步骤，此时进行部署(deploy)操作，如图22所示：
这个时候部署成功，然后我们可以在Nexus中看到部署后的结果，如图23所示
在Snapshots的索引中可以查看到刚刚部署的user-core模块。
通过Nexus搜索构件
首先我们来明确一下构件的含义，
构件：构件是系统中实际存在的可更换部分，它实现特定的功能，符合一套接口标准并实现一组接口，而在我们这里就是我们要使用的即将需找的依赖。
但在我们实际使用构件的过程中通常遇到一个问题,有时候我紧紧知道我所需要的构建的大致名字,并不知道全称或group id, 这是件非常头疼的事情. Nexus基于Nexus indexer(索引)的搜索功能帮我们解决了这个问题。
还记得刚才我们在解决Could not calculate build plan...问题的时候，给出的思路1，其思想就是，通过更改Download Remote Indexes的状态为True，使得Nexus从中央仓库中将所有构件的信息同步到本地，这样在以后的开发中，就可以直接下载私有仓库中的依赖，就不需要Nexus还要去中央仓库中下载了。下面就来领略Nexus搜索构件的方便之处。
如图所示：
这里有以下几种搜索方式：
keyword(关键字查询), classname(类名查询), GAV(groupId，artifactId，version组合查询), checksum(校验和查询)，这里我认为前三种使用的最多。
比如，刚刚通过部署后的user-core模块，这个模块正好被其他项目人员使用到，他知道模块的名称叫user-core，这个时候，可以通过GAV的方式进行查询，如图所示：
查出来之后，只要将依赖文件复制到项目的pom.xml配置中，就可以从私有仓库中下载到其本地仓库进行使用了。
创建本地仓库并设置权限
在大公司的项目开发中，不可能所有的Snapshots和Releases版本都发布到Nexus中默认对应的Snapshots和Releases仓库中，我们可以给每个项目创建自己的本地仓库，并赋予相应的角色权限进行操作。比如创建一个UserRelease仓库用来存储User项目的Release版本，这个时候，操作如图所示：
接着将信息填入New Hosted Repository中，如图27所示
这个时候就创建了UserRelease的本地仓库，如图所示
虽然我们已经创建了UserRelease仓库，但仓库的权限仅为预览，如果让其可以有增删改查的权限，只要点击图中Add，如图所示：
接着进行信息填入，如图30所示
这个时候UserRelease仓库就拥有了所有的权限，如图31所示
虽然有了权限，但在使用的过程中，进一步创建一个角色，对角色添加相应的权限，然后在让角色中添加相应的用户，这样在发布的时候就可以达到权限的最细致化，管理起来更加方面。
如图32，创建角色
然后进行填写信息，如图33
在这里有Add按钮，点击按钮的时候进行如下操作
此时，创建角色后如图35所示：
角色创建好后就可以创建用户，通过专有的用户来进行专有项目的部署和其他操作，如图创建用户
然后填入信息，如图所示
在图37中点击Add按钮出现图38所示的选项，如下操作
就是选择该用户所属的角色，而角色拥有所有的权限，完成后如图39所示
注：在以上操作中，我们首先创建一个本地仓库(这里是Release版本的，项目中可以在创建一个Snapshot版本，操作过程同上)，然后给这个仓库赋予权限，然后将这些权限通过一个角色进行拥有，当然在这里可以创建不同的角色赋予不同的权限，这时候，创建一个用户，使得该用户担当一个角色，这样的话，这个用户就可以拥有这个角色中的权限，下面就可以按需对所在的项目使用相应的用户进行操作了。
这样根据以上情况可以建立UserSnapshot的仓库，以及将所有的权限付给不同的角色，或者可以让UserReleaseRole同样拥有UserSnapshot的所有权限，并且同样的用户拥有Release和Snapshot仓库的所有权限，这样的话如果进行部署，就可以如下进行配置，在对应部署模块的pom.xml中可以这样配置
………………………………………………………………
&distributionManagement&
&repository&
&id&user-core-release&/id&
&name&user core release&/name&
&url&http://localhost:8081/nexus/content/repositories/UserRelease/&/url&
&/repository&
&snapshotRepository&
&id&user-core-snapshot&/id&
&name&user core snapshot&/name&
&url&http://localhost:8081/nexus/content/repositories/UserSnapshots/&/url&
&/snapshotRepository&
&/distributionManagement&
………………………………………………………………
而在settings.xml中就可以这样进行配置
………………………………………………………………
&id&user-core-release&/id&
&username&UserRelease&/username&
&password&user123&/password&
&id&user-core-snapshot&/id&
&username&UserRelease&/username&
&password&user123&/password&
………………………………………………………………
这样就可以把相应的Release和Snapshot版本部署到相应的Nexus仓库中了。
本章节通过对仓库管理器Nexus的讲解，包括如何下载安装Nexus，配置Nexus代理中央仓库，管理Nexus的代理仓库，本地仓库，以及仓库组。并帮助你了解如何通过Nexus搜索构件。最后，如何在Maven中配置Nexus仓库，以及如何部署构件到Nexus仓库中。同时，根据大公司的要求，创建了专有的仓库，并且学习了如何进行用户管理，角色权限管理等等。
如有什么疑问或者建议意见都可以提出，本人在此不胜感激，同时，同样恭祝大家学习愉快！
自：.cn/u/
从割接到灰度，不仅仅是策略，更重要的是思想
2011年底，浙江公司分管支撑的杨剑宇副总在支撑内部召集了一次头脑风暴，要求部门里各位主管和骨干轮流发言，不讲成绩，只讲问题和思路，一圈人一个一个轮流讲过来：
l 负 责开发的主管说现在业务部门的需求经常考虑不清楚，而上线的时间压力很大，风险也很大，匆忙上线很容易把现有的业务弄乱，同时，上线后往往要在业务规则、 操作便捷性上做多次修改，形成了很多不必要的二次开发，因此要求业务部门和需求管理员加大需求分析的力度，尽早明确需求，降低上线风险，减少二次开发。
l 负责产品配置的同事说新增产品现在只能在测试环境上进行验证，发布后即为生产环境，很难分析新产品上线带来的影响，以及评估对现有产品模型、资费体系的冲击。建议增加一套类生产的环境，进行全量模拟验证。
l 负责测试发布的同事说目前回归测试案例集不全，有些前台功能使用的场景只有一线营业员才知晓，一旦在上线前的回归测试有遗漏，上线后2个小时的核心功能回归并不能保证系统正常。要求加强自动化测试范围，完善回归测试案例集。
l 负责投诉处理的同事说上线后的功能不稳定导致的前台保障、批量客户投诉对日常的运维工作的冲击很大。要求提高需求分析和上线质量，避免故障和批量差错的发生。
那为什么会有这么多的事情呢，这一切都是因为2011年浙江移动新版本的CRM割接上线后各类事件、问题非常多，对于割接前已经稳定了很多年的开发、运维体系造成了极大的冲击。
割接，是一场战争
割接，尤其是核心系统的割接，对支撑，对前台，就是一场战争，因为每一次的系统割接，基本就等同于第二天系统无法使用、或者用户的批量投诉。
先来回顾一下什么是割接。2003年刚毕业，我就赶上了浙江移动第一次全省集中BOSS系统的割接。我和同批进公司的朱骏一起问当时的BOSS项 目经理罗文模（现福建移动支撑的副总）：什么是割接，他说：割接，就是把老系统割下来，把新系统接上去，哈哈，非常形象吧。后来，百度了一下“割接”，发 现这是一个从网络专业延伸到支撑网的名词：传统的割接是指使用一种新的事物替换原有旧的事物，也指将一种业务或流量从一个网中移植到另一外网络中。现在， 凡是以新的系统替换旧的系统的行为都称为割接。
在通信行业，割接是一件很慎重的事情，凡是割接，都是在晚上进行，要求进行周密的测试、数据的备份、以及失败紧急回退方案演练等等，不管是正向，还是反向，都要有充足的准备和演练，才能保证割接的成功。同时，一般在临晨5、6点前要求割接完毕，完成业务验证，不能影响第二天的运营，因此，留给真正开始割接的时间并不多，对各配合方要求都非常高。浙江移动CRM割接步骤当时专门印发成了一本小册子，A4的打印纸，100多页，详细到每一个人、每一个时间点、每一个步骤、每一个命令。
割接方案中，最难的就是涉及数据模型升级的地方了。现在的割接方案都是先把老的数据模型在系统升级前，通过批量操作方式，“一次性转换”成新版本的数据模 型。我们做过软件开发的朋友们都很清楚，做正向的升级比逆向的降级要简单，就好像连微软等这些传统的大软件开发商都没有提供这样的服务：我们把OFFICE软件从2003升级到2010，用了一段觉得不爽，不用卸载而直接回退到2003再 使用。从正向考虑把老的模型升级到新模型，大家都认为是理所当然要做的事情，从项目建设之初就考虑的很清楚，在准备割接脚本时也很充分。但反过来，从新模 型降级回老模型，绝大部分开发人员都是从内心拒绝这个事情的，人的思维中总是存在侥幸心理，万一不成功才用到的脚本，为了这个“万一”值得么，有这功夫还 不如好好想想怎么确保成功呢，所以，最容易出问题的地方往往就在这些回退的脚本上。而且，因为都是批量操作，极易出错，且要消耗大量的时间，这样，把本来 就很紧张的升级时间压缩的更短，因为割接计划中还要预留出足够的回退时间。
灰度，是一种策略
这里打断一下，最近这几年您听说过淘宝升级么？如果没有记错，最近的一次淘宝发公告要暂停业务进行系统升级是2008年，之后再也没有听说过淘宝通过半夜停业务的方式来做系统升级的事情了。您听说过QQ升级么，事实上QQ从最开始的只能有500个好友到现在支持上亿的好友，经历过大大小小上千次的升级，从来没有停业务这一说法，为什么啊？因为互联网产品有一个特点，为了减少甚至避免系统升级对用户使用造成影响，在升级的过程中都采用了灰度发布的策略。
什么是灰度发布，这里引用一下百度百科的内容。
灰度发布，是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。-- 百度百科
哦，原来灰度发布就是保持两份不同的版本，让一小撮用户先在新版本上尝鲜，等这部分小白鼠用户稳定了，在把绝大部分的用户迁移到新版本上来。别的先不说，就针对之前我们部门那么多领导提出来的问题，一一解答下：
灰度发布后：上线前需要明确业务主线，如果业务规则、操作上存在纰漏，出问题的范围也可控。而且，现在市场部门做推业务前，采用的也是先挑一个中等营业厅先操作试点，整理出业务规范，确定没问题再大规模推广，灰度发布正好就能适应这种节奏和方式。
灰度发布后：可以控制在灰度环境上验证新产品的准确性，验证各种订购、计费、查询等场景。
灰度发布后：在灰度环境上观察、收集营业员的操作，并录制成自动化测试的脚本，可以快速提高自动化测试的比例。
灰度发布后：前台的影响范围可控，也就是几个台席、百十个客户，完全可以避免上线故障和批量差错的产生。
这么一圈分析下来，灰度发布真是个令人激动的好东西啊！接下来，部门内针对灰度发布的事情组织一拨人讨论，论证我们的CRM系统是否适合做灰度发布。
当前系统典型的分层架构都是三层结构，在WEB层、APP层做灰度发布很容易，只需要搭建两套不同版本的生产环境，然后从WEB层控制访问的源头即可。但是服务总要收敛到数据层，因为客户的数据只能保留一个版本才能保证最小粒度（单客户级）的对外服务一致性，所以，一旦要在这个层上做灰度，不但要保留两个不同版本的数据，而且在程序控制、代码逻辑上会非常困难。
最后的结论是如果只有WEB层的功能上线，做灰度是合适的，但我们每次上线都涉及都后台表的变化，无法承担两份数据的差异，所以无法实施灰度发布。
这事就一直搁置在这里了。
是不是在运营商里，真的就不适合用灰度呢？
灰度，更是一种思想
如果真的能通过在WEB层、APP层的灰度发布控制影响的话，为什么一定要提前批量把数据转换过去呢，为什么不能在客户访问到系统，要用到数据的时候，才把客户数据从老模型转换成新模型呢？
也就是说，除了系统层面、数据层面能做灰度这种选择，我们在过程上为什么不能同样采用灰度呢？
具体的说，就是把以前批量的数据割接和回退的脚本“单元化”，封装成一个个针对单独数据来源的小脚本。不管你做没做过DBA，我想这类针对单客户的数据迁移，您一定会使用到索引，执行效率非常高，这样，单个数据迁移完成后再调用新版本的服务，对客户感知基本没有什么影响。
这样，前端 的灰度发布，加上后端数据的即时转换，我们就能做到每次升级后的版本至开放到一两家营业厅、几个台席，控制较少量的用户使用，同时，采取动态数据迁移的方 式，把这些台席上受理的客户数据动态升级到新的数据模型，前台只要加上个“数据转换中，请等待”的提示，前台人员一定能够理解，对这些“小白鼠”客户持续 跟踪，等系统稳定了再逐步放开台席，放开试点数量，这不就是一个完整的灰度发布么？
事情就是这样，只要你持续在一个问题上深入想下去，总会有解决的办法。2013年初去广东公司交流的时候，他们正在做CRM系统的割接，因为地市公司担心割接带来的业务影响，配合意愿不强，而且在第一次割接的时候确实是因为系统问题产生了一些影响，被地市公司把问题放大，给了支撑很大的压力。如果广东公司能考虑下灰度的策略，在地市只挑1、2个营业厅，让他们先感受新系统，接受新系统，后续的割接应该会顺畅很多。即使是新系统有问题，一两家营业厅、几个台席的失败，对地市公司都是可以承受的。所以，灰度发布看似一个加长系统升级的过程，其实是一个有效减低风险，加快割接进度的好策略呢。
灰度部署典型的框架如下图，供参考：
2011年亚信在浙江割接，2012年在上海、北京、辽宁割接，亚信的余鹏武总还计划写一本移动CRM割接的书，说要把这些经历和痛苦都写出来，虽然我相信这本书里一定有很多的内容和趣闻，但我个人还是不赞成这种宣扬靠人堆、靠硬干蛮干的工作方法。
真心希望移动公司以后的上线不再有“割接”这样的词，而都是采用“灰度”的方式，大家轻装上阵，不用提心吊胆、不用熬夜干活，大家白天里轻轻松松就把事情做掉了。
口试总结之Wind资讯篇
面试总结之Wind资讯篇
周六也就是5月25日中午，我刚吃过午饭正在办公室里休息，接到了Wind资讯公司的面试电话。我本人只在八年前大学毕业时求过职，后来一直没有换过工作，因而面试经验相当匮乏，事前也没有做特别的准备，再加上刚吃过午饭，大脑供血不足，影响到了发挥。总体而言，这次面试非常不成功，下面记录一下面试过程。
为了叙述方便，下面把Wind公司面试我的朋友称呼为W先生。
W先生准备的问题不多，如下一一道来。
第一个问题
如何做JVM调优？
我觉得这是一个好问题，但我的回答不太好。我的答复是，依据GC日志，分析GC规律，结合业务特性，制订专门的改进措施。这个答复不够具体，像是背书，听起来似乎没有感觉，以至于W先生也不知道如何继续问下去。我的简历里提到了擅长做JVM调优，我想W先生可能是比较好奇，想了解下JVM调优还有什么特别的方法，不过我的表现让他失望了。
JVM调优不是每个程序员都会遇到的工作，而对于很多做过JVM调优的程序员而言，调优要解决的问题多数和内存有关系，我遇到的场景也仅和内存相关，其它场景只从官方的文档里看到过。调优的方法说起来非常简单，只是过程其实非常枯燥。
从我个人的经历看，做JVM调优的诱因比较简单，产品在生产环境部署之后，由于数据量不断上升，应用的压力不断加大，以致于出现了OOM（OutOfMemoryError的缩写）和GC（垃圾回收）线程CPU占用长时间100%两个问题，这两个问题很严重，发生时直接导致重要特性失效，必须通过重启才能让应用恢复正常。在当时相关的问题出现了多次，导致产品的质量受到客户的严重质疑，项目组的成员感受到了极大的压力。
我个人观点，JVM调优只是应用调优的一部分，而影响应用运行效率、性能的因素很多，JVM参数只是其中一小部分。由于调整JVM参数会打破原有的平衡，为了简化单次调优过程，需要保证其它因素相对稳定，否则变量太多会加大分析的难度，进而影响调优的效果。
现在回顾当时被动对JVM调优的过程，假如有机会重新进行产品的开发，我想我会选择如下处理策略，提前完成JVM的调优，减少生产环境暴露问题的机率。
1）分析业务要求，制定压力测试的场景及相关的指标；
比如业务要求应用可以支持100万用户在线，半小时内处理完成100万用户终端应用数据的随机上报，响应时长不超过2秒，CPU峰值不超过150%（应用所在服务器的CPU是多核的），不低于60%，内存占用不超过XXXM等待。
2）制定测试计划，测试顺序；
明确了要求之后，就可以开始准备模拟数据，以及分析测试步骤，确定每个步骤准入、准出的标准；设定观察点，比如把业务场景划分为空闲期、空闲进入忙时、忙时进入空闲、忙时，测试时需要考虑收集相关的数据，设定合理的观察项目；
3）设置初始JVM参数；
介绍JVM参数的资料很多，网上一找一大把，这里不详细介绍。依据业务特性以及实现方式，确定如下几点：
分析应用的内存分布，确定长期存活对象的占用空间的上限，这点很重要；
确定不同业务场景下的JVM可用的进程堆值上限，即Xmx和Xms，一般而言，这两个值可以设置为相等，减少JVM动态调整堆大小的开销；
划分好新生代和老生代的比例，JDK官方文档推荐比例为3：5，同时设置新生代中Eden区和Survior区的比例，保证Suvivor区可以保存单次回收过程中的全部对象；
确定GC算法，比如使用CMS还是其它的并行回收算法；
启用GC日志输出，这点相当重要，不然无法做事后分析；
依据应用的特性，启用或者关闭一些JVM特性，比如会我当时使用CMS做为GC算法，应用使用Java RMI来做组件内部通信，考虑到RMI内部实现会定时调用System.gc()来主动触发GC操作，增加参数将主动的gc操作替换了CMS的一次回收操作，同时调整了RMI主动调用System.gc()方法的间隔周期，提高CMS GC的工作效率；
4）预测试；
正式测试时收集很多方面的数据，因而在正式测试之前，还需要做几次短时间的模拟，积累经验。比如验证前面准备的初始参数是否可用，是否有效，可以配合一些实时监控工具提前验证一下参数的工作效率；另外数据收集时使用的工具如iostat、vmstat、top、jmap、jstack之类工具的如何使用，数据如何提取、如何分析，如何理解等等，测试报告模板之类的准备工作。
5）正式测试
千呼万唤始出来，相对而言，这一阶段的工作相对简单，记录数据、观察应用运行情况即可。在关键的时间点，最好要收集应用的栈数据和堆数据，便于进一步的分析。
6）数据分析
万里长征第一步，前面其实都是铺垫。分析的目的是要确定瓶颈点，依据上一步收集到的数据，对测试场景下，应用的表现、JVM的表现做出一个准确的评估。对于JVM而言，即是要评估GC停顿时长、新生代GC频率、Full GC次数、Full GC频率等等指标是否在合理值范围内；对于应用而言，就是要评估资源占用，业务响应时延，吞吐量等等是否达到合理范围，同时在测试过程中是否发现有瓶颈点，触发原因，分析瓶颈与JVM参数是否有关。可能的场景，比如调整JVM在启动
确定当前调优是否达到最终效果，调优过程是否可以结束；否则需要调整参数，重复5和6。
第二个问题
大数据量并发时如何应对
这个问题问的很空泛，以至于我都不知道如何回答，因为没搞明白W先生问话的重点在哪里，只好简单的答复说，不相关的操作异步处理，可以批量的操作要批量处理，但这个答复我自己都不满意，W先生听了之后的效果可想而知了。
我自己在做产品的时候遇到过两个“大数据”，一是应用面临大数量的IO并发访问，在解决这个问题的过程中，又引入了另外一个大数据量问题。我所做产品的特点是用户数量比较多，用户设备与管理中心交互时，管理中心短时间内要处理的报文数量多，而管理中心收到报文之后的处理比较简单，比对数据，然后决定如何回复用户设备的请求，另外还要完成DB内数据的刷新。在这个过程中，应用需要保证有非常高的响应成功率，比较短的响应时延，不允许影响DB正常工作。根据我的答复，处理策略很简单，比如消息解码、消息处理、消息应答、DB操作，其它业务操作，在我们的业务场景里都是不相关的，因而都可以异步处理，好处是可以明显提高吞吐量，有效利用机器的CPU资源。至于DB方面，在处理报文这个场景里，管理中心依据用户设备上报的信息与DB表中保存的数据进行对比，决定响应消息的内容，同时完成数据插入或者更新操作。从管理中心的操作看，涉及DB的操作比较简单，包括查询操作、插入或者更新，查询操作是不可能取消的，但可以考虑把数据加载到内存中之后，使用内存中的数据进行比较，这就消除了读取表数据的操作；插入或者更新操作可以批量提交DB执行，因而效率也有好的保证。
第三个问题
如何降低对DB的影响
这方面经验不多，我的答复如下，好像W先生也不大满意。
1）通过合理设计表的结构，应用分区、索引技术，提升查询、更新操作的效率；
2）应用服务器的在设计时，把频繁操作的行为调整为批量SQL执行；
3）为只读的数据或者访问频繁的数据设计合理的缓存方案，平滑应用对DB的访问操作；
4）针对表的访问特点，有针对性的设计表数据分析策略，降低DB的分析上的开销；
5）定期分析AWR报告，及时发现、消除问题SQL，或者调整实现方案；
第四个问题
薪资，这个保密。
。。。。。。。
1）求职经验少是硬伤，面试前没有针对Wind公司此次招聘的需求进行专门的准备，以至于心理没有底，影响到了发挥；
2）简历是弱项，我留在求职网站上的简历里缺少项目经验，这其实犯了大忌，W先生毫不留情的指了出来。招聘有工作经验的人时，应聘人之前的项目经验会被特别的分析和研究，以确定应聘人是否合乎要求，是否有胜任当前的工作的可能，我自己在面试新员工时对这点深有体会。
3）工作时间久了，很多技术细节变成了工作习惯，有时反而不知道如何通过语言恰当的表达出来，或者说不知如何使用他人理解的方式表达出来。
4）有部分技术细节因为长时间用不到，都忘记了，感觉现在还不如刚工作的时候记的清楚；虽然以现在的经验和能力，遇到相关的问题可以快速的搞定，但面试前如果不做针对性的准备，回答问题时还是觉得有点吃力。这是面试和工作不同的地方，面试的时候回答不好，可能会让人产生怀疑。
5）需要准备几个好的Story，针对招聘方对职位的需求，恰当表现出自己的能力，满足对方的需求，这是本次面试中没有做好的地方，W先生反复要求举例子说明，结果都被我无意忽视了。
求职经验少是硬伤，面试前没有针对Wind公司此次招聘的需求进行专门的准备，以至于心理没有底，影响到了发挥；
简历是弱项，我留在求职网站上的简历里缺少项目经验，这其实犯了大忌，W先生毫不留情的指了出来。招聘有工作经验的人时，应聘人之前的项目经验会被特别的分析和研究，以确定应聘人是否合乎要求，是否有胜任当前的工作的可能，我自己在面试新员工时对这点深有体会。
工作时间久了，很多技术细节变成了工作习惯，有时反而不知道如何通过语言恰当的表达出来，或者说不知如何使用他人理解的方式表达出来。
有部分技术细节因为长时间用不到，都忘记了，感觉现在还不如刚工作的时候记的清楚；虽然以现在的经验和能力，遇到相关的问题可以快速的搞定，但面试前如果不做针对性的准备，回答问题时还是觉得有点吃力。这是面试和工作不同的地方，面试的时候回答不好，可能会让人产生怀疑。
如果您想提高自己的技术水平，欢迎加入本站官方1号QQ群：&&，&&2号QQ群：，在群里结识技术精英和交流技术^_^
本站联系邮箱：