Kata "layanan mikro" telah ada selama beberapa tahun terakhir. Teknologi ini berkembang secara aktif, orang-orang membicarakannya di konferensi online, dan kami menuliskannya sendiri setiap hari. Dahulu kala, pendekatan baru sudah menjadi rutinitas. Tetapi sebagai arsitek Java, saya tertarik dengan seperti apa kodenya sebelumnya, bagaimana perubahannya, metode eksekusi apa yang populer sekarang dan akan digunakan pada tahun 2021: asynchrony, containers, FaaS.
Beginilah postingan ini lahir dalam dua bagian, yang saya persiapkan untuk Habr berdasarkan artikel saya di blog BellSoft dan meja bundar Joker 2020, di mana kami membahas masa depan Java. Peningkatan aktual ekosistem untuk backend saat ini tidak dapat terjadi tanpa memahami cara membuat layanan mikro: menulis dari awal atau memotong monolit dengan pisau bedah? Saya mengusulkan di bagian pertama untuk membicarakan esensi mereka, dan di bagian kedua - untuk menguraikan wadah layanan mikro menjadi beberapa lapisan dan melihat kontribusi setiap lapisan.
Keuntungan utama ada pada strukturnya
Sebagian besar material pada arsitektur layanan mikro membandingkannya dengan monolit dalam hal struktur. Bagaimana komponen bekerja secara keseluruhan atau secara terpisah. Layanan mikro tidak bergantung satu sama lain dan dapat bertukar data melalui jaringan melalui protokol arbitrer, seperti REST API. Apa yang diberikannya kepada kita? Setidaknya, kebebasan untuk memilih alat apa pun, tanpa melihat ESB, batasan skema, dan seluk-beluk kompatibilitas. Virtualisasi dan penampung juga berkembang, dan sekarang wadah kecil dengan Alpine Linux memungkinkan Anda menjalankan banyak komponen sekaligus pada perangkat keras khusus sebelumnya.
Mari kita ambil layanan sederhana seperti memesan tiket atau mengisi ulang akun. Bahkan sebelum munculnya layanan mikro, pendekatan CRUD digunakan untuk mengelola siklus hidup objek data dalam sistem tersebut. Tetapi semua fungsionalitas yang menyediakan operasi CRUD untuk beberapa entitas dapat dengan mudah diisolasi. Kemudian Anda dapat menangani penskalaan, kontrol akses, dan interaksi secara umum secara terpisah, misalnya, melalui REST.
Semuanya tampak baik-baik saja, apa masalahnya?
Masalah dan solusi
Bagian yang berbeda dari aplikasi monolitik dijalankan dalam memori bersama, dan semua permintaan dikirim ke server fisik yang sama. Microservices saling berkomunikasi melalui protokol, dan hal ini menimbulkan, misalnya:
kesulitan dalam mengatur lalu lintas jaringan dan latensi;
kegagalan permintaan dan kesalahan lainnya;
kebutuhan untuk membuat serial data dan mengenkripsi koneksi.
, API Kafka/Redis/RabbitMQ , . Kafka DevOps.
, , . . , , — . - .
:
(Kafka, Kinesis);
, service mesh (Istio, OSM);
.
— :
, , :
, . streaming platform (, Kafka) , .
, . , . , , .
Service mesh («c ») . , , Sidecar.
, JVM, , .
. , , Docker- .
-, , . , .
- . . , — SOA.
. . , — . , , REST.
Java? , . Java EE 20 . : , XML javadoc ; ; Java 5. . Java EE.
, Java EE (, JNDI), , , . Web 1.0 Web 2.0, . .
Container dependency injection
« ». , . « » — . . , : trailing lambdas Kotlin Ktor; data- , Java 14 record- ( Lombok).
. , /. , , , , . IDE, , . — .
Contexts and Dependency Injection (CDI). CDI Java EE JSR 299/365 Weld, WildFly. — (Inversion of Control, IoC).
: , , ( Spring Data) HTML. . — , . , Convention over Configuration ( « »), IoC- , BeanFactory Spring. .
Seperti yang saya janjikan dalam pendahuluan, postingan ini telah menjadi perjalanan kecil ke dalam sejarah arsitektur layanan mikro - bagaimanapun juga, tanpa itu, tidak ada tempat. Kami bekerja dengan teknologi hebat yang berusia 20+ tahun, tetapi masih terasa modern. Ini karena metodenya sedang diminati dan dijalankan, dan tidak berubah menjadi warisan.
Di bagian kedua, saya akan menganalisis lapisan wadah layanan mikro secara rinci, menjelaskan apa yang dipengaruhi oleh pilihan runtime yang benar, dan memberi tahu Anda cara mengurangi konsumsi sumber daya seminimal mungkin.