資料內容：
架構設計總結
架構的調整是否必須按照上述演變路徑進行？ 不是的，以上所說的架構演變順序只是針對某個側面進行單獨的
改進，在實際場景中，可能同一時間會有幾個問題需要解決，或者可能先達到瓶頸的是另外的方面，這時候就
應該按照實際問題實際解決。如在政府類的并發(fā)量可能不大，但業(yè)務可能很豐富的場景，高并發(fā)就不是重點解決
的問題，此時優(yōu)先需要的可能會是豐富需求的解決方案。
對于將要實施的系統(tǒng)，架構應該設計到什么程度？ 對于單次實施并且性能指標明確的系統(tǒng)，架構設計到能夠支
持系統(tǒng)的性能指標要求就足夠了，但要留有擴展架構的接口以便不備之需。對于不斷發(fā)展的系統(tǒng)，如電商平臺，
應設計到能滿足下一階段用戶量和性能指標要求的程度，并根據(jù)業(yè)務的增長不斷的迭代升級架構，以支持更高的
并發(fā)和更豐富的業(yè)務。服務端架構和大數(shù)據(jù)架構有什么區(qū)別？ 所謂的“大數(shù)據(jù)”其實是?量數(shù)據(jù)采集清洗轉換、數(shù)據(jù)存儲、數(shù)據(jù)分析、
數(shù)據(jù)服務等場景解決方案的一個統(tǒng)稱，在每一個場景都包含了多種可選的技術，如數(shù)據(jù)采集有Flume、 Sqoop、
Kettle等，數(shù)據(jù)存儲有分布式文件系統(tǒng)HDFS、FastDFS，NoSQL數(shù)據(jù)庫HBase、MongoDB等，數(shù)據(jù)分析有Spark技
術棧、機?學習算法等。總的來說大數(shù)據(jù)架構就是根據(jù)業(yè)務的需求，整合各種大數(shù)據(jù)組件組合而成的架構，一
般會提供分布式存儲、分布式計算、多維分析、數(shù)據(jù)倉庫、機?學習算法等能力。而服務端架構更多指的是應用
組織層面的架構，底層能力往往是由大數(shù)據(jù)架構來提供。
有沒有一些架構設計的原則？
N+1設計。系統(tǒng)中的每個組件都應做到沒有單點故障；
回滾設計。確保系統(tǒng)可以向前兼容，在系統(tǒng)升級時應能有辦法回滾版本；
禁用設計。應該提供控制具體功能是否可用的配置，在系統(tǒng)出現(xiàn)故障時能夠快速下線功能；
監(jiān)控設計。在設計階段就要考慮監(jiān)控的手段；
多活數(shù)據(jù)中心設計。若系統(tǒng)需要極高的高可用，應考慮在多地實施數(shù)據(jù)中心進行多活，至少在一個機房
斷電的情況下系統(tǒng)依然可用；
采用成熟的技術。剛開發(fā)的或開源的技術往往存在很多隱藏的bug，出了問題沒有商業(yè)支持可能會是一個
災難；
資源隔離設計。應避免單一業(yè)務占用全部資源；
架構應能水平擴展。系統(tǒng)只有做到能水平擴展，才能有效避免瓶頸問題；
非核心則購買。非核心功能若需要占用大量的研發(fā)資源才能解決，則考慮購買成熟的產品；
使用商用硬件。商用硬件能有效降低硬件故障的機率；
快速迭代。系統(tǒng)應該快速開發(fā)小功能模塊，盡快上線進行驗證，早日發(fā)現(xiàn)問題大大降低系統(tǒng)交付的風
險；
無狀態(tài)設計。服務接口應該做成無狀態(tài)的，當前接口的訪問不依賴于接口上次訪問的狀態(tài)。
