Whitepaper ini hanya untuk referensi sejarah. Beberapa konten mungkin sudah usang dan beberapa tautan mungkin tidak tersedia.
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Contoh pola arsitektur
Anda dapat menerapkan pola arsitektur populer menggunakan API Gateway dan AWS Lambda sebagai tingkat logika Anda. Whitepaper ini mencakup pola arsitektur paling populer yang memanfaatkan tingkatan logika AWS Lambda berbasis:
+ **Mobile backend -** Sebuah aplikasi mobile berkomunikasi dengan API Gateway dan Lambda untuk mengakses data aplikasi. Pola ini dapat diperluas ke klien HTTPS generik yang tidak menggunakan sumber daya AWS tanpa server untuk meng-host sumber daya tingkat presentasi (seperti klien desktop, server web yang berjalan EC2, dan sebagainya).
+ **Aplikasi halaman tunggal - Aplikasi** satu halaman yang dihosting di Amazon S3 dan CloudFront berkomunikasi dengan API Gateway dan AWS Lambda untuk mengakses data aplikasi.
+ **Aplikasi web — Aplikasi** web adalah back-end aplikasi web tujuan umum, berbasis peristiwa, yang menggunakan API AWS Lambda Gateway untuk logika bisnisnya. Ini juga menggunakan DynamoDB sebagai database dan Amazon Cognito untuk manajemen pengguna. Semua konten statis di-host menggunakan Amplify.
Selain dua pola ini, whitepaper ini membahas penerapan Lambda dan API Gateway ke arsitektur microservice umum. Arsitektur microservice adalah pola populer yang, meskipun bukan arsitektur tiga tingkat standar, melibatkan decoupling komponen aplikasi dan menerapkannya sebagai unit fungsionalitas individu tanpa kewarganegaraan yang berkomunikasi satu sama lain.
# Backend seluler
![\[Pola arsitektur untuk backend seluler tanpa server\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/arch-pattern-serverless-mobile-backend.png)
*Pola arsitektur untuk backend seluler tanpa server*
*Tabel 1 - Komponen tingkat backend seluler*
| Tingkat | Komponen-komponen |
| --- | --- |
| Presentasi | Aplikasi seluler berjalan di perangkat pengguna. |
| Logika | Amazon API Gateway dengan AWS Lambda. Arsitektur ini menunjukkan tiga layanan terbuka (`/tickets``/shows`,, dan`/info`). Titik akhir API Gateway diamankan oleh kumpulan [pengguna Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html) Dalam metode ini, pengguna masuk ke kumpulan pengguna Amazon Cognito (menggunakan pihak ketiga gabungan jika perlu), dan menerima token akses dan ID yang digunakan untuk mengotorisasi panggilan API Gateway. Setiap fungsi Lambda diberi peran Identity and Access Management (IAM) sendiri untuk menyediakan akses ke sumber data yang sesuai. |
| Data | DynamoDB digunakan untuk `/tickets` dan layanan. `/shows` Amazon RDS digunakan untuk `/info` layanan ini. Fungsi Lambda ini mengambil kredensi Amazon RDS AWS dari Secrets Manager dan menggunakan elastic network interface untuk mengakses subnet pribadi. |
# Aplikasi satu halaman
![\[AWS architecture diagram showing interactions between services like CloudFront, S3, Lambda, and DynamoDB.\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/single-page-application.png)
*Pola arsitektur untuk aplikasi satu halaman tanpa server*
*Tabel 2 - Komponen aplikasi satu halaman*
| Tingkat | Komponen-komponen |
| --- | --- |
| Presentasi | Konten situs web statis yang dihosting di Amazon S3, didistribusikan oleh. CloudFront AWS Certificate Manager memungkinkan sertifikat SSL/TLS kustom digunakan. |
| Logika | API Gateway dengan AWS Lambda. Arsitektur ini menunjukkan tiga layanan terbuka (`/tickets``/shows`,, dan`/info`). Titik akhir API Gateway diamankan oleh otorisasi Lambda. Dalam metode ini, pengguna masuk melalui penyedia identitas pihak ketiga dan mendapatkan akses dan token ID. Token ini disertakan dalam panggilan API Gateway, dan otorisasi Lambda memvalidasi token ini dan menghasilkan kebijakan IAM yang berisi izin inisiasi API. Setiap fungsi Lambda diberi peran IAM sendiri untuk menyediakan akses ke sumber data yang sesuai. |
| Data | Amazon DynamoDB digunakan untuk `/tickets` dan layanan. `/shows` Amazon ElastiCache digunakan oleh `/shows` layanan untuk meningkatkan kinerja database. Cache misses dikirim ke DynamoDB. Amazon S3 digunakan untuk meng-host konten statis yang digunakan oleh. `/info service` |
# Aplikasi web
![\[AWS Cloud architecture diagram showing client interaction with various Layanan AWS.\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/web-application.png)
*Pola arsitektur untuk aplikasi web*
*Tabel 3 - Komponen aplikasi web*
| Tingkat | Komponen-komponen |
| --- | --- |
| Presentasi | Aplikasi front-end adalah semua konten statis (HTML, CSS, JavaScript dan gambar) yang dihasilkan oleh utilitas React seperti. create-react-app Amazon CloudFront menampung semua objek ini. Aplikasi web, ketika digunakan, mengunduh semua sumber daya ke browser dan mulai berjalan dari sana. Aplikasi web terhubung ke backend yang memanggil file. APIs |
| Logika | Lapisan logika dibangun menggunakan fungsi Lambda yang digawangi oleh API Gateway REST. APIs Arsitektur ini menunjukkan beberapa layanan yang terbuka. Ada beberapa fungsi Lambda yang berbeda masing-masing menangani aspek aplikasi yang berbeda. Fungsi Lambda berada di belakang API Gateway dan dapat diakses menggunakan jalur URL API. Otentikasi pengguna ditangani menggunakan kumpulan pengguna Amazon Cognito atau penyedia pengguna gabungan. API Gateway menggunakan integrasi di luar kotak dengan Amazon Cognito. Hanya setelah pengguna diautentikasi, klien akan menerima token JSON Web Token (JWT) yang kemudian harus digunakan saat melakukan panggilan API. Setiap fungsi Lambda diberi peran IAM sendiri untuk menyediakan akses ke sumber data yang sesuai. |
| Data | Dalam contoh khusus ini, DynamoDB digunakan untuk penyimpanan data tetapi database Amazon atau layanan penyimpanan lain yang dibuat khusus dapat digunakan tergantung pada kasus penggunaan dan skenario penggunaan. |
# Layanan Mikro dengan Lambda
![\[AWS Cloud architecture with API Gateways and Lambda functions across two accounts.\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/microservices-with-lambda.png)
*Pola arsitektur untuk layanan mikro dengan Lambda*
Pola arsitektur microservice tidak terikat pada arsitektur tiga tingkat yang khas; Namun, pola populer ini dapat mewujudkan manfaat yang signifikan dari penggunaan sumber daya tanpa server.
Dalam arsitektur ini, masing-masing komponen aplikasi dipisahkan dan dikerahkan dan dioperasikan secara independen. API yang dibuat dengan Amazon API Gateway, dan fungsi yang kemudian diluncurkan oleh AWS Lambda, adalah semua yang Anda butuhkan untuk membangun layanan mikro. Tim Anda dapat menggunakan layanan ini untuk memisahkan dan memecah lingkungan Anda ke tingkat perincian yang diinginkan.
Secara umum, lingkungan layanan mikro dapat menimbulkan kesulitan berikut: overhead berulang untuk membuat setiap layanan mikro baru, masalah dengan mengoptimalkan kepadatan dan pemanfaatan server, kompleksitas menjalankan beberapa versi beberapa layanan mikro secara bersamaan, dan proliferasi persyaratan kode sisi klien untuk diintegrasikan dengan banyak layanan terpisah.
Saat Anda membuat layanan mikro menggunakan sumber daya tanpa server, masalah ini menjadi lebih sulit untuk dipecahkan dan, dalam beberapa kasus, hilang begitu saja. Pola layanan mikro tanpa server menurunkan penghalang untuk pembuatan setiap layanan mikro berikutnya (API Gateway bahkan memungkinkan kloning yang ada APIs, dan penggunaan fungsi Lambda di akun lain). Mengoptimalkan pemanfaatan server tidak lagi relevan dengan pola ini. Terakhir, Amazon API Gateway menyediakan klien yang dihasilkan secara terprogram SDKs dalam sejumlah bahasa populer untuk mengurangi overhead integrasi.