Cerita penggergajian Monolith sering terlihat serupa. Tim memiliki monolit kikuk yang besar dan kuat, mereka memutuskan untuk memotongnya menjadi hamburan layanan microser biasa dan pintar, semuanya menjadi keren. Kisah-kisah hanya berbeda dalam tingkat horor "sebelum", sukacita "setelah" dan sejumlah karakteristik sekunder.
Di RBK.money, kami juga memiliki layanan microser. Tetapi kami datang kepada mereka sedikit berbeda dari kebanyakan. Semuanya lebih buruk bagi kami daripada monolit - pada awalnya, semuanya hanya buruk.
Di bawah kucing tentang bagaimana kita, pada kenyataannya, membangun microservices, mengapa OpenSource tidak hanya hebat pada prinsipnya, tetapi juga berfungsi sebagai komponen motivasi untuk menulis kode yang baik.
Jadi, semuanya buruk. Sedemikian rupa sehingga memperbaikinya tidak masuk akal, tetapi masuk akal untuk setuju untuk tidak pernah mengingat kengerian ini dan hanya menulis semuanya dari awal. Dan segera pada layanan microser. Pada tahap pertama pengembangan, kami segera membuat peraturan untuk selalu mengingat fakta bahwa suatu hari kami ingin kembali merasakan semua kebaikan atau bagian darinya. Lagipula, semuanya disimpan dalam sejarah komit, termasuk julukan pengembang, jadi kami hanya duduk dan segera mencoba menulis semuanya sedemikian rupa sehingga nantinya kami tidak akan malu dengan kode kami di depan komunitas. Lagi pula, tidak ada yang mau memerah untuk kode mereka atau arsitektur proyek, begitu-begitu sejarah.
Cepat vs bagus
Di dunia yang ideal, Anda selalu ingin menulis kode dengan cepat dan menulisnya dengan baik. Ya, seperti "Lebih baik menjadi kaya dan sehat daripada miskin dan sakit." Oleh karena itu, layanan microser menjadi cara terbaik untuk mengatasi situasi ini. Proses penulisan kode dibangun di atas tugas-tugas bisnis. Misalkan bisnis membutuhkan fungsionalitas yang akan memperhitungkan dana akun dalam akun rekanan ketika melakukan pembayaran. Fungsi ini berubah menjadi microservice, Accounter dengan nama kode, yang bergerak dalam alat akuntansi. Dengan layanan microser lainnya, cerita yang sama.
Hal utama di sini adalah untuk memastikan bahwa setiap fungsi bisnis dikonkretkan sehingga satu orang dapat menulisnya. Ini sangat tergantung pada tugas-tugas yang datang sendiri untuk bekerja, dan pada bagaimana direktur teknis atau proyek menerjemahkan ini ke tim. Kami berhasil melakukan ini, segera memberikan beberapa keuntungan signifikan yang baik.
Pertama, ini memberikan paralelisasi besar pembangunan. Pada awalnya, kami memiliki sekitar 10 orang, dan kami berhasil menulis sejumlah besar kode secara bersamaan (dan menulis dengan baik). Kedua, ini memberi Anda kesempatan untuk memutar penuh. Tapi ini sudah sedikit lebih penting daripada yang terlihat pada pandangan pertama.
Sangat sering, seseorang mulai buang air besar, bukan karena dia mendapatkan pekerjaan ini untuk Anda, tetapi karena matanya menjadi klise dan matanya menjadi kusam dan bosan. Jika satu orang terus-menerus duduk di microservice yang sama, ia dapat mulai menghasilkan govnokod. Dan ini bukan masalah profesionalisme, melainkan masalah waktu. Setelah 7-8 bulan, orang akan bosan mendukung layanan microser yang sama, mereka akan melihat-lihat - dan ada kehidupan, musim semi datang setelah musim dingin, kolega saya memiliki semacam gerakan, sekali lagi iPhone baru keluar, dan Anda semua duduk di microservice yang sama . Inilah mengapa monolith dilahirkan dengan satu titik kegagalan dalam bentuk orang yang lelah dengan tas di bawah matanya.
Atau, secara umum, seseorang mulai berpikir bahwa semuanya hanya pada dirinya dan bersandar pada dirinya. Dia akan mencoba membuat dirinya sangat diperlukan dengan mengelilingi karyanya dengan sekelompok "pengetahuan rahasia" dan prosedur aneh. Pada awal perjalanan saya, saya memiliki situasi di mana warisan itu sangat liar sehingga tidak mungkin untuk mengetahuinya tanpa sepengetahuan ini. Misalnya, Anda harus memulai satu layanan. Seperti yang biasanya Anda bayangkan ini:
- Mulai layanan.
Bagaimana itu:
- Pergi ke registri Windows.
- Temukan kunci tertentu di sana.
- Ubah ke 1.
- Mulai layanan.
- Atur ulang nilai kunci ke 0.
Ini adalah contoh klasik kompleksitas demi kompleksitas dan "Tidak ada yang berfungsi di sini tanpa saya." Faktanya, tanpa ini, semuanya bekerja. Hanya lebih cepat dan lebih baik. Anda dapat menghilangkan ini dengan rotasi - idealnya, ketika seseorang menulis satu layanan microser untuk sekitar beberapa sprint, dan kemudian pergi untuk melakukan tugas lain. Dengan cara yang sama, kami mendukung pertukaran pengetahuan yang konstan dalam sebuah tim.
Kode dari protokol
Jika Anda mengambil TK apa pun dari bisnis, menerjemahkannya dengan baik ke dalam manusia, buang kulitnya dan menguap - Anda mendapatkan protokol, bahasa yang akan berkomunikasi dengan mesin. Yaitu, kami mengambil tugas bisnis, memahami sendiri apa sebenarnya dan bagaimana kami akan melakukannya, dan mengubahnya menjadi spesifikasi untuk penghematan atau kesombongan (layanan mikro di dalam berkomunikasi melalui penghematan). Langkah pertama adalah menjelaskan semuanya secara terperinci: apa yang akan dilakukan oleh layanan mikro, jenis data apa yang akan diterimanya, apa yang akan dijawab, struktur apa yang akan, dan sebagainya. Protokol ini melewati tinjauan pertama dari mereka yang memiliki gagasan yang jelas tentang bagaimana semuanya bekerja (arsitek de facto). Ini bekerja seperti filter kasar di mana beberapa omong kosong tidak akan lulus bahkan pada tingkat konsep.
Segera setelah protokol muncul, Anda dapat duduk untuk menulis kode. Dan jika protokol sepenuhnya direvisi sendiri oleh orang-orang universal, maka kode itu sendiri ada dalam tim orang-orang tertentu. Kami menulis dalam tiga bahasa - JS, Java, Erlang. Hal utama adalah tidak membuat orang terburu-buru dengan ulasan atau menulis kode. Ya, bisnis selalu dan di mana saja harus cepat dan keren. Tetapi saya jarang menyibukkan mereka sebagai direktur teknis, karena saya mengerti apa yang ingin mereka lakukan dengan baik. Hasilnya adalah situasi yang saya sering didorong oleh pelanggan bisnis dari waktu ke waktu. Namun praktis tidak harus memerah untuk kualitas.
Kami hanya bergegas sekali, ketika jackpot itu ditumpangkan - pelanggan super dan tenggat waktu yang sangat mendesak, baru saja menciptakan Dompet kami. Kemudian ya, kami menurunkan lengan baju kami dan melakukan segalanya lebih cepat dari yang kami rencanakan (dan lebih buruk dari yang kami inginkan, ya). Idealnya, semuanya dianggap sebagai sekelompok layanan mikro yang rapi. Ternyata sepotong monolit seperti itu. Keuntungan dari situasi ini adalah kita sekali lagi menyadari untuk diri kita sendiri bahwa tidak perlu terburu-buru. Dan layanan itu sendiri perlahan-lahan ditarik ke dalam layanan microser terpisah, seperti yang mereka inginkan.
Ada 50 layanan mikro dalam RBK Money, semuanya ditulis oleh sekitar 20 orang. Hemat ada di mana-mana di dalam, untuk pengembang itu adalah protokol yang agak rumit, debasing sulit, dokumentasi juga sulit untuk ditulis. Dan jika saya membiarkan penghematan dalam bentuk yang paling murni, mereka akan memanggil saya kata-kata buruk. Oleh karena itu, kami tidak menemukan apa pun - JSON yang lain, sederhana dan intuitif, plus OpenAPI, sangat menonjol. Untuk dapat menerima permintaan ini dari luar, mereka harus divalidasi, diotorisasi, dan kemudian diluncurkan ke platform oleh layanan Microsoft lainnya. Dan kami juga menulis semua ini sebagai microservice independen, yang:
- menerima barang curian dari luar;
- memvalidasi skema;
- mengizinkan pengguna;
- mengubah semua ini menjadi permintaan penghematan;
- Yah, dia menulis log, tentu saja.
Apakah nyaman untuk menulis sistem pembayaran pada layanan microser? Tentu saja - di sini Anda memiliki paralelisasi pekerjaan, dan mempertahankan minat karyawan, dan tidak adanya titik kegagalan tunggal. Satu microservice mogok atau tiba-tiba orang yang melakukannya kemarin pergi - tidak masalah, Anda dapat dengan cepat memperbaiki sesuatu, dan menempatkan orang baru di kursi pilot selama sprint baru.
Tetapi ada pendapat bahwa jika seseorang duduk dan dengan hati-hati memotong layanan microser tertentu untuk waktu yang lama, maka dia pasti melakukannya dengan baik. Karena kami mulai membicarakan hal ini, silakan tulis di komentar pendekatan mana yang lebih dekat dengan Anda. Dan yang paling penting - mengapa.