架構筆錄 別人架構設計經驗

2021-04-20 08:18:55 字數 827 閱讀 1096

1、**流量影響整個**架構的設計

2、**架構的設計是一種平衡的設計,沒有完美的架構,架構的設計要簡單靈活,便於擴充,因此找出平衡點是關鍵

3、**架構的設計不要過渡,考慮到1~2年內的使用者需求即可

4、小**與大**的區別在於,當資料量達到一定級別,小問題會變成大問題

5、大的**架構不適合做小事情,小架構也做不了大事情

6、即使通過硬體的擴充,架構的負荷已經超過設計負荷的5~10倍,就要考慮重新設計系統的架構,舉例來說就是乙個研發團隊是10個人以內,可以採用家長式管理,而到100人以內,管理方式必須變化,因此架構也要根據負荷情況不斷變化

7、要通過**的監控分析,來找到系統瓶頸的臨界點

8、任何乙個**的開發都會是從集中式-分布式-高階分布式的方向過渡

9、google可以通過機器的擴充來達到**擴充套件的要求,依賴的是系統架構設計中的線性可擴充套件性

10、中國的**架構和運營要考慮自身的網路運營環境如網通和電信網路的區別

11、**架構的設計也要考慮運營成本的問題,能得到的資源往往比預期的要少

12、架構的設計要考慮安全性和惡意客戶的攻擊

13、**的負載要通過測試來驗證,並通過監控系統進行分析,並且要做好風險的應對,系統的負載永遠不要超過80%

14、架構的設計中無時無刻不存在折中的情況,痛苦的取捨是必須作出的抉擇

15、架構設計中要充分考慮團隊、領導和使用者間的溝通,龍的那片不能動的鱗也要有策略的動一動

16、架構設計要充分分析資料的特性,讀和寫哪個更重要,例如google的搜尋根本不用資料庫,甚至連檔案系統都進行重寫,以達到最快的資料讀取效果

17、**架構的設計要考慮api介面的開放性

架構設計經驗分享

不是的,以上所說的架構演變順序只是針對某個側面進行單獨的改進在實際場景中,可能同一時間會有幾個問題需要解決,或者可能先達到瓶頸的是另外的方面,這時候就應該按照實際問題實際解決。如在 類的併發量可能不大,但業務可能很豐富的場景,高併發就不是重點解決的問題,此時優先需要的可能會是豐富需求的解決方案。對於...

web架構設計經驗分享

架構設計的幾個心得 一,不要過設計 never over design 這是乙個常常被提及的話題,但是只要想想你的架構裡有多少功能是根本沒有用到,或者最後廢棄的,就能明白其重要性了,初涉架構設計,往往傾向於設計大而化一的架構,希望設計出具有無比擴充套件性,能適應一切需求的增加架構,web開發領域是個...

Web架構設計的經驗分享

一 不要過設計 never over design 這是乙個常常被提及的話題,但是只要想想你的架構裡有多少功能是根本沒有用到,或者最後廢棄的,就能明白其重要性了,初涉架構設計,往往傾向於設計 大而化一的架構,希望設計出具有無比擴充套件性,能適應一切需求的增加架構web開發領域是個非常動態的過程,我們...