Komunikasi Antara Perkhidmatan
Laksanakan pelbagai corak komunikasi antara perkhidmatan mikro FastAPI, seperti HTTP atau baris gilir mesej.
Komunikasi Antara Perkhidmatan ialah pelajaran Kem Intensif Pembangunan Bahagian Belakang FastAPI percuma di CoddyKit. Ini ialah pelajaran 2 daripada 4. Sebanyak 3 pelajaran dalam laluan pembelajaran ini boleh dibaca sepenuhnya secara percuma — selepas itu, CoddyKit PRO membuka akses kepada semua pelajaran, serta latihan praktikal dengan penyunting kod terbina dalam dan tutor kecerdasan buatan yang tersedia 24/7. Pelajaran ini merupakan sebahagian daripada laluan pembelajaran Kem Intensif Pembangunan Bahagian Belakang FastAPI, dan kemajuan anda disegerakkan merentas web serta aplikasi CoddyKit. Kursus Kem Intensif Pembangunan Bahagian Belakang FastAPI merangkumi sejumlah 4 pelajaran.
Mengapa Perkhidmatan Berkomunikasi
Dalam seni bina perkhidmatan mikro, aplikasi Anda bukanlah satu program besar. Sebaliknya, aplikasi itu terdiri daripada banyak perkhidmatan kecil dan bebas yang bekerjasama. Untuk mencapai matlamat bersama, perkhidmatan ini perlu berkomunikasi antara satu sama lain.
Bayangkan sistem e-dagang: satu perkhidmatan mengurus akaun pengguna, satu lagi mengurus inventori produk, dan perkhidmatan ketiga memproses pesanan. Apabila pengguna membuat pesanan, perkhidmatan pesanan perlu berkomunikasi dengan perkhidmatan inventori untuk menyemak stok dan perkhidmatan pengguna untuk mendapatkan butiran pembayaran.
HTTP: Perbualan Langsung
Cara paling biasa untuk perkhidmatan mikro berkomunikasi adalah melalui permintaan HTTP. Ini seperti satu perkhidmatan memanggil titik hujung API perkhidmatan lain secara terus.
- Segerak: Perkhidmatan yang membuat panggilan menunggu respons sebelum meneruskan operasi.
- Ringkas: Mudah difahami dan dilaksanakan, terutamanya untuk corak permintaan-respons.
- Biasa: Menggunakan protokol HTTP yang sama seperti yang Anda gunakan untuk melayari web.
Perkhidmatan FastAPI secara semula jadi mendedahkan titik hujung HTTP, menjadikannya kaedah yang mudah dilaksanakan.
Membuat Permintaan HTTP
Dalam Python, pustaka requests sangat baik untuk membuat panggilan HTTP. Berikut ialah cara satu perkhidmatan FastAPI memanggil perkhidmatan lain untuk mendapatkan data pengguna.
Andaikan Service B mendedahkan titik hujung /users/{user_id}, dan Service A memanggilnya:
import requests
def get_user_from_service_b(user_id: int):
# In a real scenario, 'service_b_url' would be a config variable
service_b_url = f"http://localhost:8001/users/{user_id}"
try:
response = requests.get(service_b_url)
response.raise_for_status() # Raises HTTPError for bad responses (4xx or 5xx)
return response.json()
except requests.exceptions.RequestException as e:
print(f"Error calling Service B: {e}")
return None
if __name__ == "__main__":
print("Simulating a call to Service B for user 1...")
user_data = get_user_from_service_b(1)
if user_data:
print(f"Received user data: {user_data}")
else:
print("Failed to get user data.")
print("\nNote: For this to truly work, a service B needs to be running at http://localhost:8001.")Mengendalikan Respons HTTP
Selepas membuat permintaan HTTP, Anda perlu mengendalikan respons dengan betul. Ini termasuk menyemak kod status HTTP dan menghuraikan isi respons.
- Kod Status:
200 OKbermaksud berjaya,404 Not Foundbermaksud sumber itu tidak tersedia, manakala500 Internal Server Errormenunjukkan masalah pada bahagian pelayan. - Isi Respons: Selalunya mengandungi data dalam format JSON yang boleh dihuraikan menggunakan
response.json(). - Pengendalian Ralat: Sentiasa bungkus permintaan Anda dalam blok
try-exceptuntuk menangkap masalah rangkaian atau ralat pelayan.
HTTP Berdaya Tahan: Tamat Masa dan Percubaan Semula
Masalah rangkaian atau perkhidmatan yang perlahan boleh menyebabkan panggilan HTTP Anda tergantung atau gagal. Membina daya tahan dalam komunikasi Anda amat penting.
- Tamat masa: Tetapkan tempoh maksimum untuk menunggu respons. Jika perkhidmatan tidak memberikan respons dalam tempoh ini, permintaan akan gagal dan mengelakkan perkhidmatan Anda daripada tergantung tanpa had.
- Percubaan semula: Jika permintaan gagal disebabkan ralat sementara (contohnya gangguan rangkaian atau lebihan beban perkhidmatan buat sementara waktu), Anda boleh mencuba semula permintaan itu secara automatik beberapa kali dengan selang masa. Pustaka seperti
tenacityboleh membantu melaksanakan ciri ini dengan mudah.
Strategi ini meningkatkan keteguhan perkhidmatan mikro Anda.
Baris Gilir Mesej: Mengasingkan Kebergantungan Perkhidmatan
Adakalanya, panggilan HTTP secara terus bukanlah pilihan terbaik. Untuk tugas yang tidak memerlukan respons segera, atau apabila Anda mahu mengurangkan kebergantungan terus antara perkhidmatan, baris gilir mesej amat berguna.
Baris gilir mesej bertindak sebagai perantara yang menyimpan mesej sehingga perkhidmatan pengguna bersedia memprosesnya. Contoh yang popular termasuk RabbitMQ dan Apache Kafka.
- Tak segerak: Penghantar (pengeluar) tidak menunggu penerima (pengguna) memproses mesej.
- Terpisah: Perkhidmatan tidak perlu mengetahui lokasi rangkaian terus antara satu sama lain.
- Boleh diskalakan: Lonjakan beban boleh dikendalikan dengan mudah dengan menambah pengguna.
Model Pengeluar-Pengguna
Baris gilir mesej beroperasi berdasarkan prinsip yang mudah:
- Pengeluar: Perkhidmatan yang mencipta dan menghantar mesej ke baris gilir. Perkhidmatan ini menghantar mesej tanpa menunggu hasilnya.
- Baris gilir: Penimbal storan sementara yang menyimpan mesej sehingga mesej tersebut diproses.
- Pengguna: Perkhidmatan yang mendengar baris gilir, mendapatkan mesej dan memprosesnya.
Model ini membolehkan komunikasi yang teguh, boleh diskalakan dan tahan terhadap ralat, terutamanya untuk tugas latar belakang atau seni bina dipacu peristiwa.
Pengeluar Mesej Konseptual
Walaupun contoh baris gilir mesej yang lengkap dan boleh dijalankan adalah kompleks, berikut ialah fungsi Python konseptual yang menunjukkan cara perkhidmatan mungkin "menghantar" mesej ke baris gilir. Dalam keadaan sebenar, ini akan melibatkan pustaka klien seperti pika (untuk RabbitMQ) atau confluent-kafka.
Perhatikan bahawa penghantar tidak menunggu mesej diproses; penghantar hanya meletakkannya dalam baris gilir.
import json
import time
# This is a simplified, conceptual representation.
# In a real app, 'queue_client' would be an actual library client.
class MockQueueClient:
def publish(self, queue_name: str, message: dict):
print(f"[{time.time():.2f}] PRODUCER: Sending message to '{queue_name}'...")
print(f" Message content: {json.dumps(message)}")
# In a real scenario, this would send to a message broker
print(" (Message sent to broker, producer continues its work)")
def send_new_order_event(order_details: dict):
queue_client = MockQueueClient()
queue_client.publish("order_processing_queue", order_details)
print("PRODUCER: Order event sent successfully.")
if __name__ == "__main__":
order_info = {"order_id": "ORD001", "item": "Laptop", "quantity": 1}
send_new_order_event(order_info)
print("\nPRODUCER: Service continues other tasks while order processes.")Bila Perlu Memilih HTTP
Komunikasi HTTP biasanya diutamakan untuk:
- Permintaan Segerak: Apabila perkhidmatan yang membuat panggilan memerlukan respons segera untuk meneruskan aliran kerjanya (contohnya mendapatkan data profil pengguna atau menyemak inventori sebelum mengesahkan pesanan).
- Corak Permintaan-Respons: Pertanyaan ringkas, pengambilan data atau operasi yang memerlukan klien menerima hasil secara terus.
- Gandingan Rapat Diterima: Apabila perkhidmatan direka untuk bekerjasama rapat dan panggilan terus adalah cekap.
- Interaksi Pengguna Masa Nyata: Selalunya digunakan untuk komunikasi daripada bahagian hadapan ke bahagian belakang atau apabila kemas kini antara muka pengguna perlu dilakukan dengan segera.
Memilih Alat yang Tepat
Anda telah melihat dua cara utama perkhidmatan berkomunikasi. Setiap cara mempunyai kelebihannya. Pertimbangkan senario berikut:
Seorang pengguna menghantar permintaan untuk menjana laporan kompleks yang mungkin mengambil masa beberapa minit untuk disiapkan. Pengguna itu tidak perlu menunggu, tetapi mahu dimaklumkan apabila laporan tersebut siap.
Corak komunikasi manakah yang paling sesuai untuk penghantaran permintaan awal?
Imbas Kembali: Perkhidmatan Berkomunikasi
Syabas! Anda telah meneroka cara asas perkhidmatan mikro berkomunikasi.
- HTTP: Paling sesuai untuk interaksi segerak dan permintaan-respons yang memerlukan maklum balas segera. Kaedah ini terus dan mudah dilaksanakan menggunakan pustaka seperti
requests. - Baris Gilir Mesej: Sesuai untuk komunikasi tak segerak dan terpisah, mengendalikan tugas yang berjalan lama serta membolehkan seni bina dipacu peristiwa. Kaedah ini menggunakan model pengeluar-pengguna untuk penghantaran mesej yang teguh.
Pemilihan corak yang tepat bergantung pada keperluan khusus Anda dari segi gandingan, kependaman dan kebolehpercayaan. Dalam pelajaran seterusnya, kita akan mendalami pembinaan Get Laluan API!
Pelajari Kem Intensif Pembangunan Bahagian Belakang FastAPI dengan tutor kecerdasan buatan — percuma
Tulis dan jalankan kod sebenar dalam pelayar anda, dapatkan bantuan segera daripada tutor kecerdasan buatan yang tersedia 24/7, dan sambung semula dari tempat anda berhenti di web atau dalam aplikasi.
- Kursus
- 21
- Pelajaran
- 84
Soalan Lazim
Adakah pelajaran “Komunikasi Antara Perkhidmatan” percuma?
Ya — sebanyak 3 pelajaran dalam laluan pembelajaran Kem Intensif Pembangunan Bahagian Belakang FastAPI, termasuk “Komunikasi Antara Perkhidmatan”, boleh dibaca sepenuhnya secara percuma di web ini. Selepas itu, CoddyKit PRO membuka akses kepada semua pelajaran, serta latihan interaktif dengan penyunting kod terbina dalam dan tutor kecerdasan buatan yang tersedia 24/7. Kursus Kem Intensif Pembangunan Bahagian Belakang FastAPI merangkumi sejumlah 4 pelajaran.
Apakah yang akan saya pelajari dalam “Komunikasi Antara Perkhidmatan”?
Laksanakan pelbagai corak komunikasi antara perkhidmatan mikro FastAPI, seperti HTTP atau baris gilir mesej. Anda berlatih Kem Intensif Pembangunan Bahagian Belakang FastAPI menggunakan kod praktikal yang dijalankan terus dalam pelayar, manakala tutor kecerdasan buatan 24/7 menjawab soalan anda semasa anda mengikuti pelajaran.
Adakah saya memerlukan pengalaman untuk memulakan Kem Intensif Pembangunan Bahagian Belakang FastAPI?
Tiada pengalaman terdahulu diperlukan. Pembelajaran Kem Intensif Pembangunan Bahagian Belakang FastAPI di CoddyKit disusun untuk pelajar daripada peringkat pemula hingga lanjutan, jadi anda boleh bermula di sini atau dari awal dan belajar mengikut kadar anda sendiri. Ini ialah pelajaran 2 daripada 4.
Berapa lamakah pelajaran “Komunikasi Antara Perkhidmatan” diambil?
Kebanyakan pelajaran CoddyKit mengambil masa kira-kira 5–10 minit. Setiap pelajaran ringkas dan interaktif, jadi anda boleh membuat kemajuan secara berterusan dan menyambung tepat dari tempat anda berhenti di web atau aplikasi.
Bolehkah saya menulis dan menjalankan kod dalam pelajaran Kem Intensif Pembangunan Bahagian Belakang FastAPI ini?
Ya. Setiap pelajaran Kem Intensif Pembangunan Bahagian Belakang FastAPI menyertakan penyunting kod terbina dalam, jadi anda boleh menulis dan menjalankan kod sebenar terus dalam pelayar serta menerima maklum balas kecerdasan buatan serta-merta — tanpa memerlukan persediaan setempat.
Semua pelajaran dalam kursus ini
- Mereka Bentuk Seni Bina Perkhidmatan Mikro
- Komunikasi Antara Perkhidmatan
- Melaksanakan Gerbang API dengan FastAPI
- Penemuan Perkhidmatan dan Semakan Kesihatan