Apa yang sebenarnya berbeda antara SOA dan Microservices

Penolakan

Saya harap saya tidak menginjak kaki siapa pun atau menyinggung penggemar salah satu konsep

Latar Belakang

Saya telah mencari perbedaan nyata antara Arsitektur Berorientasi Layanan dan Layanan Mikro, tanpa menemukan jawaban yang jelas.

Saya membaca hal-hal seperti:

• efek samping SOA
• SOA menjadi anti-pola
• Layanan Microsoft datang untuk memperbaiki kegagalan SOA
• ESB bukan benar-benar ESB melainkan EAI
• Ketergantungan berlebihan pada Pialang Pesan
• Vendor menyalahgunakan gagasan SOA dan mencoba menjual produk mereka
• SOA tumbuh tak terkendali

Tapi tetap saja, tidak ada yang jelas mendefinisikan perbedaan arsitektur antara Service Oriented Architecture (sebagai konsep) dan Layanan Mikro (sebagai konsep)

Menurut apa yang saya pahami, mereka berdua memiliki:

• Penyedia Layanan, hanya melakukan satu hal
• Service Gateway / ESB memaparkan layanan tersebut kepada konsumen
• Service Consumers, mengakses layanan melalui ESB / Service Gateway

Pertanyaan

Jadi, apakah ada yang berbeda selain mengubah SOA menjadi Microservices? apakah itu kendala teknologi yang ditempatkan untuk membatasi Microservices dari menjadi makro?

Catatan: Saya tidak mencari pendapat, hanya fakta sulit, semoga dalam poin-poin singkat

Referensi

• Pertanyaan Rekayasa Perangkat Lunak
• Situs Martin Fowler (saya pikir dia sangat membencinya)
• Dunia info
• Situs web Michael Fethers
• Pertanyaan Stack Overflow

Memperbarui

Tampaknya debat serupa terjadi dalam pertanyaan Stack overflow , dengan pendapat yang terbelah apakah atau tidak Layanan Mikro Berorientasi Arsitektur dalam Penyamaran.

Kesimpulan dari pertanyaan SO:

• MS adalah kasus khusus SOA
• MS mendukung ukuran yang lebih kecil dari aplikasi layanan hosting
• MS tergantung pada teknologi (penggunaan HTTP daripada opsi protokol terbuka)
• MS mengandalkan teknologi untuk menegakkan disiplin (penyebaran layanan otomatis)
• MS Mempertimbangkan ESB (jahat), tetapi menggunakan Gateway Gateway yang IMHO adalah jenis ESB

Itu menyimpulkan bahwa MS adalah SOA, jika yang berikut ini benar:

• Apakah MS mendukung gagasan Orkestrasi? Satu atau lebih proses master mengelola alur kerja
• Apakah ada lapisan broker pesan di MS? Seperangkat adaptor yang menerjemahkan format pesan dari ruang pesan produsen layanan ke konsumen layanan
• Dapatkah layanan mikro membaca data dari aplikasi perusahaan monolitik? Apakah bisa berupa API aplikasi monolitik? atau harus mandiri aplikasi mandiri, mampu beroperasi secara mandiri?

Jika jawaban untuk pertanyaan terakhir ternyata tidak, maka Microservices tidak akan mampu menangani sistem alur kerja yang kompleks, misalnya Sistem Manajemen Kartu Kredit, atau sistem rekonsiliasi

Penyedia Layanan, hanya melakukan satu hal

Perbedaan utama, yang memiliki konsekuensi luas dari proyek, adalah bahwa dengan Microservices, Penyedia Layanan ini dapat digunakan secara terpisah dan dapat diskalakan .

Ini hebat, karena Anda bisa lebih gesit. Jika suatu layanan perlu diubah, Anda hanya perlu mengubah yang itu, tidak ada satu pun kerabatnya. Jika Anda ingin mencoba kerangka kerja atau bahasa baru, cukup lakukan penggantian drop-in untuk layanan yang satu itu. Jika Anda tiba-tiba membutuhkan kapasitas 100x, putar beberapa mesin baru dengan layanan itu untuk menangani masuknya itu. Jika Anda ingin versi sesuatu, cukup versi itu tanpa menyentuh seluruh aplikasi. Dan itu membuat segalanya lebih mudah untuk memantau, instrumen, membagi di antara tim, usang ...

Tetapi ia datang dengan beberapa implikasi berat:

• Proses rilis Anda perlu diubah, karena menggunakan beberapa layanan sangat berbeda dengan menggunakan beberapa lusin layanan.
• Proses rilis Anda perlu diubah, karena menyebarkan layanan ke satu mesin sangat berbeda dari penempatan ke beberapa lusin mesin.
• Desain, penggunaan, dan penyebaran basis data Anda perlu diubah karena sepertinya tidak ada artinya untuk menggunakan layanan jika perlu menggunakan DB besar yang dibagikan ini untuk bekerja (melanggar semua layanan Anda yang lain).
• Desain dan penggunaan perpustakaan Anda perlu diubah karena agak tidak berarti untuk menggunakan layanan jika perlu memperbarui perpustakaan bersama ini (melanggar semua layanan Anda yang lain).
• Logging Anda / otorisasi / sesi manajemen / etc kebutuhan untuk perubahan karena cukup mudah untuk hal-hal pangsa ketika Anda hanya satu layanan, tetapi berbeda ketika Anda memiliki banyak layanan kecil independen yang membentuk produk - dan mereka akan ke ingin berbagi barang. Oh, dan semua hal yang dibagikan perlu ditangani dengan kemungkinan berada pada versi yang berbeda.
• Komunikasi Anda perlu diubah. Dengan sedikit layanan, Anda dapat merusak hal-hal di mana komunikasi tidak sering terjadi dan / atau bisa terjadi dengan lambat. Dengan layanan microser, mereka akan banyak berbicara satu sama lain, dan latensi tinggi tidak akan memotongnya.

Berikut adalah garis bawah. Satu perbedaan yang jelas antara SOA dan Microservices adalah gagasan tentang

Smart Endpoints Dumb Pipes

Tidak seperti SOA , yang akan bergantung pada konsumen dan produsen layanan yang tidak menyadari, mendelegasikan manajemen lalu lintas, terjemahan format pesan dan orkestrasi layanan ke sistem eksternal, misalnya ESB, orkestra layanan, broker pesan.