Membangun masa depan: Arsitektur layanan mikro

Ketika membahas roadmap arsitektur 2-3 tahun untuk sistem e-commerce yang sudah berjalan beberapa tahun, pertanyaan umum adalah— apakah kita perlu menggunakan arsitektur microservices?

Layanan mikro adalah kata kunci yang populer saat ini, jadi wajar untuk mempertimbangkannya untuk evolusi sistem. Namun, pendorong utama untuk merancang ulang sistem monolitik menjadi layanan mikro benar-benar bersifat bisnis dan operasional, seperti:

1. Merancang untuk pertumbuhan bisnis: Karena sistem melayani lebih banyak pelanggan dan memproses lebih banyak transaksi, dibutuhkan lebih banyak kapasitas dan sumber daya. Namun, tidak semua bagian dari sistem dapat tumbuh dengan kecepatan yang sama.
2. Menangani puncak lalu lintas: Idealnya, sistem harus dapat menskalakan secara otomatis, atau setidaknya secara dinamis dengan cara infrastruktur tidak didorong ke kapasitas maksimal untuk mendukung lalu lintas puncak setiap saat.
3. Waktu pemasaran yang lebih cepat: Ada nilai signifikan bagi bisnis saat menambahkan atau memodifikasi fitur membutuhkan waktu berhari-hari atau berminggu-minggu, bukan berbulan-bulan dan tidak memerlukan pengujian regresi yang berlebihan (dan seringkali mahal) dan memulai ulang semua aplikasi yang menjalankan seluruh lingkungan. Jawabannya adalah modularitas dan desain untuk penggantian, yang difasilitasi oleh layanan mikro.
4. Perubahan cepat dan instan pada konten dan pengalaman pengguna: Banyak sistem online tradisional menghasilkan konten secara dinamis di sisi server, dari aplikasi web yang sama yang juga berisi fungsionalitas untuk checkout, akun saya, dan fitur lainnya (mis. monolit). Ini berarti bahwa meskipun konten yang dihadapi pelanggan dapat diperbarui, berpotensi dipersonalisasi, dan dapat dikelola, terus diperbarui, konten tersebut menghabiskan banyak sekali siklus CPU, menciptakan ketergantungan online pada penyimpanan data dan kemungkinan subsistem lainnya.

Tujuan akhir dari arsitektur layanan mikro adalah untuk memecah aplikasi ini menjadi layanan yang relatif independen yang menyajikan konten default, memberikan informasi tentang status inventaris, dan menyajikan penawaran dan rekomendasi yang dipersonalisasi. Layanan ini kemudian dapat disetel, diskalakan, dan dikelola untuk mencapai pengalaman pengguna terbaik.

Idenya di sini adalah untuk memiliki sistem yang terdiri dari beberapa layanan mandiri, terukur, dan dapat diganti.

Bata demi bata: Memindahkan sistem secara bertahap

Lalu pertanyaannya, bagaimana kita mengeksekusi rencana ini? Menulis ulang sistem dari awal biasanya tidak dapat diterima. Ada investasi ke dalam platform saat ini, fungsionalitasnya diuji dan dibuktikan, atau ada peningkatan fungsional lain yang perlu diselesaikan dalam sistem saat ini.

Mungkin merupakan pendekatan yang lebih baik untuk menyetujui arsitektur target dan mulai secara bertahap menggerakkan sistem menuju target dengan memasukkan aktivitas re-arsitektur dalam rencana pengembangan peta jalan:

1. Identifikasi perubahan yang akan mengatasi masalah bisnis prioritas utama dan rencana untuk refactoring/migrasi. Misalnya "memisahkan manajemen konten dari bagian transaksional sistem ", sehingga perubahan dapat didorong ke situs lebih cepat.
2. Saat menambahkan fitur (misalnya 'Anda mungkin juga menyukai' atau 'Jika Anda menghabiskan X tambahan…') alih-alih memadukannya ke dalam aplikasi saat ini, pertimbangkan apakah itu sesuatu yang dapat memberikan nilai sebagai layanan mandiri yang menampilkan antarmuka dan dapat dikelola secara mandiri. Itu tidak perlu dijalankan sebagai proses mandiri atau dapat digunakan sendiri di awal, tetapi harus dienkapsulasi dengan baik dengan dependensi minimum yang dipahami dengan baik.
3. Saat membuat perubahan signifikan pada subsistem—misalnya MyAccount—pertimbangkan apakah ini saat yang tepat untuk menjadikannya sebagai aplikasi atau layanan sendiri. Sekali lagi, faktor penting adalah mempertimbangkan ketergantungan—pada kode serta tingkat runtime.

Jika dengan membuat perubahan pada layanan MyAccount mengharuskan semua modul lain dikompilasi ulang dan digunakan kembali, maka itu bukan kandidat yang baik untuk migrasi (belum). Tetapi mungkin ada modul kandidat lain yang mencakup masalah domain spesifik mereka sendiri:

• • Layanan komunikasi email pelanggan
  • Checkout sebagai layanan
  • Layanan ketersediaan barang
  • Mesin pencari perdagangan
  • Berbagai layanan personalisasi, konsultasi, atau rekomendasi
  • Ulasan produk/layanan penilaian

Menskalakan proyek Anda dengan cara yang benar: Mendefinisikan proses dan rencana arsitektur layanan mikro

Seperti yang Anda lihat, gambar ini dapat dengan cepat mulai merasa sibuk, dengan jumlah layanan yang bertambah dan menambah perasaan kompleksitas solusi yang meningkat. Untuk mengatasi hal ini, tim perlu memberikan perhatian ekstra pada aspek proyek berikut:

Kejelasan arsitektur: Ini tidak berarti pendekatan 'desain besar di depan', tetapi tim perlu berbagi visi dan pemahaman yang sama tentang layanan mana yang akan terdiri dari sistem, dan bagaimana layanan akan dibangun, disebarkan , dan dipantau. Tim harus siap untuk mengadopsi praktik yang berbeda (API-pertama), kerangka kerja (Spring Cloud), elemen infrastruktur aplikasi umum—API Gateway, server autentikasi, registri layanan, dll. Tidak semuanya selalu diperlukan, tetapi harus keputusan arsitektur sadar apakah mereka akan menjadi bagian dari sistem atau tidak.

DevOps: Ini adalah kata kunci populer lainnya, tetapi sangat penting dalam konteks ini. Seiring pertumbuhan sistem, jumlah layanan bisa menjadi sangat banyak, jadi di dunia layanan mikro, DevOps adalah elemen yang diperlukan. Itu berarti otomatisasi dan perampingan build, pengujian penerapan, restart, penskalaan otomatis, peringatan, dll. Kami tidak berurusan dengan satu file biner yang disebarkan ke beberapa server aplikasi. Mungkin ada lusinan fungsionalitas yang lebih kecil yang masing-masing berpotensi berjalan dalam banyak instance, itu bukan sesuatu yang ingin didukung oleh siapa pun secara manual. Bayangkan saja mengumpulkan log secara manual dari semua aplikasi yang berjalan ini…

Arsitektur layanan mikro: Melakukannya dengan benar

Ada banyak cara untuk membuat migrasi ke layanan mikro salah: Dengan hanya mengikuti buzz teknologi, tanpa kasus bisnis nyata untuk itu, mengidentifikasi layanan yang tidak sesuai yang terlalu bergantung satu sama lain, gagal mengadopsi praktik DevOps untuk mengatasi kompleksitas, tidak mengembangkan keterampilan yang tepat dalam tim dll.

Namun, dengan perencanaan dan manajemen risiko yang tepat, setelah beberapa waktu (dan stres, dan keraguan, dan kepanikan PM) tim harus mulai merasakan beberapa dampak positif:

• Sistem atau bagian-bagian penting skala lebih baik
• Lebih mudah untuk menghadirkan fitur baru tanpa harus memulai ulang yang lainnya di tengah malam
• Komponen sistem memiliki tujuan yang lebih jelas, dan karenanya lebih mudah untuk dikembangkan, diuji, dan diganti

Peta jalan arsitektur adalah alat yang membantu menentukan arah evolusi sistem untuk dua-tiga tahun ke depan.

Itu perlu diselaraskan dengan baik dengan peta jalan bisnis, teknologi strategis dan arah industri dan dengan keterampilan dan kemampuan tim. Kepentingannya terutama meningkat dengan pengenalan konsep dan pendekatan arsitektur baru seperti layanan mikro.