還是以上此圖（此圖在我的另一篇博客草稿中）
1、概述
目的：爲持續提高企業對需求、問題的響應速度
用戶使用的服務可以簡稱爲前臺
系統運營管理可以簡稱爲中臺
系統運行狀況管理簡稱爲後臺
最近在研究一個針對互聯網管理系統，在不斷思考如何搭建架構，網上搜索許多材料以及結合自己的經驗做一下總結。
前臺後臺的概念我們已經非常熟悉，而且現在我公司還在用這樣的模式，但大的公司和互聯網公司已經是各種中臺模式，甚至更復雜的模式。
2、前後臺模式
這個模式是我司現在使用也是當前大部分企業管理系統用的模式，前臺還是給用戶用的。只是後臺是運營人員、運維人員、開發人員共用的，主要是運營人員使用。
爲什麼說主要是運營人員使用，大部分時候是運營人員查看用戶賬號、用戶業務量、客服等數據；當然我們爲了跟蹤用戶使用行爲，運營人員也要看用戶行爲數據。這些數據有疑問開發人員和運維人員也是先看這個後臺，與運營人員在內部達成共同語言，大部分時候還是可以解決問題的。
但是當數據不正確的時候，開發人員和運維人員看這個後臺就沒有太大意義了。開發人員會直接訪問數據庫查看問題，如果需要解決則直接操作數據庫數據，運維人員也是同樣的操作方式。如果是小系統或非關鍵性系統這樣的操作是沒有大問題的，但是如果這個系統數據比較關鍵敏感，一旦操作不對，導致數據丟失等，這樣的操作就比較危險，加大的系統的風險性。
因此我們既要解決問題，又要有容錯性。那麼我們就需要讓所有的操作可回溯，數據可回滾。在這樣的述求下，我們就逐漸需要更加嚴格操作權限分工、操作/數據可回溯可回滾的機制。
所以中臺的概念應運而生！
3、中臺
通過第2節的描述，我們基本知道爲什麼需要中臺。那麼我們需要一個什麼樣的中臺。在這裏，鄙人認爲不需要有過於嚴格的定義，需要根據業務、公司的實際情況進行定義中臺。
先說中臺需要有什麼特點：
a）標準化、規範化
儘量所有操作和數據控制都在中臺中進行。什麼人能做什麼操作，查看修改什麼數據都能統一控制，達到標準化。所有的操作都在中臺中進行達到規範化，以免因爲個人失誤造成損失。
b）靈活性
不管怎樣，我們的目的還是對需求、問題的快速響應，那麼中臺提供的操作和數據需要比較靈活，才能做到快速響應；過於靈活就會導致失控，所以需要有權限對操作和數據進行限制。當然權限也要足夠靈活，才能做到細粒度控制，才能做到快速響應。
c）管理機制
光有系統沒有人操作也是白瞎。所以公司或組織也要建議一套人員管理機制，與中臺模式進行匹配。（所以奉勸管理機制不能改革的機構就不要想中臺了）
小結：中臺就是不要一有問題就直接找開發人員，一找到開發人員，就去操作數據庫。（夠直白了吧）
以下舉一個例，希望有所啓發：
針對一個互聯網項目，中臺需要技術中臺、業務中臺、數據中臺、運維中臺
技術中臺：
技術中臺主要是爲提高代碼層面的複用性和快速響應。現在流行的說法就是提供微服務，可以抽象技術模塊，以接口的方式開放，技術前臺根據業務需求組織呈現給用戶。用戶端可以是app、網站、硬件等。
業務中臺：
業務中臺主要是運營人員使用。需要提供用戶賬號管理、用戶業務處理、用戶行爲分析、用戶客服管理。
數據中臺：
數據中臺可以給運營人員和開發人員使用。屏蔽敏感修改刪除數據庫、數據表、數據行等操作，提供普通數據增刪查改。在業務中臺中發現數據不正確時可以在數據中臺中進行管理。相當於是屏蔽敏感操作後的透明數據庫管理。
運維中臺：
運維中臺是提供給運維人員使用。類似於現在的堡壘機機制，運維人員所有操作都經過一個統一個系統，與數據中臺類似，相當於是屏蔽敏感操作的操作系統指令集系統。
業務中臺、數據中臺、運維中臺中所有操作都要求進行記錄、可回溯、可回滾。
最後建議：
看完上面的描述，請各位結合自己業務需求考慮是否需要中臺，需要什麼樣的中臺，畢竟還是需要工作量的。
