JSON lwn FlatBuffers lwn Protocol Buffers

Apabila kita berfikir tentang komunikasi antara perkhidmatan/perkhidmatan mikro, pilihan pertama yang terlintas di fikiran ialah JSON lama yang bagus. Dan ini bukan tanpa sebab, kerana formatnya mempunyai kelebihan, seperti:

• mudah dibaca oleh komputer dan manusia;
• semua bahasa pengaturcaraan moden boleh membaca dan menjana JSON;
• ia adalah kurang bertele-tele berbanding alternatif sebelumnya, Jurassic XML.

Menggunakan JSON ialah cadangan untuk sebahagian besar API yang dibangunkan dalam kehidupan harian syarikat. Tetapi dalam beberapa kes, di mana prestasi adalah kritikal, kita mungkin perlu mempertimbangkan alternatif lain. Siaran ini bertujuan untuk menunjukkan dua alternatif kepada JSON apabila ia berkaitan dengan komunikasi antara aplikasi.

Tetapi apa masalahnya dengan JSON? Salah satu kelebihannya ialah ia "mudah dibaca oleh manusia," tetapi ini boleh menjadi titik lemah dalam prestasi. Hakikatnya ialah kita perlu menukar kandungan JSON kepada beberapa struktur yang diketahui oleh bahasa pengaturcaraan yang kita gunakan. Pengecualian kepada peraturan ini adalah jika kami menggunakan JavaScript, kerana JSON adalah asalnya. Tetapi jika anda menggunakan bahasa lain, Go, sebagai contoh, kami perlu menghuraikan data, seperti yang dapat kita lihat dalam contoh kod (tidak lengkap) di bawah:

type event struct {
    ID      uuid.UUID
    Type    string `json:"type"`
    Source  string `json:"source"`
    Subject string `json:"subject"`
    Time    string `json:"time"`
    Data    string `json:"data"`
}

var e event
err := json.NewDecoder(data).Decode(&e)
if err != nil {
    http.Error(w, err.Error(), http.StatusBadRequest)
}

Untuk menyelesaikan masalah ini, kami boleh menguji dua alternatif, Penampan Protokol dan Penampan Rata.

Penampan Protokol

Protobuf (Penimbal Protokol), yang dicipta oleh Google, adalah, menurut tapak web rasmi :

Penimbal protokol ialah mekanisme Google yang neutral bahasa, neutral platform, boleh diperluaskan untuk mensiri data berstruktur—fikirkan XML, tetapi lebih kecil, lebih pantas dan lebih mudah. Anda menentukan cara anda mahu data anda distrukturkan sekali. Kemudian, anda boleh menggunakan kod sumber yang dijana khas untuk menulis dan membaca data berstruktur anda dengan pantas ke dan dari pelbagai aliran data menggunakan pelbagai bahasa.

Secara amnya digunakan bersama gRPC (tetapi tidak semestinya), Protobuf ialah protokol binari yang meningkatkan prestasi dengan ketara berbanding format teks JSON. Tetapi ia "mengalami" masalah yang sama seperti JSON: kita perlu menghuraikannya ke struktur data bahasa kita. Contohnya, dalam Go:

//generated code
type Event struct {
    state         protoimpl.MessageState
    sizeCache     protoimpl.SizeCache
    unknownFields protoimpl.UnknownFields

    Type    string `protobuf:"bytes,1,opt,name=type,proto3" json:"type,omitempty"`
    Subject string `protobuf:"bytes,2,opt,name=subject,proto3" json:"subject,omitempty"`
    Source  string `protobuf:"bytes,3,opt,name=source,proto3" json:"source,omitempty"`
    Time    string `protobuf:"bytes,4,opt,name=time,proto3" json:"time,omitempty"`
    Data    string `protobuf:"bytes,5,opt,name=data,proto3" json:"data,omitempty"`
}

e := Event{}
err := proto.Unmarshal(data, &e)
if err != nil {
    http.Error(w, err.Error(), http.StatusBadRequest)
}

Mengguna pakai protokol perduaan memberikan kami peningkatan prestasi, tetapi kami masih perlu menyelesaikan masalah penghuraian data. Pesaing ketiga kami menumpukan pada menyelesaikan masalah ini.

Penampan rata

Menurut laman web rasmi:

FlatBuffers ialah perpustakaan bersiri merentas platform yang cekap untuk C++, C#, C, Go, Java, Kotlin, JavaScript, Lobster, Lua, TypeScript, PHP, Python, Rust dan Swift. Ia pada mulanya dicipta di Google untuk pembangunan permainan dan aplikasi kritikal prestasi lain.

Walaupun pada mulanya dicipta untuk pembangunan permainan, ia sangat sesuai dengan persekitaran yang kami pelajari dalam siaran ini. Kelebihannya ialah kami tidak perlu menghuraikan data selain menjadi protokol binari. Contohnya, dalam Go:

//generated code
e := events.GetRootAsEvent(data, 0)

//we can use the data directly
saveEvent(string(e.Type()), string(e.Source()), string(e.Subject()), string(e.Time()), string(e.Data()))

Tetapi berapa banyak lagi prestasi kedua-dua alternatif kepada JSON? Jom siasat...

Permohonan

Persoalan pertama yang terlintas di fikiran saya ialah, "bagaimana saya boleh menggunakan ini dalam senario sebenar?". Saya membayangkan senario berikut:

Sebuah syarikat dengan aplikasi mudah alih, diakses setiap hari oleh berjuta-juta pelanggan, dengan seni bina perkhidmatan mikro dalaman dan yang perlu menyimpan acara yang dijana oleh pengguna dan sistem untuk tujuan pengauditan.

Ini adalah senario yang tulen. Sangat nyata sehingga saya hidup dengannya setiap hari di syarikat tempat saya bekerja :)

Nota: senario di atas adalah pemudahan dan tidak mewakili kerumitan sebenar permohonan pasukan. Ia berfungsi untuk tujuan pendidikan.

Langkah pertama ialah mentakrifkan acara dalam Protocol Buffers dan Flatbuffers. Kedua-duanya mempunyai bahasa mereka sendiri untuk menentukan skema, yang kemudiannya boleh kita gunakan untuk menjana kod dalam bahasa yang akan kita gunakan. Saya tidak akan menyelidiki butiran setiap skim kerana ini mudah didapati dalam dokumentasi.

Fail event.proto mempunyai definisi Penampan Protokol:

syntax = "proto3";
package events;

option go_package = "./events_pb";

message Event {
    string type = 1;
    string subject = 2;
    string source = 3;
    string time = 4;
    string data = 5;
}

Dan fail event.fbs mempunyai persamaan dalam Flatbuffers:

namespace events;

table Event {
    type: string;
    subject:string;
    source:string;
    time:string;
    data:string;
}

root_type Event;

Langkah seterusnya ialah menggunakan takrifan ini untuk menjana kod yang diperlukan. Perintah berikut memasang kebergantungan pada macOS:

go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
brew install protobuf
protoc -I=. --go_out=./ event.proto
brew install flatbuffers
flatc --go event.fbs

Hasilnya ialah penciptaan pakej Go untuk memanipulasi data dalam setiap format.

Dengan keperluan dipenuhi, langkah seterusnya ialah melaksanakan API acara. The main.go kelihatan seperti ini:

package main

import (
    "fmt"
    "net/http"
    "os"

    "github.com/go-chi/chi/v5"
    "github.com/go-chi/chi/v5/middleware"
    "github.com/google/uuid"
)

func main() {
    r := handlers()
    http.ListenAndServe(":3000", r)
}

func handlers() *chi.Mux {
    r := chi.NewRouter()
    if os.Getenv("DEBUG") != "false" {
        r.Use(middleware.Logger)
    }
    r.Post("/json", processJSON())
    r.Post("/fb", processFB())
    r.Post("/pb", processPB())
    return r
}

func saveEvent(evType, source, subject, time, data string) {
    if os.Getenv("DEBUG") != "false" {
        id := uuid.New()
        q := fmt.Sprintf("insert into event values('%s', '%s', '%s', '%s', '%s', '%s')", id, evType, source, subject, time, data)
        fmt.Println(q)
    }
    // save event to database
}

Untuk organisasi yang lebih baik, saya mencipta fail untuk memisahkan setiap fungsi, yang kelihatan seperti berikut:

package main

import (
    "encoding/json"
    "net/http"

    "github.com/google/uuid"
)

type event struct {
    ID      uuid.UUID
    Type    string `json:"type"`
    Source  string `json:"source"`
    Subject string `json:"subject"`
    Time    string `json:"time"`
    Data    string `json:"data"`
}

func processJSON() http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        var e event
        err := json.NewDecoder(r.Body).Decode(&e)
        if err != nil {
            http.Error(w, err.Error(), http.StatusBadRequest)
        }
        saveEvent(e.Type, e.Source, e.Subject, e.Time, e.Data)
        w.WriteHeader(http.StatusCreated)
        w.Write([]byte("json received"))
    }
}

package main

import (
    "io"
    "net/http"

    "github.com/eminetto/post-flatbuffers/events_pb"
    "google.golang.org/protobuf/proto"
)

func processPB() http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        body := r.Body
        data, _ := io.ReadAll(body)

        e := events_pb.Event{}
        err := proto.Unmarshal(data, &e)
        if err != nil {
            http.Error(w, err.Error(), http.StatusBadRequest)
        }
        saveEvent(e.GetType(), e.GetSource(), e.GetSubject(), e.GetTime(), e.GetData())
        w.WriteHeader(http.StatusCreated)
        w.Write([]byte("protobuf received"))
    }
}

package main

import (
    "io"
    "net/http"

    "github.com/eminetto/post-flatbuffers/events"
)

func processFB() http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        body := r.Body
        data, _ := io.ReadAll(body)
        e := events.GetRootAsEvent(data, 0)
        saveEvent(string(e.Type()), string(e.Source()), string(e.Subject()), string(e.Time()), string(e.Data()))
        w.WriteHeader(http.StatusCreated)
        w.Write([]byte("flatbuffer received"))
    }
}

In the functions processPB() and processFB(), we can see how the generated packages are used to manipulate the data.

Benchmark

The last step of our proof of concept is generating the benchmark to compare the formats. I used the Go stdlib benchmark package for this.

The file main_test.go has tests for each format:

package main

import (
    "bytes"
    "fmt"
    "net/http"
    "net/http/httptest"
    "os"
    "strings"
    "testing"

    "github.com/eminetto/post-flatbuffers/events"
    "github.com/eminetto/post-flatbuffers/events_pb"
    flatbuffers "github.com/google/flatbuffers/go"
    "google.golang.org/protobuf/proto"
)

func benchSetup() {
    os.Setenv("DEBUG", "false")
}

func BenchmarkJSON(b *testing.B) {
    benchSetup()
    r := handlers()
    payload := fmt.Sprintf(`{
        "type": "button.clicked",
        "source": "Login",
        "subject": "user1000",
        "time": "2018-04-05T17:31:00Z",
        "data": "User clicked because X"}`)
    for i := 0; i < b.N; i++ {
        w := httptest.NewRecorder()
        req, _ := http.NewRequest("POST", "/json", strings.NewReader(payload))
        r.ServeHTTP(w, req)
        if w.Code != http.StatusCreated {
            b.Errorf("expected status 201, got %d", w.Code)
        }
    }
}

func BenchmarkFlatBuffers(b *testing.B) {
    benchSetup()
    r := handlers()
    builder := flatbuffers.NewBuilder(1024)
    evtType := builder.CreateString("button.clicked")
    evtSource := builder.CreateString("service-b")
    evtSubject := builder.CreateString("user1000")
    evtTime := builder.CreateString("2018-04-05T17:31:00Z")
    evtData := builder.CreateString("User clicked because X")

    events.EventStart(builder)
    events.EventAddType(builder, evtType)
    events.EventAddSource(builder, evtSource)
    events.EventAddSubject(builder, evtSubject)
    events.EventAddTime(builder, evtTime)
    events.EventAddData(builder, evtData)
    evt := events.EventEnd(builder)
    builder.Finish(evt)

    buff := builder.FinishedBytes()
    for i := 0; i < b.N; i++ {
        w := httptest.NewRecorder()
        req, _ := http.NewRequest("POST", "/fb", bytes.NewReader(buff))
        r.ServeHTTP(w, req)
        if w.Code != http.StatusCreated {
            b.Errorf("expected status 201, got %d", w.Code)
        }
    }
}

func BenchmarkProtobuffer(b *testing.B) {
    benchSetup()
    r := handlers()
    evt := events_pb.Event{
        Type:    "button.clicked",
        Subject: "user1000",
        Source:  "service-b",
        Time:    "2018-04-05T17:31:00Z",
        Data:    "User clicked because X",
    }
    payload, err := proto.Marshal(&evt)
    if err != nil {
        panic(err)
    }
    for i := 0; i < b.N; i++ {
        w := httptest.NewRecorder()
        req, _ := http.NewRequest("POST", "/pb", bytes.NewReader(payload))
        r.ServeHTTP(w, req)
        if w.Code != http.StatusCreated {
            b.Errorf("expected status 201, got %d", w.Code)
        }
    }
}

It generates an event in each format and sends it to the API.

When we run the benchmark, we have the following result:

Running tool: /opt/homebrew/bin/go test -benchmem -run=^$ -coverprofile=/var/folders/vn/gff4w90d37xbfc_2tn3616h40000gn/T/vscode-gojAS4GO/go-code-cover -bench . github.com/eminetto/post-flatbuffers/cmd/api -failfast -v

goos: darwin
goarch: arm64
pkg: github.com/eminetto/post-flatbuffers/cmd/api
BenchmarkJSON
BenchmarkJSON-8               658386          1732 ns/op        2288 B/op         26 allocs/op
BenchmarkFlatBuffers
BenchmarkFlatBuffers-8       1749194           640.5 ns/op      1856 B/op         21 allocs/op
BenchmarkProtobuffer
BenchmarkProtobuffer-8       1497356           696.9 ns/op      1952 B/op         21 allocs/op
PASS
coverage: 77.5% of statements
ok      github.com/eminetto/post-flatbuffers/cmd/api    5.042s

If this is the first time you have analyzed the results of a Go benchmark, I recommend reading this post, where the author describes the details of each column and its meaning.

To make it easier to visualize, I created graphs for the most critical information generated by the benchmark:

‌Number of iterations (higher is better)

Nanoseconds per operation (lower is better)

Number of bytes allocated per operation (lower is better)

Number of allocations per operation (lower is better)

Conclusion

The numbers show a great advantage of binary protocols over JSON, especially Flatbuffers. This advantage is that we do not need to parse the data into structures of the language we are using.

Should you refactor your applications to replace JSON with Flatbuffers? Not necessarily. Performance is just one factor that teams must consider when selecting a communication protocol between their services and applications. But if your application receives billions of requests per day, performance improvements like those presented in this post can make a big difference in terms of costs and user experience.

The codes presented here can be found in this repository. I made the examples using the Go language, but both Protocol Buffers and Flatbuffers support different programming languages, so I would love to see other versions of these comparisons. Additionally, other benchmarks can be used, such as network consumption, CPU, etc. (since we only compare memory here).

I hope this post serves as an introduction to these formats and an incentive for new tests and experiments.

Originally published at https://eltonminetto.dev on August 05, 2024

Atas ialah kandungan terperinci JSON lwn FlatBuffers lwn Protocol Buffers. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!