如果你觉得这次峰会和开发人员一点关系没有，那你就大错特错了。因为DevOps就是以开发为主导的自动化运维，而DevOps已经在BAT及各大企业成功落地，这意味我们开发需要接管一些运维工作，来使得项目部署进度加快。

前言

不得不说，这些很多企业很大一部分都是为了DevOps落地而来，我们都收获满满。直到我参加这次峰会，我才发现自己对自动化运维的天赋。我从未想过，把自己对硬件研究+java开发经验有机结合到一起，就是DevOPs。在我公司近几个月里，我对整个开发架构进行了重大的调整，的罪了一些人，现在想想才知道这一切都是对的，我围绕着的正是DevOps，当时见识有限，不知道有这个词。

按我的理解，Dev是开发，Ops是部署，之前是运维在部署，而在DevOps的理念下，是开发参与部署。

开篇

可能你会觉得很奇怪，开发干嘛要干涉运维的工作。可是你仔细想一下，我们项目从持久化构建，到部署生产环境，中间有多少系统环境、版本部署控制的问题。我们曾多少次和运维交涉，一起查问题，而说实话，我们并不懂得很多运维知识。

可能还在犹豫为什么让开发了解运维，其实我想说的是，部分开发参与自动化部署项目开发还是很有意义的。在现场，阿里巴巴的DevOps虚拟小组负责人告诉我们，他们经过DevOps培训，不断加强开发对部分运维工作的了解，使得项目上线速度更快，周期更短。

题外话

昨天，是CNUTCon全球运维技术大会的第一天，我发表的了一篇

文章，但是效果不是很好，关注度很低，可能是我没写好，也可能是大家觉得运维跟自己没有关系。我也反思了一些，换个角度去介绍这个大会实录。我们公司在过去的半年，重点做了：

• 开发自动化运维war包
• 使用docker容器
• 封装image镜像
• 抽取image或war包内的状态，使得项目无状态
• 利用环境变量解决测试环境、生产环境配置问题
• 采用jenkins自动化构建
• 统一开发及部署流程，统一开发规则
  等

这些在本次大会中，多多少少都有介绍，当然实现功能以及稳定性肯定比我做的要多的多，但至少，我的思路是对的。下面一起聊聊大会第二天的收获。

京东物流系统自动化运维平台技术揭密

早就听说京东的项目运行在15万docker容器之上，应用依赖极为复杂，今天一听，果然名不虚传啊。

京东运维选型

• Puppet
• Saltstack
• Chef
• Ansible
  因为最终京东方面比较熟悉java，所以排除了Puppet、Chef，而因为Ansible较为基础不易扩展，最终选了salt。

对于java开发工程师，我想spring、mybatis太熟悉不过了，以后去京东应聘可多一条职位了哦。 Drools主要是一个规则引擎；Mvel是一个模版引擎；activiti是一个开源的工作流框架。

总体架构图还是比较清晰的，关于vpn自然是构建内网环境，据京东老师介绍，他们全网的服务器ip都是预分配的，我想可以理解为所有的机器在一个内网下，那在不同区域，应该是通过vpn联通吧。

京东抽取了很多元数据，当然主要是为了解决“配置中心”的问题，在本次大会中，阿里巴巴成功的一次又一次炫耀了他们的强大的配置中心，会上，老师说他们的项目在不同的环境就是一套，但是如war等自动可智能识别自己所在环境加载不同配置。会后，我找阿里的天猫互动架构师刘雄昌（花名：邵雍）聊了这个智能识别，原来他们是基于一个域名，在不同网络下，给域名指向不同的ip，来读不同的配置文件。 当然，搜狗郭理勇老师也开了一篇《搜狗配置中心架构的演化与实践》，下文详细讲。

京东的规则引擎，主要是解决不同机器部署不同应用的问题，他还支持yml文件。

京东的自动配置基于模版引擎+环境变量实现项目快速部署。

阿里一键建站技术解密

阿里的高级技术专家谢吉宝老师给我们介绍了阿里的一键建站技术，刚开始我还以为一键建站是阿里云里的那种为企业一键建网站的功能，后来才知道，我太天真了，人家这个可强大的多啊。

那么什么是一键建站呢，简单的说，就是快速部署一整套网站，包含所有模块，支持异地容灾、流量切换。那么效果如何呢，举个例子，阿里刚开始建一套完整的系统（建造了一个单元项目），需要200人月，相当于100个人干了2个月；第二阶段用了100人月；而现在只需要8个小时，2-3个人参与。

现阶段成功

• 支持混合云架构
• 覆盖全生命周期
• 过程全自动化
• 8小时内全交付弓丨流1%% , 2天回归，1天压测验证
• 边压边弹
• 快上快下
• 非电商大促场景的中间件环境快速交付

看到阿里的一次部署，全是绿色，心里满满的羡慕啊，一整个单元，阿里能做到全国内任一地点快速部署。

腾讯包管理系统演进

其实，我们公司也做了包管理，当然了那是基于nexus开源框架，之前有介绍过 有兴趣可以看看，快速实现私有maven、docker、npm、gradle私服仓库。

腾讯的包管理演进

我觉得，对于中小公司使nexus可基本解决问题。

微服务场景下的Serverless架构实践

lambada最大的特点就是按计算cpu消耗时间来扣费，成本节约几十倍啊。

并支持高可用自动扩容

看了这个图，跟我们公司还是比较相似的，流程是类似，但具体实现有些差异。

lambada限制： 资源 限制 内存 128M-1536M 临时磁盘存储 512M 每个请求最大执行时间 300 秒 request/response body size 6MB 部署包大小 50MB 解压后的部署包大小 250MB

天猫DevOps转型实践

据说在2016年，阿里成立了一个DevOps虚拟小组，为什么叫虚拟小组呢，因为这个小组里的成员跨越5个大团队，15个壮丁，每个人都在做自己事的同时，来处理DevOps工作。当然这些工作会计入kpi，算在绩效内。

取消掉应用运维岗位

开发转运维

经过16年3次尝试的转型，不断DevOps培训后开权限，审核流程急速提高。

逐步交接运维任务，舍弃掉pe的工作，会后，和刘老师交流得知，pe去做更底层、更有意义的事情了。

当然阿里还解决了持续交互-代码快速生效问题，主要想办法利用热更新技术实现批量预编译、热替换，来提高编译速度。

既然要部署，尤其中间件为tomcat，部署后得重启服务，而重启服务会中断服务。阿里怎么解决呢，采用蓝绿部署，先把流量切换到B环境，然后更新测试A环境，部署成功，通过健康检查再切换回原环境。

阿里还在做自愈模块，就是本次大会重点AIOps了，当然这个过程，目前仍需要人去处理，并没有完全交由机器。

搜狗配置中心架构演化与实践

搜狗的配置中心和阿里的配置中心，都是为了除去一些项目状态的问题。虽然呢，和阿里相比，搜狗有些精简，但是对于我们中小心公司，搜狗这一套实现起来的确极为简单。

支持各类配置文件，据我和搜狗郭理勇老师会后交流，得知，他们支持各类配置文件，尤其是java的maven工程，大部分class目录下的配置文件都可以加载并更新。起初，我不太明白具体的配置文件，是如何达到秒级送达，然后他跟我解释说，配置变更是以订阅者的模式去发送配置变更消息，仅仅是一条消息，而加载配置需要通过http去拉取。在war包启动时，他们新加了一个listen，这个listen会去比较配置中心的配置文件，然后拉取；如果配置发生变化，则在消息回调里处理变更逻辑。

当然搜狗的配置中心也是使用了nginx负载均衡，支持水平扩展，所以性能上、架构上都高可用。

在看看搜狗的部署，统一部署，加载不同配置，一个image或者一个war解决了所有环境的部署，无需将配置文件写入war或image达到高效可持续集成。刚好，目前我也在处理这一块，遇到的问题，主要是组织结构上的问题，各个项目经理的不配合。在技术上，这条路，值得每个公司学习，借鉴，无状态项目，使部署更快、更稳定。

最后

今天17点20在上海听完这次大会，就急忙忙的回南京，大雨淋漓，晚上9点多才到家。现在赶着发布这一篇文章，时间有限，明天还得上班，我想早点休息了。后面，我会给大家带来关于本次活动的更多分享，谢谢大家。