Saya ingin menulis artikel mengenai topik seni bina perkhidmatan mikro untuk masa yang lama, tetapi dua perkara terus menghalang saya - semakin saya terjun ke topik itu, semakin saya nampak bahawa apa yang saya tahu jelas, dan apa yang saya lakukan ' t tahu perlu dikaji dan dikaji. Sebaliknya, saya berpendapat bahawa sudah ada sesuatu untuk dibincangkan di kalangan khalayak yang luas. Jadi pendapat alternatif adalah dialu-alukan.
Undang-undang Conway dan hubungan antara perniagaan, organisasi dan sistem maklumat
Sekali lagi saya izinkan diri saya untuk memetik:
"Mana-mana organisasi yang mereka bentuk sistem (dalam erti kata luas) akan menerima reka bentuk yang strukturnya mereplikasi struktur pasukan dalam organisasi itu."
- Melvyn Conway, 1967
Pada pendapat saya, undang-undang ini lebih cenderung berkaitan dengan kebolehlaksanaan menganjurkan perniagaan, dan bukannya terus kepada sistem maklumat. Biar saya jelaskan dengan contoh. Katakan kita mempunyai peluang perniagaan yang agak stabil dengan kitaran hayat yang panjang sehingga masuk akal untuk menganjurkan perusahaan (ini bukan kesilapan menaip, tetapi saya sangat menyukai istilah ini yang saya curi). Sememangnya, sistem sokongan perniagaan ini secara organisasi dan proses akan sepadan dengan perniagaan ini.
Orientasi perniagaan sistem maklumat
Biar saya jelaskan dengan contoh. Katakan ada peluang perniagaan untuk menganjurkan perniagaan menjual piza. Dalam versi V1 (sebut sebagai pra-maklumat), syarikat itu ialah restoran pizza, daftar tunai dan perkhidmatan penghantaran. Versi ini telah bertahan lama dalam keadaan kebolehubahan persekitaran yang rendah. Kemudian versi 2 datang untuk menggantikannya - lebih maju dan dapat menggunakan sistem maklumat pada terasnya untuk perniagaan dengan seni bina monolitik. Dan di sini, pada pendapat saya, terdapat ketidakadilan yang dahsyat berhubung dengan monolit - seni bina monolitik yang didakwa tidak sepadan dengan model perniagaan domain. Ya, jika demikian, sistem itu tidak akan dapat berfungsi sama sekali - bertentangan dengan undang-undang dan akal sehat Conway yang sama. Tidak, seni bina monolitik sepenuhnya konsisten dengan model perniagaan pada peringkat pembangunan perniagaan ini - Saya, sudah tentu, bermaksud peringkat apabila sistem telah dibuat dan digunakan. Ia adalah fakta yang sangat mengagumkan bahawa tanpa mengira pendekatan seni bina, kedua-dua seni bina berorientasikan perkhidmatan versi 3 dan versi seni bina mikroperkhidmatan N akan berfungsi dengan baik. Apa tangkapannya?
Semuanya mengalir, semuanya berubah, atau adakah perkhidmatan mikro adalah cara untuk memerangi kerumitan?
Sebelum kita meneruskan, mari kita lihat beberapa salah tanggapan tentang seni bina perkhidmatan mikro.
Penyokong menggunakan pendekatan perkhidmatan mikro sering berhujah bahawa memecahkan monolit kepada perkhidmatan mikro memudahkan pendekatan pembangunan dengan mengurangkan asas kod perkhidmatan individu. Pada pendapat saya, kenyataan ini adalah karut. Serius, interaksi yang jelas dalam kod monolit dan homogen nampaknya rumit? Jika ini benar-benar berlaku, semua projek pada mulanya akan dibina sebagai perkhidmatan mikro, manakala amalan menunjukkan bahawa penghijrahan daripada monolit kepada perkhidmatan mikro adalah lebih biasa. Kerumitan tidak hilang; ia hanya bergerak dari modul individu ke antara muka (sama ada bas data, RPC, API dan protokol lain) dan sistem orkestra. Dan ini sukar!
Kelebihan menggunakan timbunan heterogen juga dipersoalkan. Saya tidak akan berhujah bahawa ini juga mungkin, tetapi sebenarnya ia jarang berlaku (Melihat ke hadapan - ini sepatutnya berlaku - tetapi sebaliknya sebagai akibat daripada kelebihan).
Kitaran hayat produk dan kitaran hayat perkhidmatan
Lihat sekali lagi pada rajah di atas. Bukan kebetulan bahawa saya melihat penurunan kitaran hayat versi perniagaan yang berasingan - dalam keadaan moden, ia adalah pecutan peralihan perniagaan antara versi yang menentukan kejayaannya. Kejayaan sesuatu produk ditentukan oleh kepantasan menguji hipotesis perniagaan di dalamnya. Dan di sini, pada pendapat saya, terletak kelebihan utama seni bina perkhidmatan mikro. Tetapi mari kita pergi dalam urutan.
Mari kita beralih ke peringkat seterusnya dalam evolusi sistem maklumat - kepada seni bina berorientasikan perkhidmatan SOA. Jadi, pada satu ketika kami menyerlahkan dalam produk kami perkhidmatan yang berpanjangan - tahan lama dalam erti kata bahawa apabila beralih antara versi produk, terdapat kemungkinan kitaran hayat perkhidmatan akan lebih lama daripada kitaran hayat versi produk seterusnya. Adalah logik untuk tidak mengubahnya sama sekali - kita Apa yang penting ialah kelajuan peralihan ke versi seterusnya. Tetapi malangnya, kami terpaksa membuat perubahan berterusan pada perkhidmatan - dan di sini semuanya berfungsi untuk kami, amalan DevOps, kontena dan sebagainya - semua yang terlintas di fikiran. Tetapi ini masih bukan perkhidmatan mikro!
Perkhidmatan mikro sebagai cara untuk memerangi kerumitan... pengurusan konfigurasi
Dan di sini akhirnya kita boleh beralih kepada peranan menentukan perkhidmatan mikro - ini ialah pendekatan yang memudahkan pengurusan konfigurasi produk. Secara lebih terperinci, fungsi setiap perkhidmatan mikro menerangkan dengan tepat fungsi perniagaan di dalam produk mengikut model domain - dan ini adalah perkara yang tidak wujud dalam versi jangka pendek, tetapi dalam peluang perniagaan jangka panjang. Dan peralihan kepada versi produk seterusnya berlaku tanpa disedari - anda menukar/menambah satu perkhidmatan mikro, dan mungkin hanya skema interaksi mereka, dan tiba-tiba anda mendapati diri anda pada masa hadapan, meninggalkan pesaing yang menangis yang terus melompat antara versi monolit mereka. Sekarang bayangkan bahawa terdapat jumlah perkhidmatan mikro yang agak besar dengan antara muka dan keupayaan perniagaan yang telah ditetapkan. Dan anda datang dan membina struktur produk anda daripada perkhidmatan mikro sedia - hanya dengan melukis gambar rajah, sebagai contoh. Tahniah - anda mempunyai platform - dan kini anda boleh menarik perniagaan untuk diri sendiri. Mimpi Mimpi.
Penemuan
- Seni bina sistem harus ditentukan oleh kitaran hayat komponennya. Jika komponen hidup dalam versi produk, tiada gunanya meningkatkan kerumitan sistem dengan menggunakan pendekatan perkhidmatan mikro.
- Seni bina perkhidmatan mikro harus berdasarkan model domain - kerana peluang perniagaan ialah domain yang paling lama hidup
- Amalan penghantaran (amalan DevOps) dan orkestrasi adalah salah satu yang paling penting untuk seni bina perkhidmatan mikro - atas sebab peningkatan dalam kadar perubahan komponen menyebabkan peningkatan permintaan terhadap kelajuan dan kualiti penghantaran
Sumber: www.habr.com