Transaksi dalam Perkhidmatan Mikro: Bahagian Corak SAGA dengan Koreografi

Dalam artikel pertama siri ini, kami memperkenalkan corak SAGA dan menunjukkan cara Orkestrasi yang minimum boleh mengurus urus niaga teragih dengan orkestra pusat.

Mari menjadi nyata! Kali ini, kita akan menyelami pendekatan Koreografi, di mana perkhidmatan menyelaras aliran kerja dengan memancarkan dan menggunakan acara secara autonomi.

Untuk menjadikan ini praktikal, kami akan melaksanakan aliran kerja penjagaan kesihatan berbilang perkhidmatan menggunakan Go dan RabbitMQ. Setiap perkhidmatan akan mempunyai main.go sendiri, menjadikannya mudah untuk skala, ujian dan dijalankan secara bebas.

Apakah Koreografi SAGA?

Koreografi bergantung pada komunikasi terdesentralisasi. Setiap perkhidmatan mendengar peristiwa dan mencetuskan langkah seterusnya dengan memancarkan peristiwa baharu. Tiada orkestra pusat; aliran itu muncul daripada interaksi perkhidmatan individu.

Faedah Utama:

• Perkhidmatan Terpisah: Setiap perkhidmatan beroperasi secara berasingan.
• Skalabiliti: Sistem dipacu acara mengendalikan beban tinggi dengan cekap.
• Fleksibiliti: Menambah perkhidmatan baharu tidak memerlukan perubahan logik aliran kerja.

Cabaran:

• Kerumitan Penyahpepijatan: Menjejaki acara merentas berbilang perkhidmatan boleh menjadi rumit. (Saya akan menulis artikel khusus untuk topik ini, nantikan!)
• Persediaan Infrastruktur: Perkhidmatan memerlukan broker mesej yang mantap (cth., RabbitMQ) untuk menyambungkan semua titik.
• Ribut Peristiwa: Aliran kerja yang direka bentuk dengan buruk boleh menenggelamkan sistem dengan acara.

Contoh Praktikal: Aliran Kerja Penjagaan Kesihatan

Mari kita lihat semula aliran kerja penjagaan kesihatan kami dari artikel pertama:

1. Perkhidmatan Pesakit: Mengesahkan butiran pesakit dan perlindungan insurans.
2. Perkhidmatan Penjadual: Jadualkan prosedur.
3. Perkhidmatan Inventori: Menyimpan bekalan perubatan.
4. Perkhidmatan Pengebilan: Memproses pengebilan.

Setiap perkhidmatan akan:

• Dengar acara tertentu menggunakan RabbitMQ.
• Pancarkan acara baharu untuk mencetuskan langkah seterusnya.

Menyediakan RabbitMQ dengan Docker

Kami akan menggunakan RabbitMQ sebagai baris gilir acara. Jalankannya secara tempatan menggunakan Docker:

docker run --rm --name rabbitmq -p 5672:5672 -p 15672:15672 rabbitmq:4.0.5-management

Akses antara muka pengurusan RabbitMQ di http://localhost:15672 (nama pengguna: tetamu, kata laluan: tetamu).

Persediaan Pertukaran, Baris Gilir dan Pengikatan

Kami perlu mengkonfigurasi RabbitMQ untuk menampung acara kami. Berikut ialah contoh fail init.go untuk menyediakan infrastruktur RabbitMQ:

package main

import (
    "log"

    "github.com/rabbitmq/amqp091-go"
)

func main() {
    conn, err := amqp091.Dial("amqp://guest:guest@localhost:5672/")
    if err != nil {
        log.Fatalf("Failed to connect to RabbitMQ: %v", err)
    }
    defer conn.Close()

    ch, err := conn.Channel()
    if err != nil {
        log.Fatalf("Failed to open a channel: %v", err)
    }
    defer ch.Close()

    err = ch.ExchangeDeclare("events", "direct", true, false, false, false, nil)
    if err != nil {
        log.Fatalf("Failed to declare an exchange: %v", err)
    }

    _, err = ch.QueueDeclare("PatientVerified", true, false, false, false, nil)
    if err != nil {
        log.Fatalf("Failed to declare a queue: %v", err)
    }

    err = ch.QueueBind("PatientVerified", "PatientVerified", "events", false, nil)
    if err != nil {
        log.Fatalf("Failed to bind a queue: %v", err)
    }
}

Kod penuh di sini!

Nota: Dalam tetapan pengeluaran, anda mungkin mahu mengurus persediaan ini menggunakan pendekatan GitOps (cth., dengan Terraform) atau biarkan setiap perkhidmatan mengendalikan baris gilirnya sendiri secara dinamik.

Pelaksanaan: Fail Perkhidmatan

Setiap perkhidmatan akan mempunyai main.go sendiri. Kami juga akan menyertakan tindakan pampasan untuk mengendalikan kegagalan dengan anggun.

1. Perkhidmatan Pesakit

Perkhidmatan ini mengesahkan butiran pesakit dan memancarkan acara PatientVerified. Ia juga memberi pampasan dengan memberitahu pesakit jika kegagalan hiliran berlaku.

docker run --rm --name rabbitmq -p 5672:5672 -p 15672:15672 rabbitmq:4.0.5-management

---

2. Perkhidmatan Penjadual

Perkhidmatan ini mendengar PatientVerified dan mengeluarkan ProcedureScheduled. Ia memberi pampasan dengan membatalkan prosedur jika kegagalan hiliran berlaku.

package main

import (
    "log"

    "github.com/rabbitmq/amqp091-go"
)

func main() {
    conn, err := amqp091.Dial("amqp://guest:guest@localhost:5672/")
    if err != nil {
        log.Fatalf("Failed to connect to RabbitMQ: %v", err)
    }
    defer conn.Close()

    ch, err := conn.Channel()
    if err != nil {
        log.Fatalf("Failed to open a channel: %v", err)
    }
    defer ch.Close()

    err = ch.ExchangeDeclare("events", "direct", true, false, false, false, nil)
    if err != nil {
        log.Fatalf("Failed to declare an exchange: %v", err)
    }

    _, err = ch.QueueDeclare("PatientVerified", true, false, false, false, nil)
    if err != nil {
        log.Fatalf("Failed to declare a queue: %v", err)
    }

    err = ch.QueueBind("PatientVerified", "PatientVerified", "events", false, nil)
    if err != nil {
        log.Fatalf("Failed to bind a queue: %v", err)
    }
}

---

Perkhidmatan Tambahan

Sertakan Perkhidmatan Inventori dan pelaksanaan Perkhidmatan Pengebilan, mengikut struktur yang sama seperti di atas. Setiap perkhidmatan mendengar acara sebelumnya dan mengeluarkan yang seterusnya, memastikan logik pampasan disediakan untuk kegagalan.

Kod penuh di sini!

---

Menjalankan Aliran Kerja

Mulakan RabbitMQ:

// patient/main.go
package main

import (
    "fmt"
    "log"

    "github.com/rabbitmq/amqp091-go"
    "github.com/thegoodapi/saga_tutorial/choreography/common"
)

func main() {
    conn, err := amqp091.Dial("amqp://guest:guest@localhost:5672/")
    if err != nil {
        log.Fatalf("Failed to connect to RabbitMQ: %v", err)
    }
    defer conn.Close()

    ch, err := conn.Channel()
    if err != nil {
        log.Fatalf("Failed to open a channel: %v", err)
    }
    defer ch.Close()

    go func() {
        fmt.Println("[PatientService] Waiting for events...")
        msgs, err := common.ConsumeEvent(ch, "ProcedureScheduleCancelled")
        if err != nil {
            log.Fatalf("Failed to consume event: %v", err)
        }

        for range msgs {
            fmt.Println("[PatientService] Processing event: ProcedureScheduleCancelled")
            if err := notifyProcedureScheduleCancellation(); err != nil {
                log.Fatalf("Failed to notify patient: %v", err)
            }
        }
    }()

    common.PublishEvent(ch, "events", "PatientVerified", "Patient details verified")
    fmt.Println("[PatientService] Event published: PatientVerified")

    select {}
}

func notifyProcedureScheduleCancellation() error {
    fmt.Println("Compensation: Notify patient of procedure cancellation.")
    return nil
}

Jalankan Setiap Perkhidmatan:
Buka terminal berasingan dan jalankan:

// scheduler/main.go
package main

import (
    "fmt"
    "log"

    "github.com/rabbitmq/amqp091-go"
    "github.com/thegoodapi/saga_tutorial/choreography/common"
)

func main() {
    conn, err := amqp091.Dial("amqp://guest:guest@localhost:5672/")
    if err != nil {
        log.Fatalf("Failed to connect to RabbitMQ: %v", err)
    }
    defer conn.Close()

    ch, err := conn.Channel()
    if err != nil {
        log.Fatalf("Failed to open a channel: %v", err)
    }
    defer ch.Close()

    go func() {
        fmt.Println("[SchedulerService] Waiting for events...")
        msgs, err := common.ConsumeEvent(ch, "PatientVerified")
        if err != nil {
            log.Fatalf("Failed to consume event: %v", err)
        }

        for range msgs {
            fmt.Println("[SchedulerService] Processing event: PatientVerified")
            if err := scheduleProcedure(); err != nil {
                common.PublishEvent(ch, "events", "ProcedureScheduleFailed", "Failed to schedule procedure")
                fmt.Println("[SchedulerService] Compensation triggered: ProcedureScheduleFailed")
            } else {
                common.PublishEvent(ch, "events", "ProcedureScheduled", "Procedure scheduled successfully")
                fmt.Println("[SchedulerService] Event published: ProcedureScheduled")
            }
        }
    }()

    select {}
}

func scheduleProcedure() error {
    fmt.Println("Step 2: Scheduling procedure...")
    return nil // or simulate a failure
}

Perhatikan Output:
Setiap perkhidmatan memproses peristiwa dalam urutan, mencatat kemajuan aliran kerja.

Apa yang berlaku?

Jom pecahkan!

Pertama sekali, untuk tujuan artikel ini, kami tidak melaksanakan SuppliesReserveFailed dan ProcedureScheduleFailed,l untuk mengelakkan kerumitan yang tidak berguna.

Kami sedang melaksanakan acara berikut

Langkah (atau transaksi):

• T1: (init): PatientVerified
• T2: Prosedur Dijadualkan
• T3: SuppliesReserved
• T4: Pengebilan Berjaya

Pampasan:

• C4: Pengebilan Gagal
• C3: ReservedSuppliesReleased
• C2: ProcedureScheduleCancelled
• C1: NotifyFailureToUser (tidak dilaksanakan)

Mengikuti rajah pelaksanaan ini

Rajah ini mewakili pendekatan biasa untuk mendokumentasikan koreografi. Walau bagaimanapun, saya mendapati ia agak sukar untuk difahami dan agak mengecewakan, terutamanya bagi mereka yang tidak biasa dengan pelaksanaan atau coraknya.

Jom pecahkan!

Rajah di atas adalah lebih bertele-tele dan ia memecahkan setiap langkah yang memudahkan untuk memahami perkara yang sedang berlaku.

Ringkasnya:

1. Perkhidmatan pesakit berjaya mengesahkan butiran pesakit
2. Perkhidmatan pesakit memancarkan PatientVerified
3. Perkhidmatan penjadual menggunakan PatientVerified
4. Perkhidmatan penjadual menjadualkan pelantikan dengan jayanya
5. Perkhidmatan penjadual memancarkan Prosedur Dijadualkan
6. Perkhidmatan inventori menggunakan Prosedur Dijadualkan
7. Perkhidmatan inventori menyimpan bekalan dengan jayanya
8. Perkhidmatan inventori mengeluarkan SuppliesReserved
9. Perkhidmatan pengebilan menggunakan SuppliesReserved
10. Perkhidmatan pengebilan gagal mengecaj pelanggan dan memulakan pampasan
11. Perkhidmatan pengebilan mengeluarkan Pengebilan Gagal
12. Perkhidmatan inventori menggunakan Pengebilan Gagal
13. Perkhidmatan inventori mengeluarkan bekalan, dikhaskan dalam langkah 7
14. Perkhidmatan inventori mengeluarkan ReservedSuppliesReleased
15. Perkhidmatan penjadual menggunakan ReservedSuppliesReleased
16. Perkhidmatan penjadual memadamkan janji temu yang dijadualkan dalam langkah 4
17. Perkhidmatan penjadual memancarkan ProcedureScheduleCancelled
18. Perkhidmatan pesakit menggunakan ProcedureScheduleCancelled
19. Perkhidmatan pesakit memberitahu pelanggan tentang ralat

Perhatikan bahawa kami tidak melaksanakan kegagalan untuk langkah 1, 4, dan 7 demi ringkasnya; bagaimanapun, pendekatannya adalah sama. Setiap kegagalan ini akan mencetuskan penarikan semula langkah-langkah sebelumnya.

---

Kebolehlihatan

Kecekapan adalah penting untuk penyahpepijatan dan pemantauan sistem teragih. Melaksanakan log, metrik dan jejak memastikan pembangun dapat memahami gelagat sistem dan mendiagnosis isu dengan cekap.

Pembalakan

• Gunakan pengelogan berstruktur (cth., format JSON) untuk menangkap acara dan metadata.
• Sertakan ID korelasi dalam log untuk mengesan aliran kerja merentas perkhidmatan.

Metrik

• Pantau saiz baris gilir dan masa pemprosesan acara.
• Gunakan alatan seperti Prometheus untuk mengumpul dan menggambarkan metrik.

Menjejak

• Laksanakan pengesanan teragih (cth., dengan OpenTelemetry) untuk menjejaki peristiwa merentas perkhidmatan.
• Anotasi rentang dengan data yang berkaitan (cth., nama acara, cap masa) untuk mendapatkan cerapan yang lebih baik.

Kami akan menyelami kebolehmerhatian dalam koreografi kemudian dalam siri ini, nantikan!

---

Pengambilan Utama

• Kawalan Terpencar: Koreografi membolehkan kerjasama autonomi.
• Kesederhanaan Didorong Peristiwa: RabbitMQ memudahkan pertukaran mesej.
• Seni Bina Boleh Skala: Menambah perkhidmatan baharu adalah lancar.
• Koerografi boleh menjadi sangat menggembirakan pada mulanya, tetapi seperti biasa: latihan menjadikan anda sempurna lebih baik!

Nantikan artikel seterusnya, di mana kami akan meneroka Orkestrasi!

Lihat repositori penuh untuk siri ini di sini. Jom bincang dalam komen!

Atas ialah kandungan terperinci Transaksi dalam Perkhidmatan Mikro: Bahagian Corak SAGA dengan Koreografi. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!