汽车行业的容器云化项目方案.docx

? ? ? ? ? ? ? 汽车行业的容器云化项目方案 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  目 录 TOC \o 1-3 \h \z \u 汽车行业的容器云化项目方案 1 1.整体实践历程 3 1.1 架构重定义 3 1.2 DevOps及流水线落地 5 2.容器云整体架构 7 3.容器云关键组件注意点 9 3.1 Master及高可用 10 3.4 网络 12 3.5 日志 12 4 最佳实践 12  1.整体实践历程 1.1 架构重定义 我司早期使用巨石架构和瀑布模型进行应用构建，以应对建设之初的稳态业务需求。随着我司的发展，业务变得愈发敏捷和灵活。应对敏态需求，我司开发团队在架构上逐步采用TOGAF(即The Open Group Architecture Framework)价值链相关方法论进行业务解构，将传统汽车整车厂长业务链业务逐步切分为短业务模块。 所谓TOGAF，其基础是参考美国国防部的信息管理技术架构(TAFIM，即Technical Architecture for Information Management)。其通过一套不断迭代的过程模型，支持企业的最佳实践，并且使企业或组织据此可以设计、评估、并建立组织的正确架构。TOGAF的关键是使用一个有效可靠的架构开发方法（ADM，Architecture Development Method）来发展能够满足商务需求的企业架构。 我司做了第一件事，就是架构重定义。通过架构重定义，明确业务需求的真实方向。对于开发人员而言，往往只知道根据业务需求进行系统实现，但对于这个需求的初衷、所要达到的目标却未必清楚。当一个需求被提出，如果不明确目标和范围、以及相关利益相关者的诉求，在具体落地时就可能南辕北辙。 我们通过价值链区分了基本业务、管理业务和运营业务。比如4S店针对潜在客户的售前营销活动就属于基本业务，4S店用来预测本月销量的管理预测报表就属于管理业务，4S店维修技师为了了解维修案例所查询的维修案例知识库就属于运营业务。通过业务和受众的不同进行泳道聚合，并最终通过四色模型和U/C矩阵聚合成系统。 接下来，我们做了不同开发团队技术堆栈的对齐。降低运营成本。我司目前使用Java为主的开发堆栈。具体堆栈主要用于支撑无状态应用服务为主，包括HTML5、Angular及Primeng等前端主流框架及配套自定义开发组件。在后端服务层上，主要以Spring为主，配合Jersey等MVC实现及相关自开发组件。 从技术堆栈上看，我司已经实现了无状态应用。但随着业务的模块化和微服务化，逐步开始呈现出如下的特点： （微）服务化 API接口 多种开发语言 多种数据库技术 异步式消息接口 云平台 大数据平台 移动应用 随着企业架构复杂度提高，各类应用部署和维护将随着架构复杂度的提高变得愈发复杂，由于生产变更而导致的准备和维护各种架构环境将花费大量时间，管理成本不断提高。对运维人员而言，伴随着高速的系统迭代，遗留系统升级和迁移将变为异常困难，维护总是需要小心翼翼的实施并反复验证确认。 因此，随着Docker的出现，标准化镜像和容器实例的无状态化正好解决了如上问题。通过“固化小集装箱”的构建和部署，使得运维人员只需要关注应用最小运行单元，而非可运行单元之下的细枝末节。 1.2 DevOps及流水线落地 DevOps联合了开发阶段和部署阶段，从项目计划、项目开发、项目构建、项目测试到运维发布、部署，以及运营、监控，形成一个循环环路。对我司而言，DevOps转型主要经历了三个阶段： 起步阶段：成本控制阶段：在这个阶段偏重控制项目风险，以进度控制为项目管理的首要目标。但漫长的项目或产品周期，使其无法及时获得用户反馈。大而全虽然感高大上，但无法保证所有功能的价值，一旦在UAT中发现问题，很大概率出现返工，往往导致用户不能及时获得自己真正想要的功能。在这个阶段，项目的内建质量通过SIT、UAT等人工测试手段以及上线期间的验证手段保证，上线往往需要半天至好几天的时间，其效率是较低的。 演进阶段：此时，我司通过文档标准化成熟度有所提升，通过了诸如CMMIIII等诸多认证。业务需求在BA、开发和测试之间以标准格式文档传递。在开发工具链上，通过CI工具完成自动化打包、QA部署工作，并通过部分自动化工具完成了某些场景的自动化测试，提高了SIT测试的效率。但与此同时在这个阶段，团队之间缺乏沟通，或多或少存在理解不一致问题。对于测试而言只到某个阶段才进入反馈问题。整理回归成本高。运维工单式操作存在等待浪费，手工操作且对应用的熟悉程度不高。 成熟阶段：这个阶段项目交付团队已经有一定成熟度，可以自行进行受控的开发、