資訊專欄INFORMATION COLUMN
摘要：架構團隊的人是不是很輕松，業務團隊天天加班搞項目，架構團隊貌似都是在喝茶聊天研究一些不實用的東西。架構團隊的架構師最好是在業務團隊深耕過，知道痛點所在的，這樣研發出來的系統和工具能夠和公司目前的項目所匹配發揮最大的作用，讓大家愛不釋手。
最近幾年寫博客確實寫得少了，初出茅廬的時候什么都愿意去寫，現在寫一點東西之前會反復斟酌是否有價值。工作十幾年了，做了N多個互聯網系統，業務涉及教育、游戲、電商、O2O、P2P，算是各種類型的互聯網系統都摸過，多少有一些心得，架構方面的文章網上很多很多，有些是說一些方法論，有些是說一些具體的案例，感覺自己想分享的東西和別人已分享的是有點不同的，還是應該留下點什么。在這里我更多想分享一下搭建一套完整的互聯網系統架構方面一些具體的實踐心得，大概會從這幾個方面來寫：
各種廢話的閑聊和吐槽
屢試不爽的架構三馬車：介紹一個簡單實用的可擴展的互聯網架構
相輔相成的存儲四件套：介紹一下個人比較喜歡的一個存儲組合以及適用場景
簡單好用的監控六兄弟：介紹監控方面一直在用的一些工具以及強調監控的重要性
不斷耕耘的基礎中間件：中后期的項目需要有完善的基礎中間件，這里進行逐一介紹
令人頭痛的飛機換引擎：有的時候需要對高速發展的項目進行重構，這里分享一些經驗
三十種架構設計模式（上）：針對微軟總結的一些架構設計模式給出自己的一些理解
三十種架構設計模式（下）：針對微軟總結的一些架構設計模式給出自己的一些理解
架構評審和架構文檔：自己總結的架構評審100問以及架構文檔5要素
有關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人規模的開發團隊真沒必要這么早進行技術棧的分叉。
隨著團隊規模的擴大，處于招聘成本、使用成本、性能、資源豐富性等等問題，往往會進行技術轉型，許多平臺花了幾年時間都無法徹底從.NET或PHP轉到Java，這是一個痛苦的過程。雖說技術負責人總是趨向于一開始使用自己熟悉的技術棧來搭建系統，但是不得不承認Java這門綜合性很強的語言是一個不錯的開局方式，開源資源豐富、好招人、高手多、開發效率還湊活、性能也不算差、少點折騰就能把精力更多放到業務上。倒不是說.NET和PHP不好，而是我們最后需要接受很多殘酷的現實。
隨著項目規模的擴大，很多東西勢必需要自己來寫，開源往往不適合，這個時候發揮語言各自的所長又會顯得很重要。Go在性能方面、可移植性方面、開發效率方面、高并發友好性方面有獨特的優勢，是開發（網絡）中間件的很不錯的候選語言，往往可以替代C。Python的開發效率奇高，豐富的類庫基本任何需求都是一行代碼一句API解決問題，作為運維平臺各種工具和爬蟲的開發語言再適合不過，在AI方面也是鶴立雞群無可替代。
開發應該多接觸幾門語言，這是非常有好處的。有些語言在高并發方面有優勢，有些語言在函數式編程方面發展的很好，有些語言在語法糖方面設計的很漂亮，每個語言在其特色上所在的層次會比較高一點，也容易被其它語言借鑒，多看一些語言會讓自己知道每一個技術能好到什么程度，不容易在綜合性語言中成為井底之蛙。
有關平臺架構團隊和業務團隊技術團隊到了一定程度不但會橫向拆分為前中后臺，還會縱向拆分為框架架構團隊和業務團隊，研發中間件或框架的平臺架構團隊和一心耕耘業務代碼的業務團隊我都待過。在架構團隊的時候我們總會吐槽：
業務團隊不愿意配合架構團隊做技術升級，架構團隊辛辛苦苦搞這些還不是在解決業務團隊的問題？
業務團隊太謹慎保守了總是擔心架構升級影響現有系統，想法太老舊了一點架構意識都沒有？
在業務團隊的時候我們又會吐槽：
架構團隊總是高高在上的樣子，他們體會不到業務的復雜性，做出來的東西根本不實用，這么難用的東西還不如我們的土辦法。
架構團隊的人是不是很輕松，業務團隊天天加班搞項目，架構團隊貌似都是在喝茶聊天研究一些不實用的東西。
在這里想表達幾個觀點：
技術發展到一定的程度，一定是需要一些中間件或框架來做統一的事情，這些中間件結合在一起形成一個平臺（見文5）可以大大減少出問題排錯的時間，也可以讓一些高并發下的優化工作更簡單。
架構團隊的架構師最好是在業務團隊深耕過，知道痛點所在的，這樣研發出來的系統和工具能夠和公司目前的項目所匹配發揮最大的作用，讓大家愛不釋手。
在做架構升級的時候對業務侵入性越小越好，業務團隊無感知最好，前提是我們的一些核心架構框架和中間件已經是統一的標準化的，有一些框架還是自己研發比較好，在之后的一些文中會提到這個觀點。
做業務往往變動大，我們總是會習慣很多事情先手動來做，慢慢形成了對工具化自動化理念沒有這么敏銳。如果在這個時候有局外人能參與一下說不定可以碰撞出很多好的框架和工具來幫助我們提高生產力，這其實是一個好事情。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/77358.html
摘要：架構團隊的人是不是很輕松，業務團隊天天加班搞項目，架構團隊貌似都是在喝茶聊天研究一些不實用的東西。架構團隊的架構師最好是在業務團隊深耕過，知道痛點所在的，這樣研發出來的系統和工具能夠和公司目前的項目所匹配發揮最大的作用，讓大家愛不釋手。 最近幾年寫博客確實寫得少了，初出茅廬的時候什么都愿意去寫，現在寫一點東西之前會反復斟酌是否有價值。工作十幾年了，做了N多個互聯網系統，業務涉及教育、游...
摘要：還可以初步判斷出問題的原因是異常導致還是突增的壓力所致。通過面板配置的服務調用量和業務進出量，排除上下游問題，定位出問題的模塊。 這里所說的六兄弟只指ELK套件（ElasticSearch+Logstash+Kibana）以及TIG套件（Telegraf+InfluxDb+Grafana）。 showImg(https://segmentfault.com/img/bVbhS81?w=...
摘要：同步寫服務負責第一時間把重要的數據落地和落緩存。因為或主從復制導致的一些事故也是層出不窮的。這也是圖中對于的寫入由專門的異步流程進行的原因。合理規劃好的方式，以及想好在后的全套查詢方案。合理利用不同數據源的特性，組合使用發揮所長，避免 這里所說的五件套是指關系型數據庫、索引型數據庫、時序型數據庫、文檔型數據庫和緩存型數據庫。 showImg(https://segmentfault.c...
摘要：同步寫服務負責第一時間把重要的數據落地和落緩存。因為或主從復制導致的一些事故也是層出不窮的。這也是圖中對于的寫入由專門的異步流程進行的原因。合理規劃好的方式，以及想好在后的全套查詢方案。合理利用不同數據源的特性，組合使用發揮所長，避免 這里所說的五件套是指關系型數據庫、索引型數據庫、時序型數據庫、文檔型數據庫和緩存型數據庫。 showImg(https://segmentfault.c...
閱讀 2571·2021-08-20 09:38
閱讀 1355·2019-08-30 15:43
閱讀 593·2019-08-29 17:13
閱讀 1601·2019-08-29 14:01
閱讀 1314·2019-08-29 13:29
閱讀 2322·2019-08-23 18:29
閱讀 2047·2019-08-23 17:51
閱讀 1915·2019-08-23 17:16
