Ringkasan arsitektur Apigee

Halaman ini berlaku untuk Apigee dan Apigee hybrid.

Lihat dokumentasi Apigee Edge.

Topik ini memberikan ringkasan tentang arsitektur sistem Apigee. Panduan ini dimaksudkan untuk membantu Anda memahami komponen mana yang dibuat selama penyediaan dan tujuannya dalam keseluruhan sistem.

Apigee menyediakan dua opsi untuk penyediaan: dengan peering VPC dan tanpa peering VPC. Kedua opsi tersebut dijelaskan di bagian berikut.

• Arsitektur dengan VPC peering diaktifkan
• Arsitektur dengan peering VPC dinonaktifkan

Arsitektur dengan peering VPC diaktifkan

Bagian ini menjelaskan arsitektur sistem Apigee saat Apigee disediakan dengan opsi peering VPC.

Ringkasan penyediaan

Selama penyediaan, komponen dikonfigurasi dan dibuat yang memungkinkan komunikasi dua arah antara jaringan virtual private cloud (VPC) yang dikelola oleh Anda dan jaringan VPC yang dikelola oleh Apigee. Setelah Anda menyelesaikan beberapa langkah penyediaan pertama, kedua VPC akan ada, tetapi belum dapat saling berkomunikasi. Konfigurasi lebih lanjut diperlukan untuk memungkinkan komunikasi dua arah. Lihat Gambar 1.



Gambar 1: VPC Anda dan VPC Apigee tidak dapat berkomunikasi satu sama lain tanpa konfigurasi lebih lanjut.

Untuk mengaktifkan komunikasi antar-VPC, kita menggunakan peering jaringan VPC. Peering jaringan memungkinkan konektivitas alamat IP internal di dua jaringan Virtual Private Cloud (VPC), terlepas dari apakah keduanya berasal dari project yang sama atau organisasi Google Cloud yang sama. Setelah langkah peering jaringan selesai, komunikasi dapat dilakukan antara kedua VPC. Lihat Gambar 2.



Gambar 2: Peering jaringan VPC memungkinkan komunikasi antar-VPC.

Untuk merutekan traffic dari aplikasi klien di internet ke Apigee, kami menggunakan load balancer HTTPS eksternal global (XLB). XLB dapat berkomunikasi di seluruh project Google Cloud, seperti antara project Google Cloud pelanggan dan Project Google Cloud Apigee, menggunakan referensi layanan lintas project.

Anda juga dapat menyediakan grup instance terkelola (MIG) virtual machine (VM) yang berfungsi sebagai jembatan jaringan. VM MIG memiliki kemampuan untuk berkomunikasi secara dua arah di seluruh jaringan yang di-peering. Setelah penyediaan selesai, aplikasi di internet akan berkomunikasi dengan XLB, XLB berkomunikasi dengan VM jembatan, dan VM jembatan berkomunikasi dengan jaringan Apigee. Lihat Gambar 3 dan Gambar 4.



Gambar 3: VM Terkelola memungkinkan permintaan dan respons mengalir di antara jaringan peer.

Dalam konfigurasi ini, traffic dirutekan dari Apigee (misalnya, dari kebijakan MessageLogging) ke workload yang berjalan di VPC internal Anda. Dalam hal ini, komunikasi ke VPC internal Anda tidak melalui IP NAT Egress. Sebagai gantinya, Anda dapat merutekan traffic melalui salah satu IP instance Apigee.



Gambar 4: Traffic dirutekan secara pribadi ke beban kerja di VPC internal Anda.

Siklus proses panggilan proxy API

Ilustrasi berikut menunjukkan siklus proses panggilan proxy API saat berpindah melalui komponen sistem Apigee yang disediakan (Gambar 5):



Gambar 5: Traffic dirutekan secara pribadi ke beban kerja di VPC internal Anda.

1. Aplikasi klien memanggil proxy Apigee API.
2. Permintaan tersebut akan diarahkan ke load balancer HTTPS eksternal L7 global (XLB). XLB dikonfigurasi dengan IP eksternal/publik dan sertifikat TLS.
3. XLB mengirimkan permintaan ke virtual machine (VM). VM berfungsi sebagai jembatan antara VPC Anda dan VPC Google (dikelola oleh Apigee).
   Catatan: XLB tidak dapat berkomunikasi di seluruh jaringan yang di-peering. Di sisi lain, VM dapat dikonfigurasi untuk berkomunikasi dengan Apigee di seluruh jaringan peering. Itulah sebabnya kami menyediakan VM grup instance terkelola (MIG) agar berfungsi sebagai jembatan jaringan.
4. VM mengirimkan permintaan ke Apigee, yang memproses permintaan proxy API.
5. Apigee mengirimkan permintaan ke layanan backend, dan respons dikirim kembali ke klien.

Arsitektur dengan peering VPC dinonaktifkan

Bagian ini menjelaskan arsitektur sistem Apigee saat Apigee tidak disediakan dengan opsi peering VPC.

Selama penyediaan, komponen dikonfigurasi dan dibuat yang memungkinkan komunikasi dua arah antara jaringan virtual private cloud (VPC) yang dikelola oleh Anda dan jaringan VPC yang dikelola oleh Apigee. Setelah Anda menyelesaikan beberapa langkah penyediaan pertama, kedua VPC akan ada, tetapi belum dapat saling berkomunikasi. Konfigurasi lebih lanjut diperlukan untuk memungkinkan komunikasi dua arah. Lihat Gambar 6.



Gambar 6: VPC Anda dan VPC Apigee tidak dapat berkomunikasi satu sama lain tanpa konfigurasi lebih lanjut.

Untuk mengaktifkan komunikasi antar-VPC, kami menggunakan Private Service Connect (PSC) untuk merutekan traffic northbound ke Apigee dan traffic southbound ke layanan target yang berjalan di project Google Cloud Anda.

PSC memungkinkan koneksi pribadi antara produsen layanan (Apigee) dan konsumen layanan (satu atau beberapa project Cloud lainnya yang Anda kontrol). Dengan metode ini (Gambar 7), permintaan akan diteruskan melalui load balancer eksternal global atau load balancer eksternal regional ke satu titik pemasangan, yang disebut lampiran layanan.

Untuk menghubungkan Apigee secara pribadi ke target backend, Anda harus membuat dua entitas: lampiran layanan di jaringan VPC tempat target di-deploy dan lampiran endpoint di VPC Apigee. Kedua entitas ini memungkinkan Apigee terhubung ke layanan target. Lihat Pola jaringan southbound.

Langkah-langkah untuk menyediakan Apigee dengan PSC (tanpa peering VPC) dijelaskan dalam Penyediaan command line tanpa peering VPC.

Gambar 7. Arsitektur Apigee tanpa peering VPC. Untuk mengetahui detail arsitektur ini, lihat ringkasan arsitektur Apigee.