Ringkasan arsitektur Apigee

Halaman ini berlaku untuk Apigee dan Apigee Hybrid.

Baca dokumentasi Apigee Edge.

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

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

• Arsitektur dengan peering VPC yang 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 sehingga memungkinkan komunikasi dua arah antara jaringan virtual private cloud (VPC) yang Anda kelola dan jaringan VPC yang dikelola oleh Apigee. Setelah Anda menyelesaikan beberapa langkah penyediaan pertama, kedua VPC tersebut tersedia, tetapi belum dapat berkomunikasi bolak-balik. Konfigurasi lebih lanjut diperlukan untuk memungkinkan komunikasi dua arah. Lihat Gambar 1.



Gambar 1: VPC Anda dan VPC Apigee tidak dapat saling berkomunikasi tanpa konfigurasi lebih lanjut.

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



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

Untuk mengarahkan 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 berkomunikasi dengan XLB, XLB berkomunikasi dengan VM bridge, dan VM bridge berkomunikasi dengan jaringan Apigee. Lihat Gambar 3 dan Gambar 4.



Gambar 3: VM terkelola memungkinkan aliran permintaan dan respons di antara jaringan yang di-peering.

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 untuk Traffic Keluar. Sebagai gantinya, Anda dapat mengarahkan traffic melalui salah satu IP instance Apigee.



Gambar 4: Traffic yang dirutekan secara pribadi ke workload di VPC internal Anda.

Siklus proses panggilan proxy API

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



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

1. Aplikasi klien memanggil proxy Apigee API.
2. Permintaan mengarah di load balancer HTTPS eksternal L7 (XLB) global. 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 mampu berkomunikasi di seluruh jaringan yang di-peering. Di sisi lain, VM dapat dikonfigurasi untuk berkomunikasi dengan Apigee di seluruh jaringan yang di-peering. Itulah sebabnya kami menyediakan grup instance terkelola (MIG) VM agar berfungsi sebagai jembatan jaringan.
4. VM mengirimkan permintaan ke Apigee, yang memproses permintaan proxy API.
5. Apigee mengirimkan permintaan ke layanan backend, dan responsnya 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 sehingga memungkinkan komunikasi dua arah antara jaringan virtual private cloud (VPC) yang Anda kelola dan jaringan VPC yang dikelola oleh Apigee. Setelah Anda menyelesaikan beberapa langkah penyediaan pertama, kedua VPC tersebut tersedia, tetapi belum dapat berkomunikasi bolak-balik. Konfigurasi lebih lanjut diperlukan untuk memungkinkan komunikasi dua arah. Lihat Gambar 6.



Gambar 6: VPC Anda dan VPC Apigee tidak dapat saling berkomunikasi tanpa konfigurasi lebih lanjut.

Untuk memungkinkan komunikasi antar-VPC, kami menggunakan Private Service Connect (PSC) untuk merutekan traffic yang mengarah ke utara ke Apigee dan traffic ke arah selatan 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 lain yang Anda kontrol). Dengan metode ini (Gambar 7), permintaan akan melewati load balancer eksternal global atau load balancer eksternal regional ke satu titik lampiran, yang disebut lampiran layanan.

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

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 tentang arsitektur ini, lihat Ringkasan arsitektur Apigee.