VisionStack-3.2.0版本研发历程




版本历史回顾

罗马不是一天建成的,VisionStack-3.2.0版本也不是一触而就的,在此之前还经历了2.1.x~3.0.x~3.1.0这几个版本的迭代过程,为啥要写3.2.0版本的研发历程呢?我以为是这个版本真正接近完善,精心打磨出来的一个简单易用、稳定可靠的私有云产品。因此接下来描述的新功能、重构等也包含了前几个版本的开发内容,也不做一一区分说明了。

一个好汉三个帮,VisionStack-3.2.0的完成是云容研发、产品、交互视觉团队及客户共同努力的成果。

VisionStack第一个版本的控制台是通过对原生horizon进行简单的面板修改产生的,属于实验性质,就不再详细描述,我们先看下最早2.x的产品界面:

 

再看下3.1.0版本之前的产品控制台界面:

前两个大版本控制台存在的问题:

  1. UI美观度不高
  2. 人机交互体验不够好
  3. 操作流畅度较差
  4. 排版布局比较乱
  5. 切换页面有空白过渡页
  6. 关键操作、功能限制等提示信息匮乏

最后看下3.2.0的产品界面:

可以看出每个版本界面在美观度方面我们都有很大的进步,但更多的改进是在用户体验方面(页面排版布局、操作流畅度、页面卡顿情况、人机交互流程等),可以说3.2.0版本有了质的提升。查询类操作在3.2.0之前都超过秒级,而3.2.0则绝大部分都在500ms以内,另外之前的版本一旦点击导航菜单切换页面,就会全面刷新整个浏览器页面,有很长的空白过渡页,新版本采用fullpage方案,除非手工按刷新按钮否则全部采用局部刷新,再也没有难看的空白过渡页,此外还新增了大量提示信息,支持全部页面的导出excel功能,大部分列表项目的模糊搜索功能,以及列表页自定义展示信息条数等用户友好功能。

技术演进过程

产品界面只是研发内容的冰山一角,更多的内功是在后台服务的重构更新方面,简单列一下近一年来我们重构或新增的功能(未区分时间先后):

  • 云主机:
    • 前端去掉了不符合用户习惯的卡片式列表模式
    • 列表项增加了挂载云硬盘图标、虚拟IP、限速信息展示
    • 重构在线扩容功能,支持扩容超过8核16G规格
    • 支持cloud-init/cloudbase-init执行云主机初始化
    • 新增支持win10、win server 2016版本镜像,Centos、Ubuntu等多个Linux发行版的多个版本镜像
    • 重构备份功能,并支持了在线备份,磁盘限速、网络限速功能
    • 新增重装系统功能,软重启功能,在线快照,创建过程支持设置密码(win系统)、设置安全组、配置公有私有2个网络、防误操作、可创建台数提示等
    • 重构云主机详情页,增加安全组、负载均衡、虚拟IP、伸缩组等信息
  • 容量计算
  • 防误操作
  • 监控系统
    • 进行了大的后端重构
    • 支持了磁盘使用量、使用率、IOPS、BPS监控
    • 支持了云硬盘的监控
    • 增强了对Windows系统的监控支持
  • 计费系统
    • 重构整个计费服务(移除对nova代码侵入改动,支持账单周期、审计功能等)
    • 支持云硬盘计费
    • 支持租户费用概览、详单功能
  • 项目和用户管理
    • 增加角色,支持4种等级:超级管理员、系统管理员、项目管理员、普通用户
    • 权限功能重构,配合角色等级可精细化控制每个页面每个按钮是否可用
    • 支持了用户组功能
    • 配额增强,新增支持系统盘(后台实现方案重构)、云硬盘容量及数量(按类型)、云硬盘快照数量(按类型)、伸缩组数量、安全组数量、安全组规则数量的配额管理
  • 镜像管理
    • 支持了镜像的禁用启用
    • 支持了操作系统和发行版版本设置
    • 支持了上传镜像进度条展示
    • 支持了镜像实际大小和虚拟大小(防止用自定义镜像创建云主机时选择小于镜像虚拟大小的系统盘规格导致创建失败)
    • 限制使用Ceph存储后端时只能上传raw格式镜像
  • 物理机和可用域管理
    • 可用域更名逻辑增强
    • 默认可用域显示逻辑增强(没有物理机在默认可用域时不显示,并且不能把其他可用域的物理机移动到默认可用域)
    • 物理机在可用域之间移动逻辑增强
    • 可用域和项目绑定逻辑增强(多对多映射关系)
  • 云硬盘
    • 支持云硬盘功能(适配Ceph、LVM、SAN后端)
    • 支持多种云硬盘类型(容量型、性能型、混合型)
    • 支持后端容量不足提示
    • 支持只读、读写模式
    • 支持云硬盘快照
    • xsky的ceph支持multiattach,官方开源版本不支持,所以我们没做multiattach
  • 云网络
    • 虚拟IP(port-update –allowed-address-pair)
    • 安全组:基于openvswitch原生安全组功能实现,未使用Linux bridge+iptables方案
    • 简化了网络管理的操作流程
  • 概览页
    • 完全重构,平台管理员概览页增加了平台资源总览、项目云主机用量概览、平台资源使用量、回收站资源信息、近期告警信息等内容
  • 移动客户端
    • Android版本已经开发完毕,IOS版本正在开发(重构版本采用跨平台方案)
    • 支持告警信息推送、资源使用量概览、监控图表查看等
  • 云主机弹性伸缩
    • 基于OpenStack senlin项目开发而来,并进行了定制化增强
    • 支持告警伸缩、定时伸缩功能
    • 具有伸缩组、伸缩规则、伸缩配置管理功能
    • 伸缩动作触发后通知用户功能正在开发中
  • 云负载均衡
    • 基于neutron-lbaas-agent开发,支持TCP、HTTP、HTTPS三种协议
    • 支持负载均衡后端的健康检查功能
    • 高可用功能正在调研中
  • 操作日志及平台日志
    • 补全了绝大部分操作的日志记录,如用户登录、修改权限、云主机创建、安全组创建、网络创建、各种资源的删除修改等
    • 平台日志重构,去掉了用户不关心的平台错误日志记录,改为在平台巡检中提示用户平台服务产生的错误日志条数
  • 设置页
    • 支持云主机资源(cpu、内存、系统盘)、云硬盘资源(按类型的容量)的复用比例设置功能
    • 支持自定义logo功能,可替换包括favicon在内的VisionStack控制台内所有logo相关资源
  • 平台巡检
    • 重构整个后端服务,实现功能高可用
    • 支持所有平台服务的状态、进程存活、端口连通性、物理机连通性等方面的巡检
    • 支持立即巡检、定期巡检功能,定期巡检支持按小时、天、周设置周期,并且巡检结果可通知到用户
  • 告警系统
    • 重构整个后端服务,实现功能高可用
    • 支持云主机、物理机的各个监控维度的阈值告警,细粒度支持单个cpu核级别的阈值告警
    • 支持通道沉默时间、连续告警次数设置功能
    • 支持短信、邮件告警,支持控制台告警提示
  • 平台运行报表
    • 整体平台资源情况概览
    • 资源使用量TopN用户/项目
    • 物理机、云主机利用率TopN节点
    • 平台/项目告警次数概览
    • 租户操作次数概览
    • 定期邮件发送报表
    • 功能增加中,预计增加更多平台使用优化建议类信息
  • 管理员全局视图模式
    • 全局模式不区分项目,可统一查看所有项目的资源
    • 全局模式不可执行创建、删除、修改等操作,属于只读模式
  • 激活码功能
    • 支持序列号、激活码功能
    • 支持控制节点数量、有效期等属性
  • 多区域
    • 支持了多区域(Region)功能,一个控制台管理多个机房
  • 业务监控
    • 支持HTTP/S、FTP、TCP、UDP、DNS、PING、SMTP、POP3等协议的监控
    • HTTP/S支持GET、HEAD、POST请求,告警规则支持错误码和响应时间监控
    • DNS支持A、NS、CNAME请求
    • 其他告警规则支持响应时间监控
  • 通知对象
    • 支持管理通知联系人,可添加手机号、邮箱并支持验证码
    • 全局共用通知对象,可在所有需要通知用户的页面选择通知对象

后台服务重构及新增情况:

  • friedrice
    • 类似计算节点外挂服务,对外提供HTTP RestFul API,可用来设置云主机的磁盘、网络限速(QoS),以及获取各种文件信息
  • hearkener
    • 消息队列监听服务,收集到资源操作通知后做出对应的操作,如记录操作日志,调用回调服务等
  • sqlants
    • 数据库中间件服务,对外提供HTTP RestFul API,用来操作vscloud关系数据库(VisionStack新增数据库),为所有自研项目提供数据库交互操作接口
    • 对外接口支持基于用户token的认证
  • turtle
    • 定时任务服务框架,基于apscheduler开发,集合了云主机物理机阈值告警、云主机告警伸缩、云主机定时伸缩、各种信息如后端存储空间等的定期上报、平台巡检、云主机定时备份、平台周期报表、业务监控、云主机物理机监控数据上报
    • 通过数据库表管理定时任务,使用数据库记录与前端进行任务交互
  • qemu-guest-agent
    • 进行了较多的二次开发,加入了多个维度的云主机监控数据获取接口,配合监控数据上报实现秒级实时监控和分钟级监控数据上报
    • Windows和Linux都有涉及
部署架构图

后端服务已经做到全部高可用化部署(nova-compute等不支持高可用的服务除外)。

前端技术演进

原生horizon的体验较差,尤其是查询类操作响应时间比较长,因此我们2.X版本使用了数据库触发器同步OpenStack原始数据库信息到vscloud相关表,并通过中间件进行信息的查询和聚合,改造了horizon的查询接口(从调用OpenStack各服务的API改为调用查询中间件服务API),极大的减少了页面列表的响应时间,但该版本仍然是Django框架,所有页面都有后台horizon渲染后返回给浏览器,还有部分css、js、html的逻辑不合理,代码复用比低等问题,另外一些问题也在文章前面章节有所表述。

在3.X版本我们采用了流行的fullpage模式,配合前后端分离框架,做到了所有页面的框架代码一次性加载完毕,子页面跳转不需要经过整个页面的加载过程,大大提高了用户体验,同时我们还做了一次整体的UI改版,很好的提升了控制台的美观度。

3.X版本我们使用的前端工具链vue.js+elementUI+webpack,打包后放到Apache服务器上。

如何保证平滑演进?

从2.X到3.X版本前端改动虽然很大,但只要正常升级即可,对用户已经使用的功能不受影响。但后端服务在演进过程中就要考虑平滑过渡问题,不能导致升级后以前的功能或者数据受到影响。

后端服务重构,主要是把之前一下crontab的定时任务脚本改造成定时任务服务的一部分,另外去掉了监控服务对collectd的依赖,把所有服务都采用rpm包进行管理维护,以便于部署更新。相关的数据库表在重构服务过程中,要优先考虑数据迁移问题,保证老数据不丢失。

研发流程与项目管理

研发流程采用敏捷迭代开发,每个迭代周期在2周到1个月左右,一个完整的迭代包括需求确认、需求分析、功能模块设计、代码开发、代码review(所有代码必须经过review方可merge)、开发环境更新、测试、版本发布、集成测试这几个阶段。

版本分为内部版本和外部版本,一般通过版本是否存在影响用户使用的功能缺失或严重bug来进行区分。

代码使用分支或tag来标记版本。内部版本使用tag,外部版本使用branch,一般新版本发现或修复的严重bug要backport到比较临近的几个外部版本的分支上,正常情况下都是通过给用户更新到最新的外部版本来解决新发现的bug。

项目管理采用站会+周例会模式,并经常不定期的举行头脑风暴,进行需求的分析、原型的讨论、UI的确认、功能模块方案的交流等。所有的功能实现方案、UI等都需要有文档记录。

团队能力提升

  • 疑难问题处理能力:不定期进行问题定位分享会,交流问题定位心得和工具等
  • 方案设计能力:所有需求分析、实现方案都有文档放到wiki服务器(并经过review),供所有研发同事查看
  • 工作氛围改变:解决问题的信心、功能设计的实力、能力提升的成就感等大大改善了工作氛围
  • 开源社区贡献
  • 团队组建及人才梯队培养:保证一个方向至少有2个开发人员比较熟悉,并尽量交叉分配到各个项目或功能模块,增强模块设计的全局观
  • 新员工学习计划:为每个新入职员工定制学习计划,指定导师,方便快速上手

运维及交付流程

  • deploy_tools:安装部署工具,实现一键安装部署,支持指定版本号和节点类型
  • upgrade_tools:版本升级工具,实现一键升级,支持指定节点类型,支持指定原版本号和目标版本号,可自动更新两个版本间的数据库表结构变动

测试自动化

  • 半自动化测试环境更新:目前是一键执行更新脚本即可完成测试环境的更新,可稍作改进后做到定期自动化更新
  • yr_automated_testing:基于selenium的web自动化测试工具,正在逐步完善,用excel保存测试用例名称、元素类型、位置、执行的操作、等待时间、结果校验值等,代码量极少,可每天自动进行web测试,并将测试结果邮件通知到研发测试人员
  • 使用tempest进行后端API接口测试

后续目标

  • 计算节点安装部署web化
  • 用户业务部署自动化(DevOps)
  • SDN(overlay网络)
  • 负载均衡高可用
  • 云主机高可用
  • 持续集成(静态代码检查、集成测试等)
  • 项目管理能力提升
  • 研发人员技能提升
  • 开源社区贡献
  • ……