問(wèn)安全的關(guān)鍵.png)
使用這些基本 REST API 最佳實(shí)踐構(gòu)建出色的 API
完成項(xiàng)目設(shè)置需要克隆所需的分支并安裝所有包和依賴(lài)項(xiàng)。
一旦項(xiàng)目設(shè)置完畢，我們就可以著手討論架構(gòu)決策及其增強(qiáng)了。
下圖表示項(xiàng)目當(dāng)前狀態(tài)下的體系結(jié)構(gòu)。
此體系結(jié)構(gòu)是一個(gè)簡(jiǎn)單的整體，它將所有后端功能（例如緩存、歌曲管理和數(shù)據(jù)庫(kù)連接）整合到單個(gè)服務(wù)器或域中。為了確保服務(wù)器的帶寬不被異常使用，我們將文件服務(wù)委托給了外部存儲(chǔ)，這在架構(gòu)中體現(xiàn)為將存儲(chǔ)組件置于服務(wù)器域之外。
面對(duì)這種新構(gòu)建的可擴(kuò)展架構(gòu)，我們遇到了一個(gè)挑戰(zhàn)：用戶(hù)能夠獲取直接下載鏈接，可能會(huì)繞過(guò)流媒體服務(wù)，從而違背了通過(guò)我們的應(yīng)用程序進(jìn)行內(nèi)容流式傳輸?shù)某踔浴?/p>
為了優(yōu)化系統(tǒng)，我們將通過(guò)整合流服務(wù)組件來(lái)重新規(guī)劃架構(gòu)。
在更新后的架構(gòu)中，我們?cè)诜?wù)器上新增了一個(gè)名為Streaming Service的組件。此組件負(fù)責(zé)與數(shù)據(jù)庫(kù)交互，以檢索歌曲的相關(guān)信息。值得注意的是，存儲(chǔ)組件不再直接與客戶(hù)端進(jìn)行通信，而是改為與Streaming Service進(jìn)行通信。
那么，Streaming Service是如何運(yùn)作的呢？當(dāng)用戶(hù)發(fā)起歌曲請(qǐng)求時(shí)，API Gateway會(huì)將該請(qǐng)求重定向至Streaming Service。隨后，Streaming Service會(huì)查詢(xún)數(shù)據(jù)庫(kù)以獲取歌曲信息，并利用存儲(chǔ)文件的URL進(jìn)行下載。下載完成后，文件會(huì)被分割成多個(gè)字節(jié)塊，并通過(guò)HTTP范圍請(qǐng)求向客戶(hù)端進(jìn)行緩沖傳輸。
盡管惡意用戶(hù)可能會(huì)嘗試尋找下載歌曲的途徑，但我們可以通過(guò)加密緩沖的塊來(lái)增強(qiáng)安全性，加密密鑰由客戶(hù)端和服務(wù)器共同持有。不過(guò)，這一加密選項(xiàng)我們將在后文中詳細(xì)討論。
我們計(jì)劃使用Golang來(lái)編寫(xiě)Streaming Service。之所以選擇Golang，是因?yàn)槲覀兇蛩銟?gòu)建一個(gè)流式處理引擎，并充分利用其強(qiáng)大的并發(fā)處理能力，以應(yīng)對(duì)每分鐘可能需要處理的數(shù)千個(gè)請(qǐng)求。盡管Python也可用于構(gòu)建流式處理服務(wù)，特別是在開(kāi)發(fā)便捷性更為關(guān)鍵且性能要求相對(duì)寬松的場(chǎng)景下，但對(duì)于需要高效處理大量并發(fā)請(qǐng)求且延遲要求低的服務(wù)來(lái)說(shuō)，Go通常是更優(yōu)的選擇。
現(xiàn)在，我們對(duì)架構(gòu)的變更有了更深入的理解，接下來(lái)，讓我們著手添加流式處理引擎。
Streaming Engine 將用 Golang 編寫(xiě)，并將作為單獨(dú)的服務(wù)運(yùn)行。以下是這項(xiàng)服務(wù)的要求：
/songs/listen/{id}，其中?<id>?代表用戶(hù)希望收聽(tīng)的歌曲的 ID。該終結(jié)點(diǎn)將用于從存儲(chǔ)組件中檢索歌曲。在明確這些要求后，我們接下來(lái)討論 HTTP 范圍請(qǐng)求的相關(guān)知識(shí)。
HTTP 范圍請(qǐng)求是一種技術(shù)，它使客戶(hù)端能夠請(qǐng)求資源的特定部分，這一功能在處理大文件（如視頻或音頻流）時(shí)尤為重要。流式處理服務(wù)普遍采用這一方法，以確保內(nèi)容能夠幾乎立即開(kāi)始播放，而無(wú)需用戶(hù)等待整個(gè)文件的預(yù)先下載。
為了深入理解HTTP范圍請(qǐng)求的工作機(jī)制，讓我們逐步剖析這一過(guò)程。
當(dāng)客戶(hù)端請(qǐng)求資源時(shí)，服務(wù)器通常會(huì)使用整個(gè)文件進(jìn)行響應(yīng)。但是，在處理大文件時(shí)，服務(wù)器可能會(huì)表明它支持范圍請(qǐng)求，從而允許客戶(hù)端分批下載文件。
* The client starts by sending a standard HTTP GET request to retrieve the resource.
* If the file is large, the server might respond with the full resource or include an Accept-Ranges: bytes header to indicate that range requests are supported.
接下來(lái)，客戶(hù)端可以使用范圍請(qǐng)求功能僅下載文件的必要部分。
* To request a specific portion of the resource, the client includes a Range header in its request:
```json
Range: bytes=0-1023
```
* This header specifies the desired byte range, in this case, the first 1024 bytes.
收到此請(qǐng)求后，服務(wù)器將僅使用文件的請(qǐng)求部分進(jìn)行響應(yīng)。
* The server responds with an HTTP 206 Partial Content status, indicating that it is sending only a portion of the resource:
```json
Content-Range: bytes 0-1023/5000
```
客戶(hù)端收到此部分后，可以根據(jù)需要繼續(xù)請(qǐng)求文件的其他部分。
* If more data is needed, the client requests the next segment:
```json
Range: bytes=1024-2047
```
* The server then responds with the next chunk, continuing this process until the entire file is downloaded or the client has obtained all the necessary parts.HTTP 范圍請(qǐng)求具有多種優(yōu)勢(shì)，使其在涉及大型文件的情況下特別有用。
通過(guò)允許客戶(hù)端僅下載他們需要的文件部分，HTTP 范圍請(qǐng)求提供了幾個(gè)關(guān)鍵優(yōu)勢(shì)。
為了說(shuō)明此過(guò)程在實(shí)際場(chǎng)景中的工作原理，請(qǐng)考慮流式傳輸歌曲的示例。
當(dāng)用戶(hù)流式傳輸歌曲時(shí)，客戶(hù)端和服務(wù)器會(huì)通過(guò)一系列請(qǐng)求和響應(yīng)進(jìn)行通信。
GET /audio.mp3 HTTP/1.1 Range: bytes=0-2047HTTP/1.1 206 Partial Content Content-Range: bytes 0-2047/100000GET /audio.mp3 HTTP/1.1 Range: bytes=2048-4095HTTP/1.1 206 Partial Content Content-Range: bytes 2048-4095/100000GET /audio.mp3 HTTP/1.1 Range: bytes=8192-10239HTTP/1.1 206 Partial Content Content-Range: bytes 8192-10239/100000此示例凸顯了 HTTP 范圍請(qǐng)求如何助力實(shí)現(xiàn)高效且用戶(hù)友好的流式傳輸，通過(guò)允許立即播放和更順暢的文件傳輸，從而提供更流暢的用戶(hù)體驗(yàn)。
解釋了 HTTP Range 請(qǐng)求后，讓我們用 Golang 編寫(xiě)實(shí)現(xiàn)。我們將構(gòu)建一個(gè) API 來(lái)為終端節(jié)點(diǎn)提供服務(wù)，然后編寫(xiě)一個(gè)函數(shù)來(lái)處理通過(guò) HTTP Range Requests 進(jìn)行的流式處理。
在本節(jié)中，我們將使用 Golang 構(gòu)建流式處理服務(wù)。在項(xiàng)目的根目錄中，創(chuàng)建一個(gè)名為 的新文件夾。此目錄將包含用 Golang 編寫(xiě)的流式處理后端。
mkdir streaming-engine
cd streaming-engine然后，在此目錄中，運(yùn)行以下行以創(chuàng)建 Golang 項(xiàng)目。
go mod init streaming-engine然后安裝所需的依賴(lài)項(xiàng)，例如 Mux、Sqlite3 驅(qū)動(dòng)程序和 gorm 以與數(shù)據(jù)庫(kù)交互。
go get github.com/gorilla/mux
go get gorm.io/driver/sqlite
go get gorm.io/gorm安裝完成后，創(chuàng)建一個(gè)名為?main.go?的文件（我們將在這個(gè)文件中放置后端邏輯內(nèi)容）。
現(xiàn)在項(xiàng)目已經(jīng)設(shè)置完成，我們可以著手為流式處理引擎編寫(xiě)代碼了。首先，我們從必要的導(dǎo)入和基本結(jié)構(gòu)體定義開(kāi)始。
package main
import (
"fmt"
"io"
"log"
"net/http"
"strconv"
"strings"
"github.com/gorilla/mux"
"gorm.io/driver/sqlite"
"gorm.io/gorm"
)
var db *gorm.DB
var err error
// Song represents the song model in the existing music_song table
type Song struct {
ID uint gorm:"column:id"
Name string gorm:"column:name"
File string gorm:"column:file"
Author string gorm:"column:author"
Thumbnail string gorm:"column:thumbnail"
}
// TableName overrides the table name used by Gorm
func (Song) TableName() string {
return "music_song"
}
在上面的代碼中，我們導(dǎo)入了所需的包，以幫助編寫(xiě)流處理程序函數(shù)和設(shè)置 API。我們還定義了變量，例如用于數(shù)據(jù)庫(kù)初始化和跟蹤整個(gè)應(yīng)用程序中的錯(cuò)誤。該結(jié)構(gòu)體被定義為表示表中的歌曲模型。我們覆蓋了 Gorm 使用的默認(rèn)表名，以確保它正確映射到現(xiàn)有的數(shù)據(jù)庫(kù)表。
接下來(lái)，我們繼續(xù)編寫(xiě)用于數(shù)據(jù)庫(kù)初始化的函數(shù)：
func initDB() {
// Initialize SQLite connection
db, err = gorm.Open(sqlite.Open("../backend/db.sqlite3"), &gorm.Config{})
if err != nil {
log.Fatal("Failed to connect to database:", err)
}
}在之前的步驟中，我們定義了使用特定包的函數(shù)來(lái)初始化數(shù)據(jù)庫(kù)連接。請(qǐng)確保 SQLite 數(shù)據(jù)庫(kù)文件的路徑與您的項(xiàng)目結(jié)構(gòu)相匹配，如有需要，請(qǐng)進(jìn)行相應(yīng)調(diào)整。接下來(lái)，我們將編寫(xiě)一個(gè)名為?initDBgorm?的函數(shù)來(lái)打開(kāi)數(shù)據(jù)庫(kù)。
繼續(xù)進(jìn)行，我們還將編寫(xiě)一個(gè)將在流處理程序函數(shù)中使用的函數(shù)。
func getSongID(r *http.Request) (int, error) {
params := mux.Vars(r)
id, err := strconv.Atoi(params["id"])
return id, err
}在上面的代碼中，我們使用 從 URL 參數(shù)中提取歌曲 ID。該函數(shù)將 ID 從字符串轉(zhuǎn)換為整數(shù)，并返回 ID 以及遇到的任何錯(cuò)誤。
func getSongFromDB(id int) (Song, error) {
var song Song
err := db.First(&song, id).Error
return song, err
}該函數(shù)查詢(xún)數(shù)據(jù)庫(kù)以檢索給定 ID 的歌曲詳細(xì)信息。它返回歌曲數(shù)據(jù)以及查詢(xún)期間出現(xiàn)的任何錯(cuò)誤。
func fetchFile(fileURL string) (*http.Response, error) {
fullURL := "http://localhost:8000/media/" + fileURL
resp, err := http.Get(fullURL)
if err != nil || resp.StatusCode != http.StatusOK {
return nil, fmt.Errorf("file not found on the server")
}
return resp, nil
}在上面的代碼中，通過(guò)將 附加到基 URL 來(lái)構(gòu)建媒體文件的完整 URL，并執(zhí)行 HTTP GET 請(qǐng)求以檢索文件。如果未找到文件或出現(xiàn)問(wèn)題，它將返回響應(yīng)或錯(cuò)誤。
func parseRangeHeader(rangeHeader string, fileSize int64) (int64, int64, error) {
bytesRange := strings.Split(strings.TrimPrefix(rangeHeader, "bytes="), "-")
start, err := strconv.ParseInt(bytesRange[0], 10, 64)
if err != nil {
return 0, 0, err
}
var end int64
if len(bytesRange) > 1 && bytesRange[1] != "" {
end, err = strconv.ParseInt(bytesRange[1], 10, 64)
if err != nil {
return 0, 0, err
}
} else {
end = fileSize - 1
}
if start > end || end >= fileSize {
return 0, 0, fmt.Errorf("invalid range")
}
return start, end, nil
}在上面的代碼中，我們解析HTTP請(qǐng)求的頭，以確定客戶(hù)端想要接收的文件的開(kāi)始和結(jié)束字節(jié)。我們處理范圍規(guī)范中的任何錯(cuò)誤，并返回開(kāi)始和結(jié)束字節(jié)位置。
func writePartialContent(w http.ResponseWriter, start, end, fileSize int64, resp *http.Response) error {
w.Header().Set("Content-Range", fmt.Sprintf("bytes %d-%d/%d", start, end, fileSize))
w.Header().Set("Accept-Ranges", "bytes")
w.Header().Set("Content-Length", strconv.FormatInt(end-start+1, 10))
w.Header().Set("Content-Type", "audio/mpeg")
w.WriteHeader(http.StatusPartialContent)
// Create a channel for the buffered data and a wait group for synchronization
dataChan := make(chan []byte)
var wg sync.WaitGroup
wg.Add(1)
go func() {
defer wg.Done()
buffer := make([]byte, 1024) // 1KB buffer size
bytesToRead := end - start + 1
for bytesToRead > 0 {
n, err := resp.Body.Read(buffer)
if err != nil && err != io.EOF {
http.Error(w, "Error reading file", http.StatusInternalServerError)
return
}
if n == 0 {
break
}
if int64(n) > bytesToRead {
n = int(bytesToRead)
}
dataChan <- buffer[:n]
bytesToRead -= int64(n)
}
close(dataChan)
}()
go func() {
defer wg.Wait()
for chunk := range dataChan {
if _, err := w.Write(chunk); err != nil {
http.Error(w, "Error writing response", http.StatusInternalServerError)
return
}
}
}()
// Skip the bytes until the start position
io.CopyN(io.Discard, resp.Body, start)
return nil
}在上面的代碼中，我們?cè)O(shè)置了必要的HTTP頭部以傳遞請(qǐng)求所需的信息，并處理了指定字節(jié)范圍的并發(fā)讀取與寫(xiě)入操作。為了確保數(shù)據(jù)流的高效性，我們運(yùn)用了goroutines來(lái)同步進(jìn)行數(shù)據(jù)的緩沖與寫(xiě)入。若在此過(guò)程中遭遇任何錯(cuò)誤，這些錯(cuò)誤將被捕獲并以HTTP錯(cuò)誤的形式返回。此外，我們還實(shí)現(xiàn)了writePartialContent函數(shù)來(lái)處理部分內(nèi)容的寫(xiě)入。
現(xiàn)在，我們可以在流處理程序函數(shù)中使用這些函數(shù)，并創(chuàng)建 API 服務(wù)器來(lái)為流式處理終結(jié)點(diǎn)提供服務(wù)。
// Handles streaming of the file via HTTP range requests
func streamHandler(w http.ResponseWriter, r *http.Request) {
id, err := getSongID(r)
if err != nil {
http.Error(w, "Invalid song ID", http.StatusBadRequest)
return
}
song, err := getSongFromDB(id)
if err != nil {
http.Error(w, "Song not found", http.StatusNotFound)
return
}
resp, err := fetchFile(song.File)
if err != nil {
http.Error(w, err.Error(), http.StatusNotFound)
return
}
defer resp.Body.Close()
fileSize := resp.ContentLength
rangeHeader := r.Header.Get("Range")
if rangeHeader == "" {
http.ServeFile(w, r, song.File)
return
}
start, end, err := parseRangeHeader(rangeHeader, fileSize)
if err != nil {
http.Error(w, err.Error(), http.StatusBadRequest)
return
}
if err := writePartialContent(w, start, end, fileSize, resp); err != nil {
http.Error(w, err.Error(), http.StatusInternalServerError)
return
}
}
func main() {
initDB()
r := mux.NewRouter()
r.HandleFunc("/songs/listen/{id}", streamHandler).Methods("GET")
log.Println("Server is running on port 8005")
log.Fatal(http.ListenAndServe(":8005", r))
}streamHandler 函數(shù)負(fù)責(zé)處理流文件的HTTP范圍請(qǐng)求。它首先通過(guò)提取歌曲ID來(lái)工作，接著從數(shù)據(jù)庫(kù)中檢索該歌曲的詳細(xì)信息，并從指定的URL獲取文件。之后，該函數(shù)會(huì)解析HTTP請(qǐng)求中的范圍標(biāo)頭（如果存在），以確定需要流式傳輸文件的哪一部分。一旦確定了要傳輸?shù)牟糠郑摵瘮?shù)就會(huì)將這部分內(nèi)容寫(xiě)入HTTP響應(yīng)中。
在?main?函數(shù)中，我們對(duì)數(shù)據(jù)庫(kù)進(jìn)行了初始化設(shè)置，并配置了一個(gè)HTTP路由器來(lái)處理流媒體歌曲的請(qǐng)求。最后，我們?cè)?005端口上啟動(dòng)了服務(wù)器。要在流引擎目錄中啟動(dòng)服務(wù)器，運(yùn)行以下命令以啟動(dòng)服務(wù)器。
go run .我們現(xiàn)已編寫(xiě)完成Golang服務(wù)，允許客戶(hù)端通過(guò) /songs/listen/{id} 路徑（其中 {id} 是歌曲的 ID）來(lái)流式傳輸歌曲。
現(xiàn)在服務(wù)已經(jīng)編寫(xiě)完畢，我們必須對(duì) Django 后端和前端進(jìn)行一些調(diào)整。
在Django后端，為了控制通過(guò)API暴露的數(shù)據(jù)，我們對(duì)API響應(yīng)進(jìn)行了更新，排除了某些字段。具體來(lái)說(shuō)，我們更新了 fileSongSerializer 配置，故意省略了某個(gè)字段，以確保其不會(huì)暴露給客戶(hù)端。
# music/serializers.py
class SongSerializer(serializers.ModelSerializer):
class Meta:
model = Song
fields = ['id', 'name', 'artist', 'duration', 'thumbnail']前端方面，我們調(diào)整了邏輯以利用新創(chuàng)建的流式處理終結(jié)點(diǎn)。該前端包能夠自動(dòng)處理流，因此無(wú)需手動(dòng)管理。我們使用了 react-h5-audio-player 組件。
此外，我們還更新了 playSongapp.js 中的函數(shù)，以正確設(shè)置歌曲的URL。
// app.js
...
const playSong = (song) => {
setCurrentSong(http://localhost:8005/songs/listen/${song.id});
};
...
通過(guò)此更新，前端使用更新的 API 自動(dòng)流式傳輸音頻，為用戶(hù)提供無(wú)縫體驗(yàn)。
在編寫(xiě)完應(yīng)用程序的最終版本后，我們來(lái)探討一些可能的增強(qiáng)措施。
在構(gòu)建此應(yīng)用程序及規(guī)劃其架構(gòu)時(shí)，我們已確保架構(gòu)能夠支持大量請(qǐng)求，從而實(shí)現(xiàn)可擴(kuò)展性和可靠性。鑒于我們選擇了較為簡(jiǎn)潔的編碼方案，因此有必要說(shuō)明在架構(gòu)和編碼方面可以進(jìn)行的一些增強(qiáng)。
當(dāng)前架構(gòu)中，流式處理服務(wù)組件位于服務(wù)器上。盡管流式傳輸是通過(guò)HTTP范圍請(qǐng)求實(shí)現(xiàn)的，但我們也必須考慮帶寬的使用情況。以下是對(duì)架構(gòu)可能的增強(qiáng)措施：
下面是這些更改后的體系結(jié)構(gòu)的新關(guān)系圖。
現(xiàn)在我們有了一個(gè)更好的架構(gòu)建議，讓我們來(lái)討論編碼增強(qiáng)。
許多流媒體服務(wù)通過(guò)使用加密來(lái)保護(hù)傳輸期間的數(shù)據(jù)，這可以保護(hù)內(nèi)容免受未經(jīng)授權(quán)的訪(fǎng)問(wèn)和篡改。該過(guò)程通常包括兩個(gè)主要步驟：
這是一個(gè)可以考慮添加到流媒體引擎中的有趣步驟，以確保流媒體傳輸?shù)陌踩院涂煽啃浴?/p>
在本文中，我們利用Golang和HTTP范圍請(qǐng)求開(kāi)發(fā)了一個(gè)流媒體服務(wù)，并深入探討了關(guān)鍵的架構(gòu)改進(jìn)方案，旨在提升應(yīng)用程序的安全性和效率。
本系列的這一部分內(nèi)容至此告一段落，但請(qǐng)您持續(xù)關(guān)注我們的下一期。在接下來(lái)的一期中，我們將把這里所提及的所有概念融入一個(gè)全球性的架構(gòu)體系中。我們將詳細(xì)闡述如何構(gòu)建一個(gè)能夠向全球用戶(hù)提供服務(wù)的流媒體平臺(tái)，同時(shí)確保其高性能表現(xiàn)。
如果您喜歡本文，請(qǐng)考慮訂閱我們的時(shí)事通訊，以便您不會(huì)錯(cuò)過(guò)后續(xù)的更新內(nèi)容。
您的反饋對(duì)我們來(lái)說(shuō)至關(guān)重要！如果您有任何建議、批評(píng)或問(wèn)題，請(qǐng)?jiān)谙路搅粞浴?/p>
讓我們共同期待更多精彩內(nèi)容的呈現(xiàn)！??
對(duì)比大模型API的內(nèi)容創(chuàng)意新穎性、情感共鳴力、商業(yè)轉(zhuǎn)化潛力
一鍵對(duì)比試用API 限時(shí)免費(fèi)