您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
颠覆传统IT的敏捷开发与云原生技术栈
 
作者:球迷Long
   次浏览      
 2021-11-22
 
编辑推荐:
本文主要讲解了敏捷开发、常规敏捷开发案例与云原生技术栈。
本文来自于微信公众号DevOps,由Linda编辑、推荐。

只看到自己想看到的东西,只做老板安排的任务。这是很多传统IT已经被淘汰还不知如何适应的关键原因之一。要时刻对外面发生了什么保持敏感度。这些年,云原生已在不断蚕食传统IT,一个又一个企业的内部IT员工与传统IT厂商消失在我们的视野里,从研发模式到服务模式都必须做调整。我们今天来谈敏捷开发与云原生技术栈。

一、关于敏捷开发

敏捷开发与其说是严谨的方法体系,不如说是一组行事原则。符合敏捷价值观和原则的开发方法包括:极限编程(XP),Scrum,精益软件开发(Lean Software Development),动态系统开发方法(DSDM),特征驱动开发(Feature Driver Development),水晶开发(Crystal Clear)等等。

所有这些方法都具有以下共同特征:

迭代式开发。即整个开发过程被分为几个迭代周期,每个迭代周期是一个定长或不定长的时间块,每个迭代周期持续的时间一般较短,通常为一到六周。

增量交付。产品是在每个迭代周期结束时被逐步交付使用,而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。

开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时,团队对于用户的需求也能及时提供反馈意见。

持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候集成,有些项目则每天都在这么做。

开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队,是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制,而非把过程和机制强加给人。

二、常规敏捷开发案例

需求评审(参与人员是 客户+产品+UI+开发+测试,也就是所有人员)

主要是产品人员讲解需求,用户需要给出反馈或者提出意见,其他人员可以相应的提出自己的见解。

Story划分(产品+UI+开发)

产品根据UI做出来的原型图给开发人员讲解系统构成和运行,将整个网站按照功能划分成一个个细粒度的story来说明,开发人员(前端和后端)也需要明白自己应该关注那些关键点。

人员划分(leader+开发)

主要是项目小组的leader 根据story划分,给前端和后端开发人员划分story,开发人员根据自己的情况去估算所需时间。

方案设计(数据库设计文档、接口设计文档、方案设计文档)

先根据系统的实际情况去设计DB,包括数据库和表的名字,以及具体的字段。然后设计接口文档,按照页面和功能进行设计,包括具体的请求地址和入参出参。最后是根据接口文档中出现的疑难点去做方案设计文档,对遇到的问题进行分析并拿出至少两种具体的解决方案。

方案评审(所有人员)

对前端和后端给出的方案评审其它人员给出各自的意见,有问题的话下次再次开始。

禅道任务拆分(开发人员)

方案评审通过以后开发人员就需要按照预估的总开发时间去拆分story,可以分成多个小的任务,但是一个任务的时间最好不要超过4个小时。

开发(项目日报+工作日报+进度邮件)

每天实际开发过程中遇到问题可以写成项目日报;每天的任务完成情况写成工作日报;相比较整个系统的进度完成情况需要写进度邮件。

端对端(接口)测试(开发人员)

前端写好了页面,后端完实现了接口,就可以进行端到端的测试,可以远程测试,也可以本地测试。

压力测试+集成测试

系统完成以后需要用Jmeter 进行模拟用户访问,通过设置线程来提高并发量的方式达到一定的效果,测试生成的数据需要总结成测试报告。

Demo

对于复盘来说,这就是最后一个程序了,在前后端大师兄的评审下,主要是前端人员进行系统演示,各个功能是否实现、页面是否达到用户要求、有没有什么需要完善的地方。点评过之后如果有问题那就修改之后再次评审;如果没有问题那就算完成复盘项目了。

三、云原生技术栈

3.1 CNCF landscape

这里主要分成了几个技术板块,技术思维其实没那么复杂,无外乎是用IT在重构服务过程,实现上层应用,对接好下层资源,因此IT本身也即服务:

应用定义及部署(App Definition and Development)

编排与管理(Orchestration & Management)

运行环境(Runtime)

配置(Provisioning)

平台(Platform)

可观测性和分析(Observability and Analysis)

无服务(Serverless)

这几大板块基本把云原生技术所涉及领域都涵括进去了,下面详细介绍下各板块所涉及到的技术栈。从系统层次来看,从上到下分别是:

应用层:应用定义及部署(App Definition and Development)、配置(Provisioning)、可观测性和分析(Observability and Analysis)、无服务(Serverless)

集群:编排与管理(Orchestration & Management)

底层运行环境:运行环境(Runtime)

这个板块的技术栈主要是应用开发过程中都会用到的,像数据库、流式处理和消息队列、应用定义和镜像构建、持续集成和持续部署。

1)应用定义及部署

数据库(Database)

流式处理和消息队列(Streaming and Messaging)

应用定义和镜像构建(App Definition and Image Build)

持续集成与持续部署(Continuous Integration and Continuous Delivery)

2)编排与管理

编排与管理板块可以说是云原生的核心,其包括了容器编排、一致性与服务发现、远程程序调用(RPC)、服务代理、API网关、服务网格。

容器编排与调度(Orchestration and Scheduling)

一致性与服务发现(Coordination and Service Discovery)

远程调用服务(Remote Procedure Call)

服务代理(Service Proxy)

API网关(API Gateway)

服务网格(Service Mesh)

3)运行环境

这里的运行时板块指的就是容器运行环境,包括了容器存储、容器计算、容器网络三大工具,在k8s分别对应的是CSI、CRI和CNI三类接口定义。

云原生存储(Cloud Native Storage)

容器运行时(Container Runtime)

云原生网络(Cloud Native Network)

4)配置

自动化与配置(Automation & Configuration)

容器注册(Container Registry)

安全与合规性(Security & Compliance)

密钥管理(Key Management)

5)平台

从服务到安装到主机到分布管理的各厂家技术分布如图

6)可观测性与分析

从混沌到追踪到日志分析到监控的各厂家技术分布如图

可观测性与分析板块主要包括:

监控(Monitoring)

日志(Logging)

追踪(Tracing)

混沌工程(Chaos Engineering)

7)无服务

Serverless是一个很大的领域,因此针对 serverless 这里专门又细分了五个模块:工具、安全、框架、注册平台和可安装平台。

工具(Tools)

安全(Security)

框架(Framework)

注册平台(Hosted Platfrom)

可安装平台(Installable Platform)

 

   
次浏览       
最新活动计划
LLM大模型应用与项目构建 12-26[特惠]
QT应用开发 11-21[线上]
C++高级编程 11-27[北京]
业务建模&领域驱动设计 11-15[北京]
用户研究与用户建模 11-21[北京]
SysML和EA进行系统设计建模 11-28[北京]
 
最新文章
云原生架构概述
K8S高可用集群架构实现
容器云管理之K8S集群概述
k8s-整体概述和架构
十分钟学会用docker部署微服务
最新课程
云计算、微服务与分布式架构
企业私有云原理与构建
基于Kubernetes的DevOps实践
云平台架构与应用(阿里云)
Docker部署被测系统与自动化框架实践
更多...   
成功案例
北京 云平台与微服务架构设计
通用公司GE Docker原理与实践培训
某军工研究单位 MDA(模型驱动架构)
知名消费金融公司 领域驱动设计
深圳某汽车企业 模型驱动的分析设计
更多...   
 
 
 
 
 
相关文章

云计算的架构
对云计算服务模型
云计算核心技术剖析
了解云计算的漏洞
相关文档

云计算简介
云计算简介与云安全
下一代网络计算--云计算
软浅析云计算
相关课程

云计算原理与应用
云计算应用与开发
CMMI体系与实践
基于CMMI标准的软件质量保证