🥇Kasus panggunaan bolong layanan

Cathetan. nerjemahake.: Penulis artikel iki (Luc Perkins) minangka advokat pangembang ing organisasi CNCF, sing dadi papan kanggo proyek Open Source kaya Linkerd, SMI (Service Mesh Interface) lan Kuma (kanthi cara, sampeyan uga kepingin weruh kenapa Istio ora ana ing dhaptar iki?.). Sawise maneh nyoba nggawa komunitas DevOps luwih ngerti babagan hype trendi sing diarani "bolong layanan", dheweke nampilake 16 kapabilitas karakteristik sing diwenehake solusi kasebut.

dina iki layanan bolong - salah sawijining topik paling panas ing bidang teknik piranti lunak (lan pancen bener!). Aku mikir teknologi iki pancen njanjeni lan pengin ndeleng kanthi akeh diadopsi (mesthi bisa uga). Nanging, iku isih diubengi dening aura misteri kanggo akèh wong. Ing wektu sing padha, malah sing kondhang karo, iku asring angel kanggo ngramu kaluwihan lan apa persis iku (kalebu Panjenengan saestu). Ing artikel iki, aku bakal nyoba mbenerake kahanan kanthi dhaptar macem-macem kasus nggunakake "jarum layanan" *.

* Wigati transl.: kene lan luwih ing artikel persis terjemahan iki ("bolong layanan") bakal digunakake kanggo bolong layanan istilah isih anyar.

Nanging pisanan aku pengin nggawe sawetara komentar:

Aku ora tau nggarap layanan jejaring utawa digunakake ing njaba proyek sing diwiwiti kanggo pendhidhikanku dhewe. Ing sisih liya, aku sing nulis akeh dokumentasi kanggo bolong layanan internal Twitter ing 2015 (ora malah disebut "bolong layanan" nalika iku) lan melu pangembangan situs web lan dokumentasi kanggo Linkerd, dadi tegese soko.
Daftarku kira-kira lan ora lengkap. Bisa uga ana kasus panggunaan sing ora dingerteni kanggo aku, lan opsi anyar bakal muncul saka wektu nalika teknologi berkembang lan popularitase saya tambah.
Ing wektu sing padha, ora saben implementasine bolong layanan sing ana ndhukung kabeh kasus panggunaan sing kadhaptar. Mulane, pernyataanku kaya "bolong layanan bisa ..." kudu diwaca minangka "individu, lan mbok menawa kabeh implementasi bolong layanan populer bisa ...".
Urutane conto ora ana bedane.

Daftar singkat:

panemuan layanan;
enkripsi;
otentikasi lan wewenang;
imbangan beban;
nglanggar sirkuit;
autoscaling;
panyebaran kenari;
panyebaran biru-ijo;
mriksa kesehatan;
ngeculake beban;
pangilon lalu lintas;
insulasi;
panjalukan watesan tarif, nyoba maneh lan wektu entek;
telemetri;
audit;
visualisasi.

1. Panemuan layanan

TL;DR: Sambungake menyang layanan liyane ing jaringan nggunakake jeneng prasaja.

Layanan kudu bisa "golek" kanthi otomatis nggunakake jeneng sing nyukupi - contone, service.api.production, pets/staging utawa cassandra. Lingkungan awan elastis, lan jeneng siji bisa ndhelikake akeh conto layanan. Cetha yen ing kahanan kaya mengkono iku ora bisa hardcode kabeh alamat IP.

Kajaba iku, nalika siji layanan nemokake liyane, mesthine bisa ngirim panjaluk menyang layanan kasebut tanpa wedi yen bakal ana ing input saka conto sing rusak. Kanthi tembung liyane, bolong layanan kudu ngawasi kesehatan kabeh kedadeyan layanan lan njaga dhaptar host paling anyar.

Saben bolong layanan nindakake mekanisme panemuan layanan kanthi beda. Saiki, cara sing paling umum yaiku utusan menyang proses eksternal kaya Kubernetes DNS. Ing Twitter kepungkur, kita nggunakake sistem penamaan kanggo tujuan iki Finagle. Kajaba iku, teknologi bolong layanan ndadekake mekanisme penamaan khusus bisa muncul (sanajan aku durung weruh implementasine SM kanthi fungsi kasebut).

2. Enkripsi

TL; DR: Mbusak lalu lintas sing ora dienkripsi ing antarane layanan lan nggawe proses iki otomatis lan bisa diukur.

Iku apik kanggo ngerti manawa panyerang ora bisa nembus jaringan internal sampeyan. Firewalls nindakake proyek gedhe iki. Nanging apa sing kedadeyan yen peretas mlebu? Apa dheweke bakal bisa nindakake apa wae sing dikarepake karo lalu lintas intra-layanan? Muga-muga iki ora kedadeyan. Kanggo nyegah skenario iki, sampeyan kudu ngleksanakake jaringan nul-kapercayan sing kabeh lalu lintas antarane layanan dienkripsi. Umume jejaring layanan modern entuk iki kanthi bebarengan TLS (saling TLS, mTLS). Ing sawetara kasus, mTLS bisa digunakake ing kabeh awan lan klompok (aku mikir komunikasi antarplanet bakal diatur kanthi cara sing padha).

Mesthi, kanggo layanan mTLS bolong opsional. Saben layanan bisa ngurus TLS dhewe, nanging iki tegese sampeyan kudu golek cara kanggo ngasilake sertifikat, nyebarake menyang host layanan, lan kalebu kode ing aplikasi sing bakal mbukak sertifikat kasebut saka file. Ya, aja lali nganyari sertifikat kasebut kanthi interval biasa. Layanan meshes ngotomatisasi mTLS kanthi sistem kaya SPIFFE, sing, kanthi otomatis, ngotomatisasi proses nerbitake lan muter sertifikat.

3. Authentication lan wewenang

TL; DR: Netepake sapa sing njaluk lan nemtokake apa sing diidini sadurunge panjaluk tekan layanan kasebut.

Layanan asring pengin ngerti sing nindakake panjalukan (otentikasi), lan nggunakake informasi iki, mutusake sing entitas diwenehi diijini nindakake (wewenang). Ing kasus iki, tembung ganti "sapa" bisa ndhelikake:

Layanan liyane. Iki diarani "otentikasi" peer" Contone, layanan web pengin ngakses layanan db. Layanan meshes biasane ngatasi masalah kasebut kanthi nggunakake mTLS: sertifikat ing kasus iki minangka pengenal sing dibutuhake.
Sawetara pangguna manungsa. Iki diarani "otentikasi" panyuwunan" Contone, pangguna haxor69 arep tuku lampu anyar. Service bolong nyedhiyani macem-macem mekanisme, f.eks. Token Web JSON.
Akeh kita wis nindakake iki ing kode aplikasi. A request teka ing, kita katon liwat meja users, temokake pangguna lan mbandhingake sandhi, banjur priksa kolom kasebut permissions lsp. Ing kasus bolong layanan, iki kedadeyan sadurunge panyuwunan tekan layanan kasebut.

Sawise kita nemtokake sapa panjaluk kasebut, kita kudu nemtokake apa sing diidini entitas iki. Sawetara jejaring layanan ngidini sampeyan nyetel kabijakan dhasar (babagan sapa sing bisa nindakake) minangka file YAML utawa ing baris perintah, dene liyane nawakake integrasi karo kerangka kaya Bukak Agen Kebijakan. Tujuan utama yaiku supaya layanan sampeyan nampa panjaluk apa wae, kanthi aman yen asale saka sumber sing dipercaya и tumindak iki diijini.

4. Load balancing

TL; DR: Distribusi beban ing kasus layanan miturut pola tartamtu.

A "Layanan" ing bagean layanan asring kasusun saka akeh kedadean padha. Contone, dina iki layanan cache kasusun saka 5 salinan, lan besoke nomer bisa nambah kanggo 11. Panyuwunan dikirim menyang cache, kudu disebarake miturut tujuan tartamtu. Contone, nyilikake latensi utawa nggedhekake kemungkinan kanggo entuk conto kerja. Algoritma sing paling umum digunakake yaiku Round-robin, nanging ana akeh liyane - contone, metode bobot (bobot) pitakon (sampeyan bisa milih target sing disenengi), ring (ring) hashing (nggunakake hashing sing konsisten ing host hulu) utawa metode panyuwunan sing paling sithik (preferensi diwenehake marang conto kanthi panjaluk paling sithik).

Balance klasik duwe fungsi liyane, kayata HTTP caching lan proteksi DDoS, nanging ora cocog banget kanggo lalu lintas wetan-kulon (yaiku, kanggo lalu lintas sing mili ing pusat data - kira-kira transl.) (skop khas bolong layanan). Mesthi, ora perlu nggunakake bolong layanan kanggo ngimbangi beban, nanging ngidini sampeyan nyetel lan ngontrol kabijakan imbangan kanggo saben layanan saka lapisan kontrol terpusat, saéngga ngilangi kabutuhan kanggo mbukak lan ngatur keseimbangan beban sing kapisah ing tumpukan jaringan. .

5. Circuit breaking

TL; DR: Mungkasi lalu lintas menyang layanan masalah lan ngontrol karusakan ing skenario paling ala.

Yen sakperangan alesan layanan ora bisa ngatasi lalu lintas, layanan bolong menehi sawetara opsi kanggo ngatasi masalah iki (liyane bakal rembugan ing bagean cocok). Pemutus sirkuit minangka pilihan sing paling abot kanggo medhot layanan saka lalu lintas. Nanging, ora ana gunane - rencana serep dibutuhake. Tekanan bali bisa diwenehake (backpressure) menyang layanan sing nggawe panjalukan (aja lali ngatur bolong layanan sampeyan kanggo iki!), utawa, contone, mewarnai kaca status dadi abang lan ngarahake pangguna menyang versi kaca liyane kanthi "paus sing tiba" ("Twitter is mudhun”).

Service meshes ora mung ngijini sampeyan kanggo nemtokake nalika mati bakal tindakake lan sing iki bakal tindakake. Ing kasus iki, "kapan" bisa kalebu kombinasi paramèter sing ditemtokake: jumlah total panjalukan kanggo periode tartamtu, jumlah sambungan paralel, panjaluk sing ditundha, nyoba maneh aktif, lsp.

Sampeyan mbokmenawa ora pengin nyiksa sirkuit breaking, nanging iku apik kanggo ngerti sing duwe rencana serep ing cilik saka darurat.

6. Autoscaling

TL; DR: Tambah utawa nyuda jumlah instansi layanan gumantung saka kritéria sing ditemtokake.

Jaring layanan ora dadi panjadwal, mula ora nindakake scaling dhewe. Nanging, dheweke bisa menehi informasi babagan para perencana sing bakal nggawe keputusane. Wiwit layanan bolong duwe akses menyang kabeh lalu lintas antarane layanan, padha duwe informasi ekstensif babagan apa sing kedados: kang layanan sing ngalami masalah, kang layanan banget entheng dimuat (kapasitas diparengake kanggo wong-wong mau boroske), etc.

Contone, Kubernetes ngukur layanan adhedhasar panggunaan CPU lan memori pods (ndeleng laporan kita "Autoscaling lan manajemen sumber daya ing Kubernetes"- kb. transl.), nanging yen sampeyan nemtokake skala adhedhasar metrik liyane (ing kasus kita, lalu lintas sing gegandhengan), sampeyan butuh metrik khusus. Manajemen kaya iki nuduhake carane nindakake iki karo Envoy, Istio и Prometheus, nanging proses dhewe cukup rumit. Kita pengin bolong layanan nyederhanakake iki kanthi ngidini kita nyetel kahanan kaya "nambah jumlah conto layanan. auth, yen jumlah panjalukan sing ditundha ngluwihi batesan sajrone menit."

7. Penyebaran kenari

TL; DR: Nguji fitur utawa versi layanan anyar ing subset pangguna.

Contone, sampeyan lagi ngembangake produk SaaS lan arep ngluncurake versi anyar sing apik. Sampeyan dites ing pementasan lan bisa apik. Nanging isih ana uneg-uneg tartamtu babagan prilaku dheweke ing kahanan nyata. Ing tembung liya, sampeyan kudu nyoba versi anyar babagan masalah nyata tanpa mbebayani kapercayan pangguna. Penyebaran Canary apik kanggo iki. Dheweke ngidini sampeyan nduduhake fitur anyar menyang subset pangguna. Subset iki bisa uga kalebu pangguna sing paling setia utawa sing nggarap versi gratis produk kasebut, utawa pangguna sing pengin dadi "kelinci percobaan".

Layanan meshes ngleksanakake iki kanthi ngidini sampeyan nemtokake kritéria sing nemtokake sapa sing bakal weruh versi aplikasi kasebut, lan nuntun lalu lintas sing cocog. Nanging, ora ana owah-owahan kanggo layanan kasebut dhewe. Versi 1.0 saka layanan kasebut percaya yen kabeh panjaluk teka saka pangguna sing kudu ndeleng, lan versi 1.1 percaya uga kanggo pangguna. Sauntara kuwi, sampeyan bisa ngganti persentase lalu lintas antarane versi lawas lan anyar, ngarahake akeh pangguna menyang sing anyar yen bisa digunakake kanthi stabil lan "kelinci percobaan" sampeyan menehi go-ahead.

8. Panyebaran biru-ijo

TL; DR: Muter fitur anyar sing apik, nanging siyap kanggo langsung njupuk kabeh.

Makna panyebaran biru-ijo iku kanggo muter metu layanan "biru" anyar, miwiti ing podo karo karo lawas, "ijo" siji. Yen kabeh dadi lancar lan layanan anyar performs apik, sing lawas bisa mboko sithik dipatèni. (Alah, ing sawijining dina layanan "biru" anyar iki bakal mbaleni nasib sing "ijo" lan ilang ...) Penyebaran biru-ijo beda karo kenari amarga fungsi anyar kalebu kabeh bareng pangguna (ora bagean); Titik ing kene yaiku "pelabuhan sing aman" siap yen ana sing salah.

Layanan bolong nawakake cara sing trep banget kanggo nyoba layanan "biru" lan langsung ngalih menyang "ijo" sing bisa digunakake yen ana masalah. Ora kanggo sebutno kasunyatan sing ing dalan padha nyedhiyani akèh informasi (ndeleng "Telemetri" ing ngisor iki) bab karya saka "biru", kang mbantu kanggo ngerti apa iku siap kanggo operasi lengkap.

Cathetan. nerjemahake.: Sampeyan bisa maca liyane babagan strategi penyebaran beda ing Kubernetes (kalebu kenari kasebut, biru/ijo lan liya-liyane) ing artikel iki.

9. Priksa kesehatan

TL; DR: Lacak conto layanan sing fungsional lan nanggapi sing ora bisa digunakake maneh.

Priksa kesehatan (pemeriksaan kesehatan) mbantu mutusake apa conto layanan siap nampa lan ngolah lalu lintas. Contone, ing kasus layanan HTTP, priksa kesehatan bisa uga katon kaya panyuwunan GET menyang titik pungkasan /health. Wangsulan 200 OK bakal ateges sing Kayata iku sehat, sembarang liyane - iku ora siap kanggo nampa lalu lintas. Meshes layanan ngidini sampeyan nemtokake cara fungsi bakal dicenthang lan frekuensi mriksa iki bakal ditindakake. Informasi iki banjur bisa digunakake kanggo tujuan liyane - contone, kanggo load balancing lan circuit breaking.

Dadi, pamriksa kesehatan dudu kasus panggunaan mandiri, nanging biasane digunakake kanggo nggayuh tujuan liyane. Uga, gumantung saka asil pamriksa kesehatan, tumindak eksternal (gandhengan karo target bolong layanan liyane) bisa uga dibutuhake: contone, nganyari kaca status, nggawe masalah ing GitHub, utawa ngisi tiket JIRA. Lan bolong layanan nawakake mekanisme sing trep kanggo ngotomatisasi kabeh iki.

10. Ngeculake beban

TL; DR: Pangalihan lalu lintas kanggo nanggepi lonjakan panggunaan sementara.

Yen layanan tartamtu kakehan lalu lintas, sampeyan bisa sementara pangalihan sawetara lalu lintas iki menyang lokasi liya (yaiku, "mbucal", "transfer" (gudang) dheweke ana). Contone, menyang layanan serep utawa pusat data, utawa menyang permanen Pulsar topik. Akibaté, layanan bakal terus ngolah sawetara panjalukan tinimbang nabrak lan mandheg ngolah kabeh. Load shedding luwih disenengi kanggo ngilangi sirkuit, nanging isih ora dianjurake kanggo nyiksa. Iku mbantu nyegah gagal runtun sing nyebabake layanan hilir kacilakan.

11. Parallelization / mirroring lalu lintas

TL; DR: Kirimi siji panjalukan menyang sawetara panggonan bebarengan.

Kadhangkala ana perlu kanggo ngirim panjalukan (utawa pilihan tartamtu saka panjalukan) kanggo sawetara layanan bebarengan. Conto khas yaiku ngirim bagean saka lalu lintas produksi menyang layanan pementasan. Server web produksi utama ngirim panjalukan menyang layanan hilir products.production lan mung marang dheweke. Lan bolong layanan kanthi cerdas nyalin panjalukan iki lan dikirim menyang products.staging, sing server web malah ora ngerti.

Kasus panggunaan bolong layanan liyane sing bisa ditindakake ing ndhuwur paralelisasi lalu lintas yaiku tes regresi. Iki kalebu ngirim panjalukan sing padha menyang macem-macem versi layanan lan mriksa apa kabeh versi tumindak padha. Aku durung nemu implementasine bolong layanan karo sistem testing regresi terpadu kaya Diffy, nanging gagasan dhewe katon janjeni.

12. Isolasi

TL; DR: Break mesh layanan sampeyan dadi mini-jaringan.

Uga kasebut segmentasiIsolasi minangka seni mbagi bolong layanan dadi segmen sing beda-beda kanthi logis sing ora ngerti apa-apa. Isolasi kaya nggawe jaringan pribadi virtual. Bentenane dhasar yaiku sampeyan isih bisa nikmati kabeh keuntungan saka bolong layanan (kaya panemuan layanan), nanging kanthi keamanan tambahan. Contone, yen panyerang bisa nembus layanan ing siji subnet, dheweke ora bakal bisa ndeleng layanan apa sing mlaku ing subnet liyane utawa nyegat lalu lintas.

Kajaba iku, keuntungan bisa uga organisasi. Sampeyan bisa uga pengin subnet layanan sampeyan adhedhasar struktur perusahaan lan ngredhakaké pangembang saka beban kognitif kudu mbudidaya kabeh bolong layanan.

13. Panjaluk watesan, nyoba maneh lan wektu entek

TL; DR: Sampeyan ora perlu nglebokake tugas manajemen panyuwunan sing apik ing basis kode sampeyan.

Kabeh iki bisa dianggep kasus panggunaan sing kapisah, nanging aku mutusake kanggo gabungke amarga ana siji fitur umum: dheweke njupuk alih tugas manajemen siklus urip sing biasane ditangani dening perpustakaan aplikasi. Yen sampeyan ngembangake server web ing Ruby on Rails (ora terintegrasi karo bolong layanan) sing nggawe panjalukan kanggo backend layanan liwat gRPC, aplikasi kudu mutusake apa sing kudu ditindakake yen panjaluk N gagal. Sampeyan uga kudu mangerteni carane akeh lalu lintas layanan iki bakal bisa kanggo proses lan hardcode parameter iki nggunakake perpustakaan khusus. Kajaba iku, aplikasi kasebut kudu mutusake kapan wektune nyerah lan ngidini panjaluk kasebut mandheg (adhedhasar wektu entek). Lan kanggo ngganti parameter ing ndhuwur, server web kudu mandheg, dikonfigurasi maneh lan diwiwiti maneh.

Ngundhuh tugas kasebut menyang bolong layanan ora mung tegese pangembang layanan ora kudu mikir babagan iki, nanging uga bisa dideleng kanthi cara sing luwih global. Yen rantai layanan kompleks digunakake, ucapake A -> B -> C -> D -> E, kabeh siklus urip panyuwunan kudu dianggep. Yen tugas kanggo ngluwihi wektu entek ing layanan C, iku logis kanggo nindakake iki kabeh bebarengan, lan ora ing bagean: nganyari kode layanan lan ngenteni nganti request narik ditampa lan sistem CI deploys layanan dianyari.

14. Telemetri

TL; DR: Nglumpukake kabeh informasi sing perlu (lan ora cukup) saka layanan.

Telemetri minangka istilah umum sing kalebu metrik, tracing sing disebarake, lan log. Meshes layanan nawakake mekanisme kanggo ngumpulake lan ngolah kabeh telung jinis data. Ing kene kedadeyan rada burem amarga jumlah opsi sing bisa uga akeh banget. Kanggo ngumpulake metrik ana Prometheus lan piranti liyane sing bisa digunakake kanggo ngumpulake log lancar d, Loki, Vector lan liyane. (contone ClickHouse karo kita omah log kanggo K8s - approx. transl.), kanggo mbagekke nelusuri ana Jaeger lan liya-liyane. Saben bolong layanan bisa uga ndhukung sawetara alat lan ora liyane. Bakal menarik kanggo ndeleng manawa proyek kasebut bisa Bukak Telemetri nyedhiyakake sawetara konvergensi.

Ing kasus iki, kauntungan saka teknologi bolong layanan yaiku kontainer sidecar bisa, ing prinsip, ngumpulake kabeh data ing ndhuwur saka layanan. Ing tembung liyane, sampeyan duwe sistem koleksi telemetri siji ing pembuangan, lan bolong layanan bisa proses kabeh informasi iki ing macem-macem cara. Tuladhane:

log buntut saka layanan tartamtu ing CLI;
ngawasi volume panjalukan saka dashboard bolong layanan;
ngumpulake jejak sing disebarake lan nerusake menyang sistem kaya Jaeger.

Perhatian, pertimbangan subyektif: Umumé, telemetri minangka area sing ora dikarepake gangguan sing kuat saka bolong layanan. Nglumpukake informasi dhasar lan nelusuri sawetara metrik emas kaya panjaluk tingkat sukses lan latensi apik, nanging muga-muga kita ora weruh tumpukan Frankenstein muncul sing nyoba ngganti sistem khusus, sawetara sing wis kabukten lan sinau kanthi apik. .

15. Audit

TL;DR: Sing lali pelajaran sejarah mesthi bakal diulang maneh.

Auditing minangka seni ngamati acara penting ing sawijining sistem. Ing cilik saka bolong layanan, iki bisa ateges nelusuri sing nggawe panjalukan kanggo endpoints tartamtu kanggo layanan tartamtu, utawa kaping pirang-pirang acara sing gegandhengan karo keamanan dumadi ing sasi pungkasan.

Cetha yen audit ana hubungane banget karo telemetri. Bedane yaiku telemetri biasane ana gandhengane karo produktivitas lan integritas teknis, dene audit bisa ana gandhengane karo masalah hukum lan masalah liyane sing ngluwihi wilayah teknis sing ketat (contone, kepatuhan karo GDPR - Peraturan Umum EU babagan proteksi data).

16. Visualisasi

TL; DR: Urip React.js - sumber antarmuka sing apik banget.

Bisa uga ana istilah sing luwih apik, nanging aku ora ngerti. Maksudku mung minangka perwakilan grafis saka bolong layanan utawa sawetara komponen. Visualisasi kasebut bisa kalebu indikator kaya latensi rata-rata, informasi konfigurasi sidecar, asil pamriksa kesehatan, lan tandha.

Makarya ing lingkungan sing berorientasi layanan mbutuhake beban kognitif sing luwih dhuwur dibandhingake karo Yang Mulia Monolith. Mulane, tekanan kognitif kudu dikurangi ing kabeh biaya. Antarmuka grafis sing prasaja kanggo bolong layanan kanthi kemampuan kanggo ngeklik tombol lan entuk asil sing dikarepake bisa dadi penentu kanggo tuwuhing popularitas teknologi iki.

Padha ora klebu ing dhaftar

Aku Originally dimaksudaké kanggo kalebu sawetara liyane nggunakake kasus ing dhaftar, nanging banjur mutusaké ora kanggo. Ing ngisor iki, bebarengan karo alasan keputusanku:

Pusat multi-data. Mratelakake panemume, iki dudu kasus panggunaan minangka area sing sempit lan spesifik saka aplikasi jejaring layanan utawa sawetara fungsi kaya panemuan layanan.
Ingress lan egress. Iki minangka wilayah sing gegandhengan, nanging aku wis mbatesi dhewe (mbok menawa artifisial) kanggo kasus panggunaan "lalu lintas wétan-kulon". Ingress lan egress pantes artikel kapisah.

kesimpulan

Sing kabeh kanggo saiki! Maneh, dhaptar iki kasepakatan banget lan kemungkinan ora lengkap. Yen sampeyan mikir yen aku ora kejawab utawa ana sing salah, hubungi aku ing Twitter (@luckerkins). Mangga ngurmati aturan kesopanan.

PS saka penerjemah

Ilustrasi judhul artikel adhedhasar gambar saka artikel "Apa Service Mesh (lan nalika nggunakake)?"(dening Gregory MacKinnon). Iku nuduhake carane sawetara fungsi saka aplikasi (ing ijo) wis dipindhah menyang bolong layanan sing nyedhiyani interconnections antarane wong-wong mau (ing biru).

Waca uga ing blog kita:

Source: www.habr.com