Apa yang menarik banyak pengembang ke layanan-layanan mikro? Tidak ada teknologi revolusioner di belakang mereka, keuntungan atas monolit cukup kontroversial. Hanya kemudahan dengan alat pengembangan dan penyebaran modern yang memungkinkan Anda membuat sistem untuk dijalankan di ribuan server. Kami mengusulkan untuk melacak jalur hingga saat ini, ketika pengembangan dan penyebaran sistem terdistribusi seperti itu dimungkinkan oleh satu pengembang. Tentang bagaimana wadah Linux, Docker dan Kubernetes telah berevolusi, peran yang dimainkan oleh wadah Linux, Docker dan Kubernetes, kata Alexander Trekhlebov holonavt , arsitek perusahaan Promsvyazbank, telah mengembangkan perangkat lunak selama lebih dari 15 tahun. Dimulai dengan C ++, kemudian beralih ke Java. Baru-baru ini, ia mengembangkan backend perbankan pada platform Spring Cloud.
Jika kita mengingat implementasi pertama dari eksekusi skrip (Java Script, VB Script) sebagai bagian dari menampilkan halaman di browser, maka ini adalah urutan instruksi single-threaded. JavaScript yang sama - ini adalah tugas tunggal. Jika JS dieksekusi dalam satu halaman web, dan salah satu instruksi yang dapat dieksekusi gagal atau tertunda, maka semua yang terjadi pada halaman tersebut, semua kode dibekukan. Dan Anda tidak dapat melakukan apa pun, cukup tutup atau muat ulang halaman, dan terkadang browser atau seluruh sistem operasi.
Jelas, itu sangat tidak nyaman. Terutama ketika Anda mempertimbangkan fakta bahwa multitasking / multithreading sudah ada di mana-mana: prosesor, sistem operasi, aplikasi (kecuali OS pertama untuk perangkat seluler adalah penugasan tunggal), dan JS masih berurutan tunggal. Apa yang terjadi kemudian? Berbagai kerangka kerja mulai muncul satu demi satu, satu atau lain cara menyelesaikan masalah ini. Agar Facebook Bereaksi, Google merilis Angular.
Frontend dan backend badai multitasking
Bagaimana Anda membuat multitasking dari sistem satu-tugas? Ikuti instruksi dan sebar di berbagai aliran, plus, tentu saja, pantau aliran ini. Tentunya Anda masih ingat bagaimana di salah satu versi FB tiba-tiba muncul kemampuan untuk secara bersamaan menulis pesan dan memantau perubahan dalam rekaman itu. Dan jika tiba-tiba kaset itu jatuh, maka pesan itu terus bekerja. Saat itulah UI pertama muncul pada antarmuka modular Bereaksi. Dengan bantuan kerangka kerja, multitasking mulai bekerja di luar kotak.
Apa hubungannya semua ini dengan layanan mikro? Ketika UI bank-bank Internet mulai menyediakan fungsionalitas yang cukup luas, pembekuan, dan bahkan jatuhnya aplikasi, menjadi peristiwa yang mengejutkan bagi pengguna. Lagi pula, itu satu hal ketika Facebook macet, dan satu hal lagi - ketika Anda baru saja melakukan pembayaran hipotek, dan dana di akun Anda tidak muncul, karena ada kegagalan dalam bentuk saldo akun.
Sebuah ide sederhana muncul - elemen antarmuka pengguna independen yang memungkinkan Angular dan Bereaksi untuk dilampirkan ke elemen backend yang sama-sama independen. Setiap elemen backend independen adalah layanan microser yang dapat menskala, bangkit setelah kegagalan, dll.
Sangat penting untuk membangun antarmuka pengguna dengan benar sehingga dimodifikasi tergantung pada komponen backend yang tersedia. Jika sesuatu tidak bekerja untuk Anda di backend, maka Anda tidak menunjukkan fungsionalitas yang sesuai pada UI, atau Anda menunjukkannya dalam beberapa cara default - Anda dapat mengubah warna font menjadi abu-abu atau menampilkan piring kosong dengan tulisan "Informasi saldo akun tidak tersedia. Telepon kembali besok ". Sebenarnya, kombinasi antara elemen UI dengan layanan microser membantu meningkatkan keandalan dan skalabilitas aplikasi perbankan secara keseluruhan.
Dari Titanic ke Docker
Menurut pendapat saya, alasan utama mengapa layanan mikro menjadi begitu populer, meskipun konsumsi memori dan overhead yang signifikan dalam daya komputasi, adalah dekomposisi. Selebihnya, pada umumnya, layanan-layanan microser tidak memiliki keunggulan besar dibandingkan monolith. Menurut saya, dekomposisi adalah ketika fungsional dibagi menjadi beberapa blok independen tertentu untuk diluncurkan dan digunakan. Ini berarti bahwa sementara sisa blok bekerja, satu dapat diperbarui, seringkali tanpa menghentikan pekerjaannya (biru, hijau - penyebaran), dan meningkatkan contoh tambahan.
Semua teknologi ini muncul bukan kemarin dan bukan sehari sebelum kemarin. Solusi komputasi terdistribusi dikembangkan kembali pada zaman mainframe karena kurangnya sumber daya komputasi muncul segera setelah sumber daya ini muncul.
Mereka mulai mencari cara untuk mendistribusikan semua ini secara rasional, misalnya, perhitungan grafis di stasiun Silicon Graphix. Itu semua mahal, dan solusi seperti itu hanya tersedia untuk organisasi besar, belum lagi pengembang individu. Stasiun itu sendiri dan perangkat lunak server untuk mereka sangat mahal, sehingga kemampuan yang sesuai dikembangkan untuk kernel Linux. Sebagai contoh - komputasi komputer grafik untuk adegan film "Titanic", yang dirilis kembali pada tahun 1997, dilakukan pada server dengan prosesor Alpha yang menjalankan Linux. Sebagian besar solusi yang diperlukan untuk pengoperasian sistem terdistribusi sudah dikembangkan dan diuji pada waktu itu. Tetapi masih sulit bagi seorang spesialis untuk menggunakan semua teknologi ini, perakitan, pengiriman dan dukungan dari sistem seperti itu membutuhkan biaya tenaga kerja yang serius.
Pada awalnya hanya ada server fisik yang perlu dirutekan, kemudian era virtualisasi dimulai, mesin virtual muncul, pekerjaan berjalan lebih menyenangkan, tetapi masih memulai dan menghentikan mesin virtual tetap merupakan tindakan intensif sumber daya. Dan saya ingin itu terjadi secepat memulai proses di dalam sistem operasi. Sebuah langkah besar menuju pelepasan teknologi "pada orang-orang" dikaitkan dengan munculnya Linux-container.
Wadah Linux hampir merupakan proses sistem, tetapi memiliki antarmuka jaringan sendiri dan banyak lagi yang membuatnya hampir seperti mesin virtual. Kenapa hampir? Karena mesin virtual naik di lingkungan yang cukup terisolasi. Wadah Linux menggunakan sistem operasi induk, setiap wadah memiliki versi Linux OS sendiri, tetapi panggilan sistem disiarkan ke kernel OS induk.
Ini memiliki kelebihan - ketika membuat wadah LXC, Anda tidak perlu menaikkan kembali kernel. Namun, bekerja dengan wadah LXC dalam bentuk aslinya sangat memakan waktu dan merepotkan. Sebenarnya di beberapa titik Docker muncul. Keputusan ini mengambil semua masalah penyebaran dan pengelolaan wadah Linux, memperlihatkan antarmuka yang lebih nyaman.
Munculnya Docker adalah dorongan untuk penyebaran luas arsitektur layanan mikro. Ya, teknologi diciptakan untuk waktu yang lama, tetapi kemungkinan penggunaannya yang nyaman hanya muncul pada saat ini. Sekarang, menggunakan Docker, pengembang benar-benar dapat memasangkan beberapa mesin virtual dengan beberapa perintah dan mengatur sistem komputasi terdistribusi, dan kemudian secara dinamis memperbarui dan skala itu.
Dengan demikian, kemampuan dekomposisi memungkinkan lingkaran pengembang yang luas untuk mengubah monolith menjadi seperangkat layanan mikro di dalam wadah. Namun, kesulitan baru muncul di sini. Ketika ada beberapa lusin kontainer dan mereka tersebar di beberapa server, Anda perlu entah bagaimana mengaturnya, menemani mereka, melakukan orkestrasi mereka. Solusi seperti Docker Swarm dan Kubernetes telah muncul di sini. Pengembang individu menerima alat yang kuat baru.
Layanan microser di bank
Bagaimana situasi dengan layanan mikro di industri perbankan? Berapa banyak, misalnya, yang diperlukan untuk mendukung perbankan online? Ada contoh yang bagus: di Inggris ada bank yang sepenuhnya digital - Monzo, tidak memiliki back-office, tidak ada cabang, tidak ada situs web, pada dasarnya semuanya ada dalam aplikasi mobile. Semuanya dimulai dengan 40 layanan mikro, kemudian jumlahnya bertambah menjadi 300, sekarang lebih.
Jika Anda melihat implementasinya di Promsvyazbank, maka kami memiliki sistem dengan hingga 40 layanan mikro yang digunakan.
Secara paralel, sistem pengembangan sedang dikembangkan yang memungkinkan penggunaan beberapa baris kode untuk mengembangkan komponen utama dari sistem layanan mikro, yang dapat ditingkatkan dan diperbarui dengan cukup sederhana. Semua fitur ini sangat populer dalam pembangunan sistem pembelajaran mesin, analisis sejumlah besar data secara real time (Cloud Streaming, dll.).
Alexander Trekhlebov akan menceritakan tentang pengalaman pengembangannya berdasarkan arsitektur layanan mikro dalam laporan "Layanan mikro - toleransi kesalahan berdasarkan modularitas ujung-ke-ujung" di 404 Internet Workers Festival , yang akan diadakan pada 6-7 Oktober 2018 di Samara.