1，拆分
拆分是爲了降低系統的複雜度，模塊或服務“自治”，符合軟件設計中“單一職責”原則。拆分的太粗或者太細都會有問題，這裏沒有什麼標準答案。應該按照領域拆分，結合業務複雜程度、團隊規模等實際情況來判斷。可以想象5個人的小團隊去維護超過30多個系統，那一定是很痛苦的;
2、隔離
拆分本質上也是一種系統級、數據庫級的隔離。此外，在應用內部也可以使用線程池隔離等。分清“主、次”，找出“高風險”的並做好隔離，可以降低發生的機率。
服務器級別隔離，比如我們需要考慮爲VIP建設單獨的服務器集羣，甚至是IDC網絡接入；服務級別隔離，爲重要的業務線單獨分配並且路由到單獨的虛擬機或POD，爲大文件上傳的服務進行服務拆分部署到具有更高IO和網絡帶寬的服務器上；進程內部進行資源隔離，比如在使用Java 8 ParallelStream的時候考慮採用單獨的線程池來處理任務，比如在使用Netty處理較慢的業務操作的時候配置單獨的業務線程池進行處理，和IO處理的線程池進行隔離。
3、冗餘
避免單點，容量冗餘。機房是否單點，硬件是否單點，應用部署是否單點，數據庫部署是否單點，鏈路是否單點…硬件和軟件都是不可靠的，冗餘（“備胎”）是高可用保障的常規手段;
4、異步化
儘可能的異步化，儘可能的降低依賴。異步化某種程度可以提升性能，降低RT，還能減少直接依賴，是常用的手段;
使用線程池來進行異步處理一些非關鍵的任務，使用MQ進行異步處理。比如下單的主流程就是落地和發MQ通知其它模塊，落地後後續出庫、物流的流轉全部是其它模塊在收到MQ消息後異步處理的。
極端一點例子，對於一些用戶行爲數據分析平臺需要接收客戶端上傳的各種事件進行分析，如何可以抗住100萬TPS的併發進行處理？最簡單的方式就是直接搞10臺Nginx負載均衡，Nginx只是記錄AccessLog返回200（單機抗住10萬TPS一點不是問題），後續由定時任務拉取AccessLog進行數據分析。
5、合併請求
每一個獨立的網絡請求都是開銷，我們可以通過合併動態靜態的請求來減少請求數量。現在的Web前端應用基本都會在構件打包階段對腳本、CSS進行壓縮合並等預處理。
對於後端動態請求而言，我們更需要在設計階段考慮接口的粒度，並且區分對待實時處理和批處理的架構，數據批處理的工作不太適合通過循環調用遠程接口的方式實現。
6、邊緣加速
CDN就是邊緣加速的一個例子，一般而言我們使用CDN不僅僅爲了讓用戶訪問數據更快，而且通過在邊緣節點做一定的緩存策略可以讓節點幫我們擋住很大部分的流量（特別是靜態資源，除了回源的請求都可以由CDN擋掉）。
更進一步說，一些CDN可以做一些定製化的處理，允許業務方提供一些簡單的腳本在節點做邊緣計算，比如在秒殺場景下根據一定的策略直接在CDN節點進行計算，放行0.1%的用戶流量進入我們的後端系統。
內容分發網絡，部署在網絡運營商機房，通過將靜態頁面內容分發到離用戶最近的CDN 服務器，使用戶可以通過最短路徑獲取內容。
7、空間換時間
緩存
一種是在程序啓動的時候從外部數據源初始化大量的不怎麼變的數據到內存中，在內存中形成面向搜索友好的數據結構（比如哈希表），提供快速的數據訪問，之後所有的請求都無需請求數據源，採用定時拉取或監聽變動消息的方式同步變動。
另外一種是利用分佈式緩存做計算結果的緩存，具有比較短的過期時間，可以擋掉大量重複請求，對於搜索條件組合較多的請求命中率差。當然，緩存除了使用空間換時間之外，一般還會利用存儲介質的性能差異來提升性能，所以我們看到通過內存緩存數據比較常見。
緩衝
對非時間敏感的調用進行適當蓄水，甚至合併，一次性提交到後端服務，比如玩一個抓紅包的遊戲，用戶在屏幕上點點點來抓紅包，是否真的有必要每次都向數據庫更新紅包餘額呢？
可以在服務端緩衝一下，10次更新一次餘額甚至整個遊戲只提交一次？
8、面向數據讀取優化
比如微博的實現在發微博的時候找出大V下一定數量的活躍的在線粉絲，比如5000個，直接把微博寫入他們的關注微博列表中去（推數據過去），這樣在那些粉絲刷新自己微博首頁的時候就能更快（不用去關聯拉數據了）。
又比如許多時候我們會做所謂的固化視圖的工作，在寫入數據的時候就直接寫爲我們之後要讀取的複雜數據結構（比如數據需要Join N個表才能獲得的，在寫入的時候就直接組成這樣的數據寫到數據表）。
或者可以說我們做哈希結構，做B樹索引，做倒排索引都是這樣的思路，使用一些有利於我們之後讀取、查詢和搜索的數據結構來加速數據的讀取（雖然寫入的時候耗時多一點，並且需要佔用額外的空間）。
或者預測到將來用戶可能會訪問的請求，進行預加載或是預處理，然後之後真正請求到來的時候這個訪問就會特別快。
9、任務並行化
可以把多個子任務提交到線程池執行，然後等待所有任務都完成後進行結果彙總，這樣總的耗費時間就是最慢的那個子任務的執行時間。
10、負載均衡
將多臺應用服務器組成一個集羣，通過負載均衡技術將用戶請求分發到不同的服務器上，以應對大量用戶同時訪問時產生的高併發負載壓力。
負載均衡的策略，Backend健康檢測，服務失效後從負載均衡摘除，恢復後的上線，發佈系統和負載均衡的聯動。比如有上萬臺服務需要負載，那麼可能需要10組Nginx來做負載均衡，這10組Nginx本身也需要進行負載均衡，那麼可以在最上層使用硬件F5或Haproxy在4層再做一層負載，也就是類似主備Haproxy->Nginx集羣->tomcat集羣類似的架構。
11、分區處理
指的是把數據、任務進行分區，分發到不同的節點同時處理，提高並行度。數據表的分表分庫，然後由類似Proxy的中間件進行數據路由和彙總處理；比如Java 8 parallelStream的思想把數據分成多份在不同的線程同時處理；比如ConcurrentHashMap鎖分段的思想，把全局的鎖改爲分段鎖減少衝突；比如kafka的分區處理擴展等。
12、限流
任何系統對於壓力的負荷是有邊界的，超過這個邊界之後系統的SLA肯定無法滿足標準，導致大家都無法好好用這個服務。計數器算法、令牌桶、漏桶。
13、降級
是否可以考慮降級爲客戶端這邊之前寫死的一些靜態的活動商品列表；在外部地圖API訪問超時的時候需要考慮降級方案，把騎行距離改爲根據經緯度算出來的直線距離，至少讓服務基本可用。
14、熔斷
一個客戶端可能會依賴幾十個其它的服務，有任何一個位於同步調用的外部服務出現超時，即使客戶端的ReadTimeOut設置的時間不長也對客戶端是很大的壓力和負擔。
根據請求失敗率熔斷，比如在一定時間內有一定百分比的請求是失敗的，那麼就開啓熔斷；
根據響應時間熔斷，比如一定時間內的請求平均響應時間超過N秒則開啓熔斷。
在外部服務遇到問題的時候要自動進行熔斷，在外部服務恢復後嘗試半恢復，最後完全恢復訪問。
15、柔性化
在電商訂單的場景中，下單，扣庫存，支付是一定要執行的步驟，如果失敗則訂單失敗。但是加積分，發貨，售後是可以柔性處理，就算出錯也可以通過日誌報警讓人工去檢查，沒必要爲加積分損失整個下單的可用性。
16、靜態化
對於訪問量特別大而更新又不很頻繁的動態頁面，可以將其靜態化，即生成一個靜態頁面，利用靜態頁面的優化手段加速用戶訪問，如反向代理、CDN、 瀏覽器緩存等。
靜態資源，如JS,CSS 等文件部署在專門的服務器集羣上，和Web 應用動態內容服務分離，並使用專門的（二級）域名。
17、瀏覽器優化
通過優化響應頁面，加快瀏覽器頁面的加載和顯示，常用的有頁面緩存、合併HTTP 減少請求次數、使用頁面壓縮等。合併CSS,合併JavaScript,合併圖片，設置HTTP 頭中Cache-Control 和Expires 的屬性，可設定瀏覽器緩存，緩存時間可以是數天，甚至是幾個月；CSS 放在頁面最上面、JavaScript 放在頁面最下面。
以上總結了普通的幾點，下面附上比較收藏比較經典乾貨的文章：
1， 雙十一大型電商統一服務架構實戰 https://mp.weixin.qq.com/s/n8G-E61iQttpBSBjN07zZQ
2，這次咱們從根源聊：16招搞定高併發架構設計 https://m.sohu.com/a/320224240_411876/?_trans_=010005_pcwzywxewmsm&from=timeline
3，架構 | 大型網站分佈式高併發架構設計彙總 https://mp.weixin.qq.com/s/3niKVzeW_g-a60QTIjbRpQ
4，爲了做到微服務的高可用，鬼知道我出了多少張牌 https://mp.weixin.qq.com/s/8g-C6Li0FohMqKF-IN1vlQ
5，阿里爲啥值4萬億？看它如何應對億級高併發大流量？如何保障高可用和穩定性，就知道了！ https://mp.weixin.qq.com/s/eDlu8f99NfdBqt-OPFqb_A
6，披荊斬棘，餓了麼數據庫高可用架構演進！ https://mp.weixin.qq.com/s/ezjugOU473aLuEegk3Eryg
7，億級PV，常見性能優化策略總結與真實案例 https://mp.weixin.qq.com/s/npnikNTvrxusePmmhjeuFw
8，從訂單業務模塊到分佈式高可用：美團外賣訂單中心的演進之路 https://mp.weixin.qq.com/s/CxXzo1-hveKLqI4nFsSsFg
9，分佈式架構－－基本思想彙總 https://mp.weixin.qq.com/s/pu9lrWZQvDAVzYG1LuBE9w
10，大型分佈式網站架構技術總結 https://mp.weixin.qq.com/s/71UG1gJK_I81MIEg7D1HEg
11，支付平臺架構評審 https://mp.weixin.qq.com/s/OES3aD6V-M40u6FjZb9Qsg
12，架構師眼中的高併發架構 https://mp.weixin.qq.com/s/CeUFUwVctTbQ50fBuPcydQ
13，盤點電商大戰背後的技術力量支撐 https://mp.weixin.qq.com/s/B5TqW0o_atz3PfgMxhj3CQ
14，詳解：淘寶大秒殺系統是如何設計的？ https://mp.weixin.qq.com/s/SV-FHtxTxKIK9CyHsWuDYA
15，性能優化指南 https://mp.weixin.qq.com/s/Ok_jyuLdn6IxXa8wk1crbQ
16，大型網站技術架構：摘要與讀書筆記 https://mp.weixin.qq.com/s/g9Js_sd-vhQSNh20YbLypQ
17，構建高併發高可用的電商平臺架構實踐 https://mp.weixin.qq.com/s/spZpmt3wDVz9BPUlzNDRzQ
18，秒殺系統架構分析與實戰，一文帶你搞懂秒殺架構！ https://mp.weixin.qq.com/s/x3JIxNfCOfIF7GAn9rFMAA
19，各大互聯網公司架構演進之路差不多都在這了 https://mp.weixin.qq.com/s/rBwAWOF9da4yCUKy23eEnA
20，手把手教你從零開始搭建創業公司後臺技術棧 https://mp.weixin.qq.com/s/D6CSEklDkhNMZ_BvkK5UoA