前言
可能之前在學校里面做的很多東西是純后端的，不會涉及到太多和前端交互的細節(jié)，很多新手對前后端交互以及上中游業(yè)務鏈路的整體流程不夠清晰，做一些javaWeb項目可以讓我們有機會對其進行更深入的研究，最近總結(jié)了一下相關技術知識點并結(jié)合自己的實踐經(jīng)驗來和大家分享。
一、業(yè)務API網(wǎng)關鑒權(quán)
網(wǎng)關(GateWay)是什么？有哪些功能？
客戶端請求服務端服務的統(tǒng)一入口，功能包括服務路由轉(zhuǎn)發(fā)、服務注冊、負載均衡、彈力設計、安全認證、流控熔斷降級、日志監(jiān)控等。
網(wǎng)關一般可以包括流量網(wǎng)關和業(yè)務網(wǎng)關，當然我們也可以把它們模糊放到一起，流量網(wǎng)關主要負責垂直流量控制及安全防護，提供全局性的、與后端業(yè)務應用無關的策略，例如 HTTPS證書卸載、Web防火墻、全局流量監(jiān)控、日志記錄、黑白名單控制、接入請求到業(yè)務系統(tǒng)的Nginx負載均衡等，如kong。
業(yè)務網(wǎng)關負責流量分發(fā)調(diào)度及服務治理，與業(yè)務緊耦合，提供單個業(yè)務域級別的策略，如服務治理、身份認證,權(quán)限控制、日志輸出、數(shù)據(jù)加密、熔斷限流等，如K8s的Istio。
幾種網(wǎng)關的對比
主要聊下業(yè)務網(wǎng)關，比如GPT對話的頁面，請求到Web的地址后，用戶操作的時候會去走Http請求網(wǎng)關的Api接口，這個時候網(wǎng)關會有對應的鑒權(quán)機制。那么鑒權(quán)的目的是什么？----數(shù)據(jù)在互聯(lián)網(wǎng)中傳輸是不安全的，所有處于開放環(huán)境的數(shù)據(jù)傳輸都可以被截取、篡改，因此數(shù)據(jù)傳輸必須簽名加密。
簽名核心解決的以下問題：
請求是否合法：請求數(shù)據(jù)的是否是我規(guī)定的那部分人
請求是否被篡改：請求的數(shù)據(jù)是否是原始數(shù)據(jù)，是否被篡改過
防止重復請求（防重放）：是否重復請求
記得自己最開始不熟的時候請求網(wǎng)關API經(jīng)常報203錯誤(用戶信息為空),于是抽出一段時間來研究學習這部分內(nèi)容，發(fā)現(xiàn)目前項目接觸到的鑒權(quán)機制大概分成下面3種，另外還有基于proxy代理訪問其他服務的，都需要考慮默認是否鑒權(quán)，以及對應的具體鑒權(quán)方式(有狀態(tài)/無狀態(tài),長期/臨時)，可以參考這篇博文https://blog.csdn.net/DanielJackZ/article/details/122520971
Cookie + Session 實現(xiàn) API 鑒權(quán)
如果是自己內(nèi)部的控制臺上，可能會伴隨企業(yè)內(nèi)部的SSO單點登錄校驗功能。
復習一下Cookie和Session，估計很多后端er最早接觸到它還是在電商秒殺系統(tǒng)。
如果一個單體服務，里面設計一個登錄模塊，可以用Cookie和Session這種方式。Cookie的畫user_token傳輸可以是基于線程ThreadLocal傳輸?shù)摹?br> Cookie Session Token區(qū)別與聯(lián)系需要清楚 https://www.zhihu.com/question/353373715
如果cookie里面存儲臨時會話token的話可能過期，于是額外還有RefreshToken這種續(xù)命機制。
參考https://blog.csdn.net/NSPOKS/article/details/101771817/
如果登錄以后，打開一個新的無痕頁面，然后輸入訪問web頁面地址，可能彈出登錄頁面，讓你掃碼或者用戶密碼或者短信驗證碼SSO登錄，可以看到F12查看登錄成功以后，傳輸過去的cookie信息。
另外有空還可以研究一下cookie、session、token的具體內(nèi)容和格式。
跨域問題&網(wǎng)絡安全
同源/同域策略：域名相同,端口相同,協(xié)議相同
跨域問題出于瀏覽器的同源策略限制。同源策略（Sameoriginpolicy）是一種約定，它是瀏覽器最核心也最基本的安全功能，保證安全性防止攻擊，如果缺少了同源策略，則瀏覽器的正常功能可能都會受到影響?？梢哉fWeb是構(gòu)建在同源策略基礎之上的，瀏覽器只是針對同源策略的一種實現(xiàn)。同源策略會阻止一個域的javascript腳本和另外一個域的內(nèi)容進行交互。
前后端解決跨域問題 CORS SpringCloud Gateway注解 代理服務器
https://zhuanlan.zhihu.com/p/664531765
https://blog.csdn.net/Lee_92/article/details/129230088
https://www.shence123.com/s/11618.html
https://zhuanlan.zhihu.com/p/414130685
https://zhuanlan.zhihu.com/p/132534931?utm_id=0
網(wǎng)絡安全風控 XSS CSRF 重放攻擊等
https://blog.csdn.net/LawssssCat/article/details/104731979?utm_medium=distribute.pc_relevant.none-task-blog-2defaultbaidujs_baidulandingword~default-0-104731979-blog-106137473.235%5Ev40%5Epc_relevant_anti_vip&spm=1001.2101.3001.4242.1&utm_relevant_index=3
Cookie + Session 是最傳統(tǒng)的 API 鑒權(quán)方式，比如很多網(wǎng)站的登錄模塊就是靠這種方式實現(xiàn)用戶會話管理。在服務端會生成一個 session 來保持會話狀態(tài)，各個 session 是通過唯一的 session_id 來標識，以次來判斷請求是那個客戶端發(fā)起的，session_id 存儲在客戶端的 cookie 中，后續(xù)所有的請求都會把 cookie 傳到服務端，服務端解析 cookie 后找到對應的 session 進行判斷。
特點：
（1）為了使后臺應用識別是那個用戶發(fā)出的請求，需要在服務端存儲一份用戶登錄信息（session），這份信息也會在相應前端請求時返回給客戶端，客戶端將其保存在 cookie 中
（2）客戶端下次請求時發(fā)送給服務端，服務端根據(jù)這個標識來識別具體時那個用戶
（3）cookie 內(nèi)僅包含一個 session 標識符，其他用戶信息還是存儲在服務端中
缺點：
（1）性能相對較低：每一個用戶經(jīng)過服務端認證后服務端都要做一次記錄，以方便下次請求的鑒別，通常 session 都是保存在內(nèi)存中，而隨著用戶認證增多，服務端開銷會越來越大
（2）在一個無狀態(tài)協(xié)議里注入狀態(tài)，與 REST 風格不匹配
（3）因為改方案是基于 cookie 來進行識別，cookie 如果被獲取用戶很容易受到 CSRF 攻擊
（4）很難跨平臺，在移動端應用 session 和 cookie 很難行通，你無法與移動終端共享服務端創(chuàng)建的 session 和 cookie
API Key + API Secret
這種格式在postMan里面請求如下，這里有個小tips：可以通過PostMan的enviorment變量功能設置不同的環(huán)境（線下dev(類似http://127.0.0.1:9999 or localhost:8080等）、測試boe、預發(fā)staging、生產(chǎn)prod）等的地址，以及全局變量。
這種方式是指當請求的資源、API Key 和 API Secret 匹配時，用戶才可以訪問對應的資源，一般還會加上時間戳等方式來進行請求的時效控制。
實現(xiàn)方法：服務器生成一對 Key/Secret 保存，并下發(fā)給客戶端，Key 和 Secret 均是按照某種規(guī)則隨你生成，互相無法推算。在客戶端發(fā)起請求時，需要將包含 API Key 在內(nèi)的所有請求參數(shù)排序(一般都是使用字典序)，然后跟 API Secret(相當于加鹽)一起做 hash 生成一個 sign 參數(shù)，服務器只需要按照約定的規(guī)則做一次簽名計算，然后和請求的簽名做比較，如果一致則驗證通過，如果驗證不通過則拒絕。
這種模式并不是RBAC(角色權(quán)限控制)，而是 ACL(Access Control List: 訪問控制列表) 訪問控制。這種方式實現(xiàn)簡單，占用的計算資源和網(wǎng)絡資源都較少，安全性也可以。但是一般來說每一個 api 都需要分配一對 Key 和 Secret，因此當 Key 和 Secret 比較多的時候，服務器會有一定的存儲成本，而且服務端只能通過 API Key 來區(qū)別調(diào)用者，API Secret 一旦泄露將造成較大的安全風險。這種模式一般適用于 Web API。
token 機制實現(xiàn) API 鑒權(quán)
這個可以在一些接入第三方平臺的臨時授權(quán)，他們沒有通過Cookie+Session的登錄功能，我們就可以在服務端設置對應的固定token，線下、測試、預發(fā)、生產(chǎn)都有不同的token值，并且添加黑白名單的路徑列表，需要訪問的時候，需要把自己開發(fā)的接口地址加入到權(quán)限地址列表里面，然后請求頭帶對應環(huán)境的token才能正確訪問。
當然網(wǎng)關API肯定不能搞token過期了，經(jīng)常過期還玩?zhèn)€錘子，于是可以服務端寫死，約定好請求時候帶上正確的token就行。
之前老的業(yè)務請求方式可能基于AK/SK的方式，后來網(wǎng)關暴露的API都陸續(xù)都改成了token方式，也是為了減輕服務器的存儲負擔。
如果沒加token，或者token和環(huán)境不匹配，或者沒有把路徑添加到訪問權(quán)限列表，或者路徑寫錯不存在的話，都會報203，排查時候需要注意這幾個點。
token 令牌機制是用來代替 session 的鑒權(quán)方式，token 機制是服務端根據(jù)特定的規(guī)則生成的一串加密字符串下發(fā)給客戶端，客戶端請求服務端所有資源時都會攜帶上這個 Token(一般設置在 header 中)。服務端來校驗這個 token 的合法性，這種方式具有無狀態(tài)、適合分布式、擴展性好、性能和安全性好更好等優(yōu)點。
常見 Token 實現(xiàn)有以下幾種：
自定義實現(xiàn) token：應用開發(fā)者根據(jù) token 機制原理自行實現(xiàn)
JWT：即 json web token，是一種主流的 token 規(guī)范
Oauth：Oauth 雖然時授權(quán)規(guī)范，但其中也用到 TOken
HTTP Basic Authentication 認證機制
Web API 是基于 HTTP 協(xié)議，而 HTTP 協(xié)議本身就帶有認證機制
最后整個流程可能是下面這樣，在Http請求發(fā)送Post的Object類型對象，經(jīng)過Thrift序列化JSONString，在主服務的里面反序列化praseArray/Object，如果參數(shù)比較復雜并且頻繁變動，就用Object接收，然后直接轉(zhuǎn)String傳過去，然后那邊轉(zhuǎn)Array或者Object，然后放到parambody轉(zhuǎn)去http請求一些外部地址。
注意String類型轉(zhuǎn)JSONString會報錯，提前加instanceof判斷一下，并且注意不恰當解析導致的"\content"的轉(zhuǎn)義問題。
額外的問題：為什么公司一般HTTP接口都用POST請求,又為什么不用RestFul？
https://zhuanlan.zhihu.com/p/596637025
https://www.zhihu.com/question/336797348/answer/2189330351
https://www.zhihu.com/question/336797348/answer/2866008249?utm_id=0
額外：301 302 重定向 長鏈接和短鏈接轉(zhuǎn)換的底層設計 學習一下
接口調(diào)試工具Apipost=Postman + Swagger + Mock + JMeter
二、Tomcat、Servlet、SpringMVC
如果是C++選手可能搞過Tyni-WebServer的Web服務器開發(fā)這個項目。
首先需要搞清楚它們是什么關系，個人理解：Servlet是web服務的一套協(xié)議接口，SpringMVC實現(xiàn)了它，是對其高級封裝，Tomcat作為Web容器兼JSP/Servlet容器，可以為它們提供必要的運行環(huán)境。并且SpringBoot內(nèi)置了Tomcat，可以本機80端口直接啟動訪問。
下面是一些比較直觀的圖，就不贅述了：
有個經(jīng)典問題就是—Tomcat的類加載器隔離機制，及其類加載器的結(jié)構(gòu)，通過重寫ClassLoader的findClass和LoadClass方法可以實現(xiàn)自定義類加載。相關了解還有Panduora和AliTomcat等。
https://blog.csdn.net/zyh661120/article/details/119543402
https://blog.csdn.net/cristianoxm/article/details/121268913
https://blog.csdn.net/chenwiehuang/article/details/123957955
https://blog.csdn.net/weixin_45428910/article/details/129313723
https://blog.csdn.net/csucsgoat/article/details/121529374
上面的參考地址 https://www.cnblogs.com/wa1l-E/p/17072581.html
關于tomcat 類加載結(jié)構(gòu)，注意系統(tǒng)架構(gòu)和類繼承架構(gòu)不是一回事。
https://blog.csdn.net/weixin_42146366/article/details/97749031
https://www.cnblogs.com/wa1l-E/p/17072581.html
https://blog.csdn.net/qq_38526573/article/details/125425626
然后是SpringMVC，經(jīng)典架構(gòu)圖如下，其前端控制器本質(zhì)就是一個Servlet，并且SpringMVC簡化了很多流程，我們項目里面更多關注Controller層也就是Handler的設計。
三、額外補充：關于長鏈短鏈轉(zhuǎn)換系統(tǒng)的設計
長鏈接和短鏈接互相轉(zhuǎn)換的功能系統(tǒng)設計
其實本質(zhì)底層是301—永久重定向和302臨時重定向
經(jīng)常被問到這個系統(tǒng)的設計，包括存儲，路由，查詢規(guī)則
可以參考一些方案的地址：
https://www.cnblogs.com/lingyejun/p/15894620.html
https://blog.51cto.com/u_15300891/3057116文章來源：http://www.zghlxwxcb.cn/news/detail-833589.html
總結(jié)
這篇文章我們梳理了web服務和前端交互相關的上中游業(yè)務技術知識點，涉及到網(wǎng)關鑒權(quán)、Cookie、Session、Token、AK-SK、跨域問題、網(wǎng)絡安全、Tomcat、Servlet、SpringMVC等，總結(jié)的過程也是一種系統(tǒng)化的復習，可能自己以后工作時候遇到不清楚的地方，能夠結(jié)合自己以前的經(jīng)歷回想到自己曾經(jīng)整理過的內(nèi)容。文章來源地址http://www.zghlxwxcb.cn/news/detail-833589.html
到了這里，關于web服務和前端交互相關的上中游業(yè)務技術知識點梳理的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！
