很多技術人總是抱怨 新技術/新框架/新概念 太多了，總是學不完，抱怨實在是學不動了。哈哈，這不，最近「 中臺 」這麼火熱，要不要停止抱怨，再咬咬牙學一波？
「很多人都擔心被技術新潮流所拋棄，所以當遇見不斷湧現的新技術時，總是慌忙的去學習。可是其中到底有多少是真正有用的？又有多少是曇花一現的技術呢？當你無法分辨的時候，其實不必慌張，當一項新技術/概念剛出現的時候，你不必匆忙的去學習，更不必擔心自己會錯過它，如果它是乙個真正有價值的東西，是乙個真正經受得住考驗得技術，它遲早會再次出現在你面前」
這是我很喜歡的一段話，對技術浪潮的見識太到位了。不過很慚愧，我不記得是哪位大神說的了。
回到「 中臺 」這個話題，其實中臺已經不算新潮流了，並且它還是被很多企業成功驗證過的模式了。那麼，既然這麼靠譜，咱們是否應該趕個時髦，搞乙個？
在回答這個問題之前，咱們先縷一縷啥是中颱吧。
supercell公司公司人員人少，採用的就是「小前台」+「部落」的模式。就是有多個「前台」小組，這些小組就是專門用來快速研發遊戲的，每個小組雖然人員不多但它包含了開發一款遊戲所需的各種角色人員。這些「前台」小組只關注在業務側，也就是遊戲業務研發和創新上。而對於遊戲的底層基礎設施：遊戲引擎、開發工具、伺服器後台等這些都東西，前台小組不用去關心，這些基礎功能交由乙個稱為「部落」的組織獨立去負責。這種模式就像是戰鬥小組專門去負責打仗，後勤彈藥又由另外的小組去搞定，分工明確，業務也能快速試錯、快速創新。
根據這次拜訪學習，阿里巴巴隨後宣布組織架構全面公升級，啟動中臺戰略，構建「大中台、小前台」的組織機制和業務機制。
在網際網路大廠的領頭、產業網際網路的風口，傳統企業的轉型契機下，「 中臺 」不火都不行啊。
想了很久，想用一句簡潔清晰的語句給中臺下個定義，還是有點難度（嗯，沒錯，還是我的認知太淺了，哈哈）。
中臺就是乙個架構理念，它是介於前台與後台之間的（這句好像是廢話），它是希望將一些可復用的「能力」統一起來，採用共享的方式去建設，用來解決各個業務團隊重複開發、資料分散、試錯成本高等問題，中颱的核心就是**「對能力的共享」、「對能力的復用」**，它應該是公司內部的統一協同平台。
企業級的能力復用平台我覺得這個定義相當準確且簡潔。受不了我上面一大段囉嗦定義的同學，可以按照這個簡潔的定義去理解中臺。
上面講完了中颱的定義，我們再來看看 前台、中臺、後台 的區別吧。
「前台」是直接服務客戶、觸達使用者的平台，能夠洞察使用者需求，進行產品創新、提公升使用者價值，保持精簡和足夠敏捷度的平台。比如阿里的 **、天貓、聚划算等。
「中臺」前面已經定義過了。它通過元件化的形式輸出通用能力，為所有「前台」的業務運營和創新，提供專業能力的共享平台。中臺部門提煉各業務線的共性需求，將各種資源轉化為方便「前台」使用的能力，最大程度避免重複「造輪子」。
「後台」的職能是提供基礎設施建設、服務支援，為「前台」和「中臺」提供基礎保障。後台會比中颱更底層、更通用。「中臺」有的時候會更關注在某一行業/領域內的，而「後台」應該是行業/領域通用的。
要注意的是，中颱並不是專指技術，相反主流的中颱更側重於業務。
上面提到的 前台、中臺、後台 全部都是從使用者和職能角度出發的，很多開發同學一聽前後臺就理解成了技術架構了，技術架構中的前端展示層、技術中間層、後端資料層，與這裡的前中後台完全不是乙個概念。
阿里的中颱戰略是以業務中颱和資料中臺相結合，這也是目前市面上主流的中颱架構。
資料中臺是基於技術和大資料能力為業務提供可復用的資料服務，將業務中產生出來的資料進行二次加工，將加工的結果再服務於業務，為業務賦能。但要注意的是，大家在理解上不能將資料中颱與傳統的數倉、大資料平台劃等號。資料中颱與它們的區別是，資料中颱更貼近業務，資料中颱不只關心技術層面，不只提供分析功能，更多關心資料資產化、關心資料對業務的運用，為業務提供服務。
（**雲棲社群）
除此之外，在實際應用中，也衍生出了很多其它的中颱概念，如：移動中臺、演算法中臺、技術中臺、研發中臺、運營中臺、組織中臺等等。下面挑選幾個簡單解釋一下：
技術中臺：提供通用的技術設施能力、技術中介軟體能力，過濾掉技術細節，像各個前台應用提供統一的易用的技術服務，避免重複造輪子（也有人認為技術中颱不具備業務屬性，屬於技術中介軟體平台，不能歸屬中臺）。
研發中臺：研發中颱是關注開發效率的平台，將公司的開發流程、最佳實踐沉澱為可重用的能力，為應用的開發提供了流程、質量管控和持續交付的能力。
為什麼會出現這麼多的讓人眼花繚亂的中颱呢？根本原因是每個人自己的職業不同，所以看待的角度不同，出發點不同，並且每個公司的業務性質、形態也不相同。比如 電商團隊、ai團隊、運營團隊、研發團隊，他們眼中的中颱肯定都是不一樣的，但初衷是一樣的：資源的復用。
另外，這裡還得再囉嗦一句：「平台不是中臺」。什麼意思呢？
有的網際網路企業在對公司內的模組進行定義和表述中，並不常用「後台」的概念，反而用「平台」比較多。比如 大資料平台、運維自動化平台、財務平台等等。這些「平台」與我們今天描述的「中臺」並不是一回事。平台比中臺更底層一些，更基礎一些。平台一般是不帶業務屬性的，而中颱，確必須是具備業務屬性的，因為中颱是直接為前台業務所服務的，是乙個提煉業務能力共性的組織，在這一點上就與平台區別的很明顯了。
「中臺」這麼火，大小企業都蠢蠢欲動，各種靠譜不靠譜的平台都往中颱的概念上靠，要幹的勁頭擋不住啊。行吧，既然要幹，咱們至少得先看看問題吧，把明顯不適合搞中颱的基本條件弄清楚嘛。
公司得核心業務不成熟 或 公司業務線很少
如果企業屬於創業公司，主業務模式都不明朗，這種情況就真的不建議搞什麼中颱的。中颱是講究多業務服務用的，咱就乙個業務，這個業務還在探索，搞啥子中颱嘛，把技術平台搞好點就可以了。
公司裡沒有相類似的業務
即使不是創業公司，是乙個中型甚至是大型公司了，但如果公司裡雖然業務多，但是每個業務線做的領域都區別很大，比如業務線1做面向c端的電商，業務線2做遊戲，業務線3做面向b端企業級產品。這種情況，很難沉澱共性的業務服務，也做不了中臺，還是拉乙個團隊繼續做基礎平台給各個業務服務吧。
公司沒有足夠的人力
人力是硬指標，即使上面說的問題都沒有，完全符合做中颱，那也得考慮考慮人員安排。畢竟中颱的建設是需要由獨立的團隊去完成，並且還應該是乙個高效率的團隊（不然前台業務會抱怨中臺響應不及時），公司是否有這部分的人力預算去建設中臺，人員從哪兒來，這個硬性條件必須提前考慮。
這篇文章闡述了 啥是中颱、要不要建中臺，但貌似缺乙個「怎麼建中臺」了，這個以後聊。
另外，還有很多人擔心「 中臺 」會不會是曇花一現的新概念，我覺得糾結這個完全沒必要。當咱們充分理解了中颱，學到了其中的理念之後，它是不是曇花一現並不是很重要嘛。因為我們已經獲得了成長，獲得了視野和思維的提公升，足以。您覺得呢？
乙個值只有0和1的字段，到底要不要建索引？
關於資料庫索引的所有文章，都會告訴你不要對這種欄位建索引。舉個例子，假設表中有一千萬條記錄，某個狀態為0的記錄總數大概會有100條，那麼你想查詢狀態為0的記錄時，有沒有索引影響非常大，而查詢狀態為1的記錄，則索引基本無用。如果兩種狀態的記錄數相差無幾的話，索引也基本無用。所有的關於索引的文章，建議你...
《筆試》《面試》判斷乙個數是否在40億個中
40億個不重複無符號整數，沒排序，任意給乙個無符號整數如何快速判斷這個數是否在這40億個數中。思路 點陣圖bitmap 在stl中叫bit set 節省空間 缺點只判定存在還是不存在，不能知道出現幾次。void set size t x x對應位置1 a index 1 cout void rese...
判斷乙個字串中的字元是否都在另乙個中出現
假設這有乙個各種字母組成的字串，假設這還有另外乙個字串，而且這個字串裡的字母數相對少一些。從演算法是講，什麼方法能最快的查出所有小字串裡的字母在大字串裡都有？解答 1 把其中的每個字母都放入乙個hashtable裡 成本是o n 或16次操作 然後輪詢第二個字串，在hashtable裡查詢每個字母，...