Mereka bentuk aplikasi asli awan melibatkan pengurusan sistem kompleks perkhidmatan mikro dan komponen tanpa pelayan yang perlu berkomunikasi antara satu sama lain dengan cekap. Komunikasi segerak menggunakan panggilan HTTP atau gRPC, menunggu respons dalam julat masa tertentu, memberikan maklum balas masa nyata dan sesuai untuk senario yang memerlukan respons segera. Komunikasi tak segerak menggunakan broker mesej (seperti RabbitMQ atau Kafka) untuk bertukar-tukar mesej tanpa memerlukan respons segera, meningkatkan kebolehskalaan sistem. Dengan memahami kelebihan dan kekurangan setiap mod komunikasi, arkitek boleh mereka sistem yang menyelaraskan elemen bebas ini dengan berkesan untuk menyampaikan aplikasi awan-asli berprestasi tinggi, berskala dan boleh dipercayai.

Bayangkan membina mesin yang kompleks dengan banyak bahagian bebas, masing-masing melaksanakan fungsinya, tetapi semua perlu berkomunikasi secara berkesan antara satu sama lain untuk menyelesaikan tugas. Inilah cabaran yang kami hadapi apabila mereka bentuk aplikasi asli awan yang terdiri daripada perkhidmatan mikro yang saling berkaitan dan komponen tanpa pelayan. Dalam artikel ini, kami meneroka butiran mereka bentuk sistem komunikasi yang teguh dan berdaya tahan yang boleh menyelaraskan elemen bebas ini dengan berkesan di dalam dan di luar sempadan aplikasi.

Perkhidmatan berbutir halus ini menggunakan pelbagai kaedah komunikasi segerak atau tak segerak untuk interaksi dalaman dan luaran. Dalam komunikasi segerak, satu perkhidmatan memanggil perkhidmatan lain menggunakan HTTP atau gRPC, menunggu respons dalam jangka masa yang ditentukan, dan kemudian meneruskan. Sebaliknya, komunikasi tak segerak melibatkan pertukaran mesej tanpa mengharapkan tindak balas segera. Broker mesej seperti RabbitMQ atau Kafka bertindak sebagai perantara, menimbal mesej untuk memastikan penghantaran yang boleh dipercayai. Dalam aplikasi asli awan, menggunakan gabungan corak komunikasi selalunya merupakan pendekatan praktikal. Mari kita mulakan dengan komunikasi segerak.

Apakah komunikasi segerak?

Komunikasi segerak adalah seperti perbualan. Satu perkhidmatan (sebutkan perkhidmatan A) membuat permintaan dan kemudian menunggu respons daripada perkhidmatan lain (perkhidmatan B) atau API luaran. Ini sama seperti bertanya soalan dan menunggu jawapan. Perkhidmatan A menghantar permintaan melalui HTTP dan menunggu. Ia sama ada menunggu respons daripada perkhidmatan B atau menunggu masa menunggu maksimum untuk tamat tempoh. Dalam tempoh menunggu ini, Perkhidmatan A disekat buat sementara waktu, sama seperti seseorang menjeda aktivitinya untuk menunggu respons. Mod ini sering dipanggil mod permintaan-tindak balas dan agak mudah untuk dilaksanakan. Walau bagaimanapun, penggunaannya yang meluas mungkin menimbulkan cabaran yang memerlukan pertimbangan yang teliti.

Cabaran Komunikasi Segerak

Walaupun komunikasi segerak ialah alat yang berkuasa dalam kit alat asal awan kami, ia juga disertakan dengan set cabarannya sendiri yang perlu dipertimbangkan dengan teliti.

Gandingan Temporal

Terlalu bergantung pada komunikasi segerak sepanjang penyelesaian boleh membawa kepada isu gandingan temporal. Ini berlaku apabila sejumlah besar panggilan segerak dirantai bersama, menyebabkan aplikasi klien menunggu lebih lama untuk menerima respons.

Availability Dependencies

Komunikasi segerak memerlukan semua perkhidmatan komunikasi tersedia pada masa yang sama. Jika perkhidmatan bahagian belakang mengalami beban yang tidak dijangka, aplikasi pelanggan mungkin gagal dengan ralat tamat masa, yang menjejaskan prestasi keseluruhan.

Kesan Kualiti Rangkaian

Kualiti rangkaian boleh memberi kesan secara langsung kepada prestasi komunikasi segerak, termasuk lebar jalur yang tersedia dan tempoh yang diperlukan untuk respons melintasi antara perkhidmatan hujung belakang perkhidmatan.

Walaupun menghadapi cabaran ini, komunikasi segerak boleh menjadi tidak ternilai dalam senario tertentu. Mari kita terokai beberapa kes penggunaan yang mana komunikasi segerak mungkin merupakan pilihan yang lebih baik dalam bahagian seterusnya.

Bila menggunakan komunikasi segerak

Dalam sesetengah kes, menggunakan komunikasi segerak mungkin merupakan pilihan yang lebih baik.

Akses data masa nyata atau hasil terjamin

Komunikasi segerak meningkatkan kecekapan apabila maklum balas segera atau masa nyata diperlukan. Sebagai contoh, apabila pelanggan membuat pesanan di tapak web e-dagang, bahagian hadapan e-dagang perlu menyemak sistem inventori untuk memastikan item itu ada dalam stok. Ini adalah operasi segerak kerana aplikasi perlu menunggu maklum balas daripada sistem inventori sebelum ia boleh meneruskan pemprosesan pesanan.

Mengatur urutan tugasan yang berkaitan

Dalam situasi di mana perkhidmatan mesti melaksanakan urutan tugas, masing-masing bergantung pada tugas sebelumnya, komunikasi segerak boleh mengekalkan susunan. Ia amat sesuai untuk aliran kerja yang susunan tugasan adalah kritikal.

Kekalkan Integriti Transaksi

Apabila mengekalkan konsistensi data merentas berbilang komponen adalah kritikal, komunikasi segerak boleh membantu mengekalkan transaksi atom. Ia adalah relevan untuk senario seperti transaksi kewangan yang integriti data adalah kritikal.

Komunikasi segerak ialah alat yang berkuasa, tetapi ia juga datang dengan cabaran. Berita baiknya ialah kami juga mempunyai pilihan komunikasi tak segerak - gaya pelengkap yang boleh berfungsi dengan kaedah segerak. Mari kita terokai ini dengan lebih lanjut dalam bahagian seterusnya.

Apakah komunikasi tak segerak?

Corak komunikasi tak segerak menyediakan kaedah yang dinamik dan cekap untuk komunikasi antara perkhidmatan. Tidak seperti komunikasi segerak, komunikasi tak segerak membenarkan perkhidmatan untuk memulakan permintaan tanpa menunggu respons segera. Dalam model ini, respons mungkin tidak serta-merta atau tiba secara tidak segerak pada saluran yang berasingan (seperti baris gilir panggilan balik). Model komunikasi ini bergantung pada protokol seperti Advanced Message Qeuing Protocol (AMQP) dan middleware pemesejan, termasuk broker mesej atau broker acara.

Perisian tengah pemesejan ini bertindak sebagai perantara dengan logik perniagaan yang minimum. Ia menerima mesej daripada sumber atau perkhidmatan pengeluar dan menyampaikannya kepada perkhidmatan pengguna yang dimaksudkan. Mengintegrasikan perisian tengah pemesejan boleh meningkatkan dengan ketara keanjalan dan toleransi kesalahan pendekatan yang dipisahkan ini. Komunikasi tak segerak merangkumi pelbagai pelaksanaan. Mari kita terokai ini dengan lebih lanjut.

Komunikasi satu dengan satu

Dalam komunikasi mesej satu sama satu, pengeluar menggunakan broker mesej untuk menghantar mesej secara khusus kepada penerima. Biasanya, broker mesej bergantung pada baris gilir untuk memastikan komunikasi yang boleh dipercayai dan menyediakan jaminan penghantaran, seperti sekurang-kurangnya sekali. Pelaksanaannya serupa dengan corak arahan, di mana mesej yang dihantar bertindak sebagai arahan yang digunakan oleh perkhidmatan pelanggan untuk mencetuskan tindakan.

Mari kita pertimbangkan contoh kedai runcit dalam talian untuk menggambarkan penggunaannya. Perniagaan dalam talian bergantung pada kebolehpercayaan tapak webnya. Model ini menyediakan toleransi kesalahan dan jaminan mesej, memastikan bahawa sebaik sahaja pelanggan membuat pesanan di tapak web, sistem pemenuhan bahagian belakang menerima pesanan untuk diproses. Broker mesej mengekalkan mesej walaupun sistem back-end ditutup dan menghantarnya apabila ia boleh diproses. Sebagai contoh, dalam aplikasi e-dagang, apabila pelanggan membuat pesanan, broker mesej boleh digunakan untuk menghantar butiran pesanan sebagai mesej daripada perkhidmatan pesanan (pengeluar) kepada perkhidmatan pemenuhan (pengguna). Ini adalah contoh komunikasi satu dengan satu.

Komunikasi satu sama satu tak segerak dalam awan

Pelanjutan mod mesej satu sama satu ialah mod tindak balas permintaan tak segerak. Dalam kes ini, penghantar menghantar mesej tanpa mengharapkan balasan. Tetapi dalam beberapa senario tertentu, pengguna mesti menggunakan baris gilir dalam baris gilir infrastruktur broker mesej yang sama untuk bertindak balas kepada perkhidmatan pengeluaran. Respons daripada pengguna mungkin mengandungi metadata tambahan, seperti ID yang dikaitkan dengan permintaan awal atau alamat respons. Memandangkan pengeluar tidak mengharapkan respons segera, aliran kerja pengeluar yang berasingan mengurus balasan ini. Sebaik sahaja pesanan dibuat, perkhidmatan pemenuhan (pengguna) bertindak balas kepada perkhidmatan pesanan hadapan (pengeluar) supaya pelanggan boleh mengemas kini di laman web.

Komunikasi balas permintaan satu dengan satu tak segerak dalam awan

Komunikasi pengguna tunggal berguna apabila dua perkhidmatan berkomunikasi dari satu titik ke titik. Walau bagaimanapun, terdapat situasi di mana penerbit mesti menghantar acara tertentu kepada berbilang pelanggan, yang membawa kami kepada corak berikut.

Komunikasi satu-ke-banyak

Kaedah komunikasi ini amat berharga apabila satu komponen (penerbit) perlu menyiarkan acara kepada berbilang komponen dan perkhidmatan (pelanggan). Komunikasi satu-ke-banyak menggunakan konsep topik, serupa dengan forum dalam talian.

Ia seperti forum dalam talian di mana berbilang pengguna boleh menyiarkan artikel yang boleh dibaca oleh pengikut mereka dalam masa mereka sendiri dan bertindak balas mengikut keperluan. Begitu juga, aplikasi boleh mempunyai topik yang boleh ditulis oleh perkhidmatan pengeluar dan boleh dibaca oleh perkhidmatan pengguna. Ia adalah salah satu corak yang paling popular dalam aplikasi dunia sebenar.

Pertimbangkan sekali lagi bahawa platform e-dagang mempunyai perkhidmatan yang mengemas kini harga produk dan pelbagai perkhidmatan memerlukan maklumat ini (seperti perkhidmatan langganan, perkhidmatan pengesyoran, dll.), kemas kini harga boleh dihantar sebagai mesej kepada topik dalam broker mesej . Semua perkhidmatan yang berminat (pelanggan) boleh mendengar topik dan menerima kemas kini harga. Ini adalah contoh komunikasi satu-ke-banyak. Terdapat beberapa alatan yang tersedia untuk melaksanakan corak ini, dengan Apache Kafka, Redis Pub/Sub, Amazon SNS dan Azure Event Grid menjadi antara pilihan yang paling popular.

Komunikasi Satu-ke-Banyak Asynchronous dalam Awan

Cabaran Komunikasi Asynchronous

Walaupun komunikasi tak segerak memberikan banyak faedah, ia juga datang dengan set cabarannya sendiri.

Ketahanan dan Toleransi Kesalahan

Dengan sejumlah besar perkhidmatan mikro dan komponen tanpa pelayan, setiap satu dengan berbilang kejadian, kegagalan tidak dapat dielakkan. Kejadian boleh ranap, menjadi terharu atau mengalami kegagalan sementara. Selain itu, pengirim tidak menunggu mesej diproses, jadi jika ralat berlaku, ia mungkin tidak menyedarinya dengan segera. Kita mesti mengguna pakai strategi berikut:

Cuba semula mekanisme: cuba semula panggilan rangkaian yang gagal untuk kegagalan sementara

Corak pemutus litar: mengelakkan panggilan berulang ke perkhidmatan yang gagal untuk mengelakkan kesesakan sumber

Pengesanan teragih

Segerakan perkhidmatan, komunikasi segerak ini menjadikan pemantauan prestasi sistem secara keseluruhan mencabar. Melaksanakan pengesanan teragih membantu mengikat log dan metrik bersama-sama untuk memahami aliran transaksi.

Nyahpepijat dan Pemantauan Kompleks

Komunikasi tak segerak boleh menjadi lebih sukar untuk nyahpepijat dan dipantau kerana operasi tidak mengikut aliran linear. Alat dan teknik khusus selalunya diperlukan untuk nyahpepijat dan memantau sistem ini dengan berkesan.

Pengurusan Sumber

Sistem tak segerak selalunya melibatkan sambungan jangka panjang dan pemprosesan latar belakang, yang boleh membawa kepada cabaran pengurusan sumber. Penjagaan mesti diambil untuk mengurus sumber dengan cekap untuk mengelakkan kebocoran memori atau penggunaan CPU yang berlebihan.

Memahami cabaran ini boleh membantu mereka bentuk sistem komunikasi tak segerak yang lebih teguh dan berdaya tahan dalam aplikasi asli awan.

Kata Akhir

Pilihan antara mod komunikasi segerak dan tak segerak bukanlah binari tetapi keputusan strategik berdasarkan keperluan khusus aplikasi.

Komunikasi segerak mudah dilaksanakan dan menyediakan maklum balas segera, menjadikannya sesuai untuk akses data masa nyata, mengatur tugas berkaitan dan mengekalkan integriti transaksi. Walau bagaimanapun, ia juga menghadapi cabaran seperti gandingan temporal, pergantungan ketersediaan dan impak kualiti rangkaian.

Sebaliknya, komunikasi tak segerak membolehkan perkhidmatan memulakan permintaan tanpa menunggu respons segera, dengan itu meningkatkan responsif dan kebolehskalaan sistem. Ia memberikan fleksibiliti dan sesuai untuk senario di mana maklum balas segera tidak diperlukan. Walau bagaimanapun, ia membawa kerumitan sekitar daya tahan, toleransi kesalahan, pengesanan teragih, penyahpepijatan, pemantauan dan pengurusan sumber.

Ringkasnya, mereka bentuk sistem komunikasi yang teguh dan berdaya tahan untuk aplikasi asli awan memerlukan pemahaman yang mendalam tentang corak komunikasi segerak dan tak segerak. Dengan mempertimbangkan dengan teliti kelebihan dan kekurangan setiap corak dan menyelaraskannya dengan keperluan, arkitek boleh mereka bentuk sistem yang mengatur elemen bebas secara berkesan di dalam dan di luar sempadan aplikasi untuk menyampaikan aplikasi asli awan yang berprestasi tinggi, berskala dan boleh dipercayai.

Atas ialah kandungan terperinci . Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!