Ringkasan arsitektur Apigee

Halaman ini berlaku untuk Apigee dan Apigee hybrid.

Lihat Dokumentasi Apigee Edge.

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

Apigee menyediakan dua opsi penyediaan: dengan peering VPC dan tanpa peering VPC. Keduanya opsi akan dijelaskan di bagian berikut.

  • 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 antara virtual yang dikelola oleh Anda dan jaringan VPC yang dikelola oleh Apigee. Setelah Anda menyelesaikan langkah penyediaan pertama, kedua VPC tersebut telah tersedia, tetapi tidak dapat berkomunikasi bolak-balik. Konfigurasi lebih lanjut diperlukan untuk memungkinkan dua arah komunikasi antarlayanan. 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 VPC peering jaringan. Peering jaringan memungkinkan konektivitas alamat IP internal di dua Jaringan Virtual Private Cloud (VPC) terlepas dari apakah jaringan tersebut termasuk dalam project yang sama atau organisasi Google Cloud yang sama. Setelah langkah peering jaringan selesai, komunikasi dapat dilakukan di antara kedua VPC tersebut. Lihat Gambar 2.

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

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

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

    Gambar 3: VM terkelola mengizinkan permintaan dan respons mengalir di antara kedua layanan yang di-peering jaringan.

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

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

    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 yang dirutekan secara pribadi ke workload di VPC internal.
    1. Aplikasi klien memanggil proxy Apigee API.
    2. Permintaan diterima di load balancer HTTPS (XLB eksternal) L7 global. XLB dikonfigurasi dengan IP eksternal/publik dan sertifikat TLS.
    3. XLB mengirimkan permintaan ke virtual machine (VM). VM berfungsi sebagai jembatan antara VPC dan VPC Google (dikelola oleh Apigee).
    4. VM mengirimkan permintaan ke Apigee, yang memproses permintaan proxy API.
    5. Apigee mengirimkan permintaan ke layanan backend, dan responsnya dikirim kembali ke dengan klien besar.

    Arsitektur dengan peering VPC dinonaktifkan

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

    Selama penyediaan, komponen dikonfigurasi dan dibuat sehingga memungkinkan komunikasi antara virtual machine yang dikelola oleh Anda dan jaringan VPC yang dikelola oleh Apigee. Setelah Anda menyelesaikan langkah penyediaan pertama, kedua VPC tersebut telah tersedia, tetapi tidak dapat berkomunikasi bolak-balik. Konfigurasi lebih lanjut diperlukan untuk memungkinkan dua arah komunikasi antarlayanan. 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 mengarahkan traffic ke arah utara ke Apigee dan traffic ke arah selatan ke layanan target yang sedang 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 secara pribadi ke target backend, Anda harus membuat dua entity: lampiran layanan di jaringan VPC tempat target di-deploy dan lampiran endpoint di VPC Apigee. Ini dua entity memungkinkan Apigee terhubung ke layanan target. Lihat Pola jaringan Southbound.

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

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