互聯網發展至今各種應用層出不窮，用戶量動輒上億。所以如何構建一個優秀的高性能、高可靠的應用系統對每一個開發者至關重要。本文將我所學到和在工作中使用到的一些方法歸納總結，希望給其他同學起到一些借鑒作用，在以后的開發中遇到類似的問題，能快速的找到解決方案。本人主要使用語言是JAVA，所以下面不做特殊說明，都是使用JAVA語言
高性能的關鍵
要想做到高性能，我總結了三點：
- 緩存
- 拆分
- 異步
上面舉了一些三點中常見的情況，無論什么地方遇到性能瓶頸，謹記這三點，大多數時候都能找到解決方案。以下分別介紹在整個架構中各個方面對這三點的應用
無狀態服務
說無狀態服務我們首先要想到無狀態對象，無狀態對象簡單的可以理解為沒有Field的對象，比如model/entity對象就不屬于無狀態對象，因為他含有Field，比如典型MVC場景的**Controller，**Service就是無狀態的，他們只含有method。有的也是有狀態的，比如Structs2框架的Action，所以Structs2現在用得比較少了。有了無狀態對象，我們才有可能構建無狀態服務，因為請求鏈路中不包含有狀態對象，所以我們每一次請求都是獨立的，這樣的架構有助于我們服務進行擴展。
無狀態服務有時候不可避免的會遇到一些有狀態的對象，比如最常見的就是session。因為http請求本身是無狀態的，所以必須cookie和session配合使用，才能識別多次http請求屬于同一用戶。一般有兩種方法解決：
- 使用cookie存儲
- 使用分布式session服務
第一種就是將對象信息全部存儲在cookie中，通過相應的算法等在服務端將cookie中的信息讀出來。這些信息一般都會進行加密處理。
第二種方法，就是將session存儲在分布式數據庫或者分布式緩存中，一般存在redis或者memcache中。那這種服務擴展會依賴第三方數據庫或緩存的能力。淘寶有類似的組件，開源世界也有基于memcache和redis的分布式session
無狀態服務用到了拆分和緩存
業務拆分
無狀態可以使應用服務水平擴展，但是當單個應用太大太臃腫時，有必要對應用進行拆分。垂直拆分即按業務拆分，比如電商系統中，按照訂單系統，積分系統等進行拆分。拆分可以方便開發，更方便擴展。系統大了以后，每個業務的訪問量是不一樣的，比如買家系統肯定比賣家系統訪問量大得多，這時候就可以只增加買家系統的機器即可。
除了按照業務的不同拆分成不同的系統以外，針對我們的應用分層也可以進行拆分，一般分為應用層、邏輯層和原子層。應用層就是各種數據、邏輯業務的組裝，邏輯層含有大量可重用邏輯，原子層直接操作數據庫，一些基本的數據操作包含在其中。
不論以何種形式拆分，拆分以后的系統在物理層面上就分離開來，所以系統間的通信是拆分中最重要的問題所在。
RPC
在RPC服務之前已經許多系統通信的方法，比如RMI、WebService，但是RPC以更方便，更高效，跨平臺的方式現在成為主流的通信手段。幾乎每個大公司都有自己的RPC框架：淘寶的HSF、58的SCF，也有非常多優秀的開源框架：Dubbo、GRPC、Thrift等等。國內用dubbo的大公司也很多：京東、當當都是。
MQ
RPC調用一般是用在耦合比較重，同步調用的場景下。而MQ作為另一種異步通信的手段也被廣泛使用在各個業務中。常用的有：ActiveMQ、RabbitMQ、Kafka、RocketMQ。前兩個一般作為企業級應用，主要特點是支持非常多的特性和規范。后兩者是互聯網級的，擁有更強力的吞吐和更高的性能，但是犧牲了很多MQ的特性。mq一般用在要求最終一直性即可的場景，比如用戶注冊和發積分這兩個動作，可以用戶注冊以后直接返回前臺成功，然后發送注冊成功消息給mq系統，發積分動作訂閱注冊事件，消費mq的事件信息。
MQ最大的好處就是削峰和解耦，在RPC式的同步調用場景中，如果同一個邏輯中調用A和B，那么在擴展的時候，A和B一定是需要同時擴展的，但是有了消息以后，A發送消息給B，及時B暫時處理不了，也可以等到A峰值過后B繼續處理，即使B短期無法匹配A的發送消息能力也沒有關系。
數據庫拆分
一般項目都會經歷數據量從小到大的變化，所以數據庫拆分也是根據不同的數據量已經不同的階段進行相應的處理。
讀寫分離，這是大多數應用在遇到性能瓶頸第一要干的事。大多數互聯網應用都是讀占道90%以上的場景。所以一主多從，一個master做寫，其他slave做讀即可。但是這種主從模式也存在一些問題，比如有一些數據需要及時性比較高，就是在寫入以后馬上需要讀到。因為主從同步是通過log異步復制，所以存在數據不一致窗口，這個時候必須要通過強行讀取主庫來保證數據的安全，在開發的時候一定要注意。
垂直分割，就是通過拆分將不同的業務放在不同的數據庫中，這樣就可以減少單一數據庫的壓力，提高整體性能。垂直分割要注意的是業務邊界問題，邊界問題就是有一個表，感覺放在A中和放在B庫中都合適。這個就要靠經驗了，不能過分的考慮，因為其實不論你在之前分得有多好，在應用的迭代中，總會出現更多的找不到明確邊界的表。這個問題在業務模塊劃分中也是一樣。
水平分割，一般就是說sharding。將同一個表中的不同字段，拆分成不同的表，或者將同一張表按照hash或者業務字段分成不同的分片。這種一般需要DAL框架的支持，其中有TDDL、Cobar、Mycat等。主要就是通過框架讓程序編寫者對數據庫的拆分不可見，就像操作一個數據庫一樣。不過現在的DAL框架還不能達到這樣的目的，尤其是在跨庫事務的場景下，一般都需要其他方式處理。
跨庫事務/分布式事務
跨庫事務一般都是通過最終一致性來解決，即不強求ACID都能滿足，容許數據不一致的時間窗口，但是總會有一個時間點數據會到最終一致的狀態。解決方案非常的多，不過核心原理都是一樣，不外乎都是靠補償來完成的。
緩存的使用
計算機世界有一句名言：“計算機科學領域的任何問題都可以通過增加一個間接的中間層來解決”。緩存就是一種中間層。
使用緩存的場景非常非常的多，幾乎到了你能想到的所有地方。這里我們講通常的數據庫數據緩存
緩存一般有兩種，local和remote，一般來說使用一種緩存即可，因為緩存雖好，但是維護緩存的更新和刪除卻是一件非常麻煩得事。一般緩存可分為讀緩存（大多數場景）和寫緩存（一般針對數據安全性比較低的場景）。
比如將數據庫中的數據讀出時同時寫入緩存中，下一次讀數據的時候就可以直接讀取緩存中的數據，從而大大減小數據庫的壓力，說起來很簡單，其實這也存在很多種的架構，每種架構都有利弊，大家可以詳細去了解。
寫緩存，就是先將數據寫入緩存中，然后一段時間再持久化，這樣同樣會提高效率，這種方案的問題在于如果這時候宕機，部分數據將會丟失，所以適用于數據安全性較低的場景。
緩存雖然速度快，除了維護更新較為麻煩的是，內存也是較為昂貴的硬件，所以除了將熱點數據存儲在緩存中，一般緩存中維護數據的索引或者主要字段用于列表顯示，真正的大而全的數據還需要其他方法解決。
靜態化
對于大多數場景，我們的數據在一定時間都是不會變化的，或者說即使變化，也只是頁面的一小部分會發生變化，可以將不變化的部分單獨拿出來做靜態化。比如京東商城的頁面就是靜態化的，靜態化以后，數據不用每次都從緩存或者數據庫中取得，然后再封裝成頁面，而是直接請求返回靜態頁面，性能無疑提升了非常大。
除了以上常用的方法外，還要非常多的重要的方法：
- CDN加速
- DNS緩存
- 頁面緩存
- 使用分布式存儲
- 使用多線程編寫程序
| 
