Ini mungkin artikel terperinci terbaik tentang seni bina perkhidmatan mikro yang pernah anda baca.

Artikel ini akan memperkenalkan seni bina perkhidmatan mikro dan komponen yang berkaitan, memperkenalkan apa itu dan sebab untuk menggunakan seni bina perkhidmatan mikro dan komponen ini. Artikel ini memfokuskan pada menyatakan secara ringkas gambaran keseluruhan seni bina perkhidmatan mikro, jadi ia tidak akan menerangkan secara terperinci seperti cara menggunakan komponen.

Untuk memahami perkhidmatan mikro, anda mesti terlebih dahulu memahami perkhidmatan mikro yang bukan perkhidmatan mikro. Biasanya bertentangan dengan perkhidmatan mikro ialah aplikasi monolitik, iaitu aplikasi yang membungkus semua fungsi ke dalam unit bebas. Beralih daripada aplikasi monolitik kepada perkhidmatan mikro tidak berlaku dalam sekelip mata. Ia adalah proses evolusi yang beransur-ansur. Artikel ini akan mengambil aplikasi pasar raya dalam talian sebagai contoh untuk menggambarkan proses ini.

Permintaan awal

Beberapa tahun lalu, Xiao Ming dan Xiao Pi memulakan perniagaan bersama sebagai pasar raya dalam talian. Xiao Ming bertanggungjawab untuk pembangunan program, dan Xiao Pi bertanggungjawab untuk perkara lain. Pada masa itu, Internet masih belum dibangunkan, dan pasar raya dalam talian masih lautan biru. Selagi fungsi itu dilaksanakan, anda boleh membuat wang sesuka hati. Jadi keperluan mereka sangat mudah Mereka hanya memerlukan tapak web di rangkaian awam di mana pengguna boleh menyemak imbas dan membeli produk Mereka juga memerlukan bahagian belakang pengurusan yang boleh mengurus produk, pengguna dan data pesanan.

Mari kita susun senarai fungsi:

• Laman web
• Pendaftaran pengguna dan fungsi log masuk
• Paparan produk
• Latar belakang pengurusan
• Pengurusan Pengguna
• Pengurusan Produk
• Pengurusan Pesanan

Disebabkan keperluan yang mudah, Xiao Ming hanya menggerakkan tangan kiri dan kanannya dalam gerakan perlahan, dan laman web telah sedia. Atas sebab keselamatan, bahagian belakang pengurusan tidak terletak bersama tapak web tangan kanan dan kiri Xiao Ming dimainkan semula dalam gerakan perlahan, dan tapak web pengurusan sudah sedia. Gambar rajah seni bina keseluruhan adalah seperti berikut: 🎜

Xiao Ming melambai tangannya, menemui perkhidmatan awan untuk digunakan dan tapak web itu dalam talian. Selepas dilancarkan dalam talian, ia menerima ulasan yang memberangsangkan dan sangat digemari oleh semua jenis rumah gemuk. Xiao Ming dan Xiao Pi dengan gembira mula berbaring dan mengutip wang itu.

Dengan perkembangan perniagaan...

Masa-masa indah itu tidak bertahan lama Dalam masa beberapa hari, pelbagai pasar raya dalam talian bermunculan, menyebabkan impak yang kuat kepada Xiao Ming Xiaopi.

Di bawah tekanan persaingan, Xiao Ming Xiaopi memutuskan untuk menjalankan beberapa kaedah pemasaran:

• Menjalankan aktiviti promosi. Contohnya, diskaun Hari Tahun Baru di seluruh tapak, Festival Musim Bunga beli dua percuma satu, kupon makanan anjing Hari Valentine, dsb.
• Kembangkan saluran dan tambah pemasaran mudah alih. Selain tapak web, anda juga perlu membangunkan APP mudah alih, applet WeChat, dsb.
• Pemasaran ketepatan. Gunakan data sejarah untuk menganalisis pengguna dan menyediakan perkhidmatan yang diperibadikan.
• ……

Aktiviti ini memerlukan sokongan pembangunan program. Xiao Ming mengikat rakan sekelasnya Xiao Hong untuk menyertai pasukan itu. Xiaohong bertanggungjawab untuk analisis data dan pembangunan berkaitan terminal mudah alih. Xiao Ming bertanggungjawab untuk pembangunan fungsi yang berkaitan dengan aktiviti promosi.

Oleh kerana tugas pembangunan agak mendesak, Xiao Ming dan Xiao Hong tidak merancang seni bina keseluruhan sistem dengan betul Dia hanya menepuk kepalanya dan memutuskan untuk meletakkan pengurusan promosi dan analisis data dalam latar belakang pengurusan, dan WeChat dan APP mudah alih. dibina secara berasingan. Selepas bekerja sepanjang malam selama beberapa hari, fungsi baharu dan aplikasi baharu pada dasarnya selesai. Gambar rajah seni bina pada masa ini adalah seperti berikut:

Terdapat banyak perkara yang tidak munasabah pada peringkat ini:

• Tapak web dan aplikasi mudah alih mempunyai banyak kod pendua dengan logik perniagaan yang sama.
• Data kadangkala dikongsi melalui pangkalan data, dan kadangkala dihantar melalui panggilan antara muka. Hubungan panggilan antara muka tidak kemas.
• Untuk menyediakan antara muka untuk aplikasi lain, satu aplikasi secara beransur-ansur berubah semakin banyak, termasuk banyak logik yang bukan miliknya pada mulanya. Sempadan aplikasi menjadi kabur dan atribusi fungsi mengelirukan.
• Bahagian belakang pengurusan pada mulanya direka bentuk dengan tahap keselamatan yang rendah. Selepas menambah fungsi yang berkaitan dengan analisis data dan pengurusan promosi, kesesakan prestasi muncul, menjejaskan aplikasi lain.
• Struktur jadual pangkalan data bergantung pada berbilang aplikasi dan tidak boleh dibina semula dan dioptimumkan.
• Semua aplikasi beroperasi pada pangkalan data, dan terdapat kesesakan prestasi dalam pangkalan data. Terutama apabila analisis data sedang berjalan, prestasi pangkalan data menurun secara mendadak.
• Pembangunan, ujian, penggunaan dan penyelenggaraan menjadi semakin sukar. Walaupun hanya ciri kecil yang diubah, keseluruhan aplikasi perlu dikeluarkan bersama. Kadangkala beberapa kod yang belum diuji dimasukkan secara tidak sengaja dalam sidang akhbar, atau selepas mengubah suai fungsi, satu lagi ralat yang tidak dijangka berlaku. Untuk mengurangkan kesan masalah yang mungkin disebabkan oleh pelepasan dan kesan penggantungan perniagaan dalam talian, semua permohonan mesti dikeluarkan pada pukul tiga atau empat pagi. Selepas dikeluarkan, untuk mengesahkan bahawa aplikasi berjalan seperti biasa, kami perlu memerhatikan tempoh pengguna puncak pada keesokan harinya...
• Terdapat fenomena tolak dan tarik di kalangan pasukan . Selalunya terdapat perdebatan panjang tentang aplikasi yang mana beberapa fungsi awam harus dibina, dan pada akhirnya sama ada mereka hanya melakukan perkara mereka sendiri, atau mereka hanya meletakkannya di tempat rawak tanpa mengekalkannya.

Walaupun terdapat banyak masalah, kami tidak boleh menafikan keputusan peringkat ini: sistem dibina dengan cepat mengikut perubahan perniagaan. Walau bagaimanapun, tugas yang mendesak dan berat dengan mudah boleh menyebabkan orang ramai terjerumus ke dalam pemikiran separa dan jangka pendek serta membuat keputusan berkompromi. Dalam struktur jenis ini, semua orang hanya menumpukan pada satu pertiga ekar mereka sendiri, tidak mempunyai reka bentuk keseluruhan dan jangka panjang. Jika keadaan berterusan seperti ini, pembinaan sistem akan menjadi semakin sukar, malah mungkin jatuh ke dalam kitaran penggulingan dan pembinaan semula yang berterusan.

Sudah tiba masanya untuk membuat perubahan

Nasib baik, Xiao Ming dan Xiao Hong adalah anak muda yang baik dengan usaha dan cita-cita. Selepas menyedari masalah itu, Xiao Ming dan Xiao Hong membebaskan sedikit tenaga daripada keperluan perniagaan yang remeh, mula menyusun struktur keseluruhan, dan bersedia untuk mengubah masalah itu.

Untuk melakukan transformasi, anda perlu mempunyai tenaga dan sumber yang mencukupi. Jika bahagian permintaan anda (kakitangan perniagaan, pengurus projek, bos, dll.) begitu kuat dalam mengejar kemajuan permintaan sehingga anda tidak dapat memperuntukkan tenaga dan sumber tambahan, maka anda mungkin tidak dapat melakukan apa-apa...

Dalam dunia pengaturcaraan, perkara yang paling penting ialah keupayaan abstrak. Proses transformasi perkhidmatan mikro sebenarnya adalah proses abstrak. Xiao Ming dan Xiao Hong menganjurkan logik perniagaan pasar raya dalam talian, mengabstrakkan keupayaan perniagaan biasa, dan membuat beberapa perkhidmatan awam:

• Perkhidmatan Pengguna
• Perkhidmatan Komoditi
• Perkhidmatan Promosi
• Perkhidmatan Promosi
• Perkhidmatan analisis data

Setiap bahagian belakang aplikasi hanya perlu mendapatkan data yang diperlukan daripada perkhidmatan ini, dengan itu memadamkan sejumlah besar kod berlebihan, hanya meninggalkan lapisan kawalan nipis dan bahagian hadapan. Seni bina peringkat ini adalah seperti berikut:

Peringkat ini hanya memisahkan perkhidmatan, dan pangkalan data masih dikongsi, jadi beberapa kelemahan sistem cerobong masih wujud:

1. Pangkalan data menjadi hambatan prestasi, dan terdapat satu titik Risiko kegagalan.
2. Pengurusan data cenderung menjadi huru-hara. Walaupun terdapat reka bentuk modular yang baik pada permulaannya, seiring dengan berlalunya masa, akan sentiasa ada fenomena di mana satu perkhidmatan mengambil data perkhidmatan lain terus dari pangkalan data.
3. Struktur jadual pangkalan data mungkin bergantung pada pelbagai perkhidmatan, yang mempengaruhi keseluruhan sistem dan sukar untuk dilaraskan.

Jika anda mengekalkan model pangkalan data yang dikongsi, keseluruhan seni bina akan menjadi lebih dan lebih tegar dan kehilangan makna seni bina perkhidmatan mikro. Oleh itu, Xiao Ming dan Xiao Hong bekerjasama untuk memisahkan pangkalan data. Semua lapisan kegigihan diasingkan antara satu sama lain dan menjadi tanggungjawab setiap perkhidmatan. Di samping itu, untuk meningkatkan prestasi masa nyata sistem, mekanisme baris gilir mesej ditambah. Seni bina adalah seperti berikut:

Selepas pemisahan lengkap, setiap perkhidmatan boleh menggunakan teknologi heterogen. Sebagai contoh, perkhidmatan analisis data boleh menggunakan gudang data sebagai lapisan kegigihan untuk melakukan beberapa pengiraan statistik dengan cekap dan perkhidmatan promosi diakses dengan lebih kerap, jadi mekanisme caching ditambah.

Satu lagi cara untuk mengabstrak logik awam ialah menjadikan logik awam ini menjadi perpustakaan rangka kerja awam. Kaedah ini boleh mengurangkan kehilangan prestasi panggilan perkhidmatan. Walau bagaimanapun, kos pengurusan kaedah ini sangat tinggi, dan sukar untuk memastikan konsistensi semua versi aplikasi.

Pecahan pangkalan data juga mempunyai beberapa masalah dan cabaran: seperti keperluan untuk melata pangkalan data silang, butiran pertanyaan data melalui perkhidmatan, dsb. Tetapi masalah ini boleh diselesaikan melalui reka bentuk yang munasabah. Secara keseluruhan, pemisahan pangkalan data mempunyai lebih banyak kebaikan daripada keburukan.

Seni bina perkhidmatan mikro juga mempunyai faedah bukan teknikal Ia menjadikan pembahagian kerja dalam keseluruhan sistem lebih jelas dan tanggungjawab semua orang berdedikasi untuk menyediakan perkhidmatan yang lebih baik kepada orang lain. Dalam era aplikasi monolitik, fungsi perniagaan awam selalunya tidak mempunyai pemilikan yang jelas. Pada akhirnya, sama ada setiap orang melakukan perkara mereka sendiri dan semua orang melaksanakannya semula; atau orang rawak (biasanya orang yang lebih berkebolehan atau bersemangat) melaksanakan aplikasi yang dia bertanggungjawab. Dalam kes kedua, selain bertanggungjawab untuk permohonannya sendiri, orang ini juga bertanggungjawab untuk menyediakan fungsi awam ini kepada orang lain - dan fungsi ini pada asalnya tidak bertanggungjawab untuk sesiapa sahaja, hanya kerana dia lebih berkebolehan/bersemangat menyalahkan (keadaan ini juga secara eufemisme dipanggil "yang mampu melakukan kerja keras"). Akhirnya, tiada siapa yang sanggup menyediakan majlis awam. Dari masa ke masa, orang dalam pasukan secara beransur-ansur menjadi bebas dan tidak lagi mengambil berat tentang reka bentuk seni bina keseluruhan. Ikuti akaun rasmi Java Journey untuk menerima e-book.

Dari perspektif ini, menggunakan seni bina perkhidmatan mikro juga memerlukan pelarasan yang sepadan dengan struktur organisasi. Oleh itu, transformasi perkhidmatan mikro memerlukan sokongan pengurus.

Selepas transformasi selesai, Xiao Ming dan Xiao Hong jelas membahagikan peranan masing-masing. Mereka berdua sangat berpuas hati, semuanya cantik dan sempurna seperti persamaan Maxwell.

Namun...

Tiada peluru perak

Musim bunga sudah tiba, semuanya kembali hidup, dan ia adalah karnival beli-belah tahunan sekali lagi. Melihat bilangan pesanan harian yang semakin meningkat, Xiaopi, Xiaoming dan Xiaohong tersenyum gembira. Malangnya, masa yang baik itu tidak bertahan lama.

Pada masa lalu, untuk aplikasi tunggal, penyelesaian masalah biasanya melibatkan melihat log, mengkaji mesej ralat dan susunan panggilan. Dalam seni bina perkhidmatan mikro, keseluruhan aplikasi disebarkan kepada berbilang perkhidmatan, menjadikannya sangat sukar untuk mengesan titik kerosakan. Xiao Ming menyemak log satu per satu dan memanggil setiap perkhidmatan secara manual satu per satu. Selepas lebih sepuluh minit mencari, Xiao Ming akhirnya menemui titik kesalahan: perkhidmatan promosi berhenti bertindak balas kerana banyak permintaan yang diterima. Perkhidmatan lain secara langsung atau tidak langsung memanggil perkhidmatan promosi, jadi mereka juga turun. Dalam seni bina perkhidmatan mikro, kegagalan perkhidmatan mungkin mempunyai kesan runtuhan salji, menyebabkan keseluruhan sistem gagal. Malah, sebelum cuti, Xiao Ming dan Xiao Hong menjalankan penilaian jumlah permintaan. Seperti yang dijangkakan, sumber pelayan mencukupi untuk menyokong volum permintaan cuti, jadi mesti ada sesuatu yang tidak kena. Walau bagaimanapun, keadaan itu mendesak Setiap minit dan setiap detik yang berlalu adalah membazirkan wang, jadi Xiao Ming tidak mempunyai masa untuk menyelesaikan masalah itu dengan segera membuat keputusan untuk mencipta beberapa mesin maya baharu, dan kemudian menggunakan perkhidmatan promosi baharu oleh satu nod. Selepas beberapa minit beroperasi, sistem akhirnya kembali normal. Dianggarkan ratusan ribu jualan hilang sepanjang keseluruhan gangguan itu, dan hati mereka bertiga berdarah...

Selepas itu, Xiao Ming hanya menulis alat analisis log (volumenya sangat besar sehingga hampir mustahil untuk membukanya dengan editor teks dan tidak dapat dilihat dengan mata kasar), mengira log akses perkhidmatan promosi, dan mendapati bahawa semasa kegagalan, perkhidmatan produk adalah Terdapat isu kod Dalam beberapa senario, sejumlah besar permintaan akan dibuat kepada perkhidmatan promosi. Masalah ini tidak rumit Xiao Ming membetulkan pepijat yang bernilai ratusan ribu dengan satu jentikan jarinya.

Masalah telah selesai, tetapi tiada siapa yang boleh menjamin bahawa masalah lain yang serupa tidak akan berulang. Walaupun seni bina perkhidmatan mikro kelihatan sempurna dalam reka bentuk logik, ia adalah seperti istana yang cantik dibina daripada blok bangunan dan tidak dapat menahan angin dan ombak. Walaupun seni bina perkhidmatan mikro menyelesaikan masalah lama, ia juga memperkenalkan masalah baharu:

• Keseluruhan aplikasi seni bina perkhidmatan mikro tersebar ke dalam berbilang perkhidmatan, dan sangat sukar untuk mengesan titik kerosakan.
• Kestabilan menurun. Apabila bilangan perkhidmatan bertambah, kebarangkalian satu kegagalan perkhidmatan meningkat, dan kegagalan perkhidmatan boleh menyebabkan keseluruhan sistem ditutup. Malah, dalam senario pengeluaran dengan volum akses yang besar, kegagalan akan sentiasa berlaku.
• Bilangan perkhidmatan adalah sangat besar, dan beban kerja penempatan dan pengurusan adalah besar.
• Pembangunan: Bagaimana untuk memastikan pelbagai perkhidmatan masih mengekalkan sinergi dalam pembangunan berterusan.
• Pengujian: Selepas perkhidmatan dibahagikan, hampir semua fungsi akan melibatkan pelbagai perkhidmatan. Ujian asal program tunggal menjadi ujian panggilan antara perkhidmatan. Ujian menjadi lebih kompleks.

Xiao Ming dan Xiao Hong belajar daripada pengalaman dan berazam untuk menyelesaikan masalah ini. Penyelesaian masalah secara amnya melibatkan dua aspek: dalam satu pihak, kami cuba mengurangkan kebarangkalian kegagalan, dan sebaliknya, kami mengurangkan kesan kegagalan.

Pemantauan - Temui tanda-tanda kegagalan

Dalam senario pengedaran konkurensi tinggi, kegagalan sering berlaku secara tiba-tiba seperti runtuhan salji. Oleh itu, sistem pemantauan yang lengkap mesti diwujudkan untuk mengesan tanda-tanda kegagalan sebanyak mungkin.

Terdapat banyak komponen dalam seni bina perkhidmatan mikro, dan setiap komponen perlu memantau penunjuk yang berbeza. Sebagai contoh, cache Redis secara amnya memantau nilai yang diduduki memori dan trafik rangkaian, pangkalan data memantau bilangan sambungan dan ruang cakera, dan perkhidmatan perniagaan memantau bilangan konkurensi, kelewatan respons, kadar ralat, dsb. Oleh itu, adalah tidak realistik untuk membina sistem pemantauan yang besar dan komprehensif untuk memantau setiap komponen, dan skalabiliti akan menjadi sangat lemah. Pendekatan umum adalah untuk membenarkan setiap komponen menyediakan antara muka (antara muka metrik) untuk melaporkan status semasanya Output format data oleh antara muka ini harus konsisten. Kemudian gunakan komponen pengumpul penunjuk untuk mendapatkan dan mengekalkan status komponen secara kerap daripada antara muka ini, sambil menyediakan perkhidmatan pertanyaan. Akhir sekali, UI diperlukan untuk menanyakan pelbagai penunjuk daripada pengumpul penunjuk, melukis antara muka pemantauan atau mengeluarkan penggera berdasarkan ambang.

Kebanyakan komponen tidak perlu dibangunkan sendiri, terdapat komponen sumber terbuka di Internet. Xiao Ming memuat turun RedisExporter dan MySQLExporter Kedua-dua komponen ini menyediakan antara muka penunjuk untuk cache Redis dan pangkalan data MySQL. Microservices melaksanakan antara muka penunjuk tersuai berdasarkan logik perniagaan setiap perkhidmatan. Kemudian Xiao Ming menggunakan Prometheus sebagai pengumpul penunjuk, dan Grafana mengkonfigurasi antara muka pemantauan dan makluman e-mel. Sistem pemantauan perkhidmatan mikro sedemikian dibina:

Masalah lokasi - penjejakan pautan

Di bawah seni bina perkhidmatan mikro, permintaan pengguna selalunya melibatkan beberapa panggilan perkhidmatan dalaman. Untuk memudahkan pencarian masalah, adalah perlu untuk dapat merekodkan bilangan panggilan perkhidmatan yang dijana dalam perkhidmatan mikro apabila setiap pengguna memintanya, dan perhubungan panggilan mereka. Ini dipanggil penjejakan pautan.

Kami menggunakan contoh penjejakan pautan dalam dokumen Istio untuk melihat kesan:

Gambar berasal dari dokumen Istio

Seperti yang anda lihat dari gambar, ini adalah permintaan untuk pengguna untuk mengakses halaman halaman produk. Semasa proses permintaan, perkhidmatan halaman produk secara berurutan memanggil antara muka butiran dan perkhidmatan ulasan. Perkhidmatan ulasan memanggil antara muka penilaian semasa proses respons. Rekod keseluruhan penjejakan pautan ialah pokok:

Untuk melaksanakan penjejakan pautan, setiap panggilan perkhidmatan akan merekodkan sekurang-kurangnya empat keping data dalam HTTP HEADERS:

• traceId: traceId mengenal pasti pengguna Yang diminta pautan. Panggilan dengan traceId yang sama tergolong dalam pautan yang sama.
• spanId: ID yang mengenal pasti panggilan perkhidmatan, iaitu ID nod penjejakan pautan.
• parentId: spanId nod induk.
• requestMasa & responsMasa: masa permintaan dan masa respons.

Selain itu, anda juga perlu memanggil komponen untuk pengumpulan dan penyimpanan log, serta komponen UI untuk memaparkan panggilan pautan.

Di atas hanyalah penjelasan minimalis Asas teori untuk penjejakan pautan boleh didapati dalam Dapper Google

Setelah memahami asas teori, Xiao Ming memilih Zipkin, pelaksanaan sumber terbuka Dapper. Kemudian dengan jentikan jarinya, saya menulis pemintas permintaan HTTP, menjana data ini dan menyuntiknya ke dalam HEADERS untuk setiap permintaan HTTP, dan pada masa yang sama menghantar log panggilan secara tidak segerak kepada pengumpul log Zipkin. Sebutan tambahan di sini ialah pemintas permintaan HTTP boleh dilaksanakan dalam kod perkhidmatan mikro, atau ia boleh dilaksanakan menggunakan komponen proksi rangkaian (tetapi dalam kes ini, setiap perkhidmatan mikro perlu menambah lapisan proksi).

Penjejakan pautan hanya boleh mengesan perkhidmatan yang bermasalah dan tidak dapat memberikan maklumat ralat tertentu. Keupayaan untuk mencari maklumat ralat khusus perlu disediakan oleh komponen analisis log.

Masalah Analisis - Analisis Log

Komponen analisis log sepatutnya digunakan secara meluas sebelum kebangkitan perkhidmatan mikro. Walaupun dengan seni bina aplikasi tunggal, apabila bilangan capaian meningkat atau saiz pelayan bertambah, saiz fail log akan berkembang ke tahap yang sukar untuk diakses dengan penyunting teks bertaburan di beberapa pelayan. Untuk menyelesaikan masalah, anda perlu log masuk ke setiap pelayan untuk mendapatkan fail log, dan mencari maklumat log yang dikehendaki satu persatu (dan membuka dan mencari adalah sangat perlahan).

Oleh itu, apabila skala aplikasi menjadi lebih besar, kita memerlukan log "Search Engine". Supaya anda boleh mencari log yang anda mahukan dengan tepat. Selain itu, bahagian sumber data juga memerlukan komponen untuk mengumpul log dan komponen UI untuk memaparkan hasil:

Xiao Ming menyiasat dan menggunakan komponen analisis log ELK yang terkenal. ELK ialah singkatan daripada tiga komponen: Elasticsearch, Logstash dan Kibana.

• Elasticsearch: enjin carian dan storan log.
• Logstash: Pengumpul log, yang menerima input log, melakukan beberapa prapemprosesan pada log, dan kemudian mengeluarkannya kepada Elasticsearch.
• Kibana: Komponen UI, mencari data melalui Elasticsearch API dan memaparkannya kepada pengguna.

Soalan kecil terakhir ialah bagaimana untuk menghantar log ke Logstash. Satu penyelesaian adalah dengan menghubungi terus antara muka Logstash untuk menghantar log apabila mengeluarkan log. Dengan cara ini, kod itu perlu diubah suai sekali lagi (Hei, mengapa menggunakan "dan")... Jadi Xiao Ming memilih penyelesaian lain: log masih dikeluarkan kepada fail, dan Ejen digunakan dalam setiap perkhidmatan untuk mengimbas log fail dan kemudian keluarkannya ke Logstash .

Iklan Rehat: Ikuti akaun awam: Panduan Belajar Java untuk mendapatkan lebih banyak artikel teknikal.

Gerbang - kawalan kebenaran, tadbir urus perkhidmatan

Selepas berpecah kepada perkhidmatan mikro, sejumlah besar perkhidmatan dan antara muka muncul, menjadikan keseluruhan perhubungan panggilan tidak kemas. Selalunya semasa proses pembangunan, semasa menulis dan menulis, saya tiba-tiba tidak ingat perkhidmatan mana yang perlu dipanggil untuk data tertentu. Atau ia ditulis secara bengkok, memanggil perkhidmatan yang tidak sepatutnya dipanggil, dan fungsi baca sahaja akhirnya mengubah suai data...

Untuk menangani situasi ini, panggilan perkhidmatan mikro memerlukan penyemak, iaitu , pintu masuk. Tambahkan lapisan get laluan antara pemanggil dan penerima, dan lakukan pengesahan kebenaran setiap kali ia dipanggil. Selain itu, gerbang juga boleh digunakan sebagai platform untuk menyediakan dokumen antara muka perkhidmatan.

Satu masalah dengan menggunakan get laluan adalah untuk menentukan bagaimana ia harus digunakan: penyelesaian berbutir paling kasar ialah pintu masuk untuk keseluruhan perkhidmatan mikro Bahagian luar perkhidmatan mikro mengakses perkhidmatan mikro melalui get laluan dan bahagian dalam panggilan perkhidmatan mikro secara langsung; butiran terbaik ialah semua Panggilan, sama ada dalaman kepada perkhidmatan mikro atau dari luar, mesti melalui get laluan. Penyelesaian kompromi adalah dengan membahagikan perkhidmatan mikro kepada beberapa kawasan mengikut kawasan perniagaan, memanggilnya terus dalam kawasan tersebut dan memanggilnya melalui pintu masuk.

Memandangkan bilangan perkhidmatan di seluruh pasar raya dalam talian tidak begitu besar, Xiao Ming menggunakan penyelesaian berbutir paling kasar:

Pendaftaran dan Penemuan Perkhidmatan - Pengembangan Dinamik

semuanya direka untuk komponen sebelumnya

mengurangkan Kemungkinan kegagalan. Namun, kegagalan akan sentiasa berlaku, jadi satu lagi aspek yang perlu dikaji ialah bagaimana untuk mengurangkan kesan kegagalan.

Strategi pengendalian kerosakan yang paling kasar (dan paling biasa digunakan) ialah redundansi. Secara umumnya, perkhidmatan akan menggunakan berbilang kejadian, supaya ia boleh berkongsi tekanan dan meningkatkan prestasi, dan kedua, walaupun satu kejadian gagal, kejadian lain masih boleh bertindak balas.

Satu masalah redundansi ialah berapa banyak redundansi digunakan? Tiada jawapan yang pasti untuk soalan ini pada garis masa. Bergantung pada fungsi perkhidmatan dan tempoh masa, bilangan kejadian yang berbeza diperlukan. Contohnya, pada hari bekerja, 4 kejadian mungkin mencukupi semasa promosi, apabila trafik meningkat dengan ketara, 40 kejadian mungkin diperlukan. Oleh itu, jumlah lebihan bukan nilai tetap, tetapi boleh dilaraskan dalam masa nyata mengikut keperluan. Secara amnya, operasi menambah tika baharu ialah:

Kerahkan tika baharu
Daftarkan tika baharu ke pengimbangan beban atau DNS
2. Operasi itu hanya dua langkah, jika anda hanya dua langkah daftar ke pengimbangan beban atau DNS Jika operasi adalah manual, maka perkara tidak akan mudah. Fikirkan tentang perasaan perlu memasukkan 40 IP secara manual selepas menambah 40 kejadian...

Penyelesaian kepada masalah ini ialah pendaftaran dan penemuan perkhidmatan automatik. Pertama, anda perlu menggunakan perkhidmatan penemuan perkhidmatan yang menyediakan maklumat alamat untuk semua perkhidmatan berdaftar. DNS juga boleh dianggap sebagai perkhidmatan penemuan perkhidmatan. Kemudian setiap perkhidmatan aplikasi secara automatik mendaftar sendiri dengan perkhidmatan penemuan perkhidmatan apabila ia bermula. Dan selepas perkhidmatan aplikasi dimulakan, senarai alamat setiap perkhidmatan aplikasi akan disegerakkan daripada perkhidmatan penemuan perkhidmatan kepada tempatan dalam masa nyata (secara kerap). Perkhidmatan penemuan perkhidmatan juga akan sentiasa menyemak status kesihatan perkhidmatan aplikasi dan mengalih keluar alamat contoh yang tidak sihat. Dengan cara ini, apabila menambah tika, anda hanya perlu menggunakan tika baharu Apabila tika pergi ke luar talian, anda boleh mematikan perkhidmatan secara automatik akan menyemak peningkatan atau penurunan kejadian.

Penemuan perkhidmatan juga akan digunakan bersama-sama dengan pengimbangan beban pelanggan. Memandangkan perkhidmatan aplikasi telah menyegerakkan senarai alamat perkhidmatan secara setempat, anda boleh memutuskan sendiri strategi pemuatan apabila mengakses perkhidmatan mikro. Anda juga boleh menambah beberapa metadata (versi perkhidmatan dan maklumat lain) semasa mendaftarkan perkhidmatan dan beban pelanggan akan melaksanakan kawalan trafik berdasarkan metadata ini untuk melaksanakan fungsi seperti ujian A/B dan penerbitan biru-hijau.

Terdapat banyak komponen untuk dipilih untuk penemuan perkhidmatan, seperti Zookeeper, Eureka, Consul, Etcd, dll. Walau bagaimanapun, Xiao Ming merasakan bahawa dia cukup bagus dan ingin menunjukkan kemahirannya, jadi dia menulis satu berdasarkan Redis...

Litar, kemerosotan perkhidmatan, pengehadan semasa

Litar

Apabila perkhidmatan berhenti bertindak balas atas pelbagai sebab, pemanggil biasanya menunggu untuk tempoh masa, dan kemudian tamat masa atau menerima pemulangan ralat. Jika pautan panggilan agak panjang, permintaan mungkin terkumpul dan keseluruhan pautan mengambil banyak sumber dan menunggu respons hiliran. Oleh itu, apabila mengakses perkhidmatan beberapa kali gagal, pemutus litar harus rosak, menandakan perkhidmatan itu telah berhenti berfungsi, dan mengembalikan ralat secara langsung. Tunggu sehingga perkhidmatan kembali normal sebelum mewujudkan semula sambungan. . tidak terganggu. Sebagai contoh, antara muka pesanan pasar raya dalam talian mempunyai fungsi untuk mengumpul pesanan untuk produk yang disyorkan Apabila modul pengesyoran tidak berfungsi, fungsi pesanan tidak boleh turun pada masa yang sama Anda hanya perlu mematikan fungsi pengesyoran buat sementara waktu.

Penghadan Semasa

Selepas perkhidmatan dimatikan, perkhidmatan huluan atau pengguna biasanya akan mencuba semula akses secara lazim. Ini bermakna sebaik sahaja perkhidmatan kembali normal, ia berkemungkinan akan menutup sambungan serta-merta disebabkan oleh trafik rangkaian yang berlebihan dan mengulangi sit-up dalam keranda. Oleh itu perkhidmatan itu perlu dapat melindungi dirinya sendiri - mengehadkan trafik. Terdapat banyak strategi pengehadan semasa yang paling mudah ialah membuang lebihan permintaan apabila terdapat terlalu banyak permintaan setiap unit masa. Di samping itu, pengehadan arus partition juga boleh dipertimbangkan. Hanya tolak permintaan daripada perkhidmatan yang menjana sejumlah besar permintaan. Sebagai contoh, kedua-dua perkhidmatan produk dan perkhidmatan pesanan perlu mengakses perkhidmatan promosi Perkhidmatan produk memulakan sejumlah besar permintaan kerana masalah kod Perkhidmatan promosi hanya mengehadkan permintaan daripada perkhidmatan produk dan permintaan daripada perkhidmatan pesanan bertindak balas biasalah.

Pengujian

Di bawah seni bina perkhidmatan mikro, ujian dibahagikan kepada tiga peringkat:

1. Pengujian hujung ke hujung: meliputi keseluruhan sistem, biasanya menguji model antara muka pengguna.
2. Ujian perkhidmatan: Uji antara muka perkhidmatan.
3. Ujian unit: Unit kod ujian.

Kemudahan pelaksanaan tiga ujian meningkat dari atas ke bawah, tetapi kesan ujian berkurangan. Ujian hujung ke hujung adalah yang paling memakan masa dan intensif buruh, tetapi selepas lulus ujian kami mempunyai keyakinan yang paling tinggi terhadap sistem. Ujian unit adalah yang paling mudah untuk dilaksanakan dan paling cekap, tetapi tidak ada jaminan bahawa keseluruhan sistem akan bebas masalah selepas ujian.

Disebabkan kesukaran dalam melaksanakan ujian hujung ke hujung, ujian hujung ke hujung biasanya hanya dilakukan pada fungsi teras. Sebaik sahaja ujian hujung ke hujung gagal, ia perlu dipecahkan kepada ujian unit: kemudian sebab kegagalan dianalisis, dan kemudian ujian unit ditulis untuk menghasilkan semula masalah supaya kita dapat menangkap ralat yang sama dengan lebih cepat dalam masa hadapan.

Kesukaran ujian perkhidmatan ialah perkhidmatan sering bergantung pada beberapa perkhidmatan lain. Masalah ini boleh diselesaikan melalui Mock Server:

Semua orang sudah biasa dengan ujian unit. Kami biasanya menulis sejumlah besar ujian unit (termasuk ujian regresi) untuk cuba merangkumi semua kod.

Rangka kerja Mikroperkhidmatan . Ia akan sangat memakan masa dan intensif buruh untuk melaksanakan setiap perkhidmatan aplikasi dengan sendirinya. Berdasarkan prinsip DRY, Xiao Ming membangunkan rangka kerja mikroperkhidmatan, mengekstrak kod yang antara muka dengan setiap komponen dan kod awam lain ke dalam rangka kerja, dan semua perkhidmatan aplikasi dibangunkan menggunakan rangka kerja ini.

Banyak fungsi tersuai boleh dicapai menggunakan rangka kerja perkhidmatan mikro. Anda juga boleh menyuntik maklumat tindanan panggilan program ke dalam penjejakan pautan untuk mencapai penjejakan pautan peringkat kod. Atau keluarkan maklumat status kumpulan benang dan kumpulan sambungan, dan pantau status asas perkhidmatan dalam masa nyata.

Terdapat masalah serius dengan menggunakan rangka kerja mikroperkhidmatan bersatu: kos mengemas kini rangka kerja adalah sangat tinggi. Setiap kali rangka kerja dinaik taraf, semua perkhidmatan aplikasi perlu bekerjasama dengan peningkatan. Sudah tentu, penyelesaian keserasian biasanya digunakan, meninggalkan tempoh masa selari untuk menunggu semua perkhidmatan aplikasi dinaik taraf. Walau bagaimanapun, jika terdapat banyak perkhidmatan aplikasi, masa naik taraf mungkin sangat lama. Dan terdapat beberapa perkhidmatan aplikasi yang sangat stabil yang jarang dikemas kini, dan orang yang bertanggungjawab mungkin menolak untuk menaik taraf... Oleh itu, menggunakan rangka kerja mikroperkhidmatan bersatu memerlukan kaedah pengurusan versi lengkap dan spesifikasi pengurusan pembangunan.

Cara lain - Service Mesh

Cara lain untuk mengabstrak kod biasa ialah mengabstrak kod ini terus ke dalam komponen proksi terbalik. Setiap perkhidmatan juga menggunakan komponen proksi ini, dan semua trafik keluar dan masuk diproses dan dimajukan melalui komponen ini. Komponen ini dipanggil Sidecar.

Sidecar tidak akan menanggung kos rangkaian tambahan. Sidecar akan digunakan pada hos yang sama dengan nod perkhidmatan mikro dan berkongsi kad rangkaian maya yang sama. Oleh itu, komunikasi antara sidecar dan nod perkhidmatan mikro sebenarnya hanya direalisasikan melalui salinan memori.

Gambar daripada: Corak: Service Mesh

Sidecar hanya bertanggungjawab untuk komunikasi rangkaian. Komponen juga diperlukan untuk mengurus konfigurasi semua sidecar secara seragam. Dalam Service Mesh, bahagian yang bertanggungjawab untuk komunikasi rangkaian dipanggil satah data, dan bahagian yang bertanggungjawab untuk pengurusan konfigurasi dipanggil satah kawalan. Satah data dan satah kawalan membentuk seni bina asas Service Mesh. . Ia sering dikritik kerana isu prestasi. Walaupun rangkaian gelung balik tidak menjana permintaan rangkaian sebenar, masih terdapat kos tambahan untuk salinan memori. Di samping itu, beberapa pemprosesan trafik berpusat juga akan menjejaskan prestasi.

Akhirnya juga adalah permulaan

Perkhidmatan mikro bukanlah penamat evolusi seni bina. Melangkah lebih jauh, terdapat Tanpa Pelayan, FaaS dan arah lain. Sebaliknya, ada juga orang yang menyanyi bahawa korus mesti dibahagikan untuk masa yang lama dan mesti disatukan untuk masa yang lama, dan menemui semula seni bina monolitik...

Walau bagaimanapun, transformasi perkhidmatan mikro seni bina telah berakhir buat masa ini. Xiao Ming menepuk kepalanya yang semakin licin dengan kepuasan dan bercadang untuk berehat hujung minggu ini dan bertemu Xiao Hong untuk secawan kopi.

Atas ialah kandungan terperinci Ini mungkin artikel terperinci terbaik tentang seni bina perkhidmatan mikro yang pernah anda baca.. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!