Melaksanakan mikroservis dalam persekitaran pengeluaran

Informatec Digital » Sumber » Melaksanakan mikroservis dalam persekitaran pengeluaran

Mengguna pakai seni bina mikroservis dalam persekitaran dunia sebenar bukan sekadar memecahkan monolit kepada bahagian yang lebih kecil; ia melibatkan pemikiran semula infrastruktur, pasukan, proses, data, keselamatan dan operasi . Apabila sistem beralih daripada teori kepada kluster pengeluaran, isu timbul mengenai penemuan perkhidmatan, kontrak antara pasukan, CI/CD, kebolehcerapan, daya tahan dan kebolehskalaan. Jika isu-isu ini tidak ditangani dengan betul, ia boleh mengubah mikroservis menjadi huru-hara teragih.

Berita baiknya ialah hari ini kita mempunyai banyak pengalaman terkumpul daripada organisasi seperti Netflix, Amazon, Google dan syarikat besar lain yang menjalankan beratus-ratus perkhidmatan mikro dalam pengeluaran . Berdasarkan pengajaran ini, berserta amalan terbaik dalam persekitaran perusahaan menggunakan Kubernetes dan OpenShift, kita boleh membangunkan pendekatan yang sangat mantap untuk mereka bentuk, menggunakan dan mengendalikan perkhidmatan mikro pada skala besar tanpa kehilangan kawalan.

Mengapa menggunakan mikroservis untuk pengeluaran (dan apabila ia tidak berbaloi)

Seni bina mikroservis yang direka bentuk dengan baik membolehkan anda bekerjasama dengan pasukan kecil, autonomi dan pelbagai fungsi yang mengambil alih pemilikan perkhidmatan hujung ke hujung. Setiap pasukan beroperasi dalam konteks yang jelas, boleh menggunakan perkhidmatan dengan kerap dan memikul tanggungjawab penuh untuk perkhidmatannya, sekali gus mengurangkan masa kitaran pembangunan dan mempercepatkan penyampaian ciri baharu.

Satu lagi manfaat utama ialah penskalaan bebas bagi setiap perkhidmatan . Anda tidak perlu membesar-besarkan keseluruhan aplikasi jika hanya katalog, pembayaran atau API awam yang mengalami lonjakan trafik. Anda boleh melaraskan setiap perkhidmatan mikro secara mendatar atau menegak mengikut corak pemuatannya, mengukur kos setiap ciri dengan tepat dan mengekalkan ketersediaan walaupun kawasan tertentu mengalami lonjakan penggunaan.

Cara perkhidmatan ini dibungkus dan digunakan memudahkan pelaksanaan berterusan dan berisiko rendah . Mengeluarkan setiap mikroservis secara bebas menjadikan pengujian idea baharu dan pemulihan versi yang bermasalah lebih mudah: penggunaan canary, pengembalian biru/hijau dan pengembalian automatik mengurangkan kos kegagalan dan menyediakan ruang untuk eksperimen.

Dari sudut pandangan teknologi, perkhidmatan mikro memupuk kebebasan untuk memilih bahasa, rangka kerja dan pangkalan data untuk setiap perkhidmatan. Tidak semua keperluan sesuai dengan susunan teknologi yang sama: anda mungkin mempunyai perkhidmatan perniagaan dalam .NET atau Java, pemprosesan data dalam Scala/Spark, perkhidmatan khusus dalam Python atau F# atau perkhidmatan mikro AI dalam R. Kepelbagaian terkawal ini membolehkan anda menggunakan alat yang betul untuk setiap kes, tanpa memaksa keseluruhan aplikasi ke dalam anjakan teknologi global.

Tambahan pula, memecahkan sistem kepada bahagian-bahagian kecil yang jelas memudahkan penggunaan semula fungsi sebagai blok binaan . Mikroservis yang pada mulanya dicipta sebagai sebahagian daripada fungsi yang lebih besar kemudiannya boleh digunakan semula sebagai kebergantungan kepada bahagian lain sistem tanpa menulis semula logiknya. Dan kerana perkhidmatan tersebut diasingkan, kegagalan dalam salah satu daripadanya biasanya mengakibatkan degradasi sistem separa, bukan gangguan sistem sepenuhnya, dengan syarat daya tahan telah direka bentuk dari awal lagi.

Reka bentuk seni bina dan perkhidmatan

Agar perkhidmatan mikro berfungsi dengan baik dalam pengeluaran, adalah penting untuk bermula dengan reka bentuk sempadan dan tanggungjawab perkhidmatan yang teliti . Secara praktikal, ini biasanya bermula dengan mengenal pasti perkhidmatan kasar dalam monolit sedia ada: kawasan fungsian yang besar atau domain perniagaan (cth., pesanan, katalog, pengguna, pengebilan) yang sudah mempunyai beberapa pemisahan logik.

Bermula dengan blok binaan yang besar ini, proses ini melibatkan penambahbaikan reka bentuk untuk mendapatkan perkhidmatan mikro yang terperinci yang beroperasi pada set data yang koheren , memiliki model mereka sendiri dan mengetahui dengan tepat apa yang mereka perlu baca atau tulis kepada perkhidmatan lain. Proses ini biasanya bergantung pada konsep reka bentuk dipacu domain (DDD) dan konteks yang dibatasi, menghalang perkhidmatan mikro daripada menjadi "monolit mini".

API yang mendedahkan perkhidmatan ini mesti mempunyai kontrak yang jelas dan stabil . Ini melibatkan dokumentasi yang ketat (REST dengan OpenAPI, gRPC dengan fail .proto, dll.), versi eksplisit, mengekalkan keserasian ke belakang jika boleh dan mengautomasikan pengesahan kontrak untuk mengesan perubahan yang tidak normal sebelum ia mencapai pengeluaran.

Dalam persekitaran dengan berpuluh-puluh atau beratus-ratus perkhidmatan, adalah penting untuk menggabungkan corak daya tahan dari peringkat reka bentuk, supaya sistem bersedia untuk kegagalan separa . Corak seperti pemutus litar, percubaan semula dengan undur, tamat masa yang jelas, sekatan dan tekanan balik membantu mencegah kegagalan satu perkhidmatan daripada menjatuhkan yang lain. Alat kejuruteraan huru-hara seperti ChaosMonkey atau Gremlin berguna untuk menguji secara praktikal bagaimana platform bertindak balas di bawah gangguan simulasi.

Banyak sistem yang kompleks menggabungkan perkhidmatan CRUD yang agak mudah dengan perkhidmatan yang lebih canggih yang mengendalikan peraturan perniagaan yang sentiasa berubah. Tidak semua mikroservis memerlukan seni bina dalaman yang kompleks : sesetengahnya boleh menjadi pengawal HTTP mudah dengan akses data asas, manakala yang lain, seperti perkhidmatan pesanan atau pengebilan, boleh memanfaatkan corak yang lebih maju (DDD, CQRS, peristiwa domain, dll.).

Infrastruktur pengeluaran: awan, kontena dan Kubernetes/OpenShift

Pengalaman dunia sebenar menunjukkan bahawa mikroservis berfungsi dengan lebih baik apabila digunakan pada infrastruktur awan dengan kontena dan orkestrasi berbanding pada mesin maya terpencil. Platform seperti Kubernetes dan OpenShift menyediakan primitif yang diperlukan untuk membungkus perkhidmatan sebagai kontena, menskala, mengemas kini, mengimbangkan beban dan mengurus ketersediaan tinggi.

Biasanya, setiap mikroservis dibungkus dalam imej kontena berdasarkan imej asas korporat (contohnya, OpenJDK 21 untuk perkhidmatan Java) yang diuruskan oleh pasukan infrastruktur. Imej asas ini sentiasa dikemas kini dengan tampalan keselamatan, dan apabila versi baharu dikeluarkan, pasukan pembangunan bertanggungjawab untuk membina semula dan menggunakan semula perkhidmatan mereka dalam persekitaran yang sepadan.

Dalam Kubernetes/OpenShift, unit pelaksanaan asas ialah pod, yang merangkum satu atau lebih bekas . Biasanya, mikroservis sepadan dengan jenis pod dan digunakan menggunakan sumber seperti Deployments (untuk perkhidmatan tanpa status) atau StatefulSets (apabila terdapat status yang berkaitan). Dari awal lagi, bilangan replika minimum bagi setiap persekitaran ditakrifkan supaya persekitaran ujian, pra-pengeluaran dan pengeluaran mempunyai tahap ketersediaan yang sesuai dengan kekritikannya.

Penskalaan automatik dilaksanakan menggunakan HorizontalPodAutoscaler (HPA) , yang melaraskan bilangan replika berdasarkan metrik seperti CPU, memori atau metrik tersuai lain. Platform ini juga mesti mengkonfigurasi peraturan anti-afiniti pod untuk mengagihkan replika perkhidmatan yang sama merentasi nod yang berbeza, menghalang kegagalan nod tunggal daripada menghapuskan semua tika.

Berkenaan saiz menegak, resources.requests dan resources.limits digunakan untuk menentukan julat CPU dan memori yang boleh digunakan oleh pod. Contohnya, menempah minimum 100MB CPU dan 256MB memori, dan membenarkan sehingga 500MB dan 2GB masing-masing untuk perkhidmatan Java, melaraskan JVM (Xms, Xmx, Xss) untuk memanfaatkan sumber kontena dengan baik.

Pengurusan keadaan: mikroservis tanpa kewarganegaraan dan bernegara

Kebanyakan mikroservis perniagaan direka bentuk sebagai perkhidmatan tanpa status . Ini bermakna pod tidak menyimpan maklumat yang perlu bertahan selepas but semula; status dikekalkan dalam pangkalan data luaran, barisan mesej atau storan lain. Pendekatan ini memudahkan penskalaan mendatar dinamik dan penggunaan tanpa geseran, kerana mana-mana replika boleh mengendalikan sebarang permintaan.

Walau bagaimanapun, terdapat senario di mana tiada alternatif selain mempunyai mikroservis stateful yang disokong oleh volum berterusan . Ini adalah kes bagi sesetengah pangkalan data, sistem fail teragih atau komponen yang memerlukan penyelenggaraan data setempat. Pod ini biasanya digunakan dengan StatefulSets, dipautkan kepada PersistentVolumes menggunakan PersistentVolumeClaims dan diskalakan secara menegak dan bukannya mendatar.

Apabila sesuatu perkhidmatan mikro memerlukan storan berterusan, PersistentVolumeClaim (PVC) diminta dengan saiz, mod akses dan tujuan penggunaannya , dan pasukan operasi akan memperuntukkannya mengikut dasar platform. PVC ini dirujuk dalam manifes penggunaan dan dipasang pada pod supaya perkhidmatan boleh membaca dan menulis data secara berterusan.

Walaupun model berstatus mungkin diperlukan dalam kes tertentu, cadangan umum adalah untuk memastikan seberapa banyak perkhidmatan yang mungkin tanpa status . Ini memudahkan penggunaan, penskalaan, daya tahan dan pemulihan bencana serta mengurangkan kerumitan operasi dalam persekitaran dengan banyak perkhidmatan mikro.

Desentralisasi data dan kedaulatan perkhidmatan

Dalam infrastruktur tradisional, adalah perkara biasa untuk memusatkan pangkalan data dan storan untuk memaksimumkan kecekapan. Dengan mikroservis, pendekatan ini bercanggah dengan autonomi pasukan dan penyahgandingan . Jika banyak perkhidmatan berkongsi skema hubungan yang sama, sebarang perubahan struktur boleh menyekat berbilang pasukan dan secara tidak sengaja merosakkan keserasian.

Oleh itu, amalan yang disyorkan adalah untuk setiap perkhidmatan mikro memiliki model data dan pangkalan datanya sendiri , walaupun dalam persekitaran pembangunan, pangkalan data tersebut berjalan sebagai bekas dalam kluster untuk memudahkan penggunaan. Dalam pengeluaran, contoh yang diuruskan awan atau pelayan pangkalan data ketersediaan tinggi yang lain biasanya digunakan, sentiasa mengekalkan sempadan pemilikan yang jelas.

Ini tidak bermakna tiada penyepaduan data; ia bermakna konsistensi antara perkhidmatan diuruskan dengan peristiwa dan pemesejan tak segerak , menerima konsistensi akhirnya apabila munasabah. Adalah perkara biasa untuk menggunakan bas peristiwa (RabbitMQ, Azure Service Bus, Kafka, dll.) untuk menyebarkan perubahan keadaan antara mikroservis, mengurangkan kebergantungan yang kuat pada pangkalan data tunggal.

Platform awan memudahkan pasukan memilih jenis pangkalan data optimum untuk setiap perkhidmatan (relasi, dokumen, nilai kunci, siri masa, dll.), tanpa mengenakan satu teknologi pun. Kuncinya ialah reka bentuk mempertimbangkan kemungkinan pemindahan skema dan struktur tanpa melanggar kontrak dengan perkhidmatan lain, dan keputusan data dibuat sejajar dengan sempadan domain setiap perkhidmatan mikro.

Tadbir urus, pasukan dan organisasi yang diagihkan

Beralih kepada perkhidmatan mikro tanpa mengubah organisasi memerlukan masalah. Struktur berdasarkan pasukan produk digalakkan berbanding silo berfungsi klasik rangkaian, sistem, pangkalan data, pembangunan dan operasi , yang menggabungkan profil daripada pembangunan, QA, DevOps dan, jika berkenaan, penganalisis perniagaan atau data.

Setiap pasukan bertanggungjawab untuk satu atau lebih mikroservis dalam domain fungsi yang sama, mengendalikan pembangunan dan operasi (anda membinanya, anda menjalankannya) . Ini bermakna pasukan menguruskan saluran paip CI/CDnya, bekerjasama dengan infrastruktur untuk keperluan khusus dan mengambil bahagian dalam pemantauan dan tindak balas insiden. Platform infrastruktur dan awan memberi tumpuan kepada penyediaan perkhidmatan yang sama dan standard.

Untuk mengelakkan tadbir urus teragih ini daripada menjadi anarki, adalah penting untuk menentukan piawaian ringan dan katalog kongsi : imej asas yang diluluskan, corak penggunaan, konvensyen penamaan untuk ruang nama dan perkhidmatan, garis panduan API, templat Dockerfile dan Kustomize, dsb. Garis panduan ini berfungsi sebagai "penghadang" yang mengorientasikan pasukan tanpa menyekat keupayaan mereka untuk membuat keputusan.

Dalam banyak persekitaran perusahaan, ruang nama berasingan digunakan untuk setiap projek atau domain , dengan sekurang-kurangnya satu bagi setiap persekitaran (pembangunan, pra-pengeluaran, pengeluaran). Projek besar boleh mengedarkan mikroservisnya merentasi beberapa ruang nama, dengan syarat komunikasi dalaman dikonfigurasikan dengan betul dan peraturan keselamatan dipatuhi.

CI/CD, automasi dan model GitOps

Apabila sesuatu seni bina terdiri daripada berpuluh-puluh atau beratus-ratus mikroservis, satu-satunya cara untuk memastikan ia beroperasi adalah dengan melabur banyak dalam automasi hujung ke hujung . Ini termasuk saluran paip CI/CD yang konsisten, definisi penggunaan deklaratif, ujian automatik dan mekanisme pengembalian automatik.

Saluran integrasi dan penghantaran berterusan yang biasa mengendalikan penyusunan kod, menjalankan ujian, menganalisis kualiti dengan alatan seperti SonarQube , membina imej kontena daripada fail Docker korporat dan mengemas kini manifes penggunaan. Dari situ, sistem seperti ArgoCD atau yang serupa menggunakan perubahan pada kluster menggunakan pendekatan GitOps.

Setiap repositori mikroservis biasanya merangkumi fail Docker yang diseragamkan, fail konfigurasi saluran paip (cth., ci.json) , sifat untuk analisis kualiti dan direktori pelaksanaan dengan definisi Kubernetes (Kustomize atau Helm) yang dipisahkan oleh persekitaran. Webhook repositori mencetuskan saluran paip apabila peristiwa seperti tolakan tag atau permintaan penggabungan berlaku.

Corak GitOps menetapkan repositori Git sebagai sumber kebenaran untuk infrastruktur dan penggunaan . Manifes untuk Penggunaan, Perkhidmatan, ConfigMaps, PVC, SealedSecrets dan sumber lain diversikan di sana dan alatan khusus mengendalikan penyegerakan keadaan kluster dengan apa yang ditakrifkan dalam Git. Ini menyediakan kebolehkesanan, semakan permintaan tarik dan keupayaan pengembalian semula yang mudah.

Tetapan, rahsia dan keselamatan

Dalam platform mikroservis yang matang, pengurusan konfigurasi bergantung pada ConfigMaps untuk parameter yang tidak sensitif dan Secrets untuk maklumat sulit . Setiap mikroservis biasanya mempunyai ConfigMap khusus persekitarannya sendiri, yang menyimpan sifat seperti URL perkhidmatan bergantung, bendera fungsi dan parameter penalaan.

Rahsia (kelayakan, kunci, token, sijil) dikendalikan dengan dasar keselamatan yang ketat . Dalam persekitaran yang kurang kritikal, ia mungkin boleh diterima untuk menyimpannya dalam teks biasa yang diuruskan oleh pasukan pembangunan, tetapi dalam persekitaran pra-pengeluaran dan pengeluaran, adalah disyorkan untuk menyulitkannya menggunakan alatan seperti Sealed Secrets atau pengurus luaran berasaskan awan tertentu.

Apabila rahsia perlu dikongsi antara berbilang perkhidmatan (contohnya, kelayakan Pengumpul OTEL atau stor kunci biasa ), ia boleh dipusatkan dalam repositori konfigurasi bagi setiap ruang nama. Projek yang berkongsi ruang nama tersebut menyelaras untuk mengemas kininya mengikut keperluan, mengekalkan kawalan ke atas siapa yang boleh membaca atau mengubah suai sumber ini.

Dari segi keselamatan komunikasi, corak dominan ialah Kepercayaan Sifar : tiada apa yang dianggap remeh hanya kerana trafik adalah "dalaman." Semua panggilan antara perkhidmatan, baik dalaman mahupun luaran, mesti disahkan dan dibenarkan, idealnya dengan mTLS, token JWT atau mekanisme lain yang setara. Perkhidmatan mikro tidak mewakilkan keselamatan secara membuta tuli kepada Pengurus API atau rangkaian; mereka juga melakukan pemeriksaan mereka sendiri.

Komunikasi antara mikroservis, API dan pemesejan

Dalam seni bina mikroservis yang matang, lapisan komunikasi dibahagikan kepada beberapa kes. Untuk trafik daripada klien (pelayar, aplikasi mudah alih, pihak ketiga) ke bahagian belakang, API yang diterbitkan yang dikawal oleh Pengurus API digunakan . API ini biasanya RESTful (selalunya menggunakan OpenAPI) atau, dalam beberapa kes, gRPC yang didedahkan melalui gerbang.

Panggilan antara mikroservis yang berada dalam ruang nama yang sama, atau merentasi berbilang ruang nama dalam projek yang sama, biasanya dikendalikan oleh perkhidmatan Kubernetes dalaman dengan DNS dalaman . Panggilan ini memintas Pengurus API awam tetapi mematuhi dasar keselamatan, pengesahan dan kebenaran. Untuk senario ini, jaringan perkhidmatan atau gerbang dalaman yang menguatkuasakan dasar biasa boleh digunakan.

Apabila mikroservis tergolong dalam domain atau projek berfungsi yang berbeza , komunikasi dianggap "awam" di peringkat organisasi. Dalam kes ini, amalan biasa adalah untuk menggunakan Pengurus API atau bas interoperabiliti, di mana kontrak, kuota, keselamatan, versi dan pengauditan diuruskan, menghalang gandingan langsung antara kluster atau ruang nama bebas.

Berkenaan penyepaduan dengan sistem legasi atau luaran, yang mungkin tidak selalunya mendedahkan API moden, adalah perkara biasa untuk bergantung pada penyambung tertentu berbanding bas interoperabiliti . Dengan cara ini, mikroservis bertutur dalam bahasa yang sama (contohnya, peristiwa atau API REST dalaman), dan penyambung mengendalikan terjemahan ke dan dari sistem legasi, sentiasa dengan keselamatan yang dipertingkatkan.

Selain komunikasi segerak, pemesejan tak segerak memainkan peranan penting . Ia digunakan untuk memisahkan proses, menyerap lonjakan, menyebarkan peristiwa perniagaan antara perkhidmatan dan meningkatkan daya tahan. Setiap peristiwa biasanya mempunyai skema yang jelas dan berversi, dengan mekanisme penjejakan untuk mencegah kerosakan antara pengeluar dan pengguna semasa mereka berkembang.

Kebolehcerapan, Pengumpul dan operasi OTEL

Dalam sistem yang terdiri daripada banyak perkhidmatan mikro, mendiagnosis masalah tanpa kebolehcerapan yang baik adalah hampir mustahil. Itulah sebabnya metrik, pembalakan berpusat dan jejak teragih disepadukan dari peringkat reka bentuk , membolehkan pemahaman tentang apa yang berlaku di peringkat perkhidmatan dan platform.

Komponen utama skema ini ialah Pengumpul OpenTelemetri (Pengumpul OTEL) , yang digunakan dalam ruang nama atau secara berpusat untuk mengumpul metrik, log dan jejak daripada semua komponen. Perkhidmatan mikro hanya perlu tahu bahawa mereka harus menghantar telemetri mereka kepada Pengumpul; Pengumpul kemudian meneruskannya kepada sistem kebolehcerapan (Prometheus, Grafana, Jaeger, Elastic, dll.) tanpa perkhidmatan perlu mengetahui butirannya.

Untuk lapisan infrastruktur, pengumpul dan pengeksport peringkat nod digunakan untuk mengumpulkan metrik CPU, memori, cakera, rangkaian dan log daripada pod, menghantarnya masing-masing ke Prometheus dan Elasticsearch. Alat seperti Grafana dan Kibana digunakan untuk menggambarkan maklumat ini, membina papan pemuka dan menentukan amaran dengan ambang pintar dan buku larian yang berkaitan.

Apabila sesuatu projek memerlukan pemprosesan metrik atau jejaknya yang sangat spesifik, ia boleh menggunakan tika OTEL Collectornya sendiri dalam ruang namanya, dengan syarat ia mempunyai kelulusan operasi dan model penyelenggaraan pengeluaran adalah jelas.

Strategi pengujian, kontrak dan pengalaman pembangunan tempatan

Menguji seni bina mikroservis teragih memerlukan strategi pengujian yang lebih canggih daripada menguji monolit. Ujian unit kekal penting, tetapi ujian kontrak (untuk API dan peristiwa), ujian integrasi antara perkhidmatan dan ujian hujung ke hujung yang merentasi aliran lengkap menjadi semakin penting.

Untuk mengelakkan isu keserasian, teknik seperti ujian kontrak berorientasikan pengguna digunakan , di mana pelanggan menentukan jangkaan API dan penyedia perkhidmatan memenuhinya. Setiap perubahan kontrak menjalani ujian automatik dalam saluran paip CI, mencegah penggunaan yang melanggar mana-mana pengguna yang diketahui.

Apabila bilangan perkhidmatan meningkat melebihi seratus, mereplikasi keseluruhan sistem secara setempat menjadi tidak praktikal. Oleh itu, pembangunan bergantung pada simulasi perkhidmatan bergantung atau penerowongan ke persekitaran jauh . Pembangun biasanya hanya melancarkan subset perkhidmatan mikro dan menutup selebihnya dengan olok-olok, palsu atau simulator, atau mengalihkan panggilan tertentu ke persekitaran integrasi kongsi.

Pengujian hujung ke hujung semakin bergantung pada persekitaran sementara atau "pratonton" yang dicipta daripada cabang ciri , yang mewujudkan persekitaran terpencil dengan perkhidmatan yang berkaitan dengan fungsi tersebut. Ini meminimumkan geseran antara pasukan, mengurangkan kesan "ia berfungsi pada mesin saya" dan mengesan masalah integrasi sebelum mencapai persekitaran yang lebih mahal seperti pra-pengeluaran.

Corak penggunaan mikroservis dalam pengeluaran

Selain Kubernetes, terdapat beberapa corak penggunaan mikroservis dalam pengeluaran yang perlu diketahui kerana ia menangani senario pengasingan, kos dan kematangan yang berbeza . Salah satu corak tertua ialah berbilang contoh perkhidmatan bagi setiap hos, di mana satu hos fizikal atau maya menjalankan beberapa contoh perkhidmatan yang berbeza, biasanya pada pelayan aplikasi kongsi.

Dalam corak contoh perkhidmatan setiap VM , setiap perkhidmatan dipaketkan sebagai imej VM (contohnya, EC2 AMI) dan dijalankan pada contohnya sendiri. Ini menawarkan pengasingan yang kuat dengan kos penggunaan sumber yang lebih tinggi dan masa permulaan yang lebih perlahan. Alat seperti Packer atau penyelesaian khusus penyedia awan memudahkan untuk menjana imej VM sedia pengeluaran.

Corak yang paling meluas hari ini ialah contoh perkhidmatan setiap kontena , yang mana setiap mikroservis dibina sebagai imej kontena dan digunakan pada orkestrator (Kubernetes, OpenShift, dll.). Kontena lebih ringan daripada VM, dimulakan dengan sangat cepat dan membolehkan anda membungkus semua yang diperlukan untuk perkhidmatan, memudahkan penggunaan dan mendayakan penskalaan automatik.

Akhirnya, pendekatan tanpa pelayan, seperti AWS Lambda , telah mendapat populariti. Fungsi pakej ini yang bertindak balas terhadap permintaan HTTP atau peristiwa daripada perkhidmatan lain (S3, DynamoDB, barisan, dll.), dengan pengguna hanya membayar untuk apa yang mereka gunakan. Corak ini amat sesuai untuk mikroservis yang sangat kecil atau tugasan berpacu peristiwa yang berjangka pendek, walaupun ia memperkenalkan pertimbangan tambahan mengenai kebolehcerapan, permulaan sejuk dan had pelaksanaan.

Dalam praktiknya, banyak organisasi berakhir dengan ekosistem hibrid: bahagian teras sistem berjalan pada kontena dan orkestrator, sementara komponen tambahan tertentu dilaksanakan sebagai fungsi tanpa pelayan atau sebagai VM khusus, sentiasa dengan antara muka yang jelas dan protokol yang jelas untuk mengintegrasikannya ke dalam keseluruhannya.

Apabila melibatkan penghasilan semua ini, apa yang membezakannya bukan sekadar teknologi yang dipilih, tetapi juga kerana ia telah membina seni bina yang boleh menerima kerosakan, menskala jika perlu, menggunakan secara automatik dan boleh diperhatikan . Dengan pasukan yang sejajar dengan produk, kontrak yang diurus dengan baik, data terpencar dan platform awan yang mantap, perkhidmatan mikro bertukar daripada sekadar janji kepada cara yang berkesan dan mampan untuk mengembangkan aplikasi yang kompleks selama bertahun-tahun.