Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Pola untuk mengaktifkan persistensi data
Pola berikut digunakan untuk mengaktifkan persistensi data di layanan mikro Anda.
**Topics**
+ [Database-per-service pola](database-per-service.md)
+ [Pola komposisi API](api-composition.md)
+ [Pola CQRS](cqrs-pattern.md)
+ [Pola sumber acara](service-per-team.md)
+ [Sagapola](saga-pattern.md)
+ [Shared-database-per-service pola](shared-database.md)
# Database-per-service pola
Kopling longgar adalah karakteristik inti dari arsitektur layanan mikro, karena setiap layanan mikro individu dapat secara mandiri menyimpan dan mengambil informasi dari penyimpanan datanya sendiri. Dengan menerapkan database-per-service pola, Anda memilih penyimpanan data yang paling tepat (misalnya, database relasional atau non-relasional) untuk aplikasi dan kebutuhan bisnis Anda. Ini berarti bahwa layanan mikro tidak berbagi lapisan data, perubahan pada database individual layanan mikro tidak memengaruhi layanan mikro lainnya, penyimpanan data individu tidak dapat langsung diakses oleh layanan mikro lainnya, dan data persisten hanya diakses oleh. APIs Memisahkan penyimpanan data juga meningkatkan ketahanan aplikasi Anda secara keseluruhan, dan memastikan bahwa satu database tidak dapat menjadi satu titik kegagalan.
Dalam ilustrasi berikut, AWS database yang berbeda digunakan oleh layanan mikro “Penjualan,” “Pelanggan,” dan “Kepatuhan”. Layanan mikro ini digunakan sebagai AWS Lambda fungsi dan diakses melalui API Amazon API Gateway. AWS Identity and Access Management Kebijakan (IAM) memastikan bahwa data tetap pribadi dan tidak dibagikan di antara layanan mikro. Setiap layanan mikro menggunakan tipe database yang memenuhi persyaratan masing-masing; misalnya, “Penjualan” menggunakan Amazon Aurora, “Pelanggan” menggunakan Amazon DynamoDB, dan “Kepatuhan” menggunakan Amazon Relational Database Service (Amazon RDS) untuk SQL Server.
![\[Database-per-service diagram pola\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/modernization-data-persistence/images/enabling-diagram1.png)
Anda harus mempertimbangkan untuk menggunakan pola ini jika:
+ Kopling longgar diperlukan antara layanan mikro Anda.
+ Layanan mikro memiliki kepatuhan atau persyaratan keamanan yang berbeda untuk database mereka.
+ Diperlukan kontrol penskalaan yang lebih granular.
Ada kelemahan berikut untuk menggunakan database-per-service pola:
+ Mungkin sulit untuk menerapkan transaksi dan kueri kompleks yang mencakup beberapa layanan mikro atau penyimpanan data.
+ Anda harus mengelola beberapa database relasional dan non-relasional.
+ Penyimpanan data Anda harus memenuhi dua persyaratan [teorema CAP](https://www.ibm.com/cloud/learn/cap-theorem): *konsistensi*, *ketersediaan*, atau *toleransi partisi*.
**catatan**
Jika Anda menggunakan database-per-service pola, Anda harus menerapkan pola lain untuk mengimplementasikan kueri yang mencakup beberapa layanan mikro. Anda dapat menggunakan [Pola komposisi API](api-composition.md) (yang dapat Anda percepat dengan[Pola CQRS](cqrs-pattern.md)) atau [pola sumber acara](service-per-team.md) untuk membuat hasil agregat.
# Pola komposisi API
Pola ini menggunakan komposer API, atau agregator, untuk mengimplementasikan kueri dengan menjalankan layanan mikro individual yang memiliki data. Kemudian menggabungkan hasil dengan melakukan gabungan dalam memori.
Diagram berikut menggambarkan bagaimana pola ini diterapkan.
![\[Diagram pola komposisi API\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/modernization-data-persistence/images/enabling-diagram2.png)
Diagram menunjukkan alur kerja berikut:
1. Gateway API melayani API “/customer”, yang memiliki layanan mikro “Pesanan” yang melacak pesanan pelanggan dalam database Aurora.
1. Layanan mikro “Support” melacak masalah dukungan pelanggan dan menyimpannya dalam database OpenSearch Layanan Amazon.
1. Layanan mikro CustomerDetails "" mempertahankan atribut pelanggan (misalnya, alamat, nomor telepon, atau detail pembayaran) dalam tabel DynamoDB.
1. Fungsi “GetCustomer” Lambda menjalankan APIs untuk layanan mikro ini, dan melakukan gabungan dalam memori pada data sebelum mengembalikannya ke pemohon. Ini membantu dengan mudah mengambil informasi pelanggan dalam satu panggilan jaringan ke API yang dihadapi pengguna, dan membuat antarmuka sangat sederhana.
Pola komposisi API menawarkan cara paling sederhana untuk mengumpulkan data dari beberapa layanan mikro. Namun, ada kelemahan berikut untuk menggunakan pola komposisi API:
+ Ini mungkin tidak cocok untuk kueri kompleks dan kumpulan data besar yang memerlukan gabungan dalam memori.
+ Sistem Anda secara keseluruhan menjadi kurang tersedia jika Anda meningkatkan jumlah layanan mikro yang terhubung ke komposer API.
+ Peningkatan permintaan database membuat lebih banyak lalu lintas jaringan, yang meningkatkan biaya operasional Anda.
# Pola CQRS
Pola pemisahan tanggung jawab permintaan perintah (CQRS) memisahkan mutasi data, atau bagian perintah sistem, dari bagian kueri. Anda dapat menggunakan pola CQRS untuk memisahkan pembaruan dan kueri jika mereka memiliki persyaratan yang berbeda untuk throughput, latensi, atau konsistensi. Pola CQRS membagi aplikasi menjadi dua bagian — sisi perintah dan sisi query — seperti yang ditunjukkan pada diagram berikut. Sisi perintah menangani`create`,`update`, dan `delete` permintaan. Sisi kueri menjalankan `query` bagian dengan menggunakan replika baca.
![\[Tampilan pola CQRS tingkat tinggi\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/modernization-data-persistence/images/cqrs.png)
Diagram menunjukkan proses berikut:
1. Bisnis berinteraksi dengan aplikasi dengan mengirimkan perintah melalui API. Perintah adalah tindakan seperti membuat, memperbarui atau menghapus data.
1. Aplikasi memproses perintah yang masuk di sisi perintah. Ini melibatkan validasi, otorisasi, dan menjalankan operasi.
1. Aplikasi mempertahankan data perintah dalam database write (command).
1. Setelah perintah disimpan dalam database tulis, peristiwa dipicu untuk memperbarui data dalam database baca (kueri).
1. Database baca (kueri) memproses dan mempertahankan data. Database baca dirancang untuk dioptimalkan untuk persyaratan kueri tertentu.
1. Bisnis berinteraksi dengan membaca APIs untuk mengirim kueri ke sisi kueri aplikasi.
1. Aplikasi memproses kueri yang masuk di sisi kueri dan mengambil data dari database baca.
Anda dapat menerapkan pola CQRS dengan menggunakan berbagai kombinasi database, termasuk:
+ Menggunakan database sistem manajemen basis data relasional (RDBMS) untuk kedua perintah dan sisi query. Operasi tulis masuk ke database utama dan operasi baca dapat dirutekan untuk membaca replika. Contoh: [Amazon RDS membaca replika](https://aws.amazon.com/rds/features/read-replicas/)
+ Menggunakan database RDBMS untuk sisi perintah dan database NoSQL untuk sisi query. Contoh: [Memodernisasi database lama menggunakan sumber acara](https://aws.amazon.com/blogs/database/modernize-legacy-databases-using-event-sourcing-and-cqrs-with-aws-dms/) dan CQRS dengan AWS DMS
+ Menggunakan database NoSQL untuk kedua perintah dan sisi query. Contoh: [Membangun toko acara CQRS dengan](https://aws.amazon.com/blogs/database/build-a-cqrs-event-store-with-amazon-dynamodb/) Amazon DynamoDB
+ Menggunakan database NoSQL untuk sisi perintah dan database RDBMS untuk sisi query, seperti yang dibahas dalam contoh berikut.
Dalam ilustrasi berikut, penyimpanan data NoSQL, seperti DynamoDB, digunakan untuk mengoptimalkan throughput tulis dan menyediakan kemampuan kueri yang fleksibel. Ini mencapai skalabilitas penulisan yang tinggi pada beban kerja yang memiliki pola akses yang terdefinisi dengan baik saat Anda menambahkan data. Database relasional, seperti Amazon Aurora, menyediakan fungsionalitas kueri yang kompleks. Aliran DynamoDB mengirimkan data ke fungsi Lambda yang memperbarui tabel Aurora.
![\[Pola CQRS diimplementasikan dengan layanan AWS\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/modernization-data-persistence/images/enabling-diagram3.png)
Menerapkan pola CQRS dengan DynamoDB dan Aurora memberikan manfaat utama ini:
+ DynamoDB adalah database NoSQL yang dikelola sepenuhnya yang dapat menangani operasi penulisan volume tinggi, dan Aurora menawarkan skalabilitas baca tinggi untuk kueri kompleks di sisi kueri.
+ DynamoDB menyediakan akses data dengan latensi rendah dan throughput tinggi, yang membuatnya ideal untuk menangani operasi perintah dan pembaruan, dan kinerja Aurora dapat disetel dengan baik dan dioptimalkan untuk kueri yang kompleks.
+ DynamoDB dan Aurora menawarkan opsi tanpa server, yang memungkinkan bisnis Anda membayar sumber daya berdasarkan penggunaan saja.
+ DynamoDB dan Aurora adalah layanan yang dikelola sepenuhnya, yang mengurangi beban operasional pengelolaan database, backup, dan skalabilitas.
Anda harus mempertimbangkan untuk menggunakan pola CQRS jika:
+ Anda menerapkan database-per-service pola dan ingin menggabungkan data dari beberapa layanan mikro.
+ Beban kerja baca dan tulis Anda memiliki persyaratan terpisah untuk penskalaan, latensi, dan konsistensi.
+ Konsistensi akhirnya dapat diterima untuk kueri baca.
**penting**
Pola CQRS biasanya menghasilkan konsistensi akhirnya antara penyimpanan data.
# Pola sumber acara
Pola sumber acara biasanya digunakan [Pola CQRS](cqrs-pattern.md) untuk memisahkan beban kerja baca dari penulisan, dan mengoptimalkan kinerja, skalabilitas, dan keamanan. Data disimpan sebagai serangkaian peristiwa, bukan pembaruan langsung ke penyimpanan data. Microservices memutar ulang peristiwa dari toko acara untuk menghitung status yang sesuai dari penyimpanan data mereka sendiri. Pola ini memberikan visibilitas untuk keadaan aplikasi saat ini dan konteks tambahan untuk bagaimana aplikasi sampai pada keadaan itu. Pola sumber acara bekerja secara efektif dengan pola CQRS karena data dapat direproduksi untuk acara tertentu, bahkan jika penyimpanan data perintah dan kueri memiliki skema yang berbeda.
Dengan memilih pola ini, Anda dapat mengidentifikasi dan merekonstruksi status aplikasi untuk setiap titik waktu. Ini menghasilkan jejak audit yang persisten dan membuat debugging lebih mudah. Namun, data pada akhirnya menjadi konsisten dan ini mungkin tidak sesuai untuk beberapa kasus penggunaan.
Pola ini dapat diimplementasikan dengan menggunakan Amazon Kinesis Data Streams EventBridge atau Amazon.
## Implementasi Amazon Kinesis Data Streams
Dalam ilustrasi berikut, Kinesis Data Streams adalah komponen utama dari toko acara terpusat. Toko acara menangkap perubahan aplikasi sebagai peristiwa dan mempertahankannya di Amazon Simple Storage Service (Amazon S3).
![\[Implementasi Amazon Kinesis Data Streams\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/modernization-data-persistence/images/enabling-diagram4.png)
Alur kerja terdiri dari langkah-langkah berikut:
1. Ketika layanan mikro “/withdraw” atau “/credit” mengalami perubahan status peristiwa, mereka mempublikasikan acara dengan menulis pesan ke Kinesis Data Streams.
1. Layanan mikro lainnya, seperti “/balance” atau “/creditLimit,” membaca salinan pesan, menyaringnya untuk relevansi, dan meneruskannya untuk diproses lebih lanjut.
## EventBridge Implementasi Amazon
Arsitektur dalam ilustrasi berikut menggunakan EventBridge. EventBridge adalah layanan tanpa server yang menggunakan peristiwa untuk menghubungkan komponen aplikasi, yang memudahkan Anda untuk membangun aplikasi yang dapat diskalakan dan digerakkan oleh peristiwa. Arsitektur berbasis peristiwa adalah gaya membangun sistem perangkat lunak yang digabungkan secara longgar yang bekerja sama dengan memancarkan dan menanggapi peristiwa. EventBridge menyediakan [bus acara default](https://docs.aws.amazon.com//eventbridge/latest/userguide/create-event-bus.html) untuk acara yang diterbitkan oleh AWS layanan, dan Anda juga dapat membuat [bus acara khusus untuk bus](https://docs.aws.amazon.com//eventbridge/latest/userguide/create-event-bus.html) khusus domain.
![\[EventBridge Implementasi Amazon\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/modernization-data-persistence/images/enabling-diagram5.png)
Alur kerja terdiri dari langkah-langkah berikut:
1. Acara OrderPlaced “” diterbitkan oleh layanan mikro “Pesanan” ke bus acara khusus.
1. Layanan mikro yang perlu mengambil tindakan setelah pesanan ditempatkan, seperti layanan mikro “/route”, diprakarsai oleh aturan dan target.
1. Layanan mikro ini menghasilkan rute untuk mengirimkan pesanan ke pelanggan dan memancarkan acara RouteCreated "”.
1. Layanan mikro yang perlu mengambil tindakan lebih lanjut juga diprakarsai oleh acara RouteCreated "”.
1. Acara dikirim ke arsip acara (misalnya, EventBridge arsip) sehingga dapat diputar ulang untuk diproses ulang, jika diperlukan.
1. Peristiwa urutan historis dikirim ke antrian Amazon SQS baru (antrean putar ulang) untuk diproses ulang, jika diperlukan.
1. Jika target tidak dimulai, peristiwa yang terpengaruh ditempatkan dalam antrian surat mati (DLQ) untuk analisis dan pemrosesan ulang lebih lanjut.
Anda harus mempertimbangkan untuk menggunakan pola ini jika:
+ Peristiwa digunakan untuk sepenuhnya membangun kembali status aplikasi.
+ Anda memerlukan acara untuk diputar ulang dalam sistem dan bahwa status aplikasi dapat ditentukan kapan saja.
+ Anda ingin dapat membalikkan peristiwa tertentu tanpa harus memulai dengan status aplikasi kosong.
+ Sistem Anda memerlukan aliran acara yang dapat dengan mudah diserialisasi untuk membuat log otomatis.
+ Sistem Anda memerlukan operasi baca berat tetapi ringan pada operasi tulis; operasi baca berat dapat diarahkan ke database dalam memori, yang terus diperbarui dengan aliran peristiwa.
**penting**
Jika Anda menggunakan pola sumber peristiwa, Anda harus menerapkan [Sagapola](saga-pattern.md) untuk menjaga konsistensi data di seluruh layanan mikro.
# Sagapola
sagaPola ini adalah pola manajemen kegagalan yang membantu membangun konsistensi dalam aplikasi terdistribusi, dan mengoordinasikan transaksi antara beberapa layanan mikro untuk menjaga konsistensi data. Layanan mikro menerbitkan acara untuk setiap transaksi, dan transaksi berikutnya dimulai berdasarkan hasil acara. Ini dapat mengambil dua jalur berbeda, tergantung pada keberhasilan atau kegagalan transaksi.
Ilustrasi berikut menunjukkan bagaimana saga pola mengimplementasikan sistem pemrosesan pesanan dengan menggunakan. AWS Step Functions Setiap langkah (misalnya, “ProcessPayment”) juga memiliki langkah-langkah terpisah untuk menangani keberhasilan (misalnya, "UpdateCustomerAccount“) atau kegagalan (misalnya," SetOrderFailure “) dari proses.
![\[Sagapola\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/modernization-data-persistence/images/enabling-diagram6.png)
Anda harus mempertimbangkan untuk menggunakan pola ini jika:
+ Aplikasi perlu menjaga konsistensi data di beberapa layanan mikro tanpa kopling yang ketat.
+ Ada transaksi berumur panjang dan Anda tidak ingin layanan mikro lainnya diblokir jika satu layanan mikro berjalan untuk waktu yang lama.
+ Anda harus dapat memutar kembali jika operasi gagal dalam urutan.
**penting**
sagaPolanya sulit untuk di-debug dan kompleksitasnya meningkat dengan jumlah layanan mikro. Pola ini membutuhkan model pemrograman kompleks yang mengembangkan dan merancang transaksi kompensasi untuk memutar kembali dan membatalkan perubahan.
Untuk informasi selengkapnya tentang penerapan saga pola dalam arsitektur microservices, lihat pola [Implementasikan saga pola tanpa server dengan menggunakan AWS Step Functions](https://docs.aws.amazon.com//prescriptive-guidance/latest/patterns/implement-the-serverless-saga-pattern-by-using-aws-step-functions.html) di situs web AWS Prescriptive Guidance.
# Shared-database-per-service pola
Dalam shared-database-per-service polanya, database yang sama dibagikan oleh beberapa layanan mikro. Anda perlu menilai arsitektur aplikasi dengan cermat sebelum mengadopsi pola ini, dan pastikan Anda menghindari hot table (tabel tunggal yang ditulis oleh beberapa layanan mikro). Semua perubahan database Anda juga harus kompatibel ke belakang; misalnya, pengembang dapat menjatuhkan kolom atau tabel hanya jika objek tidak direferensikan oleh versi saat ini dan sebelumnya dari semua layanan mikro.
Dalam ilustrasi berikut, database asuransi dibagi oleh semua layanan mikro dan kebijakan IAM menyediakan akses ke database. Ini menciptakan kopling waktu pengembangan; misalnya, perubahan dalam layanan mikro “Penjualan” perlu mengoordinasikan perubahan skema dengan layanan mikro “Pelanggan”. Pola ini tidak mengurangi dependensi antar tim pengembangan, dan memperkenalkan runtime coupling karena semua microservices berbagi database yang sama. Misalnya, transaksi “Penjualan” yang berjalan lama dapat mengunci tabel “Pelanggan” dan ini memblokir transaksi “Pelanggan”.
![\[Shared-database-per-service pola\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/modernization-data-persistence/images/enabling-diagram7.png)
Anda harus mempertimbangkan untuk menggunakan pola ini jika:
+ Anda tidak ingin terlalu banyak refactoring dari basis kode yang ada.
+ Anda menegakkan konsistensi data dengan menggunakan transaksi yang memberikan atomisitas, konsistensi, isolasi, dan daya tahan (ACID).
+ Anda ingin memelihara dan mengoperasikan hanya satu database.
+ Menerapkan database-per-service pola ini sulit karena saling ketergantungan di antara layanan mikro Anda yang ada.
+ Anda tidak ingin sepenuhnya mendesain ulang lapisan data yang ada.