Halo, Habr!
Kami mulai menerjemahkan buku
Pola-pola Pola Makan Chris Richardson
dengan contoh-contoh di Jawa . Sudah setengah tahun sebelum pemutaran perdana dalam bahasa Rusia, tetapi kami ingin menawarkan kepada Anda sejenis trailer - ulasan singkat tentang buku ini dari Ben Nadel, yang membaca versi MEAP. Ulasan ini secara aktif mengutip teks dari versi Kindle dari Richardson.
Selamat datang di kucing!
Saya belajar tentang Chris Richardson ketika saya mengenal sumber online
Microservices.io- nya. Di mana, jujur saja, ada sejumlah informasi yang mengejutkan - yang saya putuskan untuk ditunda nanti, karena pada saat itu saya tidak tahu bagaimana cara mendekatinya, terutama mengingat bahwa saya praktis tidak pernah berurusan dengan layanan mikro. Saya suka membaca lebih lanjut. Oleh karena itu, ketika saya mengetahui bahwa Chris menerbitkan buku penulis
Microservices Patterns: With Examples In Java , saya sangat terinspirasi. Sedemikian rupa sehingga dia tidak bisa menunggu keluarnya. Jadi saya memperoleh dan membaca "versi awal" Manning (MEAP). Minggu lalu, saya baru saja melakukan apa yang saya pelajari buku ini, dan saya pikir ini adalah studi yang menarik, pragmatis dan holistik dari pendekatan layanan-mikro untuk pengembangan.
Seluruh buku ini dibangun dalam bentuk kisah Mary - CTO (CTO) dari Food To Go, Inc (FTGO). Perusahaan berusaha mengembangkan bisnis dengan meluncurkan refactoring aplikasi monolitik lamanya dan mengubahnya menjadi arsitektur layanan mikro. Mary mengambil proyek ini, karena kecepatan pengembangan telah menurun, dan bos semakin kesal karena programmer di bawah kepemimpinan Mary tidak dapat menghasilkan fitur baru dalam bentuk yang cukup berkualitas tinggi.
Tentu saja, masalah utama Mary adalah apa yang disebut "neraka monolitik" dalam terminologi Richardson. Meskipun monolit adalah aplikasi yang besar dan terus berkembang, Richardson berfokus pada aspek migrasi FTGO yang agak halus, sehingga lebih mudah untuk mengekspos dan menyampaikan semua konsep. Pada saat yang sama, isi buku ini sangat mudah dicerna. Sebagian besar pertimbangan arsitektur biasanya terlalu disederhanakan atau terlalu rumit. Namun, Richardson berhasil menemukan jalan tengah dengan membangun model domain yang (hampir) pas di kepala, tetapi pada saat yang sama cukup kompleks untuk menggambarkan aliran tugas antar-layanan yang menarik di dalamnya.
Sejak awal, saya telah menantikan Richardson bersikap pragmatis dalam setiap detail. Tidak satu aspek pun dari buku ini disajikan sebagai "peluru perak" atau "satu-satunya solusi." Di mana-mana kita melihat pilihan yang diperhitungkan, satu set kompromi yang jelas. Sebagai contoh, penulis bahkan mengajukan gagasan layanan microser dalam nada ini: arsitektur layanan microser harus selalu dihindari, kecuali dalam kasus di mana itu benar-benar diperlukan:
Tantangan lain yang terkait dengan penggunaan arsitektur microservice adalah memutuskan pada titik apa dalam siklus hidup aplikasi untuk mulai menggunakan arsitektur ini. Saat mengembangkan versi pertama aplikasi, Anda sering masih tidak menemukan masalah yang dipecahkan arsitektur seperti itu. Selain itu, menggunakan arsitektur terdistribusi yang seimbang hanya akan memperlambat pengembangan. Dilema semacam itu dapat muncul pada startup, di mana tantangan paling penting biasanya terletak pada perkembangan cepat model bisnis dan aplikasi sendiri. Saat menggunakan arsitektur layanan mikro, jauh lebih sulit untuk mengatur iterasi cepat. Pengembangan startup pasti harus dimulai dengan aplikasi monolitik. (Versi Kindle, alamat 416)
Richardson juga mempertimbangkan layanan mikro dalam perspektif holistik, membahas dinamika tim sebagai lingkaran masalah yang sepenuhnya independen yang dibangun pada bagian teknologi. Tentu saja, ia mempertimbangkan topik-topik seperti
Hukum Conway dan “Manuver Kebalikan
Conway ”, tetapi pada saat yang sama, ia juga menyentuh fakta bahwa para programmer adalah karakter-karakter pathos emosional yang dengannya Anda harus “menjual” ide layanan-mikro:
Pindah ke paradigma layanan-mikro, Anda dipaksa untuk mengubah arsitektur, organisasi, dan proses pengembangan Anda. Namun, pada akhirnya, lingkungan kerja berubah, kondisi di mana orang bekerja, dan orang-orang, sebagaimana telah disebutkan, adalah emosional. Jika emosi manusia diabaikan, maka pengenalan layanan mikro dalam suatu organisasi dapat berubah menjadi rute yang curam. (Versi Kindle, alamat 718)
Strategi yang dijelaskan oleh penulis menyangkut seluruh bisnis, memengaruhi manajer dan eksekutif yang mungkin tidak berani memulai refactoring besar, mengambil sumber daya berharga darinya, orang-orang yang secara aktif dapat mengembangkan fitur baru:
Manfaat signifikan dari refactoring selangkah demi selangkah menuju arsitektur layanan mikro adalah bahwa strategi semacam itu segera mulai membuahkan hasil. Ini bukan situasi sama sekali ketika "merombak" kode yang tidak membawa manfaat apa pun sampai sepenuhnya selesai ...
Kelebihan lain dari situasi di mana nilai dari transisi diperoleh pada tahap awal adalah bahwa kita dapat menarik dukungan bisnis untuk memastikan migrasi. Dukungan berkelanjutan seperti itu sangat penting, karena semakin aktif refactoring, semakin sedikit waktu yang dapat Anda habiskan untuk mengembangkan fitur. Di beberapa organisasi, sulit untuk menghilangkan utang teknis, karena upaya sebelumnya bisa menjadi terlalu ambisius dan tidak membawa manfaat yang diinginkan. Akibatnya, bisnis tersebut enggan untuk terus berinvestasi dalam "pembersihan". Sifat langkah-demi-langkah dari refactoring dalam kasus layanan-mikro berarti bahwa suatu tim dapat menunjukkan hasil yang sangat sering. (Alamat versi Kindle 10769)
Dari sudut pandang teknologi, dalam buku “Microservices. Pengembangan dan pola refactoring ”memeriksa berbagai topik: mulai dari arsitektur heksagonal, pengujian dan integrasi berkelanjutan hingga pola pesan dan penciptaan sistem yang dapat diamati. Cakupan seperti itu menyiratkan bahwa beberapa topik dalam buku ini dicakup secara lebih rinci daripada yang lain. Namun, sekali lagi, Richardson berhasil dengan sempurna menyeimbangkan semuanya dan memberikan begitu banyak detail sehingga orang dapat membahas topik tersebut dengan wajar tanpa mengecilkan hati pembaca.
Bahkan, isi buku ini disusun sedemikian rupa sehingga Anda sendiri dapat memilih topik mana yang akan dibahas. Dalam setiap bab, sebelum pencelupan terperinci dalam topik, daftar TL; DR diberikan, yang secara singkat mencantumkan semua pro dan kontra. Dengan demikian, Anda berhasil menangkap poin paling penting dari bab ini tanpa membaca setiap kata.
Jujur, saya baru saja membolak-balik dua bab tentang pengujian layanan microser dan satu bab tentang penggunaan layanan microser. Saya yakin bahwa penulis mengerjakan topik-topik ini dengan sempurna, tetapi bagi saya tampaknya ada lebih banyak informasi daripada yang bisa saya cerna. Penempatan bukan tugas sehari-hari yang mendesak bagi saya. Dia menulis beberapa ujian dalam hidupnya.
Jadi, saya ingin meninggalkan ruang yang cukup dalam kesadaran gua saya yang tidak jelas untuk meletakkan materi di sana dari semua bab lain: pada desain berorientasi subjek (DDD), komunikasi antar proses dan sinkronisasi data.
Salah satu bagian yang sangat mengesankan saya menceritakan tentang layanan mana yang harus menangani permintaan dari satu jenis khusus, yaitu: menemukan restoran yang cocok di dekat lokasi pengguna saat ini:
Namun, bisa jadi sulit untuk mengimplementasikan bahkan permintaan tersebut yang bersifat lokal dalam hal layanan tertentu. Ini dimungkinkan karena beberapa alasan. Pertama, karena (seperti dijelaskan di bawah), kadang-kadang tidak masuk akal untuk mengimplementasikan permintaan dalam layanan yang memiliki data. Alasan lain adalah bahwa kadang-kadang database layanan (atau model data) tidak dapat secara efisien mendukung permintaan (versi Kindle, alamat 5659)
... Jika dalam aplikasi FTGO, informasi tentang restoran disimpan dalam basis data [beberapa lainnya], maka penerapan kueri findAvailableRestaurant() jauh lebih rumit. Replika data restoran harus disimpan dalam bentuk yang mendukung pertanyaan geospasial. Misalnya, aplikasi dapat menggunakan Perpustakaan Pengindeksan Geospasial untuk DynamoDB, di mana tabel digunakan sebagai indeks geospasial. Alternatif: aplikasi dapat menyimpan replika data restoran dalam jenis database yang sama sekali berbeda. Situasi serupa terjadi ketika kami menggunakan kueri teks dengan database untuk pencarian teks. (Versi Kindle, alamat 5675)
... Dalam hal ini, disarankan (setidaknya pada pandangan pertama) bahwa operasi permintaan dilaksanakan oleh layanan yang memiliki data. Namun, selain kepemilikan data, faktor-faktor lain harus dipertimbangkan.
Anda juga perlu mempertimbangkan kebutuhan pemisahan tugas dan menghindari layanan yang berlebihan dengan fitur yang terlalu banyak. Misalnya, tanggung jawab utama tim yang mengembangkan layanan Restoran adalah membantu manajer restoran melayani pekerjaan perusahaan. Tugas ini sama sekali bukan rencana implementasi dari permintaan kritis untuk bekerja dengan sejumlah besar data. Selain itu, jika tim pengembangan bertanggung jawab atas operasi findAvailableRestaurants() , maka akan selalu takut untuk memperkenalkan perubahan yang dapat mencegah konsumen melakukan pemesanan. (Versi Kindle, alamat 5675)
Di sini, otak saya meledak sedikit karena saya pertama kali melihat layanan yang fungsinya hanya mengoptimalkan data layanan lain untuk melakukan tugas tertentu. Namun, seperti yang ditunjukkan Richardson, ini hanyalah abstraksi yang lebih umum dari ide yang mendasari pencarian teks lengkap, misalnya, di Apache Lucene (alat ini menyediakan pengindeksan teks lengkap di atas gudang data lain).
Saya curiga - atau lebih tepatnya, saya ingin berharap - bahwa, setelah melihat pembagian tanggung jawab seperti itu, pembaca akan mulai menarik garis baru di antara layanan. Dia tidak hanya akan berpikir tentang "kepemilikan data", tetapi juga akan mulai memperhitungkan "peluang bisnis" - yaitu, faktor nilai riil sehingga basis data tidak hanya menjadi tempat penyimpanan negara.
Aspek lain yang disorot dalam diskusi ini adalah pentingnya sinkronisasi dan replikasi data, serta pesan tidak sinkron dalam arsitektur layanan mikro. Topik ini berjalan melalui seluruh buku Richardson dengan utas merah, tidak peduli apa yang mereka bicarakan: penciptaan layanan mikro dari awal atau refactoring bertahap dari monolit menjadi layanan mikro (bab terpisah dikhususkan untuk topik ini). Dia menjelaskan bahwa sinkronisasi adalah kekuatan tulang punggung yang benar-benar memungkinkan banyak hal untuk direalisasikan.
Saya bisa menyebutkan banyak hal menarik. Apa yang layak, misalnya, fakta bahwa Richardson berbicara tentang otentikasi dan otorisasi dalam sistem terdistribusi dengan baik? Saya pikir topik ini belum sepenuhnya dieksplorasi, untuk membuatnya lebih sederhana. Penulis menjelaskan desain berorientasi subjek dengan cara yang paling mudah diakses. Dia juga menunjukkan bahwa bahkan kelas yang sangat sederhana pun dapat memiliki perilaku.
Selama lebih dari satu tahun sekarang, saya telah mencoba memahami dengan baik arsitektur sistem terdistribusi dan pola layanan-mikro (yang khususnya sulit, karena pekerjaan sehari-hari saya terhubung dengan pelayanan monolit). Banyak teks yang saya baca tentang topik-topik ini terlalu dangkal atau terlalu sempit dan pada saat yang sama mendalam. Buku "Layanan Mikro. Pengembangan dan pola refactoring ”memang merupakan jalan tengah di antara kedua ekstrem ini.
Saya sangat merekomendasikan buku ini kepada semua orang (berani kami) yang mencoba (termasuk, sejauh ini tidak berhasil) untuk beralih dari arsitektur monolitik ke sistem terdistribusi.