跳到主要内容
版本:v1.5

3.2 技术架构

概述

SREWorks 运维套件定位为面向全面云原生方向,利用数据化、智能化的思想,解决云原生下的运维问题而生。 该套件中包含两块内容:企业云原生应用管控云原生化运维开发

SREWorks套件自身也是云原生化的应用,并且采用运维中台思想构建,也就是运维的大中台和小前台,在中台里构建大量的PaaS化的运维服务能力,在前台里围绕运维业务场景——“交、监、管、控、营、服”提供SaaS化的运维场景应用

同时在SREWorks中有一套核心理念,内置提供的企业云原生应用管控的系列SaaS应用,也是由SREWorks中的运维开发的能力构建而来,该理念参考自K8s中的核心架构,K8s提供了一套抽象的基于API的资源管控模型,而同时提供的内置如Deployment、StatefulSets、Job等资源模型也是构建在基础的能力之上。分析SREWorks的核心技术架构,关键技术主要体现在如下几点:

  • 云原生应用管理
  • 云原生运维开发
  • 前端开发低代码
  • 系统扩展插件化

云原生应用管理

企业在云原生化转型的道路上,不仅是来自开发对软件产品技术架构的升级,同样对于运维也需要将资源进行云原生化管理的转变。我们将包含基础设施的企业云资源统一抽象到以Kubernetes集群进行管理,企业云应用实例都运行在集群之上,如下图所示,我们可以清晰梳理出顶层抽象模型:管理人员的团队组织、管理应用实例的应用中心、管理资源的集群。
image.png

团队

团队是集群和应用的关联点,是一个扁平化虚拟组织

集群

集群抽象了企业资源管理,包括云服务资源,统一以Kubernetes进行组织

应用

企业应用抽象了企业的业务价值承载,包含大数据,数据库,中间件,业务系统都以应用进行描述

SREWorks里的的核心业务模型也是围绕上面的三大对象:团队、应用、集群。成员都在团队中,团队持有应用和集群相关资源。由于SREWorks自身也是云原生化的,也是部署在Kubernetes集群中,用户在SREWorks中创建团队,一套SREWorks管理套件可以接入1到多个Kubernetes集群,集群归属为团队的资源。在团队的成员可以创建应用,并部署在该团队持有的Kubernetes集群之上。
image.png

云原生运维开发

在运维开发领域,参与的角色一般为运维人员、SRE等,初始团队的运维开发特点为脚本、工具的开发;随着业务规模的增长,简单的工具脚本不够以支撑业务,此时需要引入运维平台或者是运维产品的思路来构建,并沉淀出分层的运维平台体系。
SREWorks旨在解决无论是初始团队,还是成熟业务团队的运维开发问题,用户可以在SREWorks中取到自己在当前阶段所需的能力,低门槛实现运维目标的同时,保障高质量低成本。分析常见运维领域的开发活动,我们可归纳为如下一些方面:脚本、流程/规则、前端、后端、持续集成、产品化以及一些备份恢复相关。

运维应用框架

在SREWorks中打造了一套serverless化理念的云原生运维开发解决方案,也就是运维应用自身也是云原生化的。前端基于基线工程统一托管,后端基于代码打通编译构建部署闭环,用户无需参与,只需关注自身业务逻辑开发。

前端开发低代码

配置化低代码

前端技术的发展日新月异,经历了从前端三剑客(HTML, CSS,JavaScript)、到代表性的Jquery,angularjs时代,前端已经进入了React&Vue&Angular 三大框架统治时代,在运维开发领域的前端开发由于团队属性,始终难于追赶前端流行趋势,同时反观运维开发的属性,大部分页面为企业后端控制台类系统,不太需要很酷炫的交互设计,针对这些特点,我们在SREWorks里创新性地设计了一套Serverless体验的前端开发模式。
image.png

系统扩展插件化

SREWorks 产品中有个核心的思想即“插件化”,在各个核心模块中都有插件化的设计,通过插件化设计将产品的核心扩展功能与SREWorks框架能力解耦,使得用户可以基于插件开发就可以完成SREWorks的能力增强,SREWorks的系统插件扩展点主要有:

运维前端组件开发扩展

在运维前端开发中配置页面组件时,SREWorks内置了一些前端组件,按照分类列表展示。用户也可以按照前端组件开发指南,自定义实现一些基础组件或业务组件。

运维后端脚手架开发扩展

在运维后端开发中,可以新建运维微服务,创建微服务时可以选择初始化脚手架,系统内置了常见的微服务脚手架。用户也可以按照后端脚手架开发指南,自定义实现运维服务脚手架。

应用管理组件扩展

交付场景的应用开发SaaS是围绕云原生应用开发提供一系列功能,在云原生OAM规范中,组成云原生应用的核心模块是组件(Component),组件中包含了具体的应用工作负载(workload),可能是一个微服务类型的Component,也可能是一个Helm类型的Component。 当前系统提供了默认的几类添加组件类型,同时用户也可以按照组件类型扩展自定义开发新的组件类型。