The Book Building Microservices menjelaskan secara rinci gaya yang disebutkan oleh @RogerAlsing dalam jawabannya.
Pada halaman 43 di bawah Orkestrasi vs Koreografi buku ini mengatakan:
Ketika kita mulai memodelkan logika yang semakin kompleks, kita harus berurusan dengan masalah mengelola proses bisnis yang melintasi batas layanan individual. Dan dengan layanan microser, kami akan mencapai batas ini lebih cepat dari biasanya. [...] Ketika benar-benar mengimplementasikan aliran ini, ada dua gaya arsitektur yang bisa kita ikuti. Dengan orkestrasi, kami mengandalkan otak pusat untuk memandu dan mengarahkan proses, seperti konduktor dalam orkestra. Dengan koreografi, kami menginformasikan setiap bagian dari sistem pekerjaannya dan membiarkannya menyelesaikan perinciannya, seperti penari semuanya menemukan jalan mereka dan bereaksi terhadap orang lain di sekitar mereka dalam balet.
Buku ini kemudian menjelaskan dua gaya tersebut. Gaya orkestrasi lebih sesuai dengan ide SOA orkestrasi / layanan tugas , sedangkan gaya koreografi sesuai dengan pipa bodoh dan titik akhir cerdas yang disebutkan dalam artikel Martin Fowler.
Gaya orkestrasi
Di bawah gaya ini, buku di atas menyebutkan:
Mari kita pikirkan seperti apa solusi orkestrasi untuk aliran ini. Di sini, mungkin hal paling sederhana untuk dilakukan adalah menjadikan layanan pelanggan kami bertindak sebagai otak pusat. Pada pembuatan, ia berbicara ke bank poin loyalitas, layanan email, dan layanan pos [...], melalui serangkaian panggilan permintaan / respons. Layanan pelanggan itu sendiri kemudian dapat melacak di mana pelanggan berada dalam proses ini. Itu dapat memeriksa untuk melihat apakah akun pelanggan telah diatur, atau email yang dikirim, atau posting yang dikirim. Kita dapat mengambil diagram alur [...] dan memodelkannya langsung ke dalam kode. Kita bahkan bisa menggunakan tooling yang mengimplementasikan ini untuk kita, mungkin menggunakan mesin aturan yang sesuai. Alat komersial ada untuk tujuan ini dalam bentuk perangkat lunak pemodelan proses bisnis. Dengan asumsi kami menggunakan permintaan / respons sinkron, kita bahkan bisa tahu apakah setiap tahap telah berhasil [...] Kelemahan dari pendekatan orkestrasi ini adalah bahwa layanan pelanggan dapat menjadi terlalu banyak dari otoritas pemerintahan pusat. Itu bisa menjadi hub di tengah-tengah web dan titik pusat di mana logika mulai hidup. Saya telah melihat pendekatan ini menghasilkan sejumlah kecil layanan "tuhan" yang cerdas yang memberi tahu layanan berbasis CREM apa yang harus dilakukan.
Catatan: Saya kira bahwa ketika penulis menyebutkan tooling dia merujuk pada sesuatu seperti BPM (misalnya Activity , Apache ODE , Camunda ). Faktanya, Situs Web Workflow Patterns memiliki serangkaian pola yang luar biasa untuk melakukan orkestrasi semacam ini dan juga menawarkan detail evaluasi dari berbagai alat vendor yang membantu untuk mengimplementasikannya dengan cara ini. Saya tidak berpikir penulis menyiratkan bahwa diperlukan untuk menggunakan salah satu alat ini untuk menerapkan gaya integrasi ini, kerangka kerja orkestrasi ringan lainnya dapat digunakan misalnya Spring Integration , Apache Camel atau Mule ESB
Namun, buku-buku lain yang saya baca tentang topik Microservices dan secara umum mayoritas artikel yang saya temukan di web tampaknya tidak menyukai pendekatan orkestrasi ini dan malah menyarankan menggunakan yang berikutnya.
Gaya koreografi
Di bawah gaya koreografi penulis mengatakan:
Dengan pendekatan koreografi, kami hanya bisa meminta layanan pelanggan memancarkan suatu peristiwa dengan cara yang tidak sinkron, dengan mengatakan bahwa Pelanggan dibuat. Layanan email, layanan pos, dan bank poin loyalitas kemudian hanya berlangganan acara ini dan bereaksi sesuai [...] Pendekatan ini secara signifikan lebih dipisahkan. Jika beberapa layanan lain diperlukan untuk mencapai penciptaan pelanggan, itu hanya perlu berlangganan ke acara dan melakukan tugasnya saat diperlukan. Kelemahannya adalah bahwa tampilan eksplisit dari proses bisnis yang kita lihat di [alur kerja] sekarang hanya secara implisit tercermin dalam sistem kami [...] Ini berarti pekerjaan tambahan diperlukan untuk memastikan bahwa Anda dapat memantau dan melacak bahwa hal-hal yang benar telah terjadi. Sebagai contoh, apakah Anda tahu jika bank loyalitas poin memiliki bug dan karena alasan tertentu tidak membuat akun yang benar? Salah satu pendekatan yang saya suka untuk berurusan dengan ini adalah membangun sistem pemantauan yang secara eksplisit cocok dengan pandangan proses bisnis di [alur kerja], tetapi kemudian melacak apa yang dilakukan masing-masing layanan sebagai entitas independen, membiarkan Anda melihat pengecualian aneh dipetakan ke alur proses yang lebih eksplisit. [Flowchart] [...] bukan kekuatan pendorong, tetapi hanya satu lensa yang melaluinya kita dapat melihat bagaimana sistem berperilaku. Secara umum, saya telah menemukan bahwa sistem yang cenderung lebih ke arah pendekatan koreografi lebih longgar, dan lebih fleksibel dan menerima perubahan. Namun, Anda perlu melakukan pekerjaan ekstra untuk memantau dan melacak proses melintasi batas sistem. Saya telah menemukan implementasi yang sangat diatur sangat rapuh, dengan biaya perubahan yang lebih tinggi. Dengan pemikiran itu, saya sangat memilih membidik sistem koreografi, di mana setiap layanan cukup pintar untuk memahami perannya dalam seluruh tarian.
Catatan: Sampai hari ini saya masih tidak yakin apakah koreografi hanyalah nama lain untuk arsitektur berbasis kejadian (EDA), tetapi jika EDA hanya satu cara untuk melakukannya, apa cara lain? (Juga lihat Apa yang Anda maksud dengan "Event-Driven"? Dan Arti Arsitektur Event-Driven ). Juga, sepertinya hal-hal seperti CQRS dan EventSourcing sangat cocok dengan gaya arsitektur ini, bukan?
Sekarang, setelah ini datang kesenangan. Buku Microservices tidak menganggap layanan microser akan diimplementasikan dengan REST. Sebagai soal fakta di bagian selanjutnya dalam buku ini, mereka melanjutkan untuk mempertimbangkan RPC dan solusi berbasis SOA dan akhirnya REST. Poin penting di sini adalah bahwa Microservices tidak menyiratkan REST.
Jadi, Bagaimana dengan HATEOAS? (Hypermedia sebagai Engine of Application State)
Sekarang, jika kita ingin mengikuti pendekatan RESTful kita tidak bisa mengabaikan HATEOAS atau Roy Fielding akan sangat senang mengatakan di blog-nya bahwa solusi kita tidak benar-benar REST. Lihat posting blognya di REST API Must Hypertext Driven :
Saya merasa frustrasi dengan jumlah orang yang menyebut antarmuka berbasis HTTP sebagai REST API. Apa yang perlu dilakukan untuk memperjelas gaya arsitektur REST dengan anggapan bahwa hypertext merupakan kendala? Dengan kata lain, jika mesin negara aplikasi (dan karenanya API) tidak didorong oleh hypertext, maka itu tidak bisa tenang dan tidak bisa menjadi API tenang. Titik. Apakah ada beberapa manual yang rusak di suatu tempat yang perlu diperbaiki?
Jadi, seperti yang Anda lihat, Fielding berpikir bahwa tanpa HATEOAS Anda tidak benar-benar membangun aplikasi yang tenang. Untuk Fielding, HATEOAS adalah cara untuk pergi ketika datang ke mengatur layanan. Saya hanya mempelajari semua ini, tetapi bagi saya, HATEOAS tidak secara jelas mendefinisikan siapa atau apa yang menjadi kekuatan penggerak di belakang mengikuti tautan tersebut. Di UI yang bisa menjadi pengguna, tetapi dalam interaksi komputer-ke-komputer, saya kira itu perlu dilakukan oleh layanan tingkat yang lebih tinggi.
Menurut HATEOAS, satu-satunya tautan yang benar-benar perlu diketahui oleh konsumen API adalah yang memulai komunikasi dengan server (mis. POST / pesanan). Mulai saat ini, REST akan melakukan aliran, karena, dalam respons titik akhir ini, sumber daya yang dikembalikan akan berisi tautan ke status yang mungkin berikutnya. Konsumen API kemudian memutuskan tautan apa yang akan diikuti dan memindahkan aplikasi ke status berikutnya.
Meskipun kedengarannya keren, klien masih perlu tahu apakah tautan harus diposkan, DIPERLUKU, DAPATKAN, DILAKUKAN, dll. Dan klien masih perlu memutuskan muatan apa yang harus dilewati. Klien masih perlu mengetahui apa yang harus dilakukan jika gagal (coba lagi, ganti rugi, batalkan, dll.).
Saya cukup baru dalam hal ini, tetapi bagi saya, dari perspektif HATEOA, klien ini, atau konsumen API adalah layanan pesanan tinggi. Jika kami memikirkannya dari sudut pandang manusia, Anda dapat membayangkan pengguna akhir di halaman web, memutuskan tautan apa yang harus diikuti, tetapi tetap, programmer halaman web tersebut harus memutuskan metode apa yang akan digunakan untuk mengaktifkan tautan, dan payload apa yang harus dilewati. Jadi, menurut saya, dalam interaksi komputer-ke-komputer, komputer mengambil peran pengguna akhir. Sekali lagi inilah yang kami sebut layanan orkestrasi.
Saya kira kita bisa menggunakan HATEOAS dengan orkestrasi atau koreografi.
Pola Gateway API
Pola lain yang menarik disarankan oleh Chris Richardson yang juga mengusulkan apa yang disebutnya Pola Gateway API .
Dalam arsitektur monolitik, klien aplikasi, seperti browser web dan aplikasi asli, membuat permintaan HTTP melalui load balancer ke salah satu contoh identik aplikasi. Namun dalam arsitektur microservice, monolith telah digantikan oleh koleksi layanan. Akibatnya, pertanyaan kunci yang perlu kita jawab adalah apa yang berinteraksi dengan klien?
Klien aplikasi, seperti aplikasi seluler asli, dapat membuat permintaan HTTP tenang untuk masing-masing layanan [...] Di permukaan ini mungkin tampak menarik. Namun, kemungkinan ada ketidaksesuaian yang signifikan dalam granularitas antara API layanan individual dan data yang dibutuhkan oleh klien. Misalnya, menampilkan satu halaman web berpotensi memerlukan panggilan ke sejumlah besar layanan. Amazon.com, misalnya,
menjelaskan bagaimana beberapa halaman memerlukan panggilan ke 100+ layanan. Membuat banyak permintaan, bahkan melalui koneksi internet berkecepatan tinggi, apalagi jaringan seluler dengan bandwidth rendah, latensi tinggi, akan sangat tidak efisien dan menghasilkan pengalaman pengguna yang buruk.
Pendekatan yang jauh lebih baik bagi klien untuk membuat sejumlah kecil permintaan per halaman, mungkin sesedikit satu, melalui Internet ke server front-end yang dikenal sebagai gateway API.
Gateway API berada di antara klien aplikasi dan layanan Microsoft. Ini menyediakan API yang dirancang khusus untuk klien. Gateway API menyediakan API berbutir kasar untuk klien seluler dan API berbutir halus untuk klien desktop yang menggunakan jaringan berkinerja tinggi. Dalam contoh ini, klien desktop membuat beberapa permintaan untuk mengambil informasi tentang suatu produk, sedangkan klien seluler membuat satu permintaan.
Gateway API menangani permintaan yang masuk dengan membuat permintaan ke sejumlah layanan microsec melalui LAN berkinerja tinggi. Netflix, misalnya,
menjelaskan
bagaimana setiap permintaan penggemar ke rata-rata enam layanan backend. Dalam contoh ini, permintaan berbutir halus dari klien desktop hanya diproksikan ke layanan yang sesuai, sedangkan setiap permintaan berbutir kasar dari klien seluler ditangani dengan menggabungkan hasil panggilan beberapa layanan.
API gateway tidak hanya mengoptimalkan komunikasi antara klien dan aplikasi, tetapi juga merangkum detail dari layanan microser. Ini memungkinkan layanan-layanan mikro untuk berevolusi tanpa berdampak pada klien. Sebagai contoh, dua layanan Microsoft mungkin digabungkan. Layanan microser lain mungkin dipartisi menjadi dua atau lebih layanan. Hanya gateway API yang perlu diperbarui untuk mencerminkan perubahan ini. Klien tidak terpengaruh.
Sekarang kita telah melihat bagaimana API gateway memediasi antara aplikasi dan kliennya, sekarang mari kita lihat bagaimana mengimplementasikan komunikasi antara layanan microser.
Ini terdengar sangat mirip dengan gaya orkestrasi yang disebutkan di atas, hanya dengan maksud yang sedikit berbeda, dalam hal ini, tampaknya semua tentang kinerja dan penyederhanaan interaksi.
.