一、單體與集羣
1.1 問題
維護不方便，資源佔用高，但是調用方便，可以直接獲取對象調用數據共享，比如session，併發低，容易崩潰
1.2 解決單點問題
集羣，集羣並不能解決資源佔用高的問題，但是提高了可用性和併發量，但是帶來了問題：
（1）如何分發請求（負載均衡）
（2）狀態共享（session共享）
1.2.1 負載均衡
負載均衡就是從一堆一樣的東西里挑一個
- 隨機挑選
- 輪詢
- 能者多勞（權重）
- 哈希（讓一個主機一直處理）
- 最少活躍數（空閒主機處理）
1.2.2 session共享（狀態共享）
- 保存到redis
- 同步到其他服務器（不可選，因爲需要佔用其他服務器大量資源來同步數據）
- 如果使用功能hash模式的話，沒有共享問題，但是注意可能會產生故障問題，hash所指向的服務器會出現問題，所以我們使用一些特定算法來對狀態數據進行操作，比如jwt
二、拆分與合併
2.1 準則
按照項目具體清空進行拆分
2.1.2 拆分類型
（1）按照模塊拆分
登錄、註冊和商品拆分出來
（2）按照訪問量拆分
商品的查詢拆分出來
訂單的查詢拆分出來
優惠券拆分爲發券和用券系統
（3）按照查詢
查詢、修改
2.2 合併
我們把代碼拆分，但是最終還要互相調用。
分佈式，節點多，機器多，每個功能對應的機器到底是哪個我們不知道，而且這些機器會隨着訪問量進行增刪
2.2.1 註冊中心
我們不能主動找到服務器在哪，但是服務器可以主動告訴我們它在哪。
註冊中心地址是確定的，然後所有的服務器去註冊中心進行註冊，註冊其實就是把自己的信息通過註冊中心提供的接口寫進去，註冊中心會保存。
- zookeeper 保存的是接口的名字，
/dubbo/接口名/providers(consumers,routers路由網關負載均衡)在dubbo下有很多的接口，都是保存的服務，按照規則，我們可以放入，也可以獲取調用服務。一致性。
一堆的api，主要是和dubbo的整合，但是dubbo幫我們做了很多事情 - eureka 內存裏面，保存到容器，比如map容器、list容器等等。可用性。
server整合：導入server依賴包，寫個配置文件來配置地址、帳號和密碼，添加一個enableEurekaServer
client整合：導入client依賴包，配置server的地址密碼等信息，添加註解enableEurekaClient,enableDiscover
cap理論：一致性，可用性，分區容錯性，一致和可用是有衝突的，需要權衡。
微服務屬於分佈式，提供分佈式方案的有：
springCloud，採用http調用
dubbo+zookeeper，採用RPC調用，依賴java對象，比較侷限
2.2.2 負載均衡 ribbon
導入依賴包，在resttemplate上面加註解loadblanced，然後我們調用服務的時候主機
這是一個客戶端側的負載均衡
客戶端負載均衡：ribbon先從eureka上面獲取到所有服務器，然後從中間選擇一個，這就是客戶端負載均衡。
服務端負載均衡：客戶端連接一個負載均衡服務器ribbon，告訴它我要一個服務，然後服務器在裏面會找到所有服務列表，挑選一個返回。
2.2.3 feign
整合ribbon的
也是一個規則，地址路徑的拼接方式規則，通過類註解參數來聲明訪問什麼服務，通過方法參數來傳遞請求參數
2.2.4 hystrix
可能出現的問題：
- 流量或者併發太高，需要限制一部分請求，那麼被限制的就會出現問題。
- 超時，hystrix的超時機制是可以指定超時時間，信號量只能被動等待下游服務超時
- 熔斷，多次請求下游服務一直失敗，當再次請求的時候就不去了直接認爲失敗，10秒20次，或者
- 隔離機制，獨立線程池和信號量，將服務隔開，互不影響
- 爲了避免出現問題，我們提前做了降級，比如在高併發時間段，不允許用戶進行操作
降級機制：當我們的請求出現問題的時候，爲了防止出現更多的級聯故障（A>B>C>D>E，如果E拋出異常，或者E阻塞，則其他服務都會異常或者阻塞，阻塞會導致前面的機器可能線程池被消耗完畢，正常請求也拿不到線程資源，全部卡死）或者用戶體驗不好（出現系統錯誤頁面），即出現問題，不能將正常數據返回給調用者，我們需要找替代方式進行處理。
2.2.5 網關
程序的統一入口，可以做我們想做的事情，比如爲了解決功能太多，需要的服務器太多導致域名太多，產生的跨域問題以及代碼編寫的複雜度問題，可以將所有的服務器統一交給網關管理，即只需要和網關通信。
網關可以進行統一的一些數據校驗，判斷，規則審查，動態路由等等。
參數的判斷、校驗、簽名、token、動態路由、發送日誌等等。
動態路由
http://網關的端口/服務的名字/地址/參數
http://網關的端口/服務的別名/地址/參數
別名需要在配置文件中配置，也就是說每增刪服務，必須要修改一次配置文件，是不合理的，違背開閉原則。
我們配置的服務實際上是通過requestcontest中put的兩個參數，即receiveID和receiveURL來進行的映射。
因爲服務調用是客戶端或者是用戶執行的，所以我們要想辦法通過用戶傳遞來的參數來找到服務的id和url即可
這是典型的key-value，我們可以在redis中將這些關係放好，根據用戶傳遞來的參數隨時獲取即可，就能隨時更新，所以我們只要定義一個規則，即參數和服務之間的映射規則。
三、MQ
消息隊列，應用之間通信，即服務器和服務器之間的通信，主要是來取代同步操作，很多操作都是異步的
ES
存儲的服務器，模糊查詢性能很高
分詞器，一段內容如何拆分
倒排索引，根據內容找索引，然後根據索引找內容
庫和表都可以動態創建
四、微信公衆號
在微信公衆號中查詢日誌數據
微信公衆號 ---> 區分文本消息 ---> 規則 ---> 要求用戶先輸入xxx，然後輸入的內容就是查詢條件 ---> restTemplate(java中發請求的類) ---> 日誌數據 ---> ES ---> 接口（網關對應接口，都是各個模塊服務）
微信公衆號開發的BUG
在使用微信公衆號進行開發的時候，要注意，有一個bug，就是當點擊使用【click】關鍵字開頭的時候，會不斷報錯，說是編碼問題，但其實不是編碼問題，而是騰訊公司本身的問題，我們不能使用【click】關鍵字
click1.setType("click");
海爾的ERP系統
需要統計在我們的平臺的銷售記錄，怎麼統計？
只要發起請求的就是客戶端 | ERP發起請求—>網關—>對應的接口參數—>appkey—>數據整合 給用戶返回的數據需要經過10個服務獲取得到
五、分佈式
jwt身份認證組件，和shiro很類似，一般用於註冊和登錄，保證一處登錄後，使用其他相關的服務的時候不需要再登錄，但是需要用過濾器進行認證。
網關主要作用是過濾、認證、監控等等，通過網關，才能訪問註冊中心獲取服務，這中間需要redis緩存。
註冊中心有Eureka和zookeeper，主要作用是將服務註冊進去，然後提供路徑或者接口，供用戶調用。
MQ和ElasticSearch可以配合使用，一般網關調取服務，執行服務，給用戶反饋結果等主線操作不變，在其中會拉去副線，給MQ，進行日誌處理，然後給到ElasticSearch，ElasticSearch可以存儲日誌信息，並會從數據庫獲取相關的數據進行備份存儲，向外提供的是查找功能。
當數據庫數據發生更新的時候，會通知給MQ，然後MQ也會傳遞給ElasticSearch，實現更新。
六、加餐
springboot+elasticsearch的使用
