四層負載均衡和七層負載均衡
-
四層負載均衡，是指基於 ip + port 的負載均衡，實現有 LVS，F5；
-
七層負載均衡，是基於 url 的負載均衡，通過域名來路由到後面真實的服務器 ip，實現有 Nginx；
spring 循環依賴
-
循環依賴，是指 ClassA 有一個成員遍歷是 ClassB 的實例，反過來 ClassB 有一個成員變量是 ClassA，如此在構造的過程中，就會造成一個死循環；
-
循環依賴分爲構造循環依賴和屬性循環依賴，屬性循環依賴就是通過先執行構造，得到一個早期引用，這樣在隨後的屬性設值時使用早期引用，不必將依賴 bean 的屬性注入執行完才能使用，構造循環依賴需要通過 @Lazy 推遲初始化的過程來解決；
-
spring 加載 bean，是先調用構造實例化，然後進行屬性注入，最後放入緩存中，並且 spring 對 bean 的緩存分爲三級，一級存放完全初始化完成的 bean，二級存放早期bean 的引用，尚未完成屬性注入，三級存放實例化完成的bean 工廠；
首先 對象 ClassA 完成實例化，並放入三級緩存中，接着進行屬性裝配，發現需要 ClassB 的實例
然後，創建 ClassB 的實例，也是實例化完成後，放入三級緩存中，執行屬性裝配，發現需要 ClassA 的實例
第三步，又進入 ClassA 實例化過程，發現三級緩存有，此時升級到二級緩存中，且直接返回給 ClassB 的屬性裝配過程
第四步，那麼 ClassB 就完成了屬性裝配，被放入到一級緩存，並返回給第一步
第五步，回到最開始，ClassA 的屬性裝配也完成，也被順利放到一級緩存中
驗活的兩種方式：輪詢和心跳
-
輪詢是指，服務端定時請求客戶端，客戶端返回應用當前狀態，根據應用的返回，服務端保存和更新客戶端的狀態；
-
心跳是指，客戶端定時請求服務端，更新自己的狀態，同時服務端自身有一個定時，檢測哪些客戶端超時沒有來更新自己的狀態，將這些客戶端置爲異常；
-
兩種方式，都要求服務端保存客戶端的狀態，但輪詢對服務器壓力比較大，需要定時發送很多請求，且需要知道所有客戶端的地址，而心跳這種方式，就比較靈活，等待客戶端建立連接，更新即可；
-
心跳的實現，服務端建立 serverSocket 等待客戶端連接，通過一個 map 記錄客戶端狀態，如果有連接進來，將其發送的數據更新到 map 中，通過 map 中的信息，就可以獲取到所有客戶端的狀態，額外通過一個定時任務，掃描 map，將最新的心跳時間和當前時間對比，如果超過了設置的超時時間，就更新狀態爲異常，並將異常狀態發送給訂閱該客戶端的其他客戶端，標記該客戶端異常不可用；
項目安全
-
防 sql 注入，防止惡意 sql 語句在應用數據庫執行，體現在 mybatis 的 mapper.xml 文件中，禁止拼接sql，使用佔位符的方式傳參設置；
-
防 xss 攻擊，防止惡意 js 腳本渲染給用戶；
前端對特殊字符進行轉義
後端接收請求，也需要轉義，通過一個 filter 對請求 body 內容進行轉義，參考 XSSFilter
- 防 csrf 攻擊，防止在用戶不知情的情況下向站點發送了敏感請求，用戶登陸網站 A，未退出，再登陸網站 B，網站 B 利用 A 的 cookie 未失效，在用戶不知情的情況下，向 網站A 發起了請求，特別是敏感操作；
通過驗證碼進行特別敏感操作進行校驗
通過設置 cookie 爲 httpOnly，防止 js 獲取到 cookie
通過 token 來認證請求
- token 的使用，由服務端產生，登陸後服務端返回給前端一個 token，之後每次請求都會攜帶 token，避開了 cookie 的同源策略，並且在多個服務端共享，無狀態；
token 需要設置有效期，token 的刷新是通過每次請求驗證 token 時，如果發現過期，要求前端重新登陸，服務器生成新的 token，之後請求使用新的 token;
token 的無狀態，可以將狀態信息都保存在 token 中，進行散列算法簽名即可，每次服務端進行同樣的簽名來驗證是否是自己簽發，常用算法 HMAC;
用戶註銷，token 應該失效，此時可以在前端控制，當用戶註銷，要刪除該 token;
更深入的就是 JWT，單點登陸，Oauth認證;
Dubbo
-
服務註冊，解決 url 管理混亂和變化，服務監控，解決服務調用關係的錯綜複雜，難分析；
-
服務監控中心，需要服務提供者和消費者在本地內存中，保存服務調用次數和調用時間，定時發送到監控中心，由監控中心進行統計分析展示；
-
dubbo 服務間調用，支持集羣容錯，默認是 failover，即調用失敗後重試其他服務提供者節點，還有 failfast 只發起一次調用，失敗後報錯，或者 failsafe 失敗後直接忽略錯誤，或者並行調用多臺服務器節點，廣播調用所有節點；
-
服務間的註冊和訂閱，可以設置爲只註冊和只訂閱的模式，
只訂閱不註冊是指服務提供者只訂閱註冊中心其他服務，而不把自己向註冊中心註冊，這適用於服務開發者還未上線，測試階段，避免其他服務消費者調用；
只註冊不訂閱是指...
參考：https://blog.ouyangsihai.cn/dubbo-yi-pian-wen-zhang-jiu-gou-liao-dubbo-yu-dao-chu-lian.html
灰度發佈
-
灰度發佈，是發佈新版本應用後，先不切流量，測試通過後，逐步切流量進來，並且部署更多新版本應用，根本是流量控制；
-
具體過程是，先啓動一個新版本的應用，不切流量進來，測試人員先線上測試，測試通過後，切少量用戶流量到新版本，觀察運行狀態，收集運行數據，與舊版本數據對比，確認新版本運行良好後，逐步導入更多流量，並逐步部署更多的新版本應用，直到流量全部切換，最後關閉舊版本應用，完成發佈；
-
如果在灰度發佈過程中，發現了新版本有問題，需要立即將流量切回舊版本，將負面影響控制在最小範圍；
-
灰度發佈的實現，將新版本應用標記爲灰度節點，當服務消費者調用服務提供者時，通過 java agent 技術改變服務路由策略，不路由到灰度節點，或者細粒度到哪些消費者路由到灰度節點，如此控制流量的走向；
java agent 技術，可以在運行期將已經加載的類的字節碼做變更，實現不重新部署應用，但改變應用的代碼邏輯
- 控制服務路由，如 springcloud 應用，控制負載均衡組件 Ribbon 的返回，如 dubbo 應用，控制 LoadBalance 的返回，根據請求頭中的特殊字段，或者按照比例分發請求，路由到正常節點或者灰度節點，起到流量控制；
Get 和 Post
-
兩者底層都是 tcp 連接，上層 http 協議也只規定了請求行，請求頭，請求體，響應行，響應頭，響應體的數據交互規範，區分了get，post 等請求方法的不同語義，但沒有限制 get 和 post 在數據交互上有任何侷限性，理論上， get 請求，也可以在請求體傳輸數據，post 請求，也可以將參數拼接到 url 之後；
-
get 方法的語義是用於獲取後臺信息，請求參數通常是拼接在 url 後面，由於直接可見，不太安全，且 url 的長度會受到瀏覽器和服務器的限制，而 post 方法的語義是修改後臺信息，請求參數通常是放在請求體中，抓包後也是可見的，請求體大小不受限制；