对DevOps过程实践的⼀些思考和总结作者：⼈⽉神话，新浪博客同名
简介：多年SOA规划建设，私有云PaaS平台架构设计经验，长期从事⼀线项⽬实践
从2019年上半年，我们启动了DevOps过程实践相关⼯作，其中既包括了整个容器云+DevOps ⽀撑集成交付过程整合，也包括了我们传统单体系统的微服务架构化改造。本⽂主要对项⽬DevOps过程实践的⼀些内容进⾏总结。
些⽅⾯进⼀步做下阐述。
对于DevOps基本概念的理解
⾸先看下DevOps的定义：
DevOps（英⽂Development和Operations的组合）是⼀组过程、⽅法与系统的统
称，⽤于促进开发（应⽤程序/软件⼯程）、技术运营和质量保障（QA）部门之间的
沟通、协作与整合。它的出现是由于软件⾏业⽇益清晰地认识到，为了按时交付软
件产品和服务，开发和运营⼯作必须紧密合作。
在18年12⽉11⽇，当时写过⼀篇对DevOps实践价值的思考，其中的重点是在谈DevOps，容器云和微服务架构框架的三元⼀体化。只有三者相互结合才能够产⽣DevOps最佳实践。
DevOps = Dev + Ops + QA
对于DevOps⾸先还是要回到这个概念的最基础理解，即是开发，运维和QA⼯作本⾝的三元⼀体化。在有篇⽂章⾥⾯谈到⼀点，对⾃⼰很有启发，就是原来的软件开发流程，分⼯边界，包括了开发，SCM配置管理，QA，测试，运维等各个环节，相对来说分⼯明确，但是在核⼼软件交付流程中流转太多，⾃然导致效率低，同时也导致更多的上下游扯⽪。
⽽DevOps带来的⼀个关键点就是，Dev处于整个核⼼交付流程中，⽽且这个过程通过⽅法⼯具等的⽀撑完全实现⾃动化和流⽔线作业，⽽对于SCM配置，QA等则处于核⼼流程的外围⾓⾊，即这些⽀撑过程⾓⾊不参与核⼼交付流程，只是对交付完成的内容进⾏管理验证。只有这样才容易实现整个交付流程的⾃动化。
开发和运维
如何理解开发和运维？实际上这⾥⾯最关键的⼀点就是运维的基因已经融⼊在了整个开发过程中，再展开说明下，就是实际在系统上线后的运维阶段，传统是运维⼈员发现故障问题，然后转给开发再去分析和定位。
⽽实际上⼀个⾃动化可运维的软件，在出现问题后⾃动就会转为开发可理解的语⾔之间转到开发⼈员。也就是说整个过程⾥⾯并不需要运维去太多⼲预。
即传统路线是系统运⾏-》运维发现硬件故障-》运维发现中间件故障或性能问题-》转开发分析解决。⽽新的路线是系统运⾏-》各类问题直接预警或通知到对应的开发。当然整个过程硬件故障还是需要⼯程⼈员解决。
其次，传统的持续交付，特别是测试环境朝⽣产环境的持续交付，⼀定需要专门的运维和⼯程⼈员接⼊，进⾏严格的版本管理和发版流程管理。⽽开发运维⼀体化后，我们希望的是整个朝⽣产的持续交付过程也是⾃动化和流⽔化的过程，最多只是增加需要的⼈⼯审批环境⽽已。
开发和配置和QA
即使是在传统的持续集成模式下，我们看到整个过程分⼯也是开发每⽇将修改好⾃测通过的代码Check in，⽽由配置管理员负责进⾏⾃动化构建和打包，打包完成后进⾏⾃动化的部署。在部署完成后通过测试⼈员进⾏测试和验证，验证有问题后测试⼈员提交Bug并反馈给开发。持续集成的概念
简单来说，传统⽅式下类似配置或测试⼈员参与了整个软件交付过程，那么整个过程就⼀定会有协同和沟通，产⽣效率问题。类似开发提交的代码构建不通过，可能需要反复沟通，或者说在分⽀合并的时候，也需要双⽅反复沟通确认等。
对于开发和配置QA⼀体化，简单来说就是在整个持续交付过程中，不再需要过程⽀撑类⼈员的参与，这些⼈都在外围，整个持续交付构成完全⾃动化和流⽔线作业，类似QA或测试，只是对最终交付的结果进⾏检查和测试，交付过程中（包括代码提交合并，构建，打包部署，环境迁移）等各类问题全部由开发负责，这些问题属于开发内部的问题，由开发主导去解决更加⾼效快捷。
DevOps的核⼼还是在于持续集成和持续交付
个⼈理解对于DevOps的核⼼仍然是在持续集成和持续交付上，要实现整个持续集成就包括了配置版本管理，⾃动化构建和打包，⾃动化部署，⾃动环境迁移，⾃动化单元测试或冒烟测试等诸多内容。这些内容都为核⼼的持续交付⽬标⽽服务。
在DevOps和容器云结合的时候，我们增加了基于Docker容器的⾃动化部署，资源动态调度和集管理能⼒。在和微服务架构结合的时候，增加了对微服务基础管理平台框架，微服务⽹关的集成能⼒。在和运维过程集成的过程中增加了类似ETL⽇志分析，类似Zabbix，Nagios等平台监控预警能⼒。
DevOps和⽂化组织变⾰
企业要进⾏DevOps实践，另外⼀点谈的⽐较多的就是要进⾏⽂化和组织变更，这句话如何理解，即⼀个DevOps最佳实践不是简单的各种⼯具的堆砌，⽽是涉及到企业内部开发，QA和运维团队调整，开
发框架，开发流程等诸多⽅⾯的调整，最终⼈+⼯具+DevOps⽅法论融为⼀个整体，才能完成最佳实践。
DevOps = ⼯具 + ⽂化。上⾯是对于DevOps实践的另外⼀个关键说法，即⼯具和⽂化的集成，只有⼯具不⾏，还需要在组织和⽂化上⾯做调整和变更，还需要整个开发运维团队转变传统的开发和思维模式。这⾥⾯究竟涉及到哪些⽂化，个⼈理解⾄少涉及到敏捷⽂化，质量⽂化，流程⽂化，客户服务这⼏个⼤的⽅⾯。只有真正理解了这些⽂化，DevOps实践才能够在企业内落地实施，并取得好的效果和收益。
⼯具从下朝上完成了整体集成，但是⽂化的推⾏⼀定是从上到下的。
⼀个完整的DevOps解决⽅案应该包括的内容
对于DevOps实践，可以看到涉及到业务，技术，⼯程，管理规范，组织等多个⽅⾯的内容。DevOps过程实践不是简单的开源技术或⼯具链集成，更加重要的是整个研发⽂化，组织，研发项⽬过程管理的协同改进。
同时对于对于DevOps实施同样需要⽬标和业务场景驱动进⾏持续优化和完善。对于DevOps过程实践我们可以看到实际上包括如下⽅⾯的内容：
1. 传统软件过程和单体技术架构存在的问题和需求分析
2. DevOps⽀撑平台的搭建和总体架构
3. DevOps⽀撑平台涉及到的⼯具集集成
4. DevOps实现端到端流⽔线作业和持续交付过程
5. DevOps与容器技术集成实现⾃动化部署和环境迁移能⼒
6. 基于DevOps的度量分析和最佳实践
7. DevOps平台和微服务开发框架的集成
8. DevOps平台和PaaS平台技术服务组件和技术服务能⼒的集成和最佳实践
9. 基于DevOps平台实现的典型案例和场景分析
下⾯对上⾯这些点做⼀个简单的展开说明
1. 传统软件过程和单体技术架构存在的问题和需求分析
再次说明⼀下，不要为了微服务和DevOps⽽去迎合，要业务和技术需求驱动，⽐如当前软件开发过程，软件交付上究竟有哪些问题，是否已经影响到效率和质量。包括我们说的微服务架构的数据库拆分也是⼀个道理，技术成熟度不够的时候，你完全可以数据库不拆分，只拆上层组件，这也是折中可⾏⽅案。对于持续交付同样，前期你完全可以不⽤DevOps和容器化，仅仅实现传统持续集成最佳实践即可。
上任何新东西都必须要想清楚，具体解决的是资源，成本，效率，后期管控治理哪⽅⾯的问题。⼀定要有实际的需求和问题驱动，否则很难真正实践成功。包括我们现在看到的很多互联⽹架构最佳实践，都是互联⽹应⽤在⾯对海量数据，⼤并发实际场景下逐步积累和演进出来的。
2. DevOps⽀撑平台的搭建和总体架构
⼀个DevOps⽀撑平台在搭建总体架构的时候可以看到，其核⼼更多的是围绕持续交付进⾏的各种能⼒的集成和⾃动化，⽽不是说其本⾝新创作了什么能⼒。对于这种集成本⾝包括⼏个关键部分。
其⼀是和Docker容器化平台的集成，以实现⾃动化部署和环境间的动态迁移，包括灰度发布，资源动态调度，集等关键能⼒。其⼆是和微服务平台的集成，类似开源的SpringCloud平台中的注册中⼼，微服务⽹关的集成。其三包括和前⾯提到的PaaS平台各技术组件和服务的集成。其四则是对持续交付过程中的涉及到的各类⼯具链的集成，包括了配置和代码管理，代码静态检查，⾃动化编译构建，⾃
动化测试，⾃动化运维，⾃动化监控，⽇志管理等各种⼯具的集成。
⼀个DevOps平台需要提供对源代码管理，开发，编译构建，打包，部署，测试，运维完整的能⼒⽀撑，同时通过流⽔线设计将这些任务过程进⾏⾃动化串联。⼀个流⽔线既可以是完全的⾃动化流⽔线，也可以包括⼈⼯处理和检查节点。流⽔线可以对上述动作和任务进⾏可视化的设计和编排。
5. DevOps与容器技术集成实现⾃动化部署和环境迁移能⼒
⼀个DevOps⽀撑平台离不开和容器化PaaS平台的集成，即最终的编译构建完成的内容形成镜像并放到镜像仓库，后续部署，环境迁移，资源扩展基于镜像仓库进⾏快速的拷贝和复制。对于Docker容器⼀般会和K8S结合来实现资源的动态调度，集管理能⼒。
环境迁移是基于镜像进⾏环境拷贝和迁移，⽽不再需要重新构建和打包，这也是我们原来在谈持续集成技术的时候⼀直强调的⼀点。只有这样才能够保证测试通过的包就是最终部署到⽣产环境的包。
6. 基于DevOps的度量分析和最佳实践
在谈CMMI的时候我们经常会谈到软件度量，⽽对于DevOps也有标准的成熟度模型，我们需要对DevOps执⾏构成中的关键活动和任务，其执⾏的质量和效率进⾏度量分析，以确认DevOps 过程执⾏效果，并指导后续的持续改进⼯作。
这⾥⾯既会涉及到构建，部署和⾃动化测试的效率指标，也会涉及到传统的代码检查和⼈⼯测试，变更处理，缺陷泄露等质量指标等。
7. DevOps平台和微服务开发框架的集成
实际上要把这个功能谈透彻并不容易，⼀涉及到微服务架构开发模式，就涉及到基于微服务架构下的团队拆分和多团队协作，就会引⼊类似微服务⽹关和注册中⼼等基础能⼒。就会涉及到⼀个独⽴的微服务模块要真正能够运⾏并进⾏单元测试，离不开其它微服务模块提供的API接⼝服务能⼒⽀撑。
因此这种集成不是件的对开源微服务框架在开发态的集成，更多的是开发态如何和运⾏态集成和协同。如何在多团队协同模式下来实现多项⽬，多微服务模块的集成能⼒。实际上这个问题在我13年左右在谈私有云PaaS平台的持续集成的时候详细分析过，但是现在感觉在谈微服务架
构和DevOps的时候反⽽没有谈透彻。
8. DevOps平台和PaaS平台技术服务组件和技术服务能⼒的集成
这个也是需要专门写⽂章来谈的，就是对于PaaS平台提供的各类技术组件和技术服务能⼒，如何和整个DevOps持续交付过程集成起来。当然对于单个技术组件的开发，测试和部署上线也可以使⽤DevOps⽀撑平台来完成。在原来谈私有云PaaS平台的时候，我们谈到过⼀个概念，即⼀个组件要能
够运⾏起来需要两个⽅⾯的服务集成，⼀个是技术平台提供的技术服务能⼒集成，⼀个是横向的其它微服务模块组件的接⼝服务集成。
如何集成，包括在集成后如何进⾏集成测试，都是需要考虑的问题点。
基于微服务架构开发过程持续集成实践
虽然对于DevOps过程不强制要求采⽤微服务架构进⾏开发，但是如果你采⽤微服务架构开发那么更加适合实施DevOps持续集成和交付过程。
微服务模块划分
在微服务模块划分清楚后，各个微服务模块划分到不同的团队和⼈负责，那么每个团队对于⾃⼰负责的模块，在配置管理库和代码管理，数据库，开发项⽬上完全独⽴⼀套。负责A模块的团队不应该，也完全没有必要看到B模块开发的代码，⽽只需要关⼼接⼝即可。
微服务模块划分清楚后，实际上有个重点⼯作就是前期的架构设计和接⼝设计，需要先把各个微服务模块间的交互接⼝初步定下来，这个总体设计完成后再开始各个微服务模块的并⾏开发。⽽不是在开发中，想到需要什么接⼝就临时开发，这样很容易导致后续的接⼝混乱。
环境准备和微服务模块的开发
独⽴的项⽬，独⽴的代码管理，独⽴的数据库，但是不同的团队是基于相同的微服务开发框架，类似SpringCloud或其他开发框架进⾏微服务模块的开发。
A模块要调⽤B模块的接⼝才能够完成相应功能的开发和验证，这个时候就需要B模块提前准备好可⽤的接⼝并部署，在多模块协同下注意，⼀定是接⼝开发先⾏，即要确保接⼝提前开发出来可供其它模块测试⽤。
各个模块开发完成的接⼝不能部署在⾃⼰本机，因此要有独⽴的开发环境来部署这些接⼝，当然在开发环境还需要有类似SpringCloud中基础注册中⼼和管理中⼼的部署。
开发⼈员的本机在⾃测的时候可以调⽤开发环境提供的API接⼝服务能⼒，因此⾃测还是可以在本机完成，⽐如A模块调⽤B模块的API接⼝服务。但是需要B模块提前已经将可⽤的接⼝服务部署到开发环境。当然对于A模块⽽⾔如果也提供API接⼝给其它模块使⽤，也需要提前部署到开发环境并准备就绪。
A模块的开发项⽬⾥⾯，没有B模块的任何代码，⽽只是基于API接⼝远程调⽤接⼝能⼒。⽽这⾥最好的思路是实现⼀个本地化的接⼝代理包，即代理包封装⼀层后实现调⽤的时候是本地⽅法，在接⼝代理中再将本地⽅法转化为远程API接⼝调⽤。
如果A模块依赖的B模块，C模块提供的API接⼝服务都没有准备好，按道理A模块是⽆法进⾏后续开发的。基于传统集成思路，A模块也可以⾃⼰实现了⼀个本地API的接⼝模拟，在B模块或C 模块准备好后再配置为调⽤远程API接⼝服务能⼒。
编译构建
按持续集成思路，开发要管的就是⾃⼰开发好的代码在本地编译通过，同时在本地测试通过后，将代码Check in到源代码管理库，后续的编译构建完全是⾃动化的过程。例如完成通过Git + Maven + Jekins的结合来完成整个编译构建过程。
独⽴的源代码管理库，各个微服务模块的项⽬相对也要独⽴，各⾃管理并进⾏权限隔离。对于数据库变更脚本注意也要进⾏版本管理和脚本⼊库，实际上最难以管理的还是在数据库的变更上。
构建服务器和源代码管理服务器可以在相同服务器，也可以在不同的服务器上。
实际的编译构建过程，⾸先是update到最新的源代码，然后基于常规持续集成的思路，例如Maven+Jekins完成⾃动化编译构建，最终形成部署包。这个过程中远程API接⼝调⽤是松耦合⽅式调⽤，因此不会对组件依赖性进⾏检查，也不会出现编译依赖⽆法通过的问题。
部署过程
构建完成后形成可部署的部署包，按容器集成思路，⾸先要制作镜像，并推送到镜像库存储，然后再完成部署操作。部署完成后形成并发布可访问的地址信息。该过程会涉及到⼀些⾃动化脚本的编写，可以⽤Jekins，也可以⽤Puppets等各种⼯具来实现这些脚本⾃动化。
实际的部署操作最终由K8s来接管，包括具体的初始化部署容器数量，负载均衡设置等。
在采⽤微服务架构开发的时候，多个微服务模块同享⼀套服务注册中⼼，包括微服务⽹关等，这些基础内容需要提前部署到开发环境中，并在可⽤状态。
微服务模块中API接⼝注册到⽹关
如果整体架构中，所有的微服务模块都不需要和外⾯的业务系统打交道，那么你可能并不需要使⽤微服务⽹关，但是如果存在整个架构朝外部提供API接⼝服务能⼒，包括你的APP端也需要理解为外部。那么就⼀定涉及到微服务⽹关的使⽤。
微服务模块中的接⼝⽅法不是所有的都需要注册到微服务⽹关上⾯，要梳理清楚，究竟哪些接⼝⽅法要注册到微服务⽹关上⾯。⽽这块注册操作我们希望是完全⾃动化注册并运⾏。
即微服务模块部署-》k8s发布可访问的API地址-》微服务⽹关封装后暴露最终的API服务地址
⽽这个API服务地址是可以给外部系统或前端APP使⽤的⼀个地址。对于其它应⽤的开发我们可以使⽤该地址。如果说到DevOps⽀撑平台，那么在集成微服务⽹关能⼒后，最基本的就是要有服务注册和管理能⼒。
环境迁移能⼒
环境迁移难的不是单个微服务模块的环境迁移，⽽是相关微服务模块多个部署环境同时的⾃动化迁移。⽐如A模块调⽤B模块的接⼝发⽣变化，这个需要同时对A和B两个模块进⾏环境迁移和重新部署。按持续集成的思路，从开发-SIT-UAT-⽣产的多套环境，⼀定有⼀个环境看板视图，能够可视化的看到各个微服务模块在每个环境的部署版本情况。
环境迁移按道理应该进⾏独⽴的流⽔线设计，特别是涉及到多个模块的时候。
性能监控和⽇志管理
对于资源和中间件监控，对于Zabbix或Nagios等完全能够实现，最难的还是APM性能监控和服务链监控等，对于这些监控的实现，⼀定要提前在微服务开发框架中进⾏标准规范定义，相关的代理组件的植⼊。如果采⽤标准的开发框架模型，你也可以考虑在镜像制作的时候将代理植⼊到镜像⽂件中并启动运⾏。
基于DevOps实施和组织变⾰
对于DevOps过程实施不仅仅是指DevOps⽀撑平台和标准规范体系，也包括了容器化PaaS平台，微服务架构开发框架和标准规范体系，基础技术服务平台等诸多内容，⽽这些内容实际上在我最近刚出版的《SOA与⼤数据实战-企业私有云平台规划和建设》⼀书⾥⾯都有涉及。
只是持续集成变成了DevOps，组件化和服务化开发变成了微服务架构，基于CloudFoundry的PaaS平台变成了基于Docker容器 Kubernates的轻量PaaS平台，对于传统的ESB服务总线和集成平台变成了微服务⽹关或API⽹关。
对于⼤型的基于DevOps思路下的微服务架构开发和实践，如果我们作为完整的基础平台开发商和集成商，那么在实施这个项⽬的时候应该具备哪些能⼒。⽽我们经过这⼏年的发展和技术沉淀，本⾝也具备提供这种基础架构平台并进⾏实施落地的能⼒。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。