Mikroperkhidmatan ialah satu cara untuk memecahkan aplikasi besar kepada modul gandingan longgar yang berkomunikasi antara satu sama lain melalui API mudah.
Kebelakangan ini, hanya orang bisu yang tidak bercakap tentang perkhidmatan mikro. Ini menjadi semakin popular. Gaya seni bina modular nampaknya sangat sesuai untuk persekitaran berasaskan awan dan semakin popular. Sebelum kita masuk ke butirannya, mari kita lihat dari pandangan mata segala-galanya . Oleh itu: Perkhidmatan mikro ialah satu cara untuk memecahkan projek besar kepada modul yang kecil, bebas dan berganding longgar. Modul bebas bertanggungjawab untuk tugasan yang ditakrifkan dengan jelas dan diskret serta berkomunikasi antara satu sama lain melalui API yang mudah dan boleh diakses. Dalam erti kata lain, perkhidmatan mikro hanyalah gaya seni bina yang berbeza untuk mereka bentuk kompleks, kebanyakannya aplikasi web. Tetapi apa yang buruk tentang penyelesaian seni bina sedia ada seperti SOA (Seni bina berorientasikan perkhidmatan)? Kebanyakan penyelesaian perusahaan moden yang ditulis menggunakan SOA nampaknya berfungsi dengan baik. Ini mungkin masa yang sesuai untuk bercakap tentang beberapa cabaran yang dihadapi oleh industri hari ini... Mari kita mulakan dengan contoh mudah. Katakan saya perlu menjalankan aplikasi klasik yang ditulis dalam Java. Mula-mula saya akan membangunkan Antara Muka Pengguna, kemudian lapisan logik perniagaan, dengan beberapa komponen yang akan berinteraksi dengan UI, dan akhirnya lapisan pangkalan data, yang boleh diakses oleh pangkalan data berterusan. Sekarang menurut fakta bahawa saya ingin menjalankan aplikasi, saya akan mencipta WAR/EAR/JAR dan memasangnya pada pelayan (seperti JBoss, Tomcat atau WebLogic). Oleh kerana ini dilakukan semua dalam satu, saya mendapat aplikasi monolitik, yang bermaksud bahawa semua komponen berada di satu tempat... Contoh dalam gambar:
Kemungkinan besar, anda sudah biasa dengan pendekatan ini dan telah menggunakannya, tetapi ideanya adalah untuk menggunakan contoh ini untuk menunjukkan cabaran yang perlu dihadapi oleh pembangun menggunakan penyelesaian seni bina ini. Aplikasi monolitik: mencabar cabaran
Apabila aplikasi berkembang, begitu juga jumlah kod yang ditulis, yang mungkin membebankan persekitaran pembangunan setiap kali anda perlu membukanya. Ini pasti mengurangkan kecekapan pemaju.
Oleh kerana segala-galanya perlu dipasang di satu tempat, ini membawa kepada fakta bahawa beralih kepada bahasa pengaturcaraan lain atau beralih kepada teknologi lain adalah masalah besar. Sebagai contoh, anda menulis aplikasi dalam Java, dan selepas beberapa ketika Kotlin keluar dan anda tidak sabar-sabar untuk menulis semula padanya, kerana ia dinaikkan pangkat sebagai lebih sejuk, lebih baik, lebih pantas. Dengan aplikasi monolitik, walaupun memikirkan tentang pemfaktoran semula akan menyebabkan kesakitan sebenar, apatah lagi proses itu sendiri. Pada masa ini terdapat banyak aplikasi yang dibuat dengan cara ini dan bilangan baris kod adalah luar biasa.
Jika mana-mana komponen berhenti berfungsi atas sebarang sebab , keseluruhan aplikasi juga akan ranap. Cuba bayangkan bahawa terdapat aplikasi web yang mempunyai modul seperti kebenaran, pembayaran, sejarah, dll. Dan atas sebab tertentu salah seorang daripada mereka pecah. Ini hanyalah satu kejutan untuk perniagaan dan, akibatnya, untuk pembangun.
Penskalaan aplikasi monolitik hanya boleh dicapai dengan menaikkan aplikasi lain daripada jenis yang sama. Tetapi bagaimana jika anda hanya perlu skala satu komponen, dan bukan keseluruhan aplikasi. Berapa banyak sumber yang akan dibazirkan?...
Ini boleh memberi kesan besar kepada proses pembangunan dan proses pemasangan aplikasi. Lebih besar aplikasi, lebih penting ialah pembangun boleh membahagikan aplikasi kepada bahagian kerja yang lebih kecil. Oleh kerana semua modul dalam aplikasi monolitik disambungkan antara satu sama lain, pembangun tidak boleh bekerja/melekapkan modul ini secara berasingan antara satu sama lain. Memandangkan pembangun bergantung antara satu sama lain, masa pembangunan meningkat.
Pada masa yang sama, kami bersedia untuk mempertimbangkan dan memahami maksud perkhidmatan mikro, iaitu bagaimana ia boleh digunakan untuk memulihkan fleksibiliti yang hilang dengan gaya SOA. God Microservices to the rescue Salah satu ciri terpenting dalam mana-mana penyelesaian seni bina ialah kebolehskalaan. Semasa saya mempelajari perkhidmatan mikro buat kali pertama, saya melihat bahawa segala-galanya sangat serupa dengan petikan dari buku "The Art of Scalability". Ini adalah permulaan dan tempat yang bagus untuk perbincangan. Buku ini mentakrifkan apa yang dipanggil model "Scalability Cube", yang menerangkan sistem kebolehskalaan tiga dimensi:
Seperti yang anda lihat, paksi X menerangkan "penskalaan mendatar" (yang telah kami lihat juga tersedia untuk seni bina monolitik), paksi Y mewakili penskalaan dalam erti kata memisahkan komponen perkhidmatan yang berbeza . Idea paksi Z difahami apabila data dibahagikan dan aplikasi menghantar permintaan ke tempat data itu berada. Iaitu, mereka tidak semua berada di satu tempat. Idea paksi Y adalah yang akan kita fokuskan dengan lebih terperinci. Paksi ini mewakili penguraian berfungsi . Dalam strategi ini, fungsi yang berbeza boleh dianggap sebagai perkhidmatan bebas. Oleh itu, dengan memasang keseluruhan aplikasi hanya apabila segala-galanya selesai, pembangun boleh memasang perkhidmatan individu secara bebas antara satu sama lain dan tidak menunggu orang lain selesai mengerjakan modul mereka. Ini bukan sahaja akan meningkatkan masa pembangunan, tetapi juga menawarkan fleksibiliti untuk menukar dan pendawaian semula tanpa perlu risau tentang komponen aplikasi yang lain. Mari bandingkan rajah ini dengan rajah monolitik sebelumnya:
Perkhidmatan Mikro: Faedah Manfaat perkhidmatan mikro nampaknya cukup memadai untuk meyakinkan pembangun perusahaan seperti Amazon, Netflix, Ebay untuk mula menggunakan pendekatan ini. Tidak seperti aplikasi seni bina monolitik, perkhidmatan mikro:
Meningkatkan pengasingan kegagalan komponen: Aplikasi besar boleh terus berjalan dengan cekap walaupun satu modul gagal.
Menghapuskan komitmen aplikasi kepada satu tindanan teknologi: jika anda ingin mencuba tindanan teknologi baharu pada sesetengah perkhidmatan, teruskan. Kebergantungan akan menjadi lebih ringan berbanding dengan kebergantungan monolitik, dan ia juga akan menjadi lebih mudah untuk melancarkan segala-galanya. Semakin sedikit kod dalam satu aplikasi, semakin mudah ia berfungsi.
Memudahkan pekerja baharu memahami fungsi perkhidmatan.
Microservices: ciri pemasangan dan virtualisasi Kini kami memahami apa itu perkhidmatan mikro. Dan kelebihan terbesar ialah ia dipasang oleh lebih daripada satu arkib WAR/EAR/JAR. Tetapi bagaimana ia dipasang? Cara terbaik untuk memasang perkhidmatan mikro di dalam bekas. Bekas ialah sistem pengendalian maya yang dikonfigurasikan sepenuhnya dengan persekitaran yang diperlukan dikonfigurasikan, yang membantu mengasingkan akses kepada sumber sistem perkakasan di mana bekas itu dipasang. Penyelesaian yang paling terkenal di pasaran sudah tentu Docker . Mesin maya daripada IaaS (infrastruktur sebagai perkhidmatan) seperti AWS juga boleh berfungsi dengan baik untuk memasang perkhidmatan mikro, tetapi perkhidmatan mikro yang agak ringan mungkin tidak menggunakan semua sumber yang ada dalam mesin maya, yang boleh mengurangkan keuntungan penggunaan. Anda juga boleh memasang perkhidmatan mikro anda menggunakan pakej OSGI (Inisiatif Gerbang Perkhidmatan Terbuka). Dalam kes ini, semua perkhidmatan mikro akan dijalankan dalam satu JVM, tetapi ini melibatkan isu pertukaran antara kawalan dan pengasingan. Perkhidmatan Mikro: Kelemahan Hanya kerana "ini semua keren" dan "kami tidak pernah melihatnya sebelum ini" tidak bermakna tiada kelemahan. Di bawah ialah senarai kemungkinan kawasan kesakitan yang dibawa oleh seni bina perkhidmatan mikro:
Membangunkan sistem teragih boleh menjadi sukar. Dengan ini saya maksudkan bahawa semua komponen kini adalah perkhidmatan bebas - anda perlu berhati-hati mengendalikan permintaan yang berlalu antara modul. Mungkin terdapat senario di mana satu modul tidak bertindak balas, memaksa anda menulis kod tambahan untuk mengelakkan sistem ranap. Ini boleh menjadi lebih sukar jika panggilan jauh adalah sensitif kependaman .
Pelbagai pangkalan data dan pengurusan urus niaga boleh menjadi kesakitan yang nyata.
menguji aplikasi perkhidmatan mikro boleh menjadi menyusahkan. Menggunakan aplikasi monolitik, kita hanya perlu menjalankan arkib WAR/EAR/JAR pada pelayan dan pastikan ia disambungkan ke pangkalan data. Dan dalam perkhidmatan mikro, setiap perkhidmatan individu mesti dimulakan sebelum ujian boleh dimulakan.
Aplikasi pemasangan boleh menjadi rumit. Mereka mungkin memerlukan penyelarasan di sekitar pelbagai perkhidmatan yang mungkin tidak semudah dipasang sebagai bekas WAR.
.... Sudah tentu, dengan alat dan pendekatan yang betul kelemahan ini boleh dielakkan. Tetapi mereka sendiri memerlukan sokongan dan tidak menyelesaikan semua masalah sepenuhnya. Artikel tersebut telah diterjemahkan daripada laman web CloudAcademy . Terjemahan percuma. Semua orang bebas untuk menyatakan semua fikiran mereka dalam komen. Mereka pasti akan dibaca. Artikel asal Akaun Github saya
GO TO FULL VERSION