Daripada Monolit kepada Perkhidmatan Mikro
Tentukan perkara yang perlu dipecahkan dan cara menetapkan sempadan perkhidmatan.
Daripada Monolit kepada Perkhidmatan Mikro ialah pelajaran PHP Academy percuma di CoddyKit. Ini ialah pelajaran 1 daripada 4. Anda boleh membaca keseluruhan pelajaran di bawah secara percuma — kemudian berlatih secara praktikal dalam pelayar menggunakan penyunting kod terbina dalam dan tutor kecerdasan buatan 24/7. Pelajaran ini merupakan sebahagian daripada laluan pembelajaran PHP Academy, dan kemajuan anda disegerakkan merentas web serta aplikasi CoddyKit. Kursus PHP Academy merangkumi sejumlah 4 pelajaran.
Monolit kepada Mikroperkhidmatan
Mikroperkhidmatan ialah pertaruhan organisasi dan operasi, bukan pilihan lalai. Memisahkan monolit PHP menukarkan kesederhanaan dalam proses kepada panggilan rangkaian, data teragih dan kerumitan penerapan. Jika dilakukan atas sebab yang salah, semuanya menjadi lebih perlahan.
Pelajaran ini membincangkan bahagian yang paling sukar: melukis sempadan perkhidmatan. Jika sambungannya tepat, selebihnya hanyalah kerja sokongan; jika tersilap, anda akan membina monolit teragih — menanggung semua kos tanpa mendapat manfaatnya.
Mengapa (dan Mengapa Tidak) Memisahkan
Sebab yang baik untuk memisahkan:
- Kebolehterapan dan pemilikan pasukan secara bebas.
- Penskalaan subsistem yang sibuk secara bebas.
- Pengasingan teknologi/persekitaran masa jalan dan pembendungan kegagalan.
Sebab yang tidak baik: "kodnya berserabut" (perbaik monolit itu dahulu), atau sekadar mengejar trend. Jika dua perkhidmatan mesti sentiasa diterapkan bersama atau berkongsi jadual pangkalan data, kedua-duanya sebenarnya satu perkhidmatan dengan dua peranan.
Konteks Terhad
Reka Bentuk Dipacu Domain memberikan alat paling tajam untuk menentukan sempadan: konteks terhad. Dalam satu konteks, istilah mempunyai satu makna yang tepat. "Pelanggan" dalam Pengebilan (sasaran invois) berbeza daripada "Pelanggan" dalam Sokongan (penulis tiket).
Setiap konteks terhad ialah calon yang kukuh untuk menjadi sebuah perkhidmatan. Sempadan mengikut bahasa perniagaan dan cara organisasi sebenarnya berkomunikasi — Undang-undang Conway dalam tindakan.
Kohesi Tinggi, Gandingan Rendah
Sempadan perkhidmatan yang baik mengekalkan perkara yang berubah bersama-sama di dalam, dan menolak perkara yang berubah secara berasingan ke luar. Nilai pemisahan yang dicadangkan berdasarkan:
- Berapa banyak ciri memerlukan anda menyentuh dua perkhidmatan serentak? (Sepatutnya sedikit.)
- Seberapa kerap panggilan berlaku antara kedua-duanya? (Sepatutnya berbutir kasar.)
Jika pelaksanaan satu ciri sentiasa merentasi sempadan, sempadan itu berada di tempat yang salah.
<?php
// Chatty boundary smell: N network calls to render one view
foreach ($order->lineItems as $item) {
$product = $catalogApi->get($item->productId); // one call PER item!
$names[] = $product['name'];
}
// Coarse-grained: one batch call across the boundary
$ids = array_map(fn($i) => $i->productId, $order->lineItems);
$names = $catalogApi->getMany($ids); // single round-trip
echo count($names) . " products in one call\n";Pangkalan Data bagi Setiap Perkhidmatan
Peraturan yang tidak boleh dirunding: setiap perkhidmatan memiliki datanya sendiri dan tiada perkhidmatan lain menyentuh jadualnya. Pangkalan data dikongsi menghidupkan semula gandingan yang cuba anda elakkan — perubahan skema merosakkan perkhidmatan yang tiada kaitan.
Ini bermakna pertanyaan merentas perkhidmatan yang dahulunya ialah SQL JOIN dalam monolit kini menjadi panggilan API atau model bacaan yang direplikasi. Itulah kosnya, dan itulah tujuannya.
<?php
// In the monolith: one JOIN across domains
$sql = 'SELECT o.id, c.email
FROM orders o JOIN customers c ON c.id = o.customer_id';
// After split: Orders service holds only the foreign id;
// it asks the Customers service for the rest (or keeps a local read model).
$order = $orderRepo->find($id); // local
$customer = $customersApi->get($order->customerId); // network call
echo $order->id . ' / ' . $customer->email . "\n";Corak Ara Pencekik
Jangan sesekali menulis semula monolit secara besar-besaran sekaligus. Corak ara pencekik mengeluarkan bahagian sistem secara berperingkat: halakan sebahagian trafik kepada perkhidmatan baharu melalui fasad/proksi, kembangkannya, dan hapuskan laluan kod lama hanya apabila laluan baharu meliputinya sepenuhnya.
Proksi songsang (atau get laluan API) berada di hadapan dan menentukan, berdasarkan setiap laluan, sama ada hendak menghubungi monolit legasi atau perkhidmatan baharu. Penghijrahan berjalan satu keupayaan pada satu masa dan sentiasa boleh dilancarkan.
<?php
// Facade routing: peel off one capability at a time
function route(string $path): string {
$migrated = ['/invoices', '/invoices/pdf']; // moved to billing-svc
foreach ($migrated as $prefix) {
if (str_starts_with($path, $prefix)) {
return 'http://billing-svc' . $path;
}
}
return 'http://legacy-monolith' . $path; // everything else, for now
}
echo route('/invoices/pdf'), "\n";
echo route('/users/42'), "\n";Mengeluarkan Modul
Urutan pengekstrakan yang praktikal:
- Cari modul dengan sedikit kebergantungan masuk dan pemilikan data yang jelas.
- Bungkus panggilan dalam prosesnya di sebalik antara muka dalam monolit terlebih dahulu.
- Alihkan data yang dimilikinya ke skema/pangkalan data sendiri.
- Gantikan pelaksanaan antara muka dengan klien rangkaian.
- Alihkan trafik melalui fasad; padamkan kod lama.
Melakukan pembungkusan antara muka dalam monolit terlebih dahulu mengurangkan risiko langkah rangkaian.
<?php
// Step 2: hide the implementation behind a port the monolith calls
interface InvoiceService {
public function generate(string $orderId): string; // returns invoice id
}
// Today: local class. Tomorrow: HTTP client to billing-svc.
// The monolith's calling code never changes.
final class LocalInvoiceService implements InvoiceService {
public function generate(string $orderId): string { return 'inv-1'; }
}Konsistensi Data Teragih
Setelah data dipisahkan, anda kehilangan transaksi ACID merentas perkhidmatan. Terimalah konsistensi akhirnya: perkhidmatan menerbitkan peristiwa tentang data masing-masing dan perkhidmatan lain membina model bacaan setempat daripada peristiwa tersebut.
Perkhidmatan Pesanan tidak membuat pertanyaan kepada Pelanggan pada setiap permintaan — sebaliknya, ia mengekalkan unjuran kecil (hanya medan yang diperlukan), yang dikemas kini oleh peristiwa CustomerUpdated. Ini menghapuskan kebergantungan masa jalan dan satu lompatan kependaman.
<?php
// Orders service keeps a tiny local projection of customer data
function onCustomerUpdated(PDO $db, array $evt): void {
$db->prepare(
'INSERT INTO customer_read_model (id, email)
VALUES (:id, :email)
ON CONFLICT (id) DO UPDATE SET email = EXCLUDED.email'
)->execute(['id' => $evt['id'], 'email' => $evt['email']]);
}Realiti Operasi
Mikroperkhidmatan memindahkan kerumitan daripada kod kepada operasi. Sebelum memisahkan sistem, anda memerlukan:
- Pengelogan berpusat dan penjejakan teragih (ID korelasi merentasi lompatan).
- CI/CD bagi setiap perkhidmatan dan penerapan berversi secara berasingan.
- Pemeriksaan kesihatan, had masa, percubaan semula dan pemutus litar pada setiap panggilan.
- Ujian kontrak supaya penyedia tidak boleh memecahkan pengguna secara senyap.
Jika pasukan anda tidak dapat mengendalikan satu perkhidmatan dengan baik, sepuluh perkhidmatan akan menjadi sepuluh kali lebih teruk.
Penentuan Saiz Perkhidmatan
"Mikro" mengelirukan — tentukan saiz perkhidmatan berdasarkan keupayaan perniagaan dan pemilikan pasukan, bukan berdasarkan baris kod. Jika terlalu terperinci (nanoservis), satu ciri akan bercabang menjadi ribut panggilan rangkaian; jika terlalu kasar, anda kembali kepada monolit.
Panduan praktikal yang sihat: sebuah perkhidmatan harus boleh dimiliki oleh satu pasukan, boleh diterapkan sendiri dan mampu memenuhi kes penggunaan terasnya tanpa rantaian segerak merentasi banyak perkhidmatan setara.
Alternatif Monolit Modular
Sebelum beralih kepada sistem teragih, pertimbangkan monolit modular: satu unit yang boleh diterapkan, tetapi dipecahkan secara dalaman kepada modul dengan sempadan nyata dan skema masing-masing, yang berkomunikasi hanya melalui antara muka yang diterbitkan — tiada capaian jadual merentas modul.
Anda memperoleh sempadan yang kemas dan pemfaktoran semula yang mudah tanpa beban sistem teragih. Apabila sesuatu modul benar-benar memerlukan penskalaan atau pemilikan bebas, bentuknya sudah sesuai untuk dikeluarkan melalui corak ara pencekik. Bagi kebanyakan pasukan, inilah pilihan pertama yang tepat.
<?php
// Modules talk only through interfaces, never each other's tables.
namespace App\Billing; // owns billing_* tables
interface BillingFacade {
public function invoiceForOrder(string $orderId): string;
}
namespace App\Sales; // owns sales_* tables
final class Checkout {
public function __construct(private \App\Billing\BillingFacade $billing) {}
// Sales never SELECTs from billing_* directly - only via the facade.
}Semakan Pantas
Mengenal pasti pemisahan yang tidak baik.
Rumusan
Melukis sempadan perkhidmatan dengan baik:
- Pisahkan untuk kebolehterapan, penskalaan dan pemilikan — bukan kerana kod berserabut.
- Selaraskan sempadan dengan konteks terhad; sasarkan kohesi tinggi dan gandingan rendah.
- Satu pangkalan data bagi setiap perkhidmatan — tiada jadual dikongsi; gantikan JOIN dengan API atau model bacaan.
- Lakukan penghijrahan secara berperingkat dengan corak ara pencekik.
- Terima konsistensi akhirnya dan laburkan usaha dalam operasi sebelum mengembangkan sistem.
Seterusnya: cara perkhidmatan tersebut sebenarnya berkomunikasi — REST dan gRPC.
Pelajari PHP dengan tutor kecerdasan buatan — percuma
Tulis dan jalankan kod sebenar dalam pelayar anda, dapatkan bantuan segera daripada tutor kecerdasan buatan yang tersedia 24/7, dan sambung semula dari tempat anda berhenti di web atau dalam aplikasi.
- Kursus
- 49
- Pelajaran
- 195
Soalan Lazim
Adakah pelajaran “Daripada Monolit kepada Perkhidmatan Mikro” percuma?
Ya — teks penuh “Daripada Monolit kepada Perkhidmatan Mikro” boleh dibaca secara percuma di web ini. Untuk berlatih secara interaktif menggunakan penyunting kod terbina dalam dan tutor kecerdasan buatan 24/7, serta membuka kunci baki kursus PHP Academy, tingkat taraf kepada CoddyKit PRO. Kursus PHP Academy merangkumi sejumlah 4 pelajaran.
Apakah yang akan saya pelajari dalam “Daripada Monolit kepada Perkhidmatan Mikro”?
Tentukan perkara yang perlu dipecahkan dan cara menetapkan sempadan perkhidmatan. Anda berlatih PHP Academy menggunakan kod praktikal yang dijalankan terus dalam pelayar, manakala tutor kecerdasan buatan 24/7 menjawab soalan anda semasa anda mengikuti pelajaran.
Adakah saya memerlukan pengalaman untuk memulakan PHP Academy?
Tiada pengalaman terdahulu diperlukan. Pembelajaran PHP Academy di CoddyKit disusun untuk pelajar daripada peringkat pemula hingga lanjutan, jadi anda boleh bermula di sini atau dari awal dan belajar mengikut kadar anda sendiri. Ini ialah pelajaran 1 daripada 4.
Berapa lamakah pelajaran “Daripada Monolit kepada Perkhidmatan Mikro” diambil?
Kebanyakan pelajaran CoddyKit mengambil masa kira-kira 5–10 minit. Setiap pelajaran ringkas dan interaktif, jadi anda boleh membuat kemajuan secara berterusan dan menyambung tepat dari tempat anda berhenti di web atau aplikasi.
Bolehkah saya menulis dan menjalankan kod dalam pelajaran PHP Academy ini?
Ya. Setiap pelajaran PHP Academy menyertakan penyunting kod terbina dalam, jadi anda boleh menulis dan menjalankan kod sebenar terus dalam pelayar serta menerima maklum balas kecerdasan buatan serta-merta — tanpa memerlukan persediaan setempat.
Semua pelajaran dalam kursus ini
- Daripada Monolit kepada Perkhidmatan Mikro
- Komunikasi Perkhidmatan: REST dan gRPC
- Gerbang API dan Penemuan Perkhidmatan
- Ketahanan: Pemutus Litar dan Percubaan Semula