云计算环境下的高校DevOps实践之路_编程语言应用_编程语言开发

DevOps介绍

　　随着信息化的发展，高校各类业务系统数目繁多，而软件交付的方式也在发生变化。传统的软件系统交付方式是由校方信息化管理部门提供硬件服务器，只负责服务器硬件资源的正常运转和网络访问的畅通，而不参与到软件开发生命周期。这种方式在高校信息化发展初期确实非常高效，也弥补了校方人员技术水平不高的缺陷。但是随着信息化的发展，云计算技术的成熟，大数据对教育的变革，尤其是高校信息化需求的变化，各个应用不再是独立的个体，而是整个学校信息化的组件，多个应用之间相辅相成，业务流程交叉，数据流混杂。软件系统个体发展开始向平台化、集成化、统一化发展。这种变化，对于软件开发参与者发生了变化，对校方信息化人员的总体战略和运维也提出了更高的要求。这些变化，要求校方信息化人员与第三方软件供应商协同工作，参与系统部署的环境准备和后续运维。

　　DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。它的出现是由于软件行业日益清晰认识到：为了按时交付软件产品和服务，开发和运营必须紧密合作。

　　如图1所示，我们可以把DevOps看作开发（软件工程）、技术运营和质量保障（QA）三者的交集传统的软件组织将开发、IT运营和质量保障设为各自分离的部门，在这种环境下如何采用新的开发方法（例如敏捷软件开发），是一个重要的课题。按照从前的工作方式，开发和部署，不需要IT支持或者QA深入的跨部门的支持；而现在却需要极其紧密的多部门协作。而DevOps考虑的还不止是软件部署，它是一套针对这几个部门间沟通与协作问题的流程和方法。

DevOps的引入能对产品交付、测试、功能开发和维护起到意义深远的影响。在缺乏DevOps能力的组织中，开发与运营之间存在着信息“鸿沟”──例如运营人员要求更好的可靠性和安全性，开发人员则希望基础设施响应更快，而业务用户的需求则是更快地将更多的特性发布给最终用户使用。这种信息鸿沟就是最常出问题的地方。

云计算技术的发展与局限性

　　按照IDC的研究，年之前是虚拟化技术发展的第一阶段，称之为虚拟化1.0，从年到年时虚拟化发展的第二阶段，称之为虚拟化2.0，目前已经进入虚拟化2.5阶段，虚拟化3.0阶段在不久也将会到来。根据Gartner的预测，目前中国70%的X86企业服务器将实现虚拟化。而高校核心机房的虚拟化发展更是如此，几乎每个高校都在利用虚拟化部署应用系统，每个高校部署了私有云。

　　CPU的虚拟化技术将计算能力作为资源，VxLAN技术将网络作为资源，而各种分布式文件系统则将存储作为资源。以上几种资源都可以通过私有云来进行自助申请、使用以及归还。

　　目前IaaS在高校云计算中得到了实现和部署，信息化部门可以使用商业虚拟化软件管理各类虚拟化资源，并允许用户自助申请。但IaaS的可分配的资源粒度限定于虚拟机，还未能细化到服务。PaaS技术则更加侧重于某个开发平台所用组件为服务，譬如数据库作为服务，或者一整套开发环境作为服务，这种模式强调的是服务的可重用性，高校信息化的多样性决定了这种模式在高校中的局限性。SaaS是更高端的服务模式，所以云计算的发展给高校带来的最主要的服务模式的变更在于IaaS，这只是原先主机交付与虚拟机交付的差别，还未升级到对软件交付模式进行改进的高层次变更。

高校云计算环境下的DevOps实践

　　为了改进高校软件交付的模式，我们在近两年的软件系统建设中，优先采用DevOps模式，校内项目负责人员、运维人员和第三方软件开发商人员进行了对接，组建新形式的项目组，共同参与项目建设。双方职责因分工不同而侧重点不同。在项目建设中引入了敏捷开发方法，并且要求产品多次交付，具体措施有：

　　使用敏捷或其他软件开发过程与方法；

　　校方要求产品分阶段多次交付，提高产品交付的速率；

　　完善虚拟化和云计算基础设施，保障产品开发运行环境；

　　数据中心拥有自动化技术和配置管理工具。

　　有了这几项措施，DevOps增进了开发团队与运营团队之间的协作性、高效性的关系。由于团队间协作关系的改善，整个组织的效率因此得到提升，伴随频繁变化而来的生产环境的风险也能得到降低，并且降低了软件产品开发失败的风险。图2为DevOps的生命周期路线。

为了正确使用DevOps模式，在软件架构中，引入了微服务，并根据基于业务进行拆分、采用自动化文化、去中心化、服务独立部署、服务完全自治、隔离失败、渐进式拆分、避免大规模改造原有代码等原则对业务进行拆分。

　　结合我们具体的实践，现总结一下在实践DevOps模式时需要执行的步骤。

　　1.操作系统的限定

　　目前常用的服务器操作系统有WindowsServer和Linux，而软件普遍采用B/S架构，因此对于操作系统的需求，主要是为了能够运行Web服务器，考虑到目前常用Web服务器有微软的IIS，Apache 　　2.数据库的限定

　　现有编程语言，都有成熟的数据持久化工具，而数据持久化工具对于数据库是透明的，它依赖于数据驱动程序，允许用户比较容易的在多种数据库软件中迁移和部署，因此数据库可由校方自主选择决定。比较常见的数据库有Oracle、MicrosoftSQLServer和MySQL。其中Oracle基本是采取独立于软件部署服务器的方式提供，MicrosoftSQLServer和MySQL因为是轻量级的数据库服务系统，可以视软件系统的复杂性决定是否与软件部署在相同的服务器中。

　　操作系统和数据库的决定，为我们准备虚拟机模板提供了依据。在DevOps实践中，我们根据上面几个选项，分别构建了WindowsServer+MicrosoftSQLServer和CentOS+MySQL的模板，并让开发方实现知情未来的生产环境，开发方在需求调研阶段依然获知未来的运行环境，有针对性的开发，提高了后续产品的稳定性。

　　3.Web服务器的选择

　　对于Java类开发语言，对Web服务器的依赖性不强，反而是需要成熟的容器，如Tomcat、Glassfish、WebLogicServer等容器。这一方面的选择根据操作系统以及Java平台架构限定。若是轻量级的应用，可以选用Tomcat容器，也可以根据开发方的熟悉程度由开发方选择，但基本可以限定在Linux操作系统。

　　对于.Net平台下的Web应用，其Web服务器必然选择IIS，其对应的操作系统亦为WindowsServer。由于Web服务器都是以软件包的形式存在，其均可以通过命令行方式安装，因此该项没有做进虚拟机模板，而是根据实际情况实时安装。

　　4.建立统一的日志规范规范

　　整个系统而非微服务的日志体系，采用标准的日志格式非常便于后续的日志聚合检索，便于整体的视角分析、监控、查看系统；一旦系统出现问题，运维可以提供详实的日志给开发方，便于问题的查找和解决。鉴于不同的服务器操作系统有不同的日志系统，因为对于虚拟机准备中没有特殊要求。但也可以单独准备rsyslog服务器，用于接收从Linux服务器发过来的日志。

　　5.选择成熟框架

　　在DevOps中，重复使用某个模块是该模式的基础。必须避免自己重复发明轮子，尽量选择市面上成熟的开源技术框架进行支撑，比如SpringBoot、SpringCloud、Netflix、WildFlySwarm、Docker、Kubernetes、Bootstrap、CAS等框架；只有如此，才能减少DevOps组的技术负责度，降低运维人员的技术要求。由于使用组件的重复性，运维和开发人员均可以充分熟悉所用组件框架，从而快速发现问题、解决问题。

　　有了以上的要求，我们还需要建设代码共享库，问题列表库、文档知识库等DevOps所必须的支撑，而这些支撑是通过云计算的方式来提供。尤其是新的应用系统建设时，DevOps中的运维人员，即校方运维人员，可以以同样的架构应用于新的应用系统建设。

　　由此我们可以总结出如图3所示的云计算下的DevOps开发模式拓扑图。

在该拓扑结构下，原有私有云运维团队中，需要提升部分工作人员向业务层发展，并控制代码库、知识库和问题库的部署和基本运维管理。在新建项目时，私有云运维团队需要根据项目需要，分配生产环境、测试环境和开发环境给项目组，从而允许项目多次部署、多次交付。

　　在云计算环境下的DevOps要求云计算运维人员不仅是云基础架构管理员，还需要参与到项目组中，了解项目基本信息，因此对于云计算相关人员的定位提出了更明晰的要求。引入DevOps机制，可以保障软件项目的有序推荐，保障软件项目的质量。（作者单位为上海海事大学）

鍖椾含鏈€姝ｈ娌荤枟鐧界櫆椋庡尰闄?
鍖椾含娌荤枟鐧界櫆椋庣殑璐圭敤

转载请注明原文网址：http://www.gzdatangtv.com/bbqb/2678.html