朱曄的互連網架構實踐心得S1E1：Pilot
最近幾年寫部落格確實寫得少了，初出茅廬的時候什麼都願意去寫，現在寫一點東西之前會反覆斟酌是否有價值。工作十幾年了，做了N多個互連網系統，業務涉及教育、遊戲、電商、O2O、P2P，算是各種類型的互連網系統都摸過，多少有一些心得，架構方面的文章網上很多很多，有些是說一些方法論，有些是說一些具體的案例，感覺自己想分享的東西和別人已分享的是有點不同的，還是應該留下點什麼。在這裡我更多想分享一下搭建一套完整的互連網系統架構方面一些具體的實踐心得，大概會從這幾個方面來寫：
- 各種廢話的閑聊和吐槽
- 屢試不爽的架構三馬車：介紹一個簡單實用的可擴充的互連網架構
- 相輔相成的儲存四件套：介紹一下個人比較喜歡的一個儲存群組合以及適用情境
- 簡單好用的監控六兄弟：介紹監控方面一直在用的一些工具以及強調監控的重要性
- 不斷耕耘的基礎中介軟體：中後期的項目需要有完善的基礎中介軟體，這裡進行逐一介紹
- 令人頭痛的飛機換引擎：有的時候需要對高速發展的項目進行重構，這裡分享一些經驗
- 高並發架構到底是什麼：高並發架構最佳化在最佳化哪些方面，具體會做一些什麼事呢？
- ……（想到了再補充吧）
有關All-In-One架構
很多項目起步的時候都會以一個All-In-One的項目起步，使用一套MVC架構，對外提供資料的Controller、包含商務邏輯的Service、訪問資料庫的DAL、定時任務，所有的東西都在一個項目內，然後在半年和一年之後業務發展起來了急需對現在的架構進行重構（說的不好聽就是推翻重來了），原因如下：
- 超過5人在同一個大項目中修改代碼，分支管理代碼衝突解決成本太高了。
- 隨著壓力的上升這麼簡單的直腸子架構很難去拆分分散壓力從而頂不住高並發。
- 雖然對於MVC我們會有明確的目錄來存放三大組件的邏輯但是隨著商務邏輯越來越複雜，我們會有彙總的Controller和彙總的Service產生，所有組件不再位於同一個水平面，代碼全都堆積在一起腐化很快，容易形成複製粘貼的趨向。
除非已經明確是實驗性臨時性的項目，我個人不建議以這樣的方式起步，使用一個相對簡單的架構（見文2）並不會浪費太多的時間，但是這個開局往往可以避免之後的推翻重來。
有關百花齊放的平台和語言
我個人從.NET轉到Java平台，之前的公司有使用過PHP，Python，Go。經曆過.NET和PHP轉Java，經曆過混用各種語言的公司。在這幾想說幾點：
- 曾經犯過錯，在團隊不大的時候允許保留兩種技術PHP和Java同時發展。無論大小，每個團隊的成員都需要自己的技術發展和晉陞，每個技術棧都有不同的營運方式，每個技術都會有各自的妖怪問題，在一個規模不大的技術團隊裡同時使用多個技術，對於團隊來說真是一個很大的消耗。語言的確有各司其職發揮所長之說，但是小於30人規模的Team Dev真沒必要這麼早進行技術棧的分叉。
- 隨著團隊規模的擴大，處於招聘成本、使用成本、效能、資源豐富性等等問題，往往會進行技術轉型，許多平台花了幾年時間都無法徹底從.NET或PHP轉到Java，這是一個痛苦的過程。雖說技術負責人總是趨向於一開始使用自己熟悉的技術棧來搭建系統，但是不得不承認Java這門綜合性很強的語言是一個不錯的開局方式，開源資源豐富、好招人、高手多、開發效率還湊活、效能也不算差、少點折騰就能把精力更多放到業務上。倒不是說.NET和PHP不好，而是我們最後需要接受很多殘酷的現實。
- 隨著項目規模的擴大，很多東西勢必需要自己來寫，開源往往不適合，這個時候發揮語言各自的所長又會顯得很重要。Go在效能方面、可移植性方面、開發效率方面、高並發友好性方面有獨特的優勢，是開發（網路）中介軟體的很不錯的候選語言，往往可以替代C。Python的開發效率奇高，豐富的類庫基本任何需求都是一行代碼一句API解決問題，作為營運平台各種工具和爬蟲的開發語言再適合不過，在AI方面也是鶴立雞群無可替代。
- 開發應該多接觸幾門語言，這是非常有好處的。有些語言在高並發方面有優勢，有些語言在函數式編程方面發展的很好，有些語言在文法糖方面設計的很漂亮，每個語言在其特色上所在的層次會比較高一點，也容易被其它語言借鑒，多看一些語言會讓自己知道每一個技術能好到什麼程度，不容易在綜合性語言中成為井底之蛙。
有關平台架構團隊和業務團隊
技術團隊到了一定程度不但會橫向拆分為前中後台，還會縱向拆分為架構架構團隊和業務團隊，研發中介軟體或架構的平台架構團隊和一心耕耘業務代碼的業務團隊我都待過。在架構團隊的時候我們總會吐槽：
- 業務團隊不願意配合架構團隊做技術升級，架構團隊辛辛苦苦搞這些還不是在解決業務團隊的問題？
- 業務團隊太謹慎保守了總是擔心架構升級影響現有系統，想法太老舊了一點架構意識都沒有？
在業務團隊的時候我們又會吐槽：
- 架構團隊總是高高在上的樣子，他們體會不到業務的複雜性，做出來的東西根本不實用，這麼難用的東西還不如我們的土辦法。
- 架構團隊的人是不是很輕鬆，業務團隊天天加班搞項目，架構團隊貌似都是在喝茶聊天研究一些不實用的東西。
在這裡想表達幾個觀點：
- 技術發展到一定的程度，一定是需要一些中介軟體或架構來做統一的事情，這些中介軟體結合在一起形成一個平台（見文5）可以大大減少出問題排錯的時間，也可以讓一些高並發下的最佳化工作更簡單。
- 架構團隊的架構師最好是在業務團隊深耕過，知道痛點所在的，這樣研發出來的系統和工具能夠和公司目前的項目所匹配發揮最大的作用，讓大家愛不釋手。
- 在做架構升級的時候對業務侵入性越小越好，業務團隊無感知最好，前提是我們的一些核心架構架構和中介軟體已經是統一的標準化的，有一些架構還是自己研發比較好，在之後的一些文中會提到這個觀點。
- 做業務往往變動大，我們總是會習慣很多事情先手動來做，慢慢形成了對工具化自動化理念沒有這麼敏銳。如果在這個時候有局外人能參與一下說不定可以碰撞出很多好的架構和工具來協助我們提高生產力，這其實是一個好事情。
