DevOps和微服务,是目前开发运维领域最火的方向之一。作为传统企业,习惯了传统三层架构、瀑布开发模型、按照CMMI要求按部就班的做开发,如何迈出走向DevOps开发模式和微服务架构落地的第一步,一直是一个难题。本次分享基于一个传统企业项目案例,描述传统企业中的一个试点团队,如何按照DevOps和微服务的要求,调整组织架构、开发方式、开发运维管理和流程,从最初的迷茫和混乱,最终摸索形成了一套自己的DevOps体系和微服务设计开发方式,并取得初步成效的过程。涉及:DevOps和微服务结合场景下的组织架构设计、DevOps流程体系设计和工具落地、微服务设计思路和领域建模、微服务架构选型、分布式事务处理、服务治理等。

注脚

展开查看详情

1.传统企业DevOps+微服务从0到1 BoCloud博云/赵安全

2.

3.

4. 目录 Part 01 背景介绍和整体思路 Part 02 DevOps落地实践 Part 03 微服务落地实践

5. 项目背景 困境:业务总规模200多页面,外购件多,需求变更频繁,版 用 选择 本上线太慢,面向客户规模约200万 试点应 预计难于应对未来突发大流量需求。 最终目标 30% u  业务重构,能快速响应需求,上 使用开发测试大组织结构,组 组织 织内切分容易,愿意为微服务 线应用,能适应突发访问流量。 流程 调整,传统研发规范齐全 10% u  构建DevOps和微服务体系和技术 现 技术 平台 只是了解一些微服务知识, 架构 无任何试点和开发积累 状 20% 诉求 平台 u  构建DevOps体系规范并工具落地 手工、少量工具 和 工具 u  构建微服务设计理念并具体落地 0% 准 业务微服务拆分和微服务技术框 工程 无DevOps理念,无模型设计方法 架; 备 方法 度

6. 项目背景-初始人员构成 u 10+年的架构师/开发经理/资深开发:6个 u 3-10年的开发人员:8个 u 0-3年的开发:10个 u 测试人员:6个 习惯的开发模式:瀑布模型 习惯的应用架构:传统单体架构 “你们来了之后,我们既不会设计了,也不懂流程了”

7. 实施步骤与工作思路 全员宣讲 试点应用 技术框架 试点应用 试点应用 统一思想 设计 确定 开发测试 部署 试点 模块 DevOps和微服 Demo和POC测 务流程和规范 DevOpg工具链搭 规范和总结文档 建,中间件集成 试 输出 适配 全业务微服务 全业务的各微服 全业务集成测 地图设计 务分别开发 试,部署上线 全业务开发、 上线

8. 总体思路 组织 工程 流程 方法 DevOps+领域驱动设计 技术 微服务 架构 平台 20+工具支撑 工具 (Jira+Gitlab+Kubernetes+Docker+SpringCloud)

9. 目录 Part 01 背景介绍和整体思路 Part 02 DevOps落地实践 Part 03 微服务落地实践

10.DevOps 微服务 DevOps落地整体思路 流程&规范 组织&角色 工具

11.DevOps 微服务 DevOps-组织架构调整 试点领导 开发 测试 主管 主管 微服务小组1 开发+应用运维+测试 总 体 架 微服务小组2 业务需 产品 开发+应用运维+测试 构 求方 经理 团 队 开发+应用运维+测试 微服务小组3 身在心在汉之-周五转测试 身在曹营心在汉之-跨组织协调

12.DevOps 微服务 DevOps流程设计-敏捷+持续交付 DevOps 整体流程框架 概念 迭代0 开发 生命周期 需求分析 迭代启动 评审 产品立项 整体过程框架 评审 工程活动 需求收集和分析 迭代1 u 特殊的迭代0:第1个版本-考虑架构设 系统总体架构 产品Backlog 设计 工作件 (Story验收用 例) 计,业务要求,团队磨合的难度,周 系统总体架构 迭代2 子过程 产品立项报告 迭代3 实践 迭代n 期2个月(最小可用版本) u 后续版本:两周一个迭代 1.需求分析 2.应用设计 3.开发 4.测试 5.发布 6.运维 7.迭代回顾 u 有流程,好落地 单次迭代开发交付过程 迭代需求列表 系统原型 测试报告 版本发布 u 形式引导思维 评审 每日站会 持续集成 可视化管理 持续部署

13. DevOps 微服务 DevOps-部分规范示例 需求 应用 持续 生产 回顾 产品立项 开发 测试 分析 设计 发布 运维 阶段 《软件质量标准》 《产品立项制度》 《微服务业务设计指南》 《缺陷管理规范》 《版本发布规范》 《 迭代计划会议指南》 《数据库设计规范》 《测试指南》 《 迭代评审会议指南》 《构建部署规范》 《Git 分支管理规范》 《 敏捷开发过程指南》 《配置管理规范》 《微服务开发规范》 《代码评审指南》 《敏捷需求分解规范》 《迭代回顾会议指南》 … 《迭代估算指南》 《用户故事指南》 《需求开发指南》 13!

14.DevOps 微服务 DevOps工具落地全景图 发布 持续集成 测试 上线运维 代码 检查 集成环 生产环 境部署 境灰度 是测试 UAT环 发布 开发环 单元 构建镜 需求 设计 编码 测试 像 境部署 境部署 测试 测试 镜 性能测试 镜 镜 生产环 像 环境部署 像 像 境全量 编译 打包 流 … 测试 流 同 上线 转 转 步 构件 支 需求管理 计划管理 风险管理 单元测试 自动化测试 持续集成管理 代码扫描 镜像扫描 撑 (禅道/Jira) (禅道/Jira) (禅道/Jira) (JUnit) selenium (Jenkins) (Sonar) (Clair) 工 微服务框架: Spring Cloud 具 应用实例管理 自动部署服务 多环境管理 用户权限管理 代码仓库管理 缺陷管理 性能测试 日志监控 (容器云平 (容器云平 (容器云平 (Ldap) (Gitlab/SVN) (禅道/Jira) (JMeter) (ELK) 台) 台) 台)

15.DevOps-持续交付过程示例

16.DevOps 微服务 DevOps-代码分支和Pipeline触发关系 v0.1 v0.2 v1.0 Master Test Lead Pipeline 4 Commit Hotfix Release Dev Lead Pipeline 3 Commit Develop Pipeline 2 Feature Pipeline 1 Commit Commit 分支分为Develop、 Test和Release分支, 将开发、 测 Dev 试和发布进行空间上隔离。规范与工具集成,保证落地。 Dev Lead Pipeline 频率 触发点 目的 涉及项目 1 日常 独立开发人员Push 到Feature 分支 功能测试 代码检测,代码规范 2 适中 开发组长Merge 到Develop 分支 Dev集成测试 代码检测,代码规范,代码评审,等 3 不频繁 开发组长commit 到Release 分支 (测试通 UAT环境测试 代码检测,代码规范,代码评审,自动化测试,手工测试等 过) 4 不频繁 开发组长commit 到Master 分支 (测试通过) 预生产环境测 代码检测,代码规范,代码评审,自动化测试,手工测试,压力测试等 试

17. 目录 Part 01 背景介绍和整体思路 Part 02 DevOps落地实践 Part 03 微服务落地实践

18.DevOps 微服务 微服务拆分的核心需求 u  高内聚,低耦合:尽可能的减少微服务间的调用,尽可能的减少分 布式事务 u  微服务应该足够小,能够分配一个团队(5人左右)去实现,但也不 能过细

19.DevOps 微服务 微服务拆分的指导方法—领域驱动设计 使用场景: u  针对复杂业务软件 u  增强可扩展性,应对需求变化 u  对设计和开发人员要求高 核心: u 强调业务领域与系统设计的匹配 u 领域对象和设计复用

20.DevOps 微服务 整体思路-先业务分解,再领域建模 战略设计 战术实施 业务目标梳 业务场景梳 限界上下文 产品定位 流程梳理 领域建模 分层设计 理 理 (微服务)

21.DevOps 微服务 战略设计-整体思路 电梯演讲: ! 目标用户 微服务拆分,业务理解和 ! 用户需要 ! 产品名称 梳理非常关键 ! 通过分析用户工作中的痛点 )深度参与 ! 产品类型 领 域专家 ! 关键优点 和需求来找到需要提供的服 业务人员( ! 主要竞品 关键: ! 主要不同 务/业务(问题域/子领域) 业务目标梳 业务场景梳 产品定位 流程梳理 理 理 细化的流程 梳理

22.DevOps 微服务 战略设计举例-业务目标梳理 产品定位:管理层希望建设一个针对内部员工的培训系统,以提升员工技能。该 系统需要提供完成培训、考试、评级等功能 子领域 目标用户 服务 考试 识别核心用户 管理层 在线培训 识别核心域 线下 内部员工 线下培训 在线 培训 培训老师 培训 考试 管理员 评级 评级 … 用版 本 找到最小可

23.DevOps 微服务 战略设计-场景梳理方法 u 选定一块子领域 u 参与者针对所选定的问 u  对发散所得的服务场景进 行整理,得到场景分类 题域,发散思考各个服 务场景 重复的场景即潜 在的基础服务

24.DevOps 微服务 流程梳理和领域建模示例 申请 已被移交 申请 已被驳回 审批提醒 申请 通知 已送达领导 已提交 已关闭 待审批 申请已提 审批提醒 申请单 已创建 申请单 交 已提交 已送达领导 申请已查 信息已查 阅 申请 申请已被 已被审批 通知已关 审批结果 信息 申请单 实体 审批 闭 (流程节点) 待审批 已通知 申请单 (聚合 已查阅 已超时 根) 申请 申请已超 已超时 申请 申请 审批结果已 时 已被审批 已被驳回 通知 值对象 领域建模-聚合 流程梳理

25.DevOps 微服务 限界上下文设计示例 xx xx xxx xx D D xx U 设计依据: xx xx U D XX上下文 xx xx xx D D xx上下文 xx xx u  子领域 U U xx xx U u  聚合之间的关系 xx 审批 D 对象(人) 审批 XX上下文 申请单 U D xx 流程 流程实例评估 U D 发布对象 流程实例 上下文 U 员工信息管理上 U 业务系统 U 下文 流程实例完成通 D D 催办 知 D 员工信息 U OA D xxx上下文 U 流程通用信息 流程

26.DevOps 微服务 确定微服务拆分-围绕限界上下文调整 设计因素1:围绕限界上下文边界 u 理想情况下限界上下文与微服务为1:1 u 微服务拆分的底线是不能打破聚合,打破聚合会破坏事务一致性和业务约束。 设计因素2:对齐不同业务变化速率/相关度 设计因素3:考虑系统非功能性需求:安全性、伸缩性等 设计因素4:其他设计约束:复杂度、团队结构、技术异构

27.DevOps 微服务 应对需求变更 需求 需求 需求 业务场景梳 限界上下文 理 流程梳理 领域建模 (微服务) 程序设计和开发

28.DevOps 微服务 经验分享-分布式事务处理 都存在 可靠消息最终一致性方案 强一致性方案-TCC 主动方应用 1.发送消息 预发送消息 状态未待确认 3.返回消息存 消息中间件 6.投递消息 被动方应用 储结果 业务操作 4.发送业务处 理结果 5.根据业务处 理结果处理 2.存储消息 消息 消息存储 适用于一致性要求较高,实时性要求不高的业务场景 适用于实时性要求较高的业务场景 被动方开发成本低,业务系统与消息耦合度低 业务层开发代价高

29.DevOps 微服务 经验分享—模拟API u  微服务的开发是有不同的开发小组进行开发,一旦服务消费者需要服务提供者提供的api 延期,服务消费者则无法进行相应的开发工作。 u  当服务消费者需要联调时,服务提供者必须是启动状态并且网络通畅。 u  使用MockMvc实现对http请求的模拟,能够直接使用网络的形式转到controller的调 用,这样可以使得测试速度快,不依赖网络环境,而且提供了一套验证工具,使得请求的 验证统一而且方便。