一、基本概念
1、分佈式
系統中的多個模塊在不同的服務器上部署，即可稱之爲分佈式系統。如Tomcat和數據庫分別部署在不同的服務器上，或者兩個相同功能的Tomcat分別部署在不同的服務器上。
2、高可用
系統中部分節點失效的時候，其他節點可以繼續替它提供服務，則認爲系統具有高可用性。
3、集羣
一個特定領域的軟件部署在多臺服務器上並作爲一個整體提供一類服務，這個整體稱爲集羣。如zookeeper中的master和slave分別部署在不同的服務器上，共同提供服務，在常見的集羣中，客戶端可以連接任意一個節點獲得服務，並且如果有節點掛掉，其他節點可以替代它繼續提供服務。
4、負載均衡
客戶端發送請求的時候，服務器可以利用某種方式把請求均勻的分發到多個節點上，使得每個節點能夠均勻的處理請求負載。
5、正向代理和反向代理
系統內部要訪問外網的時候，統一通過一個代理服務器把請求發出去，代理服務器實現的就是正向代理。
如果有外部請求進入系統的時候，代理服務器把這些請求集中轉發到某臺服務器上，此時，代理服務器實現的就是反向代理。
所以，正向代理就是代理服務器代替系統內部向外發起請求的過程，而反向代理是外部請求通過代理服務器轉發到內部服務器的過程。
二、架構演進過程
1、單機架構
Tomcat和數據庫部署在同一個服務器上，瀏覽器訪問tabao網址，先通過DNS（域名系統）拿到具體的ip，然後瀏覽器直接訪問該IP的tomcat。
2、tomcat 和 數據庫分開部署
將數據庫和Tomcat分別部署，獨佔服務器資源。
3、引入本地緩存和分佈式緩存
使用memcached作爲本地緩存，使用Redis作爲分佈式緩存，將熱點數據放在緩存裏，降低數據庫的負載。
4、引入反向代理實現負載均衡
把tomcat部署在多個服務器上，使用反向代理（nginx）把請求均勻的發送到不同的tomcat上，可以抵禦高併發，但是數據庫壓力也會進而增加。
5、數據庫讀寫分離
把數據庫分爲多個讀庫和寫庫，通過同步機制把寫庫的數據同步到讀庫，可以利用緩存或的最新數據。Mycat，數據庫中間件，可以組織數據庫的讀寫分離和分庫分表。
6、數據庫按照業務分庫
把不同的業務保存到不同的數據庫中，使得業務之間的數據庫資源競爭降低，訪問量大的業務可以部署更多的服務器來支持。
7、把大表拆成小表
把數據庫按照一定的屬性進行表拆分等，稱爲分佈式數據庫。如分庫分表的管理和請求分發，由Mycat實現，SQL的解析由單機的數據庫實現，讀寫分離可能由網關和消息隊列來實現，查詢結果的彙總可能由數據庫接口層來實現等等，這種架構其實是MPP（大規模並行處理）架構的一類實現。
8 、使用LVS或F5來使多個Nginx負載均衡
一個負載已經不夠了
利用LVS和F5在nginx的上層在做一層負載。
LVS和F5是工作在網絡第四層的負載均衡的解決方案。
LVS：軟件，運行在操作系統內核態，可以對TCP請求或者更高層級的網絡協議進行轉發，性能遠高於nginx；
F5：負載均衡硬件。
可使用keepalived軟件模擬出虛擬IP，然後把虛擬IP綁定到多臺LVS服務器上，瀏覽器訪問虛擬IP的時候，就會被路由器重定向到真實的LVS服務器。
9、通過DNS輪詢實現機房間的負載均衡。
在DNS裏配置一個域名對應多個IP地址，每個IP地址對應到不同機房的虛擬IP，當用戶訪問連接的時候，DNS會根據策略（有可能是輪詢也有可能是其他策略），來返回某個IP。實現機房的水平擴展。
10、引入NoSQL數據庫和搜索引擎等技術
單單的數據庫已經無法滿足豐富的業務需求了。
數據庫中的數據越來越多的時候，或者查詢條件越來越複雜的時候，就必須引入其他技術來實現了。
如對於海量文件存儲，可通過分佈式文件系統HDFS解決，對於key value類型的數據，可通過HBase和Redis等方案解決，對於全文檢索場景，可通過搜索引擎如ElasticSearch解決，對於多維分析場景，可通過Kylin或Druid等方案解決。
當然，引入更多組件同時會提高系統的複雜度，不同的組件保存的數據需要同步，需要考慮一致性的問題，需要有更多的運維手段來管理這些組件等。
11、大應用拆成小應用
把大應用拆成小應用，相互之間獨立迭代，應用之間涉及的公公配置，通過分佈式配置中心zookeeper來解決。
不同應用之間存在的公共模塊，公共模塊改變，則所有的應用都要改一遍。
12、複用的功能抽離成微服務
對於所有應用都能用到的小模塊，進行抽離，做成單獨的服務來管理，也就是微服務，應用和服務之間通過http、tcp、rcp請求等多種方式來訪問公共服務，每個單獨的服務單獨管理。可以通過Dubbo、SpringCloud等框架實現服務治理、限流、熔斷、降級等功能，提高服務的穩定性和可用性。
不同服務的接口訪問方式不同，應用代碼需要適配多種訪問方式才能使用服務，此外，應用訪問服務，服務之間也可能相互訪問，調用鏈將會變得非常複雜，邏輯變得混亂。
13、引入企業服務總線ESB屏蔽服務接口的訪問差異
微服務和應用之間增加ESB統一進行協議轉換，應用通過ESB來訪問後端服務，服務與服務之間也用ESB來訪問。
把單個應用拆成多個應用，公共服務單獨抽取出來管理，並使用企業總線來解除服務之間的耦合問題，稱爲SOA（面向服務）架構。
微服務架構：把系統中的公共服務抽離出來單獨運維。
SOA架構：一種拆分服務，使服務接口訪問變得統一。
14、引入容器化技術實現運行環境隔離與動態服務管理
目前最流行的容器化技術是Docker，最流行的容器管理服務是Kubernetes（K8S），應用/服務可以打包成Docker鏡像，通過K8S來動態發佈和部署鏡像。Docker鏡像可理解爲一個能運行應用/服務的最小的操作系統，裏面放着代碼，運行環境跟實際的需要設置好，把Docker打包成鏡像，就可以分發到需要部署相關服務的機器上，直接啓動Docker鏡像可以啓動服務，使服務的部署和運維變得簡單。
大促可以增加服務器和鏡像的部署，結束之後關閉鏡像就好。
15、以雲平臺承載系統
把系統部署在雲服務上，利用雲服務的海量機器資源，解決動態硬件資源的我呢提，如遇到大促，則在雲平臺臨時申請更多的資源，結合Docker和K8S快速部署服務，大促結束之後，釋放資源。
所謂的雲平臺，就是把海量的機器資源，通過統一的資源管理，抽象成一個整體，按需動態申請硬件資源，並且提供通過的操作系統，提供常見的技術組件供用戶使用，提供開發好的應用。
IaaS：基礎設施即服務。對應於上面所說的機器資源統一爲資源整體，可動態申請硬件資源的層面；
PaaS：平臺即服務。對應於上面所說的提供常用的技術組件方便系統的開發和維護；
SaaS：軟件即服務。對應於上面所說的提供開發好的應用或服務，按功能或性能要求付費。
三、架構設計總結
1、架構的調整是否必須按照上述演變路徑進行？
不是的，以上所說的架構演變順序只是針對某個側面進行單獨的改進，在實際場景中，可能同一時間會有幾個問題需要解決，或者可能先達到瓶頸的是另外的方面，這時候就應該按照實際問題實際解決。如在政府類的併發量可能不大，但業務可能很豐富的場景，高併發就不是重點解決的問題，此時優先需要的可能會是豐富需求的解決方案。
2、對於將要實施的系統，架構應該設計到什麼程度？
對於單次實施並且性能指標明確的系統，架構設計到能夠支持系統的性能指標要求就足夠了，但要留有擴展架構的接口以便不備之需。對於不斷髮展的系統，如電商平臺，應設計到能滿足下一階段用戶量和性能指標要求的程度，並根據業務的增長不斷的迭代升級架構，以支持更高的併發和更豐富的業務。
3、服務端架構和大數據架構有什麼區別？
所謂的“大數據”其實是海量數據採集清洗轉換、數據存儲、數據分析、數據服務等場景解決方案的一個統稱，在每一個場景都包含了多種可選的技術，如數據採集有Flume、Sqoop、Kettle等，數據存儲有分佈式文件系統HDFS、FastDFS，NoSQL數據庫HBase、MongoDB等，數據分析有Spark技術棧、機器學習算法等。總的來說大數據架構就是根據業務的需求，整合各種大數據組件組合而成的架構，一般會提供分佈式存儲、分佈式計算、多維分析、數據倉庫、機器學習算法等能力。而服務端架構更多指的是應用組織層面的架構，底層能力往往是由大數據架構來提供。
4、有沒有一些架構設計的原則？
N+1設計：統中的每個組件都應做到沒有單點故障；
回滾設計：確保系統可以向前兼容，在系統升級時應能有辦法回滾版本；
禁用設計：：應該提供控制具體功能是否可用的配置，在系統出現故障時能夠快速下線功能；
監控設計：在設計階段就要考慮監控的手段；
多活數據中心設計：若系統需要極高的高可用，應考慮在多地實施數據中心進行多活，至少在一個機房斷電的情況下系統依然可用；
採用成熟的技術：剛開發的或開源的技術往往存在很多隱藏的bug，出了問題沒有商業支持可能會是一個災難；
資源隔離設計：應避免單一業務佔用全部資源；
架構應能水平擴展：系統只有做到能水平擴展，纔能有效避免瓶頸問題；
非核心則購買：非核心功能若需要佔用大量的研發資源才能解決，則考慮購買成熟的產品；
使用商用硬件：商用硬件能有效降低硬件故障的機率；
快速迭代：系統應該快速開發小功能模塊，儘快上線進行驗證，早日發現問題大大降低系統交付的風險；
無狀態設計：服務接口應該做成無狀態的，當前接口的訪問不依賴於接口上次訪問的狀態。