🥇Kes penggunaan mesh perkhidmatan

Catatan. terjemah: Pengarang artikel ini (Luc Perkins) ialah peguam bela pembangun di organisasi CNCF, yang merupakan rumah kepada projek Sumber Terbuka seperti Linkerd, SMI (Antara Muka Mesh Perkhidmatan) dan Kuma (secara langsung, adakah anda juga tertanya-tanya mengapa Istio tiada dalam senarai ini?.). Sekali lagi cuba membawa komuniti DevOps pemahaman yang lebih baik tentang gembar-gembur bergaya yang dipanggil "jaringan perkhidmatan", beliau menyenaraikan 16 keupayaan ciri yang disediakan oleh penyelesaian sedemikian.

Hari ini jaringan perkhidmatan ― salah satu topik paling hangat dalam bidang kejuruteraan perisian (dan memang betul!). Saya fikir teknologi ini sangat menjanjikan dan ingin melihatnya diterima pakai secara meluas (apabila ia masuk akal, sudah tentu). Namun, ia masih dikelilingi aura misteri bagi kebanyakan orang. Pada masa yang sama, walaupun mereka yang terkenal dengan itu, ia selalunya sukar untuk menyatakan kelebihannya dan apakah sebenarnya ia (termasuk anda sebenarnya). Dalam artikel ini saya akan cuba membetulkan keadaan dengan menyenaraikan pelbagai kes penggunaan "jaringan perkhidmatan"*.

* Catatan transl.: di sini dan seterusnya dalam artikel dengan tepat terjemahan ini (“jaringan perkhidmatan”) akan digunakan untuk jaringan perkhidmatan istilah yang masih baharu.

Tetapi pertama-tama saya ingin membuat beberapa ulasan:

Saya tidak pernah bekerja dengan jaringan perkhidmatan atau menggunakannya di luar projek yang dimulakan untuk pendidikan saya sendiri. Sebaliknya, saya adalah orang yang menulis sekumpulan dokumentasi untuk jaringan perkhidmatan dalaman Twitter pada tahun 2015 (ia tidak dipanggil "jaringan perkhidmatan" ketika itu) dan mengambil bahagian dalam pembangunan laman web dan dokumentasi untuk Linkerd, jadi itu bermakna sesuatu.
Senarai saya adalah anggaran dan tidak lengkap. Mungkin terdapat kes penggunaan yang saya tidak tahu, dan pilihan baharu mungkin akan timbul dari semasa ke semasa apabila teknologi berkembang dan popularitinya berkembang.
Pada masa yang sama, bukan setiap pelaksanaan mesh perkhidmatan sedia ada menyokong semua kes penggunaan yang disenaraikan. Oleh itu, pernyataan saya seperti "jaringan perkhidmatan boleh..." harus dibaca sebagai "individu, dan mungkin semua pelaksanaan jaringan perkhidmatan yang popular boleh...".
Susunan contoh tidak ada perbezaan.

Senarai pendek:

penemuan perkhidmatan;
penyulitan;
pengesahan dan kebenaran;
mengimbangi beban;
pemutus litar;
penskalaan automatik;
penyebaran kenari;
penempatan biru-hijau;
pemeriksaan kesihatan;
penumpahan beban;
pencerminan lalu lintas;
penebat;
mengehadkan kadar permintaan, mencuba semula dan tamat masa;
telemetri;
audit;
visualisasi.

1. Penemuan perkhidmatan

TL;DR: Sambung ke perkhidmatan lain pada rangkaian menggunakan nama mudah.

Perkhidmatan seharusnya boleh "mencari" satu sama lain secara automatik menggunakan nama yang mencukupi - contohnya, service.api.production, pets/staging atau cassandra. Persekitaran awan adalah anjal, dan satu nama boleh menyembunyikan banyak contoh perkhidmatan. Adalah jelas bahawa dalam keadaan sedemikian adalah mustahil untuk mengekod semua alamat IP secara fizikal.

Selain itu, apabila satu perkhidmatan menemui yang lain, ia sepatutnya dapat menghantar permintaan kepada perkhidmatan itu tanpa rasa takut bahawa ia akan berakhir pada input contoh yang rosak itu. Dalam erti kata lain, jaringan perkhidmatan mesti memantau kesihatan semua contoh perkhidmatan dan memastikan senarai hos adalah terkini yang mungkin.

Setiap jaringan perkhidmatan melaksanakan mekanisme penemuan perkhidmatan secara berbeza. Pada masa ini, cara yang paling biasa ialah mewakilkan kepada proses luaran seperti DNS Kubernetes. Pada masa lalu di Twitter kami menggunakan sistem penamaan untuk tujuan ini Final. Di samping itu, teknologi mesh perkhidmatan membolehkan mekanisme penamaan tersuai muncul (walaupun saya belum melihat sebarang pelaksanaan SM dengan fungsi sedemikian).

2. Penyulitan

TL;DR: Buang trafik tidak disulitkan antara perkhidmatan dan jadikan proses ini automatik dan berskala.

Senang mengetahui bahawa penyerang tidak dapat menembusi rangkaian dalaman anda. Firewall melakukan kerja yang hebat dalam hal ini. Tetapi apa yang berlaku jika penggodam masuk ke dalam? Adakah dia dapat melakukan apa sahaja yang dia mahu dengan trafik dalam perkhidmatan? Harap-harap perkara ini tidak berlaku lagi. Untuk mengelakkan senario ini, anda harus melaksanakan rangkaian sifar amanah di mana semua trafik antara perkhidmatan disulitkan. Kebanyakan rangkaian perkhidmatan moden mencapai ini melalui hubungan bersama TLS (TLS bersama, mTLS). Dalam sesetengah kes, mTLS berfungsi dalam keseluruhan awan dan kelompok (saya rasa komunikasi antara planet suatu hari nanti akan diatur dengan cara yang sama).

Sudah tentu, untuk mesh perkhidmatan mTLS pilihan. Setiap perkhidmatan boleh menjaga TLSnya sendiri, tetapi ini bermakna anda perlu mencari cara untuk menjana sijil, mengedarkannya ke seluruh hos perkhidmatan dan memasukkan kod dalam aplikasi yang akan memuatkan sijil ini daripada fail. Ya, jangan lupa untuk memperbaharui sijil ini pada selang masa yang tetap. Jaringan perkhidmatan mengautomasikan mTLS dengan sistem seperti SPIFFE, yang, seterusnya, mengautomasikan proses pengeluaran dan penggiliran sijil.

3. Pengesahan dan Kebenaran

TL;DR: Tetapkan siapa peminta dan tentukan perkara yang dibenarkan mereka lakukan sebelum permintaan itu sampai ke perkhidmatan.

Perkhidmatan sering ingin tahu yang melaksanakan permintaan (pengesahan), dan menggunakan maklumat ini, memutuskan bahawa entiti tertentu dibenarkan melakukan (kebenaran). Dalam kes ini, kata ganti "siapa" boleh menyembunyikan:

Perkhidmatan yang lain. Ini dipanggil "pengesahan" rakan sebaya" Sebagai contoh, perkhidmatan web ingin mengakses perkhidmatan tersebut db. Jejaring perkhidmatan biasanya menyelesaikan masalah sedemikian menggunakan mTLS: sijil dalam kes ini bertindak sebagai pengecam yang diperlukan.
Beberapa pengguna manusia. Ini dipanggil "pengesahan" permintaan" Contohnya, pengguna haxor69 nak beli lampu baru. Jaringan perkhidmatan menyediakan pelbagai mekanisme, mis. Token Web JSON.
Ramai daripada kita telah melakukan ini dalam kod aplikasi. Permintaan masuk, kami melihat melalui meja users, cari pengguna dan bandingkan kata laluan, kemudian semak lajur permissions dan lain-lain. Dalam kes jaringan perkhidmatan, ini berlaku sebelum permintaan itu sampai kepada perkhidmatan.

Sebaik sahaja kami telah menetapkan dari siapa permintaan itu datang, kami perlu menentukan perkara yang dibenarkan oleh entiti ini. Sesetengah jejaring perkhidmatan membenarkan anda menetapkan dasar asas (tentang siapa yang boleh melakukan apa) sebagai fail YAML atau pada baris arahan, manakala yang lain menawarkan penyepaduan dengan rangka kerja seperti Ejen Polisi Terbuka. Matlamat utama adalah untuk perkhidmatan anda menerima sebarang permintaan, dengan selamat mengandaikan ia datang daripada sumber yang dipercayai и tindakan ini dibenarkan.

4. Pengimbangan beban

TL;DR: Agihkan beban merentas kejadian perkhidmatan mengikut corak tertentu.

"Perkhidmatan" dalam bahagian perkhidmatan selalunya terdiri daripada banyak keadaan yang sama. Sebagai contoh, hari ini perkhidmatan cache terdiri daripada 5 salinan, dan esok bilangannya mungkin meningkat kepada 11. Permintaan dihantar ke cache, mesti diedarkan mengikut tujuan tertentu. Contohnya, meminimumkan kependaman atau memaksimumkan kebarangkalian untuk mendapatkan contoh yang berfungsi. Algoritma yang paling biasa digunakan ialah Round-robin, tetapi terdapat banyak lagi - contohnya, kaedah berwajaran (berwajaran) pertanyaan (anda boleh memilih sasaran pilihan), berdering (cincin) pencincangan (menggunakan pencincangan yang konsisten merentas hos huluan) atau kaedah permintaan paling sedikit (keutamaan diberikan kepada contoh dengan permintaan paling sedikit).

Pengimbang klasik mempunyai fungsi lain, seperti cache HTTP dan perlindungan DDoS, tetapi ia tidak begitu relevan untuk trafik timur-barat (iaitu, untuk trafik yang mengalir dalam pusat data - lebih kurang transl.) (skop tipikal jaringan perkhidmatan). Sudah tentu, tidak perlu menggunakan jaringan perkhidmatan untuk pengimbangan beban, tetapi ia membolehkan anda menetapkan dan mengawal dasar pengimbangan untuk setiap perkhidmatan daripada lapisan kawalan berpusat, dengan itu menghapuskan keperluan untuk menjalankan dan mengkonfigurasi pengimbang beban berasingan dalam timbunan rangkaian .

5. Pemutus litar

TL;DR: Hentikan trafik ke perkhidmatan yang bermasalah dan kawal kerosakan dalam senario terburuk.

Jika atas sebab tertentu perkhidmatan tidak dapat menampung lalu lintas, jaringan perkhidmatan menyediakan beberapa pilihan untuk menyelesaikan masalah ini (yang lain akan dibincangkan dalam bahagian yang sesuai). Pemutus litar ialah pilihan paling teruk untuk memutuskan sambungan perkhidmatan daripada trafik. Walau bagaimanapun, dengan sendirinya ia tidak masuk akal - pelan sandaran diperlukan. Tekanan belakang mungkin disediakan (tekanan belakang) kepada perkhidmatan yang membuat permintaan (hanya jangan lupa untuk mengkonfigurasi jaringan perkhidmatan anda untuk ini!), atau, sebagai contoh, mewarna halaman status merah dan mengubah hala pengguna ke versi lain halaman dengan "paus jatuh" ("Twitter ialah turun”).

Jerat perkhidmatan bukan sahaja membenarkan anda untuk menentukan apabila penutupan akan menyusul dan bahawa ini akan menyusul. Dalam kes ini, "bila" boleh termasuk sebarang kombinasi parameter yang ditentukan: jumlah bilangan permintaan untuk tempoh tertentu, bilangan sambungan selari, permintaan belum selesai, percubaan semula aktif, dsb.

Anda mungkin tidak mahu menyalahgunakan pemutus litar, tetapi senang mengetahui bahawa anda mempunyai pelan sandaran sekiranya berlaku kecemasan.

6. Autoscaling

TL;DR: Menambah atau mengurangkan bilangan contoh perkhidmatan bergantung pada kriteria yang ditentukan.

Jejaring perkhidmatan bukan penjadual, jadi ia tidak melaksanakan menskalakan diri. Walau bagaimanapun, mereka boleh memberikan maklumat mengenai perancang yang akan mendasarkan keputusan mereka. Memandangkan jejaring perkhidmatan mempunyai akses kepada semua trafik antara perkhidmatan, mereka mempunyai maklumat yang luas tentang perkara yang berlaku: perkhidmatan manakah yang mengalami masalah, perkhidmatan mana yang dimuatkan dengan sangat ringan (kapasiti yang diperuntukkan kepada mereka dibazirkan), dsb.

Contohnya, Kubernetes menskalakan perkhidmatan berdasarkan penggunaan CPU dan memori pod (lihat laporan kami "Penskalaan automatik dan pengurusan sumber dalam Kubernetes"- lebih kurang. terjemah.), tetapi jika anda memutuskan untuk menskalakan berdasarkan mana-mana metrik lain (dalam kes kami, berkaitan trafik), anda memerlukan metrik khas. Pengurusan macam ni menunjukkan bagaimana untuk melakukan ini dengan duta, Istio и Prometheus, tetapi proses itu sendiri agak rumit. Kami ingin mesh perkhidmatan memudahkan perkara ini dengan membenarkan kami menetapkan syarat seperti "menambah bilangan contoh perkhidmatan auth, jika bilangan permintaan yang belum selesai melebihi ambang dalam masa seminit."

7. Kerahan kenari

TL;DR: Uji ciri baharu atau versi perkhidmatan pada subset pengguna.

Katakan anda sedang membangunkan produk SaaS dan berhasrat untuk melancarkan versi baharunya yang hebat. Anda mengujinya dalam pementasan dan ia berfungsi dengan baik. Tetapi masih terdapat kebimbangan tertentu tentang tingkah lakunya dalam keadaan sebenar. Dengan kata lain, anda perlu menguji versi baharu tentang masalah sebenar tanpa mempertaruhkan kepercayaan pengguna. Penggunaan Canary sangat bagus untuk ini. Mereka membenarkan anda menunjukkan ciri baharu kepada subset pengguna. Subset ini mungkin terdiri daripada pengguna yang paling setia atau mereka yang bekerja dengan versi percuma produk, atau pengguna yang telah menyatakan keinginan untuk menjadi "guinea pig".

Jejaring perkhidmatan melaksanakan perkara ini dengan membenarkan anda menentukan kriteria yang menentukan siapa yang akan melihat versi aplikasi dan menghalakan trafik dengan sewajarnya. Walau bagaimanapun, tiada perubahan untuk perkhidmatan itu sendiri. Versi 1.0 perkhidmatan percaya bahawa semua permintaan datang daripada pengguna yang sepatutnya melihatnya, dan versi 1.1 percaya perkara yang sama untuk penggunanya. Sementara itu, anda boleh menukar peratusan trafik antara versi lama dan baharu, mengubah hala bilangan pengguna yang semakin meningkat kepada yang baharu jika ia berfungsi dengan stabil dan "guinea pig" anda memberikan kebenaran.

8. Kerahan biru-hijau

TL;DR: Melancarkan ciri baharu yang hebat, tetapi bersedia untuk segera mengambil semula segala-galanya.

Makna penempatan biru-hijau adalah untuk melancarkan perkhidmatan "biru" baharu, melancarkannya selari dengan perkhidmatan "hijau" lama. Jika semuanya berjalan lancar dan perkhidmatan baharu berfungsi dengan baik, maka perkhidmatan lama boleh dilumpuhkan secara beransur-ansur. (Malangnya, suatu hari nanti perkhidmatan "biru" baharu ini akan mengulangi nasib yang "hijau" dan hilang...) Penggunaan biru-hijau berbeza daripada yang kenari kerana fungsi baharu itu meliputi semua orang sekali gus pengguna (bukan bahagian); Maksudnya di sini adalah untuk menyediakan "pelabuhan selamat" sekiranya berlaku masalah.

Jejaring perkhidmatan menawarkan cara yang sangat mudah untuk menguji perkhidmatan "biru" dan serta-merta bertukar kepada perkhidmatan "hijau" yang berfungsi sekiranya berlaku masalah. Belum lagi fakta bahawa sepanjang perjalanan mereka memberikan banyak maklumat (lihat "Telemetri" di bawah) tentang kerja "biru", yang membantu untuk memahami sama ada ia bersedia untuk operasi penuh.

Catatan. terjemah: Anda boleh membaca lebih lanjut mengenai strategi penggunaan yang berbeza dalam Kubernetes (termasuk kenari yang disebutkan, biru/hijau dan lain-lain) dalam artikel ini.

9. Pemeriksaan kesihatan

TL;DR: Jejaki contoh perkhidmatan yang berfungsi dan balas kepada contoh yang tidak lagi berfungsi.

Pemeriksaan kesihatan (pemeriksaan kesihatan) membantu memutuskan sama ada kejadian perkhidmatan sedia untuk menerima dan memproses trafik. Contohnya, dalam kes perkhidmatan HTTP, pemeriksaan kesihatan mungkin kelihatan seperti permintaan GET ke titik akhir /health... Jawapan 200 OK akan bermakna bahawa contoh itu sihat, mana-mana yang lain - bahawa ia tidak bersedia untuk menerima trafik. Jejaring perkhidmatan membolehkan anda menentukan kedua-dua cara kefungsian akan diperiksa dan kekerapan pemeriksaan ini akan dijalankan. Maklumat ini kemudiannya boleh digunakan untuk tujuan lain - contohnya, untuk pengimbangan beban dan pemutus litar.

Oleh itu, pemeriksaan kesihatan bukanlah kes penggunaan yang berdiri sendiri, tetapi biasanya digunakan untuk mencapai matlamat lain. Selain itu, bergantung pada hasil pemeriksaan kesihatan, tindakan di luar sasaran jaringan perkhidmatan lain mungkin diperlukan: contohnya, mengemas kini halaman status, mencipta isu pada GitHub atau mengisi tiket JIRA. Dan mesh perkhidmatan menawarkan mekanisme yang mudah untuk mengautomasikan semua ini.

10. Penumpahan beban

TL;DR: Ubah hala trafik sebagai tindak balas kepada lonjakan sementara dalam penggunaan.

Jika perkhidmatan tertentu terlalu sarat dengan trafik, anda boleh mengubah hala beberapa trafik ini ke lokasi lain buat sementara waktu (iaitu, "buang", "pindah" (kampung) dia di sana). Contohnya, kepada perkhidmatan sandaran atau pusat data, atau kepada perkhidmatan tetap Tekan topik. Akibatnya, perkhidmatan akan terus memproses beberapa permintaan dan bukannya ranap dan berhenti memproses semuanya sama sekali. Penumpahan beban adalah lebih baik daripada memutuskan litar, tetapi masih tidak digalakkan untuk menyalahgunakannya. Ia membantu mengelakkan kegagalan melata yang menyebabkan perkhidmatan hiliran ranap.

11. Keselarian/pencerminan lalu lintas

TL;DR: Hantar satu permintaan ke beberapa tempat sekaligus.

Kadangkala terdapat keperluan untuk menghantar permintaan (atau pilihan permintaan tertentu) kepada beberapa perkhidmatan sekaligus. Contoh biasa ialah menghantar sebahagian daripada trafik pengeluaran ke perkhidmatan pementasan. Pelayan web pengeluaran utama menghantar permintaan kepada perkhidmatan hiliran products.production dan hanya kepadanya. Dan jaringan perkhidmatan menyalin permintaan ini dengan bijak dan menghantarnya kepada products.staging, yang tidak diketahui oleh pelayan web.

Satu lagi kes penggunaan mesh perkhidmatan berkaitan yang boleh dilaksanakan di atas paralelisasi trafik ialah ujian regresi. Ia melibatkan menghantar permintaan yang sama kepada versi perkhidmatan yang berbeza dan menyemak sama ada semua versi berkelakuan sama. Saya masih belum menemui pelaksanaan mesh perkhidmatan dengan sistem ujian regresi bersepadu seperti Diffy, tetapi idea itu sendiri nampaknya menjanjikan.

12. Penebat

TL;DR: Pecahkan rangkaian perkhidmatan anda kepada rangkaian mini.

Juga dikenali sebagai pembahagianPengasingan ialah seni membahagikan jaringan perkhidmatan kepada segmen yang berbeza secara logik yang tidak tahu apa-apa tentang satu sama lain. Pengasingan sedikit seperti mencipta rangkaian peribadi maya. Perbezaan asas ialah anda masih boleh menikmati semua faedah rangkaian perkhidmatan (seperti penemuan perkhidmatan), tetapi dengan keselamatan tambahan. Contohnya, jika penyerang dapat menembusi perkhidmatan pada satu subnet, dia tidak akan dapat melihat perkhidmatan yang dijalankan pada subnet lain atau memintas trafik mereka.

Di samping itu, faedah juga mungkin berorganisasi. Anda mungkin ingin mensubnet perkhidmatan anda berdasarkan struktur syarikat anda dan melegakan pembangun daripada beban kognitif kerana perlu mengingati keseluruhan rangkaian perkhidmatan.

13. Mengehadkan kadar permintaan, mencuba semula dan tamat masa

TL;DR: Anda tidak perlu lagi memasukkan tugas pengurusan permintaan yang rumit dalam pangkalan kod anda.

Semua perkara ini boleh dianggap sebagai kes penggunaan berasingan, tetapi saya memutuskan untuk menggabungkannya kerana satu ciri biasa: mereka mengambil alih tugas pengurusan kitaran hayat permintaan yang biasanya dikendalikan oleh perpustakaan aplikasi. Jika anda sedang membangunkan pelayan web dalam Ruby on Rails (tidak disepadukan dengan mesh perkhidmatan) yang membuat permintaan untuk menyandarkan perkhidmatan melalui gRPC, aplikasi perlu memutuskan perkara yang perlu dilakukan jika permintaan N gagal. Anda juga perlu mengetahui jumlah trafik perkhidmatan ini akan dapat memproses dan mengekod keras parameter ini menggunakan perpustakaan khas. Selain itu, aplikasi perlu memutuskan bila masa untuk berputus asa dan membiarkan permintaan itu gagal (berdasarkan masa tamat). Dan untuk menukar mana-mana parameter di atas, pelayan web perlu dihentikan, dikonfigurasikan semula dan dimulakan semula.

Memunggah tugasan ini ke jaringan perkhidmatan bukan sahaja bermakna pembangun perkhidmatan tidak perlu memikirkannya, tetapi juga tugas itu boleh dilihat dengan cara yang lebih global. Jika rangkaian perkhidmatan yang kompleks digunakan, sebut A -> B -> C -> D -> E, keseluruhan kitaran hayat permintaan mesti diambil kira. Jika tugasnya adalah untuk melanjutkan tamat masa dalam perkhidmatan C, adalah logik untuk melakukan ini sekaligus, dan bukan sebahagian: dengan mengemas kini kod perkhidmatan dan menunggu sehingga permintaan tarik diterima dan sistem CI menggunakan perkhidmatan yang dikemas kini.

14. Telemetri

TL;DR: Kumpul semua maklumat yang diperlukan (dan tidak lengkap) daripada perkhidmatan.

Telemetri ialah istilah umum yang merangkumi metrik, pengesanan teragih dan log. Jaringan perkhidmatan menawarkan mekanisme untuk mengumpul dan memproses ketiga-tiga jenis data. Di sinilah keadaan menjadi sedikit kabur kerana bilangan pilihan yang mungkin terlalu besar. Untuk mengumpul metrik ada Prometheus dan alatan lain yang boleh digunakan untuk mengumpul balak fasih, Loki, Vektor dan lain-lain (contohnya ClickHouse dengan kami rumah balak untuk K8s - lebih kurang. terjemah.), untuk pengesanan teragih ada Jaeger dan sebagainya. Setiap jaringan perkhidmatan mungkin menyokong beberapa alat dan bukan yang lain. Ia akan menjadi menarik untuk melihat sama ada projek itu boleh Telemetri terbuka memberikan sedikit penumpuan.

Dalam kes ini, kelebihan teknologi mesh perkhidmatan ialah bekas kereta sisi boleh, pada dasarnya, mengumpul semua data di atas daripada perkhidmatan mereka. Dalam erti kata lain, anda mempunyai sistem pengumpulan telemetri tunggal yang anda gunakan, dan jaringan perkhidmatan boleh memproses semua maklumat ini dalam pelbagai cara. Sebagai contoh:

log ekor daripada perkhidmatan tertentu dalam CLI;
memantau jumlah permintaan daripada papan pemuka mesh perkhidmatan;
kumpulkan jejak yang diedarkan dan majukannya ke sistem seperti Jaeger.

Perhatian, pertimbangan subjektif: Secara umumnya, telemetri ialah kawasan di mana gangguan kuat daripada jaringan perkhidmatan tidak diingini. Mengumpul maklumat asas dan menjejaki dengan segera beberapa metrik emas seperti kadar kejayaan permintaan dan kependaman adalah baik, tetapi harap kita tidak melihat timbunan Frankenstein muncul yang cuba menggantikan sistem khusus, beberapa daripadanya telah membuktikan sendiri dan dikaji dengan baik .

15. Audit

TL;DR: Mereka yang melupakan pelajaran sejarah ditakdirkan untuk mengulanginya.

Pengauditan ialah seni memerhati peristiwa penting dalam sesuatu sistem. Dalam kes jaringan perkhidmatan, ini boleh bermakna menjejak siapa yang membuat permintaan ke titik akhir tertentu untuk perkhidmatan tertentu atau berapa kali beberapa peristiwa berkaitan keselamatan berlaku pada bulan lepas.

Jelaslah bahawa pengauditan sangat berkait rapat dengan telemetri. Perbezaannya ialah telemetri biasanya dikaitkan dengan perkara seperti produktiviti dan integriti teknikal, manakala pengauditan boleh dikaitkan dengan isu undang-undang dan isu lain yang melangkaui bidang teknikal yang ketat (contohnya, pematuhan dengan GDPR - Peraturan Am EU mengenai perlindungan data).

16. Visualisasi

TL;DR: Hidup React.js - sumber antara muka mewah yang tidak habis-habis.

Mungkin ada istilah yang lebih baik, tetapi saya tidak tahu. Saya hanya bermaksud perwakilan grafik jaringan perkhidmatan atau beberapa komponennya. Visualisasi ini boleh termasuk penunjuk seperti kependaman purata, maklumat konfigurasi kereta sampingan, hasil pemeriksaan kesihatan dan makluman.

Bekerja dalam persekitaran berorientasikan perkhidmatan melibatkan beban kognitif yang jauh lebih tinggi berbanding Duli Yang Maha Mulia Monolith. Oleh itu, tekanan kognitif harus dikurangkan pada semua kos. Antara muka grafik yang mudah untuk jaringan perkhidmatan dengan keupayaan untuk mengklik pada butang dan mendapatkan hasil yang diingini boleh menjadi penentu untuk pertumbuhan populariti teknologi ini.

Tidak termasuk dalam senarai

Saya pada asalnya berhasrat untuk memasukkan beberapa lagi kes penggunaan dalam senarai, tetapi kemudian memutuskan untuk tidak melakukannya. Inilah mereka, bersama-sama dengan sebab keputusan saya:

Pusat berbilang data. Pada pendapat saya, ini bukanlah kes penggunaan tetapi kawasan yang sempit dan khusus bagi aplikasi jejaring perkhidmatan atau beberapa set fungsi seperti penemuan perkhidmatan.
Masuk dan keluar. Ini adalah kawasan yang berkaitan, tetapi saya telah mengehadkan diri saya (mungkin secara buatan) kepada kes penggunaan "trafik timur-barat". Masuk dan keluar layak mendapat artikel yang berasingan.

Kesimpulan

Itu sahaja buat masa ini! Sekali lagi, senarai ini sangat sewenang-wenangnya dan kemungkinan besar tidak lengkap. Jika anda rasa saya telah terlepas sesuatu atau mendapat sesuatu yang salah, sila hubungi saya di Twitter (@luckerkins). Tolong hormati peraturan kesopanan.

PS daripada penterjemah

Ilustrasi tajuk untuk artikel adalah berdasarkan imej daripada artikel “Apakah itu Service Mesh (dan bila hendak menggunakannya)?"(oleh Gregory MacKinnon). Ia menunjukkan bagaimana beberapa fungsi daripada aplikasi (berwarna hijau) telah berpindah ke jaringan perkhidmatan yang menyediakan sambungan antara mereka (berwarna biru).