不知幾年前，資料中臺這個概念開始變得很熱鬧，各個機構都要上中臺，中臺架構意味著先進，人見人愛，也冒出許多以中臺為業的軟體公司，然而，大概從去年中開始，聽說又有好多機構開始忙著拆中臺了，中臺雖然還沒到人見人煩的地步，但總體來講已經不那么受待見了，
這是怎么回事？
老實說，中臺這架構是挺合理的，在前臺和后臺之間夾一個中臺，屏蔽后臺的資料存盤，應對前臺沒完沒了的變化需求，
前臺跟著界面走，天生就穩定不了，總是有五花八門的資料請求，這是必然的事情，后臺應該主要負責資料存盤，把不同形式和規模的資料以合適的方式整理好，大資料倒騰起來動靜太大，要求有一定的穩定性，
如果前臺的請求都要求后臺直接做，那后臺管的事就太多了，應對靈活請求和規整資料存盤在一定程度上是兩個優化目標不同的需求，同一個團隊在同一套硬體上同時對付這兩件事，容易發生精神分裂，
而且，后臺是被許多前臺共享的，如果直接向前臺提供靈活資料服務，還可能導致各個前臺之間的耦合程度變高，維護成本立即陡增，
同樣的，把這些資料處理放在前臺也不合適，一方面不太安全，另一方面，前臺團隊也是忙著讓界面如何更好看使用更流暢，沒太多工夫琢磨資料的事情，
有了中臺就好很多了，后臺專心管存盤，前面專心管界面，前后臺之間的差距由中臺負責抹平，分工明確，各司其職，效率自然提高，
既然架構合理，那為什么搞不下去？
原因呢，說啥的都有，不過大都沒說到點子上，因為說這些話的大都不寫代碼，寫代碼的又大都輪不到來說話，
根本的原因在于，業界就沒有準備好能讓資料中臺落地的技術！
中臺向前臺提供資料服務，啥是資料服務呢？就是收到請求后回傳一些合適的資料回去，那咋弄出回傳的資料呢？計算唄，就是把以前在后臺讓資料庫做的事搬到中臺來唄，
那么，你打算讓我用什么技術來寫這些計算代碼呢？
Java？開玩笑呢？寫個分組匯總就好幾百行，你讓我怎么提高效率？還想迅速應對前臺變化？這代碼我連寫帶調得好幾天，下禮拜再見吧，
中臺要干的這些任務，也是之前資料庫干的事，絕大多數都是結構化資料相關的計算，而Java這些高級語言基本上沒什么好用的結構化資料計算類別庫，原先用SQL幾句話能搞定的事，現在用Java就得幾百上千行代碼了，代碼長了，不僅難寫，還容易錯，而且，Java程式員的成本也挺高啊，效率沒提高，錢倒花多了，那又何苦？
但是，貌似有些大廠的中臺架構實施得不錯，這又咋解釋？
可能是大廠人才多，Java代碼積累豐富吧，搞起這些計算就容易一點了，而且，悄悄地說一句，這些互聯網大廠雖然大，業務復雜度卻遠遠趕不上傳統行業，大廠能搞得通的事，你可未必能搞得通，
不用Java，那咱還繼續用SQL行不？
嗯，那得在中臺也放個資料庫，把一堆資料從后臺搬出來再移到中臺來，搬多少資料呢？貌似所有的資料都有可能用于計算，那得把整個后臺的資料都搬過來，然則這玩意兒還能叫中臺？不就是把后臺挪了個位置而已，純粹吃飽了撐的嘛，
在沒有不依賴于資料庫的、可被集成嵌入的、支持多樣資料源、簡單方便且豐富強大的結構化資料計算能力之時，資料中臺就是空想，架構好看，但無法落地，強行上中臺，除非你的業務足夠簡單，否則就是只會讓開發成本上升而效率下降，靈活性一點沒增加，麻煩事卻一大堆，
有一點小例外，國產報表工具通常在一定程度上擁有一些上述的計算能力（更詳細解釋報表工具的計算能力：不依賴于資料庫、可被集成嵌入、支持多樣資料源、豐富強大尚有不足但應對常規分組過濾等運算都沒問題），如果前臺應用主要用來看統計查詢結果（統計邏輯和資料源還不能太復雜，否則報表工具的計算能力就擺不平了，還得去寫Java或者搬資料），那么搞一個報表工具作為中臺是部分可行的，對于這些限定的應用場景確實可以起到提高效率和增強靈活性的作用，所以有些為數不多還能用起來的中臺其實就是個報表平臺，
資料中臺受制于計算能力，必須要具有上述特征的計算引擎之后，才能讓資料中臺的合理架構真正發揮作用，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/294695.html
標籤：java