1、雞蛋不能都放在一個籃子里——單體應用演進到微服務應用 想象一下，你家樓上有個業主在裝修，施工不當，導致你家裡有個卧室漏水了，這個時候你怎麼辦？ 正常人都是喊人來修，然後先臨時搬到另外的房間睡覺。而不是在維修人員修卧室的時候，全家搬到酒店裡去睡。因為，只是那一個房間漏水，其它房間還是能夠正常使用的 ...
想象一下，你家樓上有個業主在裝修，施工不當，導致你家裡有個卧室漏水了，這個時候你怎麼辦？
在程式中的體現：
單體應用：
項目所有的模塊都打包到一起，然後扔到伺服器上部署運行。假如這個項目是一個電商項目，裡面有下單模塊，派送模塊等等。你把這些模塊想象成你家的房間，一個模塊對應一個房間，現在派送模塊對應的房間漏水了，這個時候怎麼辦？沒辦法，只能全家出去住了，為啥，因為你所有的模塊都打包到一個項目裡面去了，一個模塊掛了，整個項目都得停下來，等派送模塊修好了，再啟動項目繼續運行。缺點一目瞭然。
微服務應用：
為瞭解決單體式應用的不足，微服務的概念橫空出世。核心就是“拆”，把一整個項目按模塊拆成一個個的小項目，所有拆分的小項目之間進行合作通信形成原先的整體項目。這樣有什麼好處，當我們的項目在運行的時候，同樣派送模塊掛了，這時候掛了的只有這一個模塊服務，你其它模塊的服務還是能後正常運行，用戶還是能夠正常下單，老闆還是正常賺錢。維修人員只需要把派送模塊修好之後重新運行起來，然後加進來繼續給用戶下的單送貨。當然，最重要的就是，你不用全家出去睡了！
2、三個臭皮匠頂個諸葛亮——系統應用的高併發怎麼處理
在學校的時候，自己的畢業課設是《網上求職招聘管理系統》，做完了之後，和同學室友測了請求響應都很迅速，沒啥毛病。但是，當在面試的時候，面試官問我這個系統的併發量、性能問題的時候，我只能說額，今天天氣真不錯。
實際在公司做項目的時候，不僅僅是系統能夠正常跑起來這麼簡單而已，更重要的是系統能夠承受住的用戶併發請求。當用戶數量龐大時，我們就需要更好的機器、更好的CPU、更大的記憶體、更好的網路環境去應對請求的高併發。
為了應對這種高併發的情況，兩種處理方式：
垂直擴展
那就是在一臺伺服器的基礎上，不斷升級其中的配件，加入更多的磁碟、升級更大的記憶體、買更好更快的CPU......更加強大的伺服器當然能夠處理更高的併發量。總結一句話，充錢使你更加強大。
但是，這樣也是有弊端的，首先就是老闆與客戶不一定願意花錢（有錢當我沒說），更重要的一點還是，就算你給這台伺服器 所有的配件都升級成最好的。但是，單台伺服器處理性能還是有瓶頸的。那怎麼辦呢？俗話說得好，三個臭皮匠能頂一個諸葛亮。於是水平擴展出現了。
水平擴展
既然一臺伺服器有瓶頸，那就多換幾個機器來處理用戶請求，把單體應用轉變成分散式集群應用。不僅省錢，處理併發 的能力也好。
3、緩存架構提高系統的讀能力
講個簡單的場景：前臺用戶訪問系統應用的數據，後臺是通過查詢資料庫的數據返回給前端展示的，在低訪問量的情況下，這簡單的流程，系統還是能夠妥妥處理的。但是，你想想，在淘寶雙11的活動下，成千上萬的用戶同時訪問淘寶，購買商品，同一個時間點，幾百萬幾千萬的用戶請求往後臺的資料庫打，能直接把後臺資料庫給打崩。
為了防止這種情況的發生，緩存出現了。在原來的邏輯中間加一層緩存，前臺用戶請求來的時候，不用每次都去資料庫里操作數據，而是將應用程式需要的數據暫存在緩存之中，請求來了，先查緩存，緩存中有的話就不用去資料庫里查。這樣就能夠大大減少資料庫直接被用戶打崩的情況，而且緩存是在記憶體中的，用戶請求不用去I/O磁碟，而是直接讀取記憶體數據，快得很。
4、非同步架構提高系統的寫能力
緩存架構的出現，大大提高了程式的讀能力，那麼系統寫的能力有沒有什麼方法提高呢？這時候，非同步架構的概念就出現了，也就是消息隊列的應用。
同步概念
快遞員在送快遞的時候，往往都會要求買家在收到快遞的時候簽個名字，有的時候，買家不在家還需要站在門口等買家回來，浪費自己送快遞的時間。
在程式中的體現：A系統向另一個B系統發了一個消息，此時，A系統要收到B系統的回信才能進行其他的操作，否則這個進程就一直卡在這裡。問題來了，要是B系統能夠立即回覆還好，要是因為網路等原因一直在延遲，那麼A系統的CPU資源就一直在那裡等著，也就是說那些CPU資源就是被浪費了。
非同步概念
快遞員在送快遞的時候，不需要用戶直接簽名簽收，我直接給你放快遞櫃里就行了，你人回家直接去快遞櫃里掃碼取件就行了。
在程式中的體現：你在微信給你的好朋友發一條消息，發完之後你就可以不用管了，手機想玩啥就玩啥，不用等到對方回了你的消息你才能夠使用手機玩別的。
流程示意圖：
你只需要將消息發給中間新加入的消息隊列組件，消息隊列在收到你發的消息之後就給你立即返回，至於這條消息發給另一個用戶的操作消息隊列自己會處理就不用你關心了。
這樣做的好處：
-
給你快速的響應，避免白白等待，浪費系統資源。
-
流量削峰，在淘寶雙11活動下，加入這個消息隊列，成千上萬的用戶請求過來，系統一時間處理不過來，就可以把用戶的請求放到這個消息隊列裡面，讓系統進行排隊處理。
-
降低系統的耦合度，在調用者系統和被調用者系統之間加入消息隊列，這樣兩者之間的代碼依賴就少了，交互的部分交給中間的消息隊列處理就好了。
5、解決機器不幹活——負載均衡的出現
前面說到，使用多台機器代替一臺機器用來處理前臺用戶的請求。那麼問題來了，前臺過來的應用，發到後臺來，後臺三個伺服器大眼瞪小眼，誰來幹活呢？這時候負載均衡就出現了。
請求來到後臺的時候，先要經過負載均衡處理器的一道處理，這裡可以想象這個負載均衡器是一個包工頭，項目來的時候，把項目分給自己手下管理的小弟來做。
當然，這個負載均衡里會涉及到很多不同的演算法，輪詢、隨機、最多、最少......等。簡單來講就是，輪詢演算法包工頭會把上面派下來的任務平均分到每一個小弟的手上，當然，包工頭也可以根據心情，故意讓你多做或者故意讓你少乾，這就是裡面你選擇的負載均衡演算法。
6、狡兔三窟——數據存儲
前面說到，大量的用戶請求都需要訪問資料庫。你想過沒有，如果系統只有一個資料庫，當這個資料庫因為停電啥的故障壞了怎麼辦，那麼整個系統就都涼涼了。為瞭解決這個問題，那就是給數據做好備份，多台資料庫伺服器提供用戶服務。當一臺資料庫伺服器掛了的時候，其它的還可以頂上去，繼續給用戶提供服務。
用專業的話來講就是，主從複製，整個伺服器有一臺主伺服器多台從伺服器，從伺服器定時同步主伺服器的數據，這樣，當主伺服器掛了的時候，從伺服器頂上，系統照樣能夠正常運行。
這種技術手段在大部分資料庫里都有使用，如mysql、redis，
7、看起來不太聰明的樣子——搜索引擎
相信對於程式員來講，面向百度谷歌編程這句話大家都比較熟悉。但是，當程式出現bug的時候，打開百度的搜索欄，想了半天不知道怎麼搜索問題。為了能夠快速找到問題的解決方案，當然是輸入的關鍵詞越接近問題，顯示出來的答案更加準確。
想百度谷歌這種大型的搜索網站都有屬於自己的一套搜索引擎，根據這些搜索引擎裡面的演算法，可以根據我們提供的搜索關鍵字，排序顯示給我們問題的答案。
現在比較熱門搜索引擎有es、solr。
轉載聲明
轉載出自：https://www.cnblogs.com/l12138h/p/16353694.html
