Kami baru-baru ini menulis tentang cara kerja arsitek TI , dan sekarang kami akan memberi tahu Anda detail tentang salah satu kasus kami dan menunjukkan skema sistem. Dalam proyek ini, kami membantu mengganti aplikasi perbankan "kotak" dengan layanan mikro RBS, sambil membuat rilis cepat rilis - rata-rata, seminggu sekali.
: , , -. NDA – , , , -.
«»
Di antara perusahaan menengah dan kecil, solusi TI siap pakai sangat diminati, yang dapat disesuaikan dan dirilis dengan logo mereka sendiri. Kontra - fungsi aplikasi "di luar kotak" terbatas, dan pembaruan seringkali harus dilakukan untuk waktu yang lama dan secara eksklusif melalui vendor.
Salah satu klien kami menggunakan sistem "kotak" layanan perbankan jarak jauh (RBS) semacam itu. Bank online adalah aplikasi monolitik dengan serangkaian fungsi yang cukup kecil.
Agar tidak kalah dengan kompetitor, bank harus senantiasa memperkenalkan penyempurnaan dan fitur baru. Namun, bahkan untuk sekadar memindahkan tombol dalam aplikasi, Anda harus menghubungi vendornya. Pembaruan dirilis rata-rata sekali dalam seperempat.
Sehingga, sulit untuk mengembangkan produk karena sejumlah batasan:
- , «» .
- - «» -.
- , .
- , . .
- , .
- - , , , .
Akibatnya, bank mengambil keputusan untuk secara bertahap meninggalkan "kotak" dan mengembangkan sistem perbankan jarak jauhnya sendiri, dengan arsitektur layanan mikro untuk mempercepat pengembangan fungsi dan memberikan kenyamanan dan keamanan bagi pengguna.
Darimana kita mulai
Penciptaan bank online dimulai dengan merancang arsitektur tingkat tinggi, mempekerjakan pengembang sebagai staf, dan menghubungkan tim khusus kami. Pada saat yang sama, arsitektur harus diletakkan dengan batas keamanan, dengan mengandalkan perluasan di masa depan.
Pada awalnya, tim pengembangan Backend kami terlibat dalam penerapan fungsi dasar tertentu: misalnya, transfer uang. Namun, kami memiliki cukup banyak pengalaman bekerja dengan bank online, salah satu proyek kami saat ini memasuki peringkat industri Markswebb, jadi kami menawarkan bantuan bank dalam desain arsitektur - dan menerima lampu hijau.
Arsitektur
Bersama dengan pemilik produk, kami memutuskan untuk menggunakan Spring Cloud, yang menyediakan semua fungsi yang diperlukan untuk mengimplementasikan arsitektur layanan mikro: ini adalah Penemuan Layanan - Eureka, Api Gateway - Zuul, server Config, dan banyak lagi. OpenShift dipilih sebagai sistem kontainer untuk image Docker, karena infrastruktur bank telah diasah untuk alat ini.
Kami juga menganalisis fitur apa dari "kotak" lama yang dapat mempersulit pekerjaan pengguna. Salah satu kelemahan utamanya adalah sistem bekerja secara sinkron melalui bus data, dan setiap tindakan pengguna menyebabkan akses ke bus. Karena beban berat, bus sering rusak, dan seluruh aplikasi berhenti bekerja. Selain itu, seperti pada banyak produk perbankan lama, warisan telah terakumulasi - "warisan" dalam bentuk CORE ABS yang lama dan berat, yang akan sulit dan mahal untuk ditulis ulang.
Kami telah mengusulkan sejumlah perbaikan:
- Pembuatan versi
Sebelumnya, "kotak" hanya mendukung satu versi, tetapi di bank online baru kami telah mengusulkan arsitektur baru yang memungkinkan kami mendukung beberapa versi berbeda pada waktu yang sama dan menggantinya jika perlu.
Skema pembuatan versi adalah sebagai berikut: jika versi minor dalam layanan telah berubah, maka layanan secara otomatis dibangun kembali dan diterapkan, menggantikan versi yang sudah ketinggalan zaman. Jika kita meletakkan versi utama, maka salinan baru dari layanan dengan versi baru akan diterapkan. Dengan demikian, pengembangan fungsi baru dengan perubahan dalam API layanan tidak mempengaruhi aplikasi seluler, sementara waktu pengujian berkurang. Sistem seperti itu memungkinkan untuk memberikan dukungan untuk versi aplikasi seluler yang bahkan sudah ketinggalan zaman jika pengguna tidak memiliki kesempatan untuk memperbarui.
- Asinkron
Kami telah menerapkan perpustakaan yang dapat digunakan dalam layanan yang membutuhkan pekerjaan asinkron. Pustaka mengimplementasikan eksekusi tugas asinkron, cocok untuk digunakan pada sejumlah salinan layanan, dan mereka tidak saling mengganggu. Sinkronisasi antar salinan yang berbeda dilakukan menggunakan antrian pesan Kafka.
Solusi ini membantu meningkatkan stabilitas aplikasi. Aplikasi seluler sekarang tidak bergantung pada bus, kami menggandakan data yang diperlukan untuk pengguna di layanan kami dan memperbaruinya di latar belakang saat ada akses ke bus bank. Semua tindakan pengguna antri untuk dieksekusi, segera setelah siap, pemberitahuan PUSH tentang hasil diterima.
- Caching
Untuk mempercepat aplikasi dan mengurangi beban pada sumber daya perbankan internal, data caching menggunakan Redis diatur. KeyDB berfungsi sebagai cache, yang menunjukkan hasil yang baik dan kompatibel dengan banyak sistem yang menggunakan Redis. Data di-cache bukan setelah permintaan pengguna, tetapi ketika data pengguna berubah, yang memungkinkan akses ke mereka secara independen dari sistem perbankan internal.
Apa yang telah berubah dalam sistem
Seperti disebutkan di atas, di bank online lama, backend diimplementasikan dalam arsitektur monolitik, aplikasi diterapkan di mesin terpisah. Saat beban meningkat, server baru harus digunakan. Saat server rusak, aplikasi seluler tidak berfungsi untuk beberapa pengguna.
Solusi baru ini menggunakan arsitektur layanan mikro, yang memungkinkan Anda menerapkan sebanyak mungkin salinan layanan yang diperlukan untuk fungsionalitas tertentu. Kami telah menambahkan cache data berbasis KeyDB untuk tidak hanya meningkatkan kecepatan pengambilan informasi, tetapi juga mengurangi beban pada database.
Mari kita lihat contoh mendapatkan data pada akun pengguna di arsitektur baru. Permintaan pengguna dari aplikasi seluler melewati penyeimbang ke Gateway, yang memahami layanan mana yang akan dikirimi permintaan. Selanjutnya, kita masuk ke API layanan akun. Layanan pertama kali memeriksa apakah ada data pengguna yang sebenarnya di Cache. Jika berhasil, ia mengembalikan data, jika tidak ia mengirimkan permintaan ke layanan akun Tengah.
Pembaruan data dalam layanan dapat terjadi dalam berbagai kasus. Misalnya, atas permintaan langsung dari pengguna, layanan membuat tugas pembaruan data yang berjalan secara asinkron, dan data yang diterima dari ESB diperbarui. Layanan juga menerima pesan dari antrian pesan dan menanggapinya. Misalnya, layanan menerima pesan tentang pengguna yang masuk ke aplikasi dan segera memperbarui data akun, menerima data tentang transaksi akun dari layanan lain, dan memperbarui datanya. Karenanya, pengguna selalu melihat data terbaru di akunnya.
Di antara perubahan terpenting adalah sebagai berikut:
- Fleksibilitas penskalaan
Untuk meningkatkan toleransi kesalahan sistem, layanan didistribusikan ke server yang berbeda. Ini memungkinkan Anda untuk menjaga sistem dalam keadaan baik jika salah satu dari mereka jatuh. Untuk respons tepat waktu terhadap situasi non-standar, kami memperkenalkan sistem pemantauan, yang membantu meningkatkan layanan jika perlu. Kami menghubungkan DevOps untuk mengonfigurasi CI / CD dari awal di server klien, membuat penerapan, dan mendukung proses untuk aplikasi di masa mendatang di beberapa server.
- Percepatan rilis karena pembuatan versi
Sebelumnya, saat memperbarui versi seluler, beberapa pengguna sudah menerapkan versi baru, sementara yang lain tidak, tetapi jumlah yang terakhir sangat sedikit. Saat mengembangkan RBS baru, kami menerapkan pembuatan versi dan kemampuan untuk merilis rilis tanpa risiko bahwa aplikasi akan berhenti berfungsi untuk sebagian besar pelanggan. Sekarang, saat mengimplementasikan fungsionalitas individu dalam versi baru, kami tidak merusak versi lama, yang berarti tidak perlu mundur. Ini membantu mempercepat frekuensi rilis setidaknya 15 kali - sekarang rilis dirilis rata-rata seminggu sekali. Tim Backend dan Seluler dapat secara bersamaan dan mandiri mengerjakan fungsi baru.
Menyimpulkan
Dalam contoh ini, kami berbicara tentang merancang arsitektur layanan mikro untuk bank, yang menggantikan solusi monolitik "kotak". Sebuah tim terdistribusi mengerjakan proyek ini, yang mencakup pengembang in-house dan agen outsourcing.
Saat mengembangkan bank online, kami bertujuan untuk mengimplementasikan ruang lingkup fungsi yang sama di aplikasi baru seperti di kotak, dan secara bertahap mengembangkannya.
Untuk mencegah pelanggan churn, itu perlu untuk membangun operasi aplikasi bebas masalah, tanpa kegagalan dan waktu henti, dan rilis reguler rilis dan pembaruan. Ini dilakukan berkat perbaikan arsitektur. Secara khusus, setelah mengurangi beban pada database, kami mencapai ketersediaan aplikasi yang konstan, dan karena versi, kami mengurangi waktu pengujian, memastikan kemungkinan pekerjaan independen pada fungsionalitas dan rilis rilis seminggu sekali.
Arsitektur aplikasi didasarkan pada pertumbuhan lebih lanjut dari produk dan alat pengembangan yang digunakan oleh tim internal perbankan sehingga pemilik produk dapat secara mandiri melakukan perbaikan pada RBS. Persyaratan pengembangan aktif dari versi alfa adalah sekitar satu tahun, setelah 3 bulan lagi versi beta dirilis untuk semua pengguna.
Kami berharap skema kerja yang dijelaskan dapat bermanfaat saat membuat produk fintech lainnya.
Terima kasih atas perhatian Anda!