Halo, Habr! Kami di RBKmoney menulis pemrosesan pembayaran baru. Dari awal. Nah, bukankah itu mimpi?
Namun, seperti biasa, dalam perjalanan ke mimpi, sebagian besar jalan harus berenang di sepanjang sungai dengan jebakan, sebagian - untuk mengendarai sepeda rakitan Anda sendiri. Dengan cara ini, kami menerima banyak pengetahuan menarik dan berguna yang ingin kami bagikan dengan Anda.
Kami akan memberi tahu Anda bagaimana seluruh pemrosesan Pembayaran RBKmoney ditulis, sebagaimana kami menyebutnya. Bagaimana mereka membuatnya tahan terhadap beban dan kegagalan peralatan, bagaimana mereka muncul dengan kemungkinan penskalaan horizontal yang hampir linier.
Dan pada akhirnya, saat kami semua lepas landas, tidak melupakan kenyamanan orang-orang di dalam, sistem pembayaran kami diciptakan dengan gagasan menjadi menarik terutama bagi pengembang, mereka yang membuatnya.
Dengan posting ini kami membuka serangkaian artikel di mana kami akan berbagi hal-hal teknis, pendekatan dan implementasi yang spesifik, serta pengalaman dalam mengembangkan sistem terdistribusi besar pada prinsipnya. Artikel pertama adalah artikel ulasan, di dalamnya kami menentukan tonggak sejarah yang akan kami ungkapkan secara rinci, dan kadang-kadang dengan sangat rinci.
PenafianSejak publikasi terakhir di blog kami, tidak kurang dari 5 tahun telah berlalu. Selama waktu ini, tim pengembangan kami secara nyata telah diperbarui, sekarang ada orang-orang baru di pucuk pimpinan perusahaan.
Saat Anda membuat sistem pembayaran, Anda perlu mempertimbangkan banyak hal yang berbeda dan mengembangkan banyak solusi. Dari pemrosesan yang dapat memproses ribuan permintaan bersamaan bersamaan untuk mendebit uang ke antarmuka yang ramah pengguna. Basi, jika Anda tidak memperhitungkan nuansa kecil.
Kenyataan pahitnya adalah ada organisasi pembayaran di belakang pemrosesan pembayaran, tidak sama sekali dengan tangan terbuka menerima lalu lintas seperti itu, dan kadang-kadang bahkan meminta "untuk mengirimi kami tidak lebih dari 3 permintaan per detik." Dan orang-orang yang, mungkin, untuk pertama kalinya di Internet memutuskan untuk membayar sesuatu, melihat antarmuka. Dan setiap kusen UX, tidak dapat dimengerti dan ditunda - ini adalah kesempatan untuk panik.
Keranjang tempat Anda dapat melakukan pembelian bahkan selama tornado
Pendekatan kami untuk membuat pemrosesan pembayaran adalah memberikan kemampuan untuk selalu memulai pembayaran. Tidak masalah apa yang terjadi di dalam diri kita - server terbakar, administrator bingung dalam jaringan, listrik terputus di gedung / kabupaten / kota, kami memiliki diesel hmm ... kami kehilangan. Itu tidak masalah. Layanan masih akan memungkinkan Anda untuk memulai pembayaran.
Pendekatannya terdengar akrab, bukan?
Ya, kami terinspirasi oleh konsep yang dijelaskan dalam Amazon Dynamo Paper . Orang-orang dari Amazon juga membangun segalanya sehingga pengguna harus bisa meletakkan buku itu di keranjang, tidak peduli apa yang terjadi di sisi lain monitornya.
Tentu saja, kami tidak melanggar hukum fisika dan belum menemukan cara untuk membantah teorema CAP . Bukan fakta bahwa pembayaran akan dilakukan segera - setelah semua, mungkin ada masalah di sisi bank, tetapi layanan akan membuat permintaan dan pengguna akan melihat bahwa semuanya bekerja. Ya, dan kami idealnya masih selusin daftar jaminan dengan hutang teknis, yang merupakan dosa, kami dapat menjawab 504 sesekali.
Mari kita melihat ke dalam bunker, begitu tornado di luar jendela
Itu diperlukan untuk membuat gateway pembayaran kami selalu tersedia. Apakah beban puncak telah meningkat, sesuatu telah jatuh atau sedang dalam pemeliharaan di DC - pengguna akhir tidak boleh memperhatikan ini sama sekali.
Ini diputuskan dengan meminimalkan tempat di mana keadaan sistem disimpan - jelas bahwa aplikasi stateless mudah untuk ditingkatkan ke cakrawala.
Aplikasi itu sendiri berputar dalam wadah Docker, log dari mana kita andal menggabungkan ke repositori Elasticsearch pusat; mereka menemukan satu sama lain melalui Service Discovery, dan data ditransmisikan melalui IPv6 di dalam layanan Makro .
Semua layanan microsoft yang dikumpulkan dan bekerja bersama, bersama dengan layanan terkait, adalah layanan makro, yang pada akhirnya memberi Anda gateway pembayaran, seperti yang Anda lihat dari luar sebagai API publik kami.
SaltStack mengawasi pesanan, yang menggambarkan seluruh status Macroservice.
Kami akan kembali dengan uraian terperinci tentang seluruh peternakan ini.
Dengan aplikasi lebih mudah.
Tetapi jika Anda menyimpan negara di suatu tempat, maka pastikan untuk dalam database di mana biaya kegagalan sebagian node minimal. Juga, sehingga tidak memiliki master node dengan data. Sehingga dengan waktu tunggu yang bisa ditebak untuk menanggapi permintaan. Apakah ini impian Anda di sini? Kemudian, bahkan untuk melayaninya, itu tidak terlalu perlu, dan bahwa pengembang erlangist menyukainya.
Ya, bukankah kita mengatakan bahwa seluruh bagian online dari pemrosesan kita di Erlang ditulis?
Seperti yang mungkin sudah banyak ditebak, kami tidak punya pilihan.
Seluruh keadaan bagian online dari sistem kami disimpan di Basho Riak . Kami juga akan memberi tahu Anda cara memasak Riak dan tidak mematahkan jari Anda (karena Anda akan mematahkan otak Anda), tetapi untuk sekarang mari kita lanjutkan.
Di mana uangnya, Lebowski?
Jika Anda mengambil jumlah uang yang tak terbatas, Anda mungkin dapat membangun pemrosesan yang sangat andal. Tetapi ini tidak akurat. Dan mereka tidak memberi kita banyak uang. Tepat di tingkat server "kualitas, tetapi China."
Untungnya, ini menimbulkan efek positif. Ketika Anda memahami bahwa sebagai pengembang, akan agak sulit bagi Anda untuk mendapatkan 40 core fisik yang menangani RAM 512GB, Anda harus keluar dan menulis aplikasi kecil. Tetapi mereka dapat digunakan sebanyak yang Anda suka - server masih murah.
Bahkan di dunia kita, server mana pun cenderung tidak hidup kembali setelah reboot, atau bahkan mengalami kegagalan pasokan daya pada saat yang paling tidak tepat.
Dengan memperhatikan semua kengerian ini, kami belajar bagaimana membangun sebuah sistem dengan harapan bahwa setiap bagian darinya akan tiba - tiba pecah. Sulit untuk mengingat apakah pendekatan ini menyebabkan ketidaknyamanan untuk pengembangan bagian pemrosesan online. Mungkin ini terkait dengan filosofi kaum Erlangis dan konsep terkenal mereka LetItCrash ?
Tetapi dengan server lebih mudah.
Kami menemukan di mana menempatkan aplikasi, ada banyak dari mereka, mereka dapat diskalakan. Pangkalan juga didistribusikan, tidak ada master, node yang terbakar tidak disayangkan, kita dapat dengan cepat memuat keranjang dengan server, datang ke DC dan meninggalkan mereka dengan garpu di rak.
Tapi ini tidak terjadi dengan array disk! Kegagalan bahkan penyimpanan disk kecil adalah kegagalan bagian dari layanan pembayaran, yang kami tidak mampu. Penyimpanan duplikat? Terlalu tidak praktis.
Dan kami tidak ingin membeli array disk bermerek yang mahal. Bahkan dari rasa keindahan yang sederhana - mereka tidak akan melihat di sebelah rak tempat kata benda dikemas dalam barisan yang rata. Dan itu sangat mahal.
Pada akhirnya, kami memutuskan untuk tidak menggunakan array disk sama sekali. Semua perangkat blok yang kita miliki menjalankan CEPH pada server murah yang sama - kita dapat menempatkannya di rak dalam jumlah besar yang kita butuhkan.
Dengan perangkat keras jaringan, pendekatannya tidak jauh berbeda. Kami mengambil petani menengah, kami mendapatkan peralatan yang bagus dan cocok untuk tugas itu cukup murah. Dalam kasus kegagalan switch, yang kedua bekerja secara paralel, dan OSPF dikonfigurasi di server, konvergensi dipastikan.
Dengan demikian, kami telah mendapatkan sistem yang nyaman, toleran terhadap kesalahan, dan universal - rak penuh server murah sederhana, beberapa sakelar. Stand selanjutnya. Dan sebagainya.
Sederhana, nyaman, dan keseluruhan - sangat andal.
Dengarkan aturan perilaku di papan tulis
Kami tidak pernah ingin datang ke kantor, bekerja dan dibayar tunai. Komponen keuangan sangat penting, tetapi itu tidak akan menggantikan kesenangan dari pekerjaan yang dilakukan dengan baik. Kami telah menulis sistem pembayaran, termasuk di tempat kerja sebelumnya. Dan kira-kira membayangkan apa yang tidak ingin kita lakukan. Dan saya tidak ingin standar, tetapi solusi yang terbukti, saya tidak ingin perusahaan yang membosankan.
Dan kami memutuskan untuk menarik kesegaran maksimal ke dalam pekerjaan. Dalam pengembangan sistem pembayaran, solusi baru seringkali terbatas, kata mereka, mengapa Anda membutuhkan buruh pelabuhan, mari kita pergi tanpanya. Dan secara umum. Bukan keamanan. Tolak.
Kami memutuskan untuk tidak melarang apa pun, melainkan untuk mendorong segala sesuatu yang baru. Jadi, dalam produksi kami, kami membangun layanan makro dari tumpukan besar aplikasi dalam wadah buruh pelabuhan, dikelola melalui SaltStack , cluster Riak, Konsul sebagai Penemuan Layanan, implementasi asli penelusuran jejak dalam sistem terdistribusi, dan banyak teknologi hebat lainnya.
Dan semua ini sangat aman sehingga Anda dapat mempublikasikan program Bugbounty di hackerone.com tanpa rasa malu.
Tentu saja, langkah pertama di sepanjang jalan ini dipenuhi dengan sejumlah rake yang benar-benar tidak senonoh. Saat kami membahasnya, kami akan memberi tahu Anda, juga memberi tahu, misalnya, mengapa kami tidak memiliki lingkungan pengujian, dan semua pemrosesan dapat digunakan pada laptop pengembang dengan make up sederhana.
Seperti banyak hal menarik.
Terima kasih telah memilih maskapai kami!
PS: Konten asli! Semua foto di pos adalah adegan dari kehidupan kantor kami.