一、背景知識
2、CDN（Content Delivery Network）：內容分發網，基本思路是儘可能避開互聯網上有可能影響數據傳輸速度和穩定性的瓶頸和環節，使內容傳輸的更快、更穩定。通過在網絡各處放置節點服務器所構成的在現有的互聯網基礎之上的一層智能虛擬網絡，CDN系統能夠實時地根據網絡流量和各節點的連接、負載狀況以及到用戶的距離和響應時間等綜合信息將用戶的請求重新導向離用戶最近的服務節點上。其目的是使用戶可就近取得所需內容，解決 Internet網絡擁擠的狀況，提高用戶訪問網站的響應速度。
二、架構演變
1、初始搭建
基於框架，運行在Tomcat容器中。文件、數據庫、應用程序在一個服務器上。
2、服務分離
隨着用戶量上升，單臺服務器無法滿足系統的負載，可以把應用服務器和數據服務器單獨部署，如果有條件也可以把文件服務器單獨部署。
3、反向代理
爲了提升服務處理能力，我們在Tomcat容器前加一個代理服務器，比如Nginx、apache也。用戶的請求發送給反向代理，然後反向代理把請求轉發到後端的服務器。嚴格意義上來說，Nginx屬於web服務器，一般處理靜態html、css、js請求，而Tomcat屬於web容器，專門處理JSP請求，當然Tomcat也是支持html的，只是效果沒有Nginx好而已。
4、動靜分離
基於以上Nginx反向代理，我們還可以實現動靜分離，靜態請求如html、css、js等請求交給Nginx處理，動態請求分發給後端Tomcat處理。Nginx 升級到1.9.5+可以開啓HTTP/2.0時代，加速網站訪問。當然，如果公司不差錢，CDN也是一個不錯的選擇。5、服務拆分
在這分佈式微服務已經普遍流行的年代，其實我們沒必要踩過多的坑，就很容易進行拆分。市面上已經有相對比較成熟的技術，比如阿里開源的Dubbo(官方明確表示已經開始維護了)，Spring家族的SpringCloud，當然具體如何去實施，無論是技術還是業務方面都要有很好的把控。
（1）Dubbo
（2）SpringCloud
- 服務發現——Netflix Eureka
- 客服端負載均衡——Netflix Ribbon
- 斷路器——Netflix Hystrix
- 服務網關——Netflix Zuul
- 分佈式配置——Spring Cloud Config
（3）微服務與輕量級通信
- 同步通信和異步通信
- 遠程調用RPC
- REST
- 消息隊列
6、持續集成部署
服務拆分以後，隨着而來的就是持續集成部署，你可能會用到以下工具：Docker、Jenkins、Git、Maven。基本拓撲結構如下所示：
整個持續集成平臺架構演進到如下圖所示：
7、服務集羣
Linux集羣主要分成三大類( 高可用集羣， 負載均衡集羣，科學計算集羣)。其實，我們最常見的也是生產中最常接觸到的就是負載均衡集羣。
（1）負載均衡實現
- DNS負載均衡，一般域名註冊商的dns服務器不支持，但博主用的阿里雲解析已經支持
- 四層負載均衡(F5、LVS)，工作在TCP協議下
- 七層負載均衡(Nginx、haproxy)，工作在Http協議下
（2）分佈式session
大家都知道，服務一般分爲有狀態和無狀態，而分佈式sessoion就是針對有狀態的服務。
8、讀寫分離
MySql主從配置，讀寫分離並引入中間件，開源的MyCat，阿里的DRDS都是不錯的選擇。如果是對高可用要求比較高，但是又沒有相應的技術保障，建議使用阿里雲的RDS或者Redis相關數據庫，省事省力又省錢。
9、緩存優化
引入緩存無非是爲了減輕後端數據庫服務的壓力，防止其"罷工"。常見的緩存服務有，Ehcache、OsCache、MemCache、Redis，當然這些都是主流經得起考驗的緩存技術實現，特別是Redis已大規模運用於分佈式集羣服務中，並證明了自己優越的性能。
10、消息隊列
（1）異步通知：比如短信驗證，郵件驗證這些非實時反饋性的邏輯操作。
（2）流量削鋒：應該是消息隊列中的常用場景，一般在秒殺或團搶活動中使用廣泛。
（3）日誌處理：系統中日誌是必不可少的，但是如何去處理高併發下的日誌確是一個技術活，一不小心可能會壓垮整個服務。工作中我們常用到的開源日誌ELK，爲嘛中間會加一個Kafka或者redis就是這麼一個道理(一羣人涌入和排隊進的區別)。
（4）消息通訊：點對點通信(個人對個人)或發佈訂閱模式(聊天室)。
11、日誌服務
消息隊列中提到的ELK開源日誌組件對於中小型創業供公司是一個不錯的選擇。
12、安全優化
以上種種，沒有安全做保證可能都會歸於零。
- 阿里雲的VPN虛擬專有網絡以及安全組配置
- 自建機房的話，要自行配置防火牆安全策略
- 相關服務訪問，比如Mysql、Redis、Solr等如果沒有特殊需求儘量使用內網訪問並設置鑑權
- 儘量使用代理服務器，不要對外開放過多的端口
- https配合HTTP/2.0也是個不錯的選擇
三、設計原則
1、高可用
- 負載均衡（負載均衡算法）
- 反向代理
- 服務隔離
- 服務限流
- 服務降級（自動優雅降級）
- 失效轉移
- 超時重試（代理超時、容器超時、前端超時、中間件超時、數據庫超時、NoSql超時）
- 回滾機制（上線回滾、數據庫版本回滾、事務回滾）
2、高併發
- 客戶端緩存（減少網絡帶寬、降低服務器壓力、減少網絡延遲）
- HTTP緩存
- 多級緩存
- 分佈式緩存
- 連接池
- 異步併發
3、分佈式事務
- 二階段提交(強一致)
- 三階段提交(強一致)
- 消息中間件(最終一致性)，推薦阿里的RocketMQ
4、隊列
- 任務隊列
- 消息隊列
- 請求隊列
5、數據庫技術
- 主從複製（易於擴展、可用備份）
- 讀寫分離（提高查詢速度、減少IO瓶頸、高擴展）
- 單體垂直擴容（業務分離、高擴展、高性能）
- 單體水平擴容（高擴展、高性能）
- 數據異構
6、網絡安全
- SQL注入
- XSS攻擊
- CSRF攻擊
- 拒絕服務（DoS，Denial of Service）攻擊
7、負載均衡
- 網絡（全局負載均衡，DNS輪詢、CDN網絡分發）
- 硬件（本地負載均衡，負載均衡器、地址轉換網關，效率高但價格貴）
- 軟件（本地負載均衡，Linux Virtual Server、Nginx、HAProxy）
四、必備工具
1、操作系統
Linux（必備）、微軟
2、負載均衡
DNS、F5、LVS、Nginx、OpenResty、HAproxy、負載均衡SLB（阿里雲）
3、分佈式框架
Dubbo、Motan、Spring-Could
4、數據庫中間件
DRDS （阿里雲）、Mycat、360Atlas、Cobar (不維護了)
5、消息隊列
RabbitMQ、ZeroMQ、Redis、ActiveMQ、Kafka
6、註冊中心
Zookeeper、Redis
7、緩存
Redis、Oscache、Memcache、Ehcache
8、集成部署
Docker、Jenkins、Git、Maven
9、存儲
OSS、NFS、FastDFS、MogileFS
10、數據庫
MySql、Redis、MongoDB、PostgreSQL、Memcache、HBase
11、網絡
專用網絡VPC、彈性公網IP、CDN
參考：https://www.cnblogs.com/smallSevens/p/7476838.html