十七年运维老兵万字长文讲透优维低代码~

Posted 优维科技EasyOps

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了十七年运维老兵万字长文讲透优维低代码~相关的知识,希望对你有一定的参考价值。

十七年运维老兵万字长文讲透优维低代码~_封装

点开此文的小伙伴

不知道你有没有看

优维老王说「优维LowCode实践」的视频

十七年运维老兵万字长文讲透优维低代码~_封装_02

十七年运维老兵万字长文讲透优维低代码~_封装_03

共45分钟,分成12个视频片段

没看过没关系

鹿小U将这45分钟的视频内容整理成下面文字

让你系统的了解

优维低代码的整个框架


低代码,是今天比较热的一个词,其实我们都知道低代码今天的热,是有它自己的原因的。

从2015年创业开始,优维前后服务了很多传统企业的项目客户,我们在服务的过程中其实也发现了一些自己的问题,特别是2019年底,有一个KA的客户提出了一个个性化的需求,对我们带来的触动是蛮大的。

当时的背景就是我们有个项目,客户提出了一个个性化的需求,且必须按照客户要求的方式去实现,否则将无法完成项目结项。对于这个事情,我们当时内部研发评估的时候,如果真做了,需要考虑这个功能对其他项目客户的一个破坏性影响。

十七年运维老兵万字长文讲透优维低代码~_封装_04

我们知道在一个产品里面,其实真正的一个功能,它没办法去兼容很多其它场景,如果真要去兼容,你可能要么就是拉代码分支,要么就在产品版本里面去开特定开关,很明显这两种方式对我们服务的大量2B客户来说,都不是最优的解决方案。所以,在2019年底开始,我们就在寻求一些全新的解决方案,那个时候我们找到的就是LowCode的这种低代码模式。

当然优维的低代码模式在发展过程中,其实也经历了我们自己的一些思考,那我今天大概是从六个方面来讲一下优维低代码的整个框架。

1

低代码发展历史

首先我还是想带大家来看一看低代码的整个发展历史,这是我根据自己个人工作经历来总结的。低代码的发展其实是经过以下三个模式的转变:

1.C/S模式

第一个,低代码其实也不是一个所谓的新技术。我2005年毕业后也做过一些应用系统开发,不过那个时候的应用系统是在C/S的模式下面去做的开发。

当时,我们也有用一些代码工具,比如像Delphi,C++Builder等这类工具,来帮助我们快速的去构建应用程序。在那个时候,S的架构很简单,基本就是DB,然后通过数据库连接JDBC,或者是ODBC的模式来构建应用程序。那主要的低代码的框架,其实是聚焦在C端能力的解决,而LowCode的能力,基本上给我们提供了快速表单的构建模式,帮助我们去达到快速开发的效果。

2.B/S模式

后来2007年进入腾讯之后,当时明显感觉C/S架构模式已经不适用面向C端的2C互联网的应用架构,当时采用的是B/S的模式。

在B/S模式的开发过程中,其实当时大家是没怎么讲低代码开发模式的,更多的是讲前端开发框架,讲前端工程化,怎么去统一化封装。那今天重新回归到2C互联网,虽然整个前后端的工程技术越来越标准化,但是在服务2B的过程中,怎样更快的提升工程效能,那新一代LowCode的开发模式就越发重要。

3.LowCode开发模式

LowCode开发模式,其实还是基于B/S模式下,怎么把前后端的软件工程低代码化。

以上,低代码的整个发展历史大概就是这样一个过程。其实,就我自己来看的话,LowCode并不是一个新的技术,也并不是一个全新的软件工程,更不是用来去替代DevOps的。所以,在行业里面有些专家在谈LowCode的时候,我觉得也不能过度的放大这个技术的作用,也不能够去跟不同维度的其他的方面去对比,比如说软件工程,比如说DevOps等等之类,它仅仅是一个技术工具和手段来满足2B和2C各端应用的快速交付需求。

2

优维为什么要做低代码?

看完低代码发展历史后,回归到优维为什么要做低代码,主要有以下几个方面原因:

1.客户需求已经呈现出个性化趋势

我经常举例来讲,每个人都有穿衣服的一些颜色样式的差别,那对一个2B企业来讲更是如此。不同的行业、不同的企业客户,根据他们的IT架构、IT规模、行业属性、业务规模和业务形态的不同,引发出客户需求在上层的一些重要的差别和变化。

2.商业模式考量

这里浅显的谈谈对商业模式的一个理解。中国商业模式主要有项目制、订阅模式、SaaS模式三个类型。这三种模式,它的一些特点其实是不一样的,比如:

  • 项目制,在中国大部分其实基本上还是以项目制为主,特别是像后端的管理类的软件,基本上是以项目制为主。比如我们做DevOps运维,在进入传统企业的过程中,基本是以项目的形式展开的。那在项目进行的过程中,结合上面客户需求的一些变化,这里面就呈现出很多个性化的需求出来。
  • 订阅模式,其实就是类似于像过去Jira,像国外一些软件的销售模式,基本上是按年付费租约的模式去走的标准化产品交付,那种模式它的定制化需求相对来说少很多。
  • SaaS模式,在HR端、人事等领域相对已经比较成熟,但是在我们这类的管理端,特别是涉及到后端的核心系统,SaaS模式的成熟度,普及度还是非常低的。

在中国现在的商业模式里面,或者是在DevOps领域,面向客户的很多个性化的需求,如何去实现快速定制,决定了我们无可避免的要去寻求一个相应的解决方案。

3.产品工程体系拆解

对于产品,我们很难去做一个信息化的定义。以前我们讲做的是一个成熟的商业软件,今天又在讲我们做是一个产品,一个平台,我们今天在上面构建场景微应用等等之类的,它的说法变化非常多,那在产品工程架构上如何实现一个标准化的能力框架,这一点是非常重要的。

我今天没有去跟大家做一个清晰的定义和划分,什么是产品什么是产品工程,我们考虑的是这个能力体系框架,这个工程体系化如何敏捷性的去适应前端的客户业务需求的变化

4.多快好省满足2B客户服务需求

面向客户需求,如何能有一个敏捷适配的能力?

比如说优维公司EasyOps®平台包含九个产品能力,像CMDB、DevOps、自动化运维、监控等等这些产品,那这九个产品体系到真正以我们的服务方式Delivery到客户端的时候,怎么去Match到客户需求,那这一点,我们需要在客户满意度和成本之间找到一个平衡点

当客户提出一个需求,你越快的去实现,就能更快的满足客户。比如客户提了一个需求,两个月实现和两天实现,这个差别是非常大的,同时对成本要素影响也是非常大的,这里我们度量的一个核心点就是效率。那要又快又好的去满足客户需求,效率我觉得是2B服务里面一个关键的底层度量点,这个度量点如果在这个体系里面被突破了,那我觉得就显得相当的重要。

以上这四个方面,决定了优维选择做低代码是一个必然的趋势。通过对商业模式、客户需求、产品工程、客户满意度的整个考虑,希望构建一个标准化的能力架构,从而带来公司整个收益的增长。

3

关于做优维低代码的一些见解

优维在做低代码的时候,我们其实是有一些观点、见解和立场的,这个立场决定了我们自己要在低代码上做一些投入。

  1. 优维低代码一定是和垂直结合,解决自己领域内相关问题。比如优维低代码是不是用来去解决OA的一些问题,这不是我们去考虑的,我们只考虑在DevOps和运维领域里面的问题,其他领域我们是不看了。
  2. 产品和服务要做到应客户需求变,而低代码是一个最有效的手段。
  3. 在2B服务里面,在客户满意度和成本之间找到一个平衡点,其中核心的关键点就是服务效率。如何在软件工程上、交付手段上形成一些突破,从而真正的解决满意度和成本之间的平衡。

4

优维低代码的技术框架

优维低代码的技术框架由三个部分组成,我们称之为“铁三角”

十七年运维老兵万字长文讲透优维低代码~_商业模式_05

第一个部分是前端部分叫VisualBuilder

在上层要构建微应用时,微应用里面肯定会涉及到大量的页面UI的交付,那VisualBuilder就是主要聚焦在UI的能力上,包括页面的一些事件、数据......包括页面可视化的拖拽式操作,全部由VisualBuilder来封装实现。

第二部分是FlowBuilder流构件

flow其实是工作流,这一部分主要就是把API这一层,怎么去实现一个可视化的编排,可视化的构建。

第三部分是BataBuilder

微应用后端可能需要存储一些数据,那这部分会涉及到model,就是数据模型该怎么去可视化构建,数据怎么去可视化存储

5

优维低代码“铁三角”的技术特点

下面我们就一个个来看一下“铁三角”整个的技术特点。

1.VisualBuilder

业界讲的最多的是可视化编排,拖拽式操作,这是VisualBuilder的核心能力,这个能力其实是一种表单式的能力

在VisualBuilder这部分,为了解决表单的快速构建的问题,我们第一步是做了一个构件化库,从原子构件到业务构件,业务构件和原子构件以及他们之间的组合,我们进一步模板化,构成我们单页面的一个能力,再基于整个业务流和场景,我们进一步把Web化的页面进行组合封装,形成一个Theme的主题库,其业务性就更强了,业务场景性更强了。

十七年运维老兵万字长文讲透优维低代码~_商业模式_06

VisualBuilder它解决的就是整个表单复用性的问题,表单一旦复用性被稳定构建了之后,带来的好处就很大。特别是测试方面,大家都知道,如果页面端一改,你整个测试的模式,你都要去进行验证和回归,这个代价其实蛮高的,那一旦被构件化之后,就被四处复用,如果今天只是构件改了一下,那我仅仅就把构件的这块能力进行测试一下,整个页面端的可用性其实大大增强。

2.FlowBuilder

我们知道,低代码需要跟底下各个平台去打交道,那跟能力平台打交道时,我们必须要有一个API网关,我们称之为“统一服务层”。这一层要把底下的很多能力平台的API注册进来,形成一个API的集市。仅仅有这个API集市肯定还不够,因为这个API集市其实就像刚才讲的前端的页面端一样,它比较偏原生的。

因此,我们在“统一服务层”的上面又加了一个“编排层”。这个编排的原理,没什么特别,它其实有点像流程引擎,它就是把不同的API重新再组合。同时,还提供了整个API的自主式的开发注入。我们不再给大家提供源代码这一层的那个模式,就你还在底下写个服务,再把它注册进来,我们不会再这样做,我们在API自动注册时,我们直接提供了一个Faas网关,直接在上面你用写Function函数的模式去封装你的API能力,可支持Go、Rast,、Python、JavaScript等多种语言。我们基本上把这块就全部封装透明起来,不需要让程序员再去触碰底下复杂的技术。

3.BataBuilder

BataBuilder这个部分,相对来说就更简单一点。

因为图数据库,列式数据存储是自研的。所以,我们基本上就在这两个数据库上面,构建了一个可视化模型构建器,让你去建立整个偏静态的,用图来存储我们的数据模型,还有一个偏动态的列式数据存储模型。

从前到后,从页面端到流程端,到逻辑端以及到后端的数据层,我们把这层的各种能力可视化,低代码化。优维低代码的整个框架,它其实是有自己的一些特色的,它不是简单的BPM式的低代码框架,因为它是应对复杂场景的,有些复杂场景的业务逻辑不是流程流转就可以实现的。

优维研发的低代码,从自身的应用上来说,我们内部开发有200多个微应用,同时我们自己平台级的产品能力,上面讲到的优维EasyOps®的九个产品包含低代码,所有产品的能力,基本上全部迁移到低代码上面,全部低代码化了,大大提高了我们整个工程效率,包括整个产品的交付,高保真模型的构建,产品需求的开发、测试、交付,包括微应用的整个上架,这过程其实非常便捷了,不像以前我们要以传统的那个软件工程的模式去做。

6

优维低代码的核心能力差异点

  1. 全栈低代码化,从页面端到到后端数据存储,基本上是全栈低代码化。
  2. 多语言支持,在API网关,FlowBuilder上面,像GO、Rast等语言,我们都是全部支持的。
  3. 模型级驱动,我们其实没有把数据模型全部简单化、表单化,只是提供单一mysql这种关系数据存储模型,根据图、列,支持全面存储。
  4. 全开源,低代码核心能力基本上开源出来,确保跟社区生态,更好的去联动。
  5. 我们的整个低代码体系能够对产品级功能进行注入

以上,就是对优维整个低代码体系的一个梳理,其实从2020年向外业界去推低代码至今,我们已经积累很多的客户,包括从行业的不同的客户属性以及场景上面,我们都有落地的一些经验,以及在落地的过程中,我们遇到的一些难点,带来的价值等等,我们都有一些经验积累,下回再跟大家详细的分享一下。

以上是关于十七年运维老兵万字长文讲透优维低代码~的主要内容,如果未能解决你的问题,请参考以下文章

Uknow | 优维低代码:Custom Processors 自定义加工函数

优维低代码:构件事件传递

优维低代码:构件 slot 说明

优维低代码:Use Resolves

优维低代码:Provider 构件

优维低代码:Best Practice