十七年運維老兵萬字長文講透優維低程式碼~

語言: CN / TW / HK

點開此文的小夥伴

不知道你有沒有看

優維老王說「優維LowCode實踐」的視訊

共45分鐘,分成12個視訊片段

沒看過沒關係

鹿小U將這45分鐘的視訊內容整理成下面文字

讓你係統的瞭解

優維低程式碼的整個框架

低程式碼,是今天比較熱的一個詞,其實我們都知道低程式碼今天的熱,是有它自己的原因的。

從2015年創業開始,優維前後服務了很多傳統企業的專案客戶,我們在服務的過程中其實也發現了一些自己的問題,特別是2019年底,有一個KA的客戶提出了一個個性化的需求,對我們帶來的觸動是蠻大的。

當時的背景就是我們有個專案,客戶提出了一個個性化的需求,且必須按照客戶要求的方式去實現,否則將無法完成專案結項。對於這個事情,我們當時內部研發評估的時候,如果真做了,需要考慮這個功能對其他專案客戶的一個破壞性影響。

我們知道在一個產品裡面,其實真正的一個功能,它沒辦法去相容很多其它場景,如果真要去相容,你可能要麼就是拉程式碼分支,要麼就在產品版本里面去開特定開關,很明顯這兩種方式對我們服務的大量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

優維低程式碼的技術框架

優維低程式碼的技術框架由三個部分組成,我們稱之為 “鐵三角”

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

在上層要構建微應用時,微應用裡面肯定會涉及到大量的頁面UI的交付,那VisualBuilder就是主要 聚焦在UI的能力上 ,包括頁面的一些 事件、資料 ......包括 頁面視覺化的拖拽式操作 ,全部由VisualBuilder來封裝實現。

第二部分是FlowBuilder流構件

flow其實是工作流,這一部分主要就是把API這一層,怎麼去實現一個 視覺化的編排 ,視覺化的構建。

第三部分是BataBuilder

微應用後端可能需要儲存一些資料,那這部分會涉及到 model ,就是資料模型該怎麼去 視覺化構建 ,資料怎麼去 視覺化儲存

5

優維低程式碼“鐵三角”的技術特點

下面我們就一個個來看一下“鐵三角”整個的技術特點。

1.VisualBuilder

業界講的最多的是 視覺化編排,拖拽式操作 ,這是VisualBuilder的核心能力,這個能力其實是 一種表單式的能力

在VisualBuilder這部分,為了解決表單的快速構建的問題,我們第一步是做了一個 構件化庫 ,從原子構件到業務構件,業務構件和原子構件以及他們之間的組合,我們進一步 模板化 ,構成我們單頁面的一個能力,再基於整個業務流和場景,我們進一步把Web化的頁面進行組合封裝,形成一個 Theme的主題庫 ,其業務性就更強了,業務場景性更強了。

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年向外業界去推低程式碼至今,我們已經積累很多的客戶,包括從行業的不同的客戶屬性以及場景上面,我們都有落地的一些經驗,以及在落地的過程中,我們遇到的一些難點,帶來的價值等等,我們都有一些經驗積累,下回再跟大家詳細的分享一下。

有疑問加站長微信聯絡(非本文作者)