Menulis Blog Layanan Mikro - Bagian 1 "Deskripsi Umum"

Dalam artikel ini saya ingin berbagi pengalaman kami dengan SergeyMaslov untuk memecahkan masalah khas menggunakan arsitektur microservice menggunakan contoh dari tugas "buat blog" (dengan harapan bahwa pembaca dapat membayangkan bagaimana blog diatur dan ini seharusnya tidak menimbulkan pertanyaan tentang fungsionalitas :)

Jadi, blog kami akan terdiri dari 5 layanan microser yang ditulis dalam golang:

• Gateway API (api-gw) - bertanggung jawab untuk perutean, otentikasi, pencatatan dan penelusuran permintaan
• Pengguna (pengguna) - pendaftaran / otentikasi pengguna, pencatatan, penelusuran permintaan
• Artikel (posting) - membuat / membaca / memodifikasi / menghapus artikel (CRUD), masuk, menelusuri dan otorisasi permintaan
• Komentar - buat / baca / modifikasi / hapus komentar (CRUD), masuk, tracing dan otorisasi permintaan
• Kategori (kategori) - membuat / membaca / mengubah / menghapus kategori (CRUD), masuk, menelusuri dan otorisasi permintaan

Aplikasi klien (web / frontend) akan diimplementasikan pada vue.js dan akan berinteraksi dengan microservices melalui REST API, dan microservices sendiri akan berinteraksi satu sama lain melalui gRPC.

Sebagai penyimpanan kita akan menggunakan MongoDB.

Kami akan menunjukkan dengan cherry terpisah pada kue bagaimana menjaga dokumentasi API (dalam format kesombongan) up-to-date dalam proyek yang sedang berkembang aktif dengan tenaga kerja minimal.

Diagram Komponen Blog

Setiap microservice akan diimplementasikan dalam wadah Docker yang terpisah, dan proyek akan diluncurkan menggunakan docker-compose.

Segera buat reservasi dalam contoh, untuk menyederhanakan proses pengembangan, saya akan menggunakan dua asumsi yang tidak boleh digunakan dalam produksi.

• Basis data dikerahkan dalam wadah buruh pelabuhan. Pendekatan ini mengurangi keandalan penyimpanan (dengan pengecualian skema yang dibahas di HighLoad 2018).
• Seluruh proyek dihosting dalam satu repositori git. Pendekatan ini bertentangan dengan salah satu prinsip dasar arsitektur layanan mikro - isolasi, dan meningkatkan kemungkinan konektivitas antar-komponen.

Anda dapat melihat demo proyek di sini , dan kode sumber di sini .

Struktur proyek

Bagaimana proses pengembangan akan dibangun

Seperti yang saya katakan sebelumnya, interaksi antara layanan microser akan didasarkan pada gRPC. Singkatnya, gRPC adalah kerangka kerja berkinerja tinggi yang dikembangkan oleh Google untuk memanggil prosedur jarak jauh (RPC) - ini berfungsi di atas HTTP / 2. GRPC didasarkan pada apa yang disebut protofile (lihat contoh di bawah), tugas utamanya adalah mendeklarasikan dua hal dalam bentuk yang ringkas:

• memberikan daftar lengkap antarmuka layanan (analog antarmuka API);
• menjelaskan apa yang diumpankan ke input dari setiap antarmuka dan apa yang kita dapatkan di output.

Di bawah ini, sebagai contoh, protofile dari layanan Kategori diberikan.

syntax = "proto3"; package protobuf; import "google/api/annotations.proto"; //   Category service CategoryService { //  rpc Create (CreateCategoryRequest) returns (CreateCategoryResponse) { option (google.api.http) = { post: "/api/v1/category" }; } //  rpc Update (UpdateCategoryRequest) returns (UpdateCategoryResponse) { option (google.api.http) = { post: "/api/v1/category/{Slug}" }; } //  rpc Delete (DeleteCategoryRequest) returns (DeleteCategoryResponse) { option (google.api.http) = { delete: "/api/v1/category/{Slug}" }; } //   SLUG rpc Get (GetCategoryRequest) returns (GetCategoryResponse) { option (google.api.http) = { get: "/api/v1/category/{Slug}" }; } // rpc Find (FindCategoryRequest) returns (FindCategoryResponse) { option (google.api.http) = { get: "/api/v1/category" }; } } //------------------------------------------ // CREATE //------------------------------------------ message CreateCategoryRequest { string ParentId = 1; string Name = 2; string Path = 3; } message CreateCategoryResponse { Category Category = 1; } //------------------------------------------ // UPDATE //------------------------------------------ message UpdateCategoryRequest { string Slug = 1; string ParentId = 2; string Name = 4; string Path = 5; int32 Status = 6; } message UpdateCategoryResponse { int32 Status =1; } //------------------------------------------ // DELETE //------------------------------------------ message DeleteCategoryRequest { string Slug = 1; } message DeleteCategoryResponse { int32 Status =1; } //------------------------------------------ // GET //------------------------------------------ message GetCategoryRequest { string Slug = 1; } message GetCategoryResponse { Category Category = 1; } //------------------------------------------ // FIND //------------------------------------------ message FindCategoryRequest { string Slug = 1; } message FindCategoryResponse { repeated Category Categories = 1; } //------------------------------------------ // CATEGORY //------------------------------------------ message Category { string Slug = 1; string ParentId = 2; string Path = 3; string Name = 4; int32 Status = 5; } 

Sekarang kita telah mengetahui secara umum mengapa protofil diperlukan, mari kita lihat bagaimana proses pengembangan dari layanan microser kami.

1. Kami menggambarkan struktur layanan di protofile;
2. Kami memulai pembuat kode (./bin/protogen.sh), itu akan menghasilkan bagian utama dari kode server untuk kami + itu akan membuat kode klien, misalnya, untuk Gateway API + itu akan membuat dokumentasi terkini dalam format angkuh;
3. Yang harus kita lakukan dengan tangan kita sendiri adalah menulis kode untuk implementasi antarmuka dalam file khusus /protobuf/functions.go.

Lebih lanjut, jika kita ingin membuat perubahan pada salah satu layanan microser kami, kami melanjutkan sesuai dengan algoritma di atas: kami mengedit protofile, menjalankan protogen, kami mengedit implementasi di functions.go, dan perubahan akan "meninggalkan" secara otomatis ke dokumentasi dan ke klien.

Lanjutan di artikel "Menulis Blog di Layanan Mikro Bagian 2 dari Gateway API . "