朱曄的互聯網架構實踐心得S1E1：Pilot

朱曄的互聯網架構實踐心得S1E1：Pilot

 

最近幾年寫博客確實寫得少了，初出茅廬的時候什麼都願意去寫，如今寫一點東西以前會反覆斟酌是否有價值。工做十幾年了，作了N多個互聯網系統，業務涉及教育、遊戲、電商、O2O、P2P，算是各類類型的互聯網系統都摸過，多少有一些心得，架構方面的文章網上不少不少，有些是說一些方法論，有些是說一些具體的案例，感受本身想分享的東西和別人已分享的是有點不一樣的，仍是應該留下點什麼。在這裏我更多想分享一下搭建一套完整的互聯網系統架構方面一些具體的實踐心得，大概會從這幾個方面來寫：

1. 各類廢話的閒聊和吐槽
2. 屢試不爽的架構三馬車：介紹一個簡單實用的可擴展的互聯網架構
3. 相輔相成的存儲五件套：介紹一下我的比較喜歡的一個存儲組合以及適用場景
4. 簡單好用的監控六兄弟：介紹監控方面一直在用的一些工具以及強調監控的重要性
5. 不斷耕耘的基礎中間件：中後期的項目須要有完善的基礎中間件，這裏進行逐一介紹
6. 給飛機換引擎和安全意識十原則：分享一些對高速發展項目進行重構以及安全方面的一些經驗
7. 三十種架構設計模式（上）：微軟一些架構方面的設計模式
8. 三十種架構設計模式（下）：微軟一些架構方面的設計模式
9. 架構評審一百問和設計文檔五要素：架構評審考察點和如何寫設計文檔
10. 數據的權衡和折騰：以數據的維度談談架構設計中的權衡和複雜點

 

有關All-In-One架構

不少項目起步的時候都會以一個All-In-One的項目起步，使用一套MVC框架，對外提供數據的Controller、包含業務邏輯的Service、訪問數據庫的DAL、定時任務，全部的東西都在一個項目內，而後在半年和一年以後業務發展起來了急需對如今的架構進行重構（說的很差聽就是推翻重來了），緣由以下：

1. 超過5人在同一個大項目中修改代碼，分支管理代碼衝突解決成本過高了。
2. 隨着壓力的上升這麼簡單的直腸子架構很難去拆分分散壓力從而頂不住高併發。
3. 雖然對於MVC咱們會有明確的目錄來存放三大組件的邏輯可是隨着業務邏輯愈來愈複雜，咱們會有聚合的Controller和聚合的Service產生，全部組件再也不位於同一個水平面，代碼全都堆積在一塊兒腐化很快，容易造成複製粘貼的趨向。

除非已經明確是實驗性臨時性的項目，我我的不建議以這樣的方式起步，使用一個相對簡單的架構（見文2）並不會浪費太多的時間，可是這個開局每每能夠避免以後的推翻重來。

 

有關百花齊放的平臺和語言

我我的從.NET轉到Java平臺，以前的公司有使用過PHP，Python，Go。經歷過.NET和PHP轉Java，經歷過混用各類語言的公司。在這幾想說幾點：

1. 曾經犯過錯，在團隊不大的時候容許保留兩種技術PHP和Java同時發展。不管大小，每一個團隊的成員都須要本身的技術發展和晉升，每一個技術棧都有不一樣的運維方式，每一個技術都會有各自的妖怪問題，在一個規模不大的技術團隊裏同時使用多個技術，對於團隊來講真是一個很大的消耗。語言的確有各司其職發揮所長之說，可是小於30人規模的開發團隊真不必這麼早進行技術棧的分叉。
2. 隨着團隊規模的擴大，處於招聘成本、使用成本、性能、資源豐富性等等問題，每每會進行技術轉型，許多平臺花了幾年時間都沒法完全從.NET或PHP轉到Java，這是一個痛苦的過程。雖然說技術負責人老是趨向於一開始使用本身熟悉的技術棧來搭建系統，可是不得不認可Java這門綜合性很強的語言是一個不錯的開局方式，開源資源豐富、好招人、高手多、開發效率還湊活、性能也不算差、少點折騰就能把精力更多放到業務上。倒不是說.NET和PHP很差，而是咱們最後須要接受不少殘酷的現實。
3. 隨着項目規模的擴大，不少東西勢必須要本身來寫，開源每每不適合，這個時候發揮語言各自的所長又會顯得很重要。Go在性能方面、可移植性方面、開發效率方面、高併發友好性方面有獨特的優點，是開發（網絡）中間件的很不錯的候選語言，每每能夠替代C。Python的開發效率奇高，豐富的類庫基本任何需求都是一行代碼一句API解決問題，做爲運維平臺各類工具和爬蟲的開發語言再適合不過，在AI方面也是鶴立雞羣無可替代。
4. 開發應該多接觸幾門語言，這是很是有好處的。有些語言在高併發方面有優點，有些語言在函數式編程方面發展的很好，有些語言在語法糖方面設計的很漂亮，每一個語言在其特點上所在的層次會比較高一點，也容易被其它語言借鑑，多看一些語言會讓本身知道每個技術能好到什麼程度，不容易在綜合性語言中成爲井底之蛙。

有關平臺架構團隊和業務團隊

技術團隊到了必定程度不但會橫向拆分爲前中後臺，還會縱向拆分爲框架架構團隊和業務團隊，研發中間件或框架的平臺架構團隊和一心耕耘業務代碼的業務團隊我都待過。在架構團隊的時候咱們總會吐槽：

1. 業務團隊不肯意配合架構團隊作技術升級，架構團隊辛辛苦苦搞這些還不是在解決業務團隊的問題？
2. 業務團隊太謹慎保守了老是擔憂架構升級影響現有系統，想法太老舊了一點架構意識都沒有？

在業務團隊的時候咱們又會吐槽：

1. 架構團隊老是高高在上的樣子，他們體會不到業務的複雜性，作出來的東西根本不實用，這麼難用的東西還不如咱們的土辦法。
2. 架構團隊的人是否是很輕鬆，業務團隊每天加班搞項目，架構團隊貌似都是在喝茶聊天研究一些不實用的東西。

在這裏想表達幾個觀點：

1. 技術發展到必定的程度，必定是須要一些中間件或框架來作統一的事情，這些中間件結合在一塊兒造成一個平臺（見文5）能夠大大減小出問題排錯的時間，也可讓一些高併發下的優化工做更簡單。
2. 架構團隊的架構師最好是在業務團隊深耕過，知道痛點所在的，這樣研發出來的系統和工具可以和公司目前的項目所匹配發揮最大的做用，讓你們愛不釋手。
3. 在作架構升級的時候對業務侵入性越小越好，業務團隊無感知最好，前提是咱們的一些核心架構框架和中間件已是統一的標準化的，有一些框架仍是本身研發比較好，在以後的一些文中會提到這個觀點。
4. 作業務每每變更大，咱們老是會習慣不少事情先手動來作，慢慢造成了對工具化自動化理念沒有這麼敏銳。若是在這個時候有局外人能參與一下說不定能夠碰撞出不少好的框架和工具來幫助咱們提升生產力，這實際上是一個好事情。