服務端問題集合
文章目錄
文章目錄
最近開發任務中需要用ts寫一些後端的接口，隨着開發的逐漸進行，需要把後端的相關知識進行重新彙總，也發現自己有很多已經遺忘的地方，特此記錄
2020/04/06 add openAPI
2020/04/13 add Springboot&SSM框架
接口
接口（英文：Interface），在JAVA編程語言中是一個抽象類型，是抽象方法的集合，接口通常以interface來聲明。一個類通過繼承接口的方式，從而來繼承接口的抽象方法。
接口並不是類，編寫接口的方式和類很相似，但是它們屬於不同的概念。類描述對象的屬性和方法。接口則包含類要實現的方法。
除非實現接口的類是抽象類，否則該類要定義接口中的所有方法。
接口無法被實例化，但是可以被實現。一個實現接口的類，必須實現接口內所描述的所有方法，否則就必須聲明爲抽象類。另外，在 Java 中，接口類型可用來聲明一個變量，他們可以成爲一個空指針，或是被綁定在一個以此接口實現的對象。
接口與類相似點：
- 一個接口可以有多個方法。
- 接口文件保存在 .java 結尾的文件中，文件名使用接口名。
- 接口的字節碼文件保存在 .class 結尾的文件中。
- 接口相應的字節碼文件必須在與包名稱相匹配的目錄結構中。
接口與類的區別：
- 接口不能用於實例化對象。
- 接口沒有構造方法。
- 接口中所有的方法必須是抽象方法。
- 接口不能包含成員變量，除了 static 和 final 變量。
- 接口不是被類繼承了，而是要被類實現。
- 接口支持多繼承。
接口特性
- 接口中每一個方法也是隱式抽象的,接口中的方法會被隱式的指定爲 public abstract（只能是 public abstract，其他修飾符都會報錯）。
- 接口中可以含有變量，但是接口中的變量會被隱式的指定爲 public static final 變量（並且只能是 public，用 private 修飾會報編譯錯誤）。
- 接口中的方法是不能在接口中實現的，只能由實現接口的類來實現接口中的方法。
抽象類和接口的區別
- 抽象類中的方法可以有方法體，就是能實現方法的具體功能，但是接口中的方法不行。
- 抽象類中的成員變量可以是各種類型的，而接口中的成員變量只能是 public static final 類型的。
- 接口中不能含有靜態代碼塊以及靜態方法(用 static 修飾的方法)，而抽象類是可以有靜態代碼塊和靜態方法。
- 一個類只能繼承一個抽象類，而一個類卻可以實現多個接口。
抽象類和類的區別
- 抽象類是不能被實例化的，就是不能用new調出構造方法創建對象，而普通類則反之
- 抽象類的訪問權限限於Public和Protected，因爲抽象類的方法是需要繼承之後讓子類去實現的，如果爲Private，則無法被子類繼承，子類也無法實現該方法
- 如果一個類繼承於抽象類，則該子類必須實現父類的抽象方法。如果子類沒有實現父類的抽象方法，則必須將子類也定義爲abstract類。
btw
一個類實現接口和繼承抽象類對於抽象方法的實現原則是相同的：
（1）如果這個類是個普通類，那麼必須實現這個接口/抽象類的所有抽象方法；
（2）如果這個類是個抽象類，那麼不必實現這個接口/抽象類的抽象方法，因爲抽象類中可以定義抽象方法。
FAAS AWS
references
AWS：amazon web service亞馬遜雲服務
FAAS: Functions as a Service
函數即服務
無服務器計算，當前使用最廣泛的是AWS的Lambada。
服務商提供一個平臺，允許客戶開發、運行和管理應用程序功能，而無需構建和維護通常與開發和啓動應用程序相關的基礎架構的複雜性。 按照此模型構建應用程序是實現“無服務器”體系結構的一種方式，通常在構建微服務應用程序時使用.
API gateway
是什麼
APIGateway 即API網關，所有請求首先會經過這個網關，然後到達後端服務，有點類似於Facade模式。API網關作爲系統接口對外的統一出口，可以減少調用方對服務實現的感知。
沒有API網關時的結系統構如下圖：由圖可以看出，在沒有API網關作爲統一出口的情況下，需要調用方自己組合各種服務，而且容易讓調用方感知後端各種服務的存在。
插播：何爲facade模式：設計模式的一種
加入了API網關之後：
用來做什麼
1.統一對外接口：
當用戶需要集成不同產品或者服務之間的功能，調用不同服務提供的能力。利用APIGateway可以讓用戶在不感知服務邊緣的情況下，利用統一的接口組裝服務。
對於公司內部不同的服務，提供的接口可能在風格上存在一定的差異，通過APIGateway可以統一這種差異。 當內部服務修改時，可以通過APIGateway進行適配，不需要調用方進行調整
減少對外暴露服務可以增加系統安全性。
2.統一鑑權:
通過APIGateway對訪問進行統一鑑權，不需要每個應用單獨對調用方進行鑑權，應用可以專注業務。
3.服務註冊與授權：
可以控制調用方可以使用和不可以使用的服務。
4.服務限流:
通過APIGateway可以對調用方調用每個接口的每日調用及總調用次數限制
5.全鏈路跟蹤：
通過APIGateway提供的唯一請求Id，監控調用流程，以及調用的響應時間
有哪些在做的
spring zuul
kong
引申：對於微服務的理解
微服務
微服務架構：就是將原來的單體應用按義務範圍來進行劃分，劃分爲多個小model，每個微服務運行在自己的進程中，不相互影響，通過完全自動化部署來獨立部署。並使用輕量級機制通信，通常是HTTP RESTUFUL API。可對各個微服務進行集中管理。這些小model可以使用不同的編程語言，以及不同的存儲技術。微服務架構是分佈式架構。
微服務架構的優點：
按業務劃分的微服務單元獨立部署，運行在獨立的進程中，服務與服務之間沒有任何耦合，有很好的擴展性和複用性
++服務與服務之間通常採用HTTP通信++，這種通信機制與平臺和語言無關(可以使用不同的編程語言和存儲方法)。也可以採用輕量級的消息總線來通信，如RabbitMQ、Kafaka消息隊列等等，數據格式一般都採用JSON
++每個微服務有自己的數據庫，服務之間數據庫是獨立的
微服務一般採用自動化部署工具部署。Docker容器技術是微服務最佳部署的容器。
服務集中化管理(服務註冊與發現Eureka、Zookeeper、Consul)，監控(服務運行狀況監控Spring-Boot-Admin-Server)
微服務架構是分佈式架構++
微服務架構的缺點：
項目構建複雜程度遠高於單體應用
分佈式系統中難保證數據一致性，一般情況下，少用分佈式事物
服務部署比單體應用複雜
微服務架構難題及解決辦法：
服務之間故障傳播影響：譬如A服務調用了B服務，但是B服務因爲網絡或其他原因遲遲沒有響應，容易引起服務的雪崩效應 — >採用“熔斷機制”，快速報錯
分佈式事物：事物失敗容易導致數據不一致 — >採用“兩階段提交”
微服務架構難題及解決辦法：
服務之間故障傳播影響：譬如A服務調用了B服務，但是B服務因爲網絡或其他原因遲遲沒有響應，容易引起服務的雪崩效應 — >採用“熔斷機制”，快速報錯
分佈式事物：事物失敗容易導致數據不一致 — >採用“兩階段提交”
傳統單體架構的缺陷：
傳統的單體應用，將所有功能的表示層、業務邏輯層，數據訪問層，包括靜態資源等等全部糅合在一個工程裏面，編譯，打包，部署在單臺服務器上上線，比如打成war包放在Tomcat的webapp目錄中部署項目。這樣的項目開發部署適合小型項目，系統功能不復雜，訪問量不大的情況下有絕對的優勢。開發速度快，運維方便。但是當業務越來越複雜，功能越來越多，參與的開發人員越來越多，就暴露出問題了：
- 業務變複雜，代碼量增大，代碼可讀性，可維護性，可擴展性下降。萬一要新同事接手代碼，理解起來花很多時間
- 測試難度增大
- 單體應用併發能力有限，訪問量高了用戶體驗差
- 單體應用容錯率低，萬一哪裏出錯，可能導致整個項目就崩了
緩解措施：
將單體應用做集羣部署，添加負載均衡服務器（例如Nginx反向代理轉發請求）可稍微緩解以上3，4條缺點，但是還是不能完美解決問題
open API
references:
什麼是open API
Open API即開放API,也稱開放平臺。 所謂的開放API（OpenAPI）是服務型網站常見的一種應用，網站的服務商將自己的網站服務封裝成一系列API（Application Programming Interface，應用編程接口）開放出去，供第三方開發者使用，這種行爲就叫做開放網站的API，所開放的API就被稱作OpenAPI（開放API）
考量條目：
- 簽名鑑權（我需要知道請求我的是誰,有沒有訪問這個接口的權限）
- 流量控制（我不可能讓你隨隨便便就無節制的訪問我,我要能隨時關停你）
- 請求轉發（請求過來的 url,需要找到真正的業務處理邏輯,api最好只負責接口的規範,不負責業務的實現）
- 日誌處理（你可以保持沉默,但你說的每一句話都會成爲呈堂供證）
- 異常處理（即使老子內部出了問題,你也不會看到我的異常堆棧信息,我會告訴你我病了,請稍後再試）
- 參數規範（順我者倡,逆我者亡）
- 多機部署（我有九條命）
- 異步回調（別想阻塞我,但我可以玩死你）
- 錯誤信息（你要認識到自己錯誤）
DDOS攻擊
分佈式拒絕服務攻擊(英文意思是Distributed Denial of Service，簡稱DDoS)是指處於不同位置的多個攻擊者同時向一個或數個目標發動攻擊，或者一個攻擊者控制了位於不同位置的多臺機器並利用這些機器對受害者同時實施攻擊。由於攻擊的發出點是分佈在不同地方的，這類攻擊稱爲分佈式拒絕服務攻擊，其中的攻擊者可以有多個
爲什麼要建立開放平臺
openapi在10年左右主要還是應用在國內的互聯網公司主要集中在社交平臺，因爲社交平臺的用戶數據對於規模較小的公司是最有價值的資源，一下子可以降低獲客成本，並且獲得了這些社交平臺開放的其他能力。2010年以後國內的開放平臺開始擺脫社交這一單一的開放平臺場景，逐漸的地圖、新聞門戶、電商等很多行業都開放了相關的核心api。
開放平臺關鍵功能模塊
服務接入網關
服務管理
服務代理
服務mesh up
mesh up:
mashup是糅合，是當今網絡上新出現的一種網絡現象,將兩種以上使用公共或者私有數據庫的web應用，加在一起，形成一個整合應用。一般使用源應用的api接口，或者是一些rss輸出（含atom）作爲內容源，合併的web應用用什麼技術，則沒有什麼限制。
服務組合：各個源系統提供的接口可能都是簡單的，需要對源系統接口進行組合後再對外進行開放。
oauth
OAuth協議致力於使網站和應用程序（統稱爲消費方）能夠在無須用戶透露其認證證書的情況下，通過API訪問某個web服務（統稱爲服務提供方）的受保護資源。更一般地說，OAuth爲API認證提供了一個可自由實現且通用的方法。
開放平臺通過oauth協議來進行鑑權，當然你也可以用自己的token體系進行鑑權，不過目前主流的開放平臺都是使用oauth鑑權，這裏建議也是使用oauth進行鑑權，這樣開發者在接入的時候也會比較容易理解，不用重新學習。oauth必須要實現以下基礎服務：
- accesstoken發放：對於通過安全登錄的終端需要進行accesstoken的發放，並在系統中進行記錄，系統中需要設計一個accesstoken的生成方案，生成的token需要加入userid作爲因子，這樣可以將token和userid進行綁定起來進行權限控制。
- accesstoken校驗：token的校驗需要實現有效期校驗和登錄有效性校驗。
- refreshtoken更換accesstoken：當accesstoken過期後，開發者在調用端可以通過refreshtoken更換新的accesstoken實現登陸有效性的延期。
服務註冊發現
安全
開發者門戶
開放平臺內管
沙箱
沙箱用大白話講其實就是一個提供交易模擬的測試環境，裏面的數據都是模擬的，交易路徑也是比較固定的。
開放平臺爲什麼需要一個沙箱？
- 首先開放平臺服務接口是對外開放的，想想我們在開發過程中是怎麼開發和測試其他系統提供的接口的，開發肯定是先和對方系統在開發、測試環境聯調接口，聯調測試通了再上測試環境再上生產環境，但是我們開放平臺因爲本身不提供業務功能，真正的業務功能都是後臺源系統提供的，生產環境可以從開放平臺到業務生產系統都搭建完整的一套，但是對於測試環境，外部開發者是沒辦法連接到我們內部測試系統的，那麼如果在公網再搭建一套成本太高了，而且還需要進行測試數據管理也不太現實。所以就引出了沙箱的概念，沙箱就是給開發者提供了一個模擬的測試環境，後臺其實是沒有真實的業務源系統的，都是沙箱配置好報文固定返回，這樣就解決了測試環境和開發者測試聯調的問題。
測試沙箱也存在一個問題，就是數據不夠真實，因爲沙箱都是固定的業務邏輯和規則，返回的報文也是固定的，可能很多異常場景是無法測試到的，這些異常情況也只能在沙箱測試完成後，進行生產測試來避免。
Spring==>Springboot,SSH,SSM
最近在用ts開發後端，但對於服務端的內容其實是有很多的遺忘的，特此進行記錄。
怎麼區分
DAO model service controller層分別代表什麼
SSM框架中Dao層，Mapper層，controller層，service層，model層，entity層都有什麼作用
Spring Boot框架model層、dao層、service層、controller層分析設計
model
- model層即數據庫實體層，也被稱爲entity層，pojo層。
- 一般數據庫一張表對應一個實體類，類屬性同表字段一一對應。
即model層=entity層。存放我們的實體類，與數據庫中的屬性值基本保持一致。
DAO
- dao層即數據持久層，也被稱爲mapper層。
- dao層的作用爲訪問數據庫，向數據庫發送sql語句，完成數據的增刪改查任務。
mapper層=dao層，現在用mybatis逆向工程生成的mapper層，其實就是dao層。對數據庫進行數據持久化操作，他的方法語句是直接針對數據庫操作的，而service層是針對我們controller，也就是針對我們使用者。service的impl是把mapper和service進行整合的文件。
（多說一句，數據持久化操作就是指，把數據放到持久化的介質中，同時提供增刪改查操作，比如數據通過hibernate插入到數據庫中。）
service
- service層即業務邏輯層。
- service層的作用爲完成功能設計。
- service層調用dao層接口，接收dao層返回的數據，完成項目的基本功能設計。
即存放業務邏輯處理，也是一些關於數據庫處理的操作，但不是直接和數據庫打交道，他有接口還有接口的實現方法，在接口的實現方法中需要導入mapper層，mapper層是直接跟數據庫打交道的，他也是個接口，只有方法名字，具體實現在mapper.xml文件裏，service是供我們使用的方法。
controller
- controller層即控制層。
- controller層的功能爲請求和響應控制。
- controller層負責前後端交互，接受前端請求，調用service層，接收service層返回的數據，最後返回具體的頁面和數據到客戶端。
即控制器，導入service層，因爲service中的方法是我們使用到的，controller通過接收前端傳過來的參數進行業務操作，在返回一個指定的路徑或者數據表。
在實際開發中的Service層可能被處理爲實體Service層，而不是接口，業務邏輯直接寫在Service（Class，不是Interface）層中，Controller直接調用Service，Service調用Mapper。