中臺思考

還是以上此圖(此圖在我的另一篇博客草稿中)

1、概述

目的:爲持續提高企業對需求、問題的響應速度

用戶使用的服務可以簡稱爲前臺

系統運營管理可以簡稱爲中臺

系統運行狀況管理簡稱爲後臺

最近在研究一個針對互聯網管理系統,在不斷思考如何搭建架構,網上搜索許多材料以及結合自己的經驗做一下總結。

前臺後臺的概念我們已經非常熟悉,而且現在我公司還在用這樣的模式,但大的公司和互聯網公司已經是各種中臺模式,甚至更復雜的模式。

2、前後臺模式

這個模式是我司現在使用也是當前大部分企業管理系統用的模式,前臺還是給用戶用的。只是後臺是運營人員、運維人員、開發人員共用的,主要是運營人員使用。

爲什麼說主要是運營人員使用,大部分時候是運營人員查看用戶賬號、用戶業務量、客服等數據;當然我們爲了跟蹤用戶使用行爲,運營人員也要看用戶行爲數據。這些數據有疑問開發人員和運維人員也是先看這個後臺,與運營人員在內部達成共同語言,大部分時候還是可以解決問題的。

但是當數據不正確的時候,開發人員和運維人員看這個後臺就沒有太大意義了。開發人員會直接訪問數據庫查看問題,如果需要解決則直接操作數據庫數據,運維人員也是同樣的操作方式。如果是小系統或非關鍵性系統這樣的操作是沒有大問題的,但是如果這個系統數據比較關鍵敏感,一旦操作不對,導致數據丟失等,這樣的操作就比較危險,加大的系統的風險性。

因此我們既要解決問題,又要有容錯性。那麼我們就需要讓所有的操作可回溯,數據可回滾。在這樣的述求下,我們就逐漸需要更加嚴格操作權限分工、操作/數據可回溯可回滾的機制。

所以中臺的概念應運而生!

3、中臺

通過第2節的描述,我們基本知道爲什麼需要中臺。那麼我們需要一個什麼樣的中臺。在這裏,鄙人認爲不需要有過於嚴格的定義,需要根據業務、公司的實際情況進行定義中臺。

先說中臺需要有什麼特點:

a)標準化、規範化

    儘量所有操作和數據控制都在中臺中進行。什麼人能做什麼操作,查看修改什麼數據都能統一控制,達到標準化。所有的操作都在中臺中進行達到規範化,以免因爲個人失誤造成損失。

b)靈活性

    不管怎樣,我們的目的還是對需求、問題的快速響應,那麼中臺提供的操作和數據需要比較靈活,才能做到快速響應;過於靈活就會導致失控,所以需要有權限對操作和數據進行限制。當然權限也要足夠靈活,才能做到細粒度控制,才能做到快速響應。

c)管理機制

光有系統沒有人操作也是白瞎。所以公司或組織也要建議一套人員管理機制,與中臺模式進行匹配。(所以奉勸管理機制不能改革的機構就不要想中臺了)

小結:中臺就是不要一有問題就直接找開發人員,一找到開發人員,就去操作數據庫。(夠直白了吧)

以下舉一個例,希望有所啓發:

    針對一個互聯網項目,中臺需要技術中臺、業務中臺、數據中臺、運維中臺

技術中臺:

    技術中臺主要是爲提高代碼層面的複用性和快速響應。現在流行的說法就是提供微服務,可以抽象技術模塊,以接口的方式開放,技術前臺根據業務需求組織呈現給用戶。用戶端可以是app、網站、硬件等。

業務中臺:

    業務中臺主要是運營人員使用。需要提供用戶賬號管理、用戶業務處理、用戶行爲分析、用戶客服管理。

數據中臺:

    數據中臺可以給運營人員和開發人員使用。屏蔽敏感修改刪除數據庫、數據表、數據行等操作,提供普通數據增刪查改。在業務中臺中發現數據不正確時可以在數據中臺中進行管理。相當於是屏蔽敏感操作後的透明數據庫管理。

運維中臺:

    運維中臺是提供給運維人員使用。類似於現在的堡壘機機制,運維人員所有操作都經過一個統一個系統,與數據中臺類似,相當於是屏蔽敏感操作的操作系統指令集系統。

業務中臺、數據中臺、運維中臺中所有操作都要求進行記錄、可回溯、可回滾。

 

最後建議:

看完上面的描述,請各位結合自己業務需求考慮是否需要中臺,需要什麼樣的中臺,畢竟還是需要工作量的。

 

 

 

 

 

發佈了40 篇原創文章 · 獲贊 7 · 訪問量 5萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章