对DevOps实践的一些思考04(1.21)

今天主要谈下DevOps下的项目实施，当然这个实施不仅仅是指DevOps支撑平台和标准规范体系，也包括了容器化PaaS平台，微服务架构开发框架和标准规范体系，基础技术服务平台等诸多内容，而这些内容实际上在13年我博客上写企业私有云PaaS平台建设一系列文章的时候已经有涉及，只是持续集成变成了DevOps，组件化和服务化开发变成了微服务架构，基于CloudFoundry的厚PaaS平台变成了基于 Docker 容器 Kubernates的轻量PaaS平台，对于传统的ESB服务总线和集成平台变成了微服务网关或API网关。

对于大型的基于DevOps思路下的微服务架构开发和实践，如果我们作为完整的基础平台开发商和集成商，那么在实施这个项目的时候应该具备哪些能力。而我们经过这几年的发展和技术沉淀，本身也具备提供这种基础架构平台并进行实施落地的能力。

这个偏业务和实施层面，即进行微服务架构的总体设计，而总体设计里面最重要的又是微服务模块的划分，模块划分后各个微服务模块的接口服务设计。这个需要有专门的既熟悉业务又懂技术的人往往才能给胜任，比如传统软件工程里面的系统分析员或资深的软件需求顾问角色是比较适合的。

这个规划不同于一个企业完整的信息化和IT架构规划，可以理解为企业某一个业务域的IT总体架构规划设计，当时对于IT架构规划的总体思路我们仍然可以参考，包括流程和业务建模，关键数据对象识别和数据架构设计，应用架构设计，技术架构设计等。特别是在应用架构设计中需要进一步体现集成架构设计，体现平台 应用的构建思想。

这个可以看做是DevOps支撑平台这个产品提供加技术支撑团队，即在有了DevOps支撑平台后，我们会对已有的Docker容器化PaaS，持续集成各类 工具 集全部进行打包提供，而真正面对开发者的就是DevOps支撑平台，这个团队即包括了产品本身的开发，也包括了对于DevOps支撑平台在使用中的技术支持。

如果我们的微服务架构开发框架选择的是SpringCLoud话，那么这个团队重点就是在总体设计完成微服务模块已经划分好后，确保各个模块的开发商严格按照已经制定好的微服务框架，技术标准规范，技术设计开发规范，集成规范进行各自微服务模块的开发。

由于即使你没使用微服务开发框架或架构，你也可以使用DevOps支撑平台，因此对应微服务架构的实践额技术支撑，最好和DevOps技术支撑团队进行分离。这个团队核心是确保微服务架构总体设计团队的输出成果，包括前期已经制定好饿微服务架构技术标准规范能给真正落地。

在采用微服务架构框架的时候，里面涉及到类似微服务注册中心，微服务网关等公共基础支撑组件，而这些基础组件的进一步定制开发，封装和实施也应该由该团队来支撑。对于微服务网关，包括服务的注册和接入，我们希望的是在DevOps整个实施过程中实现完全的自动化。

按传统平台 应用构想，在整个项目实施过程中还涉及到公共的基础技术平台建设的问题，其中最大的就是基础流程引擎能力提供，4A能力提供。其次就是涉及到日志，文件，缓存，消息，通知等各种技术服务能力提供。而这块可以统一纳入到基础技术平台开发和支撑团队。

对于技术服务的开发，每个技术服务本身也是一个独立的微服务架构模块，完全可以遵循我们已经制定的微服务架构开发看见和技术标准进行开发，并按标准提供API接口服务能力。

5. QA，测试，过程支撑团队

这个团队也是一开始就要建立，包括了质量保证，评审，配置管理和检查，测试团队。注意由于实施了DevOps实践，那么这个团队和开发团队产品交付之间将处于更加松耦合协同状态，而且边界也将划分的更加清楚。当然传统很多进行配置管理，构建，代码检查等工作也全部在DevOps实施后转为自动化处理和执行。

注意，这个团队一开始就要成立并进入到整体项目实施和管理，而不是等到最终的开发上线后再介入。一开始介入的好处就是确保整个项目在交付过程中就具备可运维属性。同时运维团队更加强调运维监控的自动化能力，传统的手工重复运维过程要在DevOps实施后被进一步替代。

也正是这个原因，在一个完整的DevOps和微服务架构实施过程中，提前就需要一个完整的运维监控平台，这个平台不是资源监控层面，而是需要在中间件服务监控层面，包括我们常说的APM应用性能间和服务链监控能力。

要意识到在实施微服务架构后，各个微服务模块间的接口数会呈现指数级增长，模块间的集成也会异常复杂，既包括模块和模块间的横向集成，也包括了模块和底层基础技术平台的纵向集成。因此对于后期的自动化运维，自动化服务监控预警就异常重要，这个必须是一开始就介入并进行评估。

也就是我们将原有的硬件资源监控，工程运维，服务链监控分析，日志采集监控分析等全部拿出来，合并到单独的运维监控团队，一开始就介入到整个项目实施过程中。