Browser ini sudah tidak didukung.
Mutakhirkan ke Microsoft Edge untuk memanfaatkan fitur, pembaruan keamanan, dan dukungan teknis terkini.
Artikel ini menyajikan pola kunci untuk arsitektur misi penting di Azure. Terapkan pola ini saat Anda memulai proses desain, lalu pilih komponen yang paling cocok untuk kebutuhan bisnis Anda. Artikel ini merekomendasikan pendekatan desain star utara dan menyertakan contoh lain dengan komponen teknologi umum.
Kami menyarankan agar Anda mengevaluasi area desain utama, menentukan alur pengguna dan sistem penting yang menggunakan komponen yang mendasar, dan mengembangkan matriks sumber daya Azure dan konfigurasinya sambil mengingat karakteristik berikut.
| Karakteristik | Pertimbangan |
|---|---|
| Seumur hidup | Berapa masa pakai sumber daya yang diharapkan, relatif terhadap sumber daya lain dalam solusi? Haruskah sumber daya hidup lebih lama atau berbagi masa pakai dengan seluruh sistem atau wilayah, atau harus bersifat sementara? |
| Provinsi | Dampak apa yang akan terjadi pada status persisten pada lapisan ini pada keandalan atau pengelolaan? |
| Jangkauan | Apakah sumber daya diperlukan untuk didistribusikan secara global? Dapatkah sumber daya berkomunikasi dengan sumber daya lain, yang terletak secara global atau di dalam wilayah tersebut? |
| Dependensi | Apa saja dependensi pada sumber daya lain? |
| Batas skala | Throughput apa yang diharapkan untuk sumber daya tersebut? Berapa banyak skala yang disediakan oleh sumber daya agar sesuai dengan permintaan tersebut? |
| Ketersediaan/pemulihan bencana | Apa dampaknya pada ketersediaan dari bencana pada lapisan ini? Apakah itu menyebabkan pemadaman sistemik atau hanya masalah kapasitas atau ketersediaan yang dilokalkan? |
Penting
Artikel ini adalah bagian dari seri beban kerja misi penting Azure Well-Architected . Jika Anda tidak terbiasa dengan seri ini, kami sarankan Anda memulai dengan apa itu beban kerja misi penting?
Sumber daya tertentu dibagikan secara global oleh sumber daya yang disebarkan di setiap wilayah. Contoh umum adalah sumber daya yang digunakan untuk mendistribusikan lalu lintas di beberapa wilayah, menyimpan status permanen untuk seluruh aplikasi, dan memantau sumber daya untuk mereka.
| Karakteristik | Pertimbangan |
|---|---|
| Seumur hidup | Sumber daya ini diperkirakan akan hidup lama (non-ephemeral). Masa pakainya mencakup masa pakai sistem atau lebih lama. Seringkali sumber daya dikelola dengan pembaruan data dan sarana kontrol di tempat, dengan asumsi mereka mendukung operasi pembaruan tanpa waktu henti. |
| Provinsi | Karena sumber daya ini ada setidaknya untuk masa pakai sistem, lapisan ini sering bertanggung jawab untuk menyimpan status global yang direplikasi secara geografis. |
| Jangkauan | Sumber daya harus didistribusikan dan direplikasi secara global ke wilayah yang menghosting sumber daya tersebut. Disarankan agar sumber daya ini berkomunikasi dengan sumber daya regional atau lainnya dengan latensi rendah dan konsistensi yang diinginkan. |
| Dependensi | Sumber daya harus menghindari dependensi pada sumber daya regional karena tidak tersedianya sumber daya dapat menjadi penyebab kegagalan global. Misalnya, sertifikat atau rahasia yang disimpan dalam satu vault dapat berdampak global jika ada kegagalan regional di mana vault berada. |
| Batas skala | Seringkali sumber daya ini adalah instans singleton dalam sistem, dan sumber daya tersebut harus dapat menskalakan sewaktu-waktu sehingga mereka dapat menangani throughput sistem secara keseluruhan. |
| Ketersediaan/pemulihan bencana | Sumber daya regional dan stempel dapat menggunakan sumber daya global. Sangat penting bahwa sumber daya global dikonfigurasi dengan ketersediaan tinggi dan pemulihan bencana untuk kesehatan seluruh sistem. |
Stempel berisi aplikasi dan sumber daya yang berpartisipasi dalam menyelesaikan transaksi bisnis. Stempel biasanya sesuai dengan penyebaran ke wilayah Azure. Meskipun suatu wilayah dapat memiliki lebih dari satu stempel.
| Karakteristik | Pertimbangan |
|---|---|
| Seumur hidup | Sumber daya diharapkan memiliki rentang hidup pendek (sementara) dengan niat bahwa sumber daya dapat ditambahkan dan dihapus secara dinamis sementara sumber daya regional di luar stempel terus bertahan. Sifat sementara diperlukan untuk memberikan lebih banyak ketahanan, skala, dan kedekatan dengan pengguna. |
| Provinsi | Karena stempel bersifat sementara dan akan dihancurkan dengan setiap penyebaran, stempel harus tanpa status sebanyak mungkin. |
| Jangkauan | Dapat berkomunikasi dengan sumber daya regional dan global. Namun, komunikasi dengan wilayah lain atau stempel lain harus dihindari. |
| Dependensi | Sumber daya stempel harus independen. Mereka diharapkan memiliki dependensi regional dan global tetapi tidak boleh mengandalkan komponen di stempel lain di wilayah yang sama atau lainnya. |
| Batas skala | Throughput ditetapkan melalui pengujian. Throughput stempel keseluruhan terbatas pada sumber daya dengan performa paling sedikit. Throughput stempel perlu memperkirakan tingkat permintaan tinggi yang disebabkan oleh failover ke stempel lain. |
| Ketersediaan/pemulihan bencana | Karena sifat stempel sementara, pemulihan bencana dilakukan dengan menyebarkan ulang stempel. Jika sumber daya dalam keadaan tidak sehat, stempel, secara keseluruhan, dapat dihancurkan dan disebarkan ulang. |
Sistem dapat memiliki sumber daya yang disebarkan di wilayah tetapi lebih lama dari sumber daya stempel. Misalnya, sumber daya pengamatan yang memantau sumber daya di tingkat regional, termasuk stempel.
| Karakteristik | Pertimbangan |
|---|---|
| Seumur hidup | Sumber daya berbagi masa pakai wilayah dan keluar menjalankan sumber daya stempel. |
| Provinsi | Status yang disimpan di suatu wilayah tidak dapat hidup melebihi masa pakai wilayah tersebut. Jika status perlu dibagikan di seluruh wilayah, pertimbangkan untuk menggunakan penyimpanan data global. |
| Jangkauan | Sumber daya tidak perlu didistribusikan secara global. Komunikasi langsung dengan wilayah lain harus dihindari dengan biaya apa pun. |
| Dependensi | Sumber daya dapat memiliki dependensi pada sumber daya global, tetapi tidak pada sumber daya stempel karena stempel dimaksudkan untuk berumur pendek. |
| Batas skala | Tentukan batas skala sumber daya regional dengan menggabungkan semua stempel dalam wilayah tersebut. |
Contoh garis besar ini berfungsi sebagai arsitektur star utara yang direkomendasikan untuk aplikasi misi penting. Garis besar sangat merekomendasikan kontainerisasi dan menggunakan orkestrator kontainer untuk platform aplikasi. Garis besar menggunakan Azure Kubernetes Service (AKS).
Lihat Beban kerja misi kritis yang dirancang dengan baik: Kontainerisasi.
Jika Anda baru memulai perjalanan misi penting, gunakan arsitektur ini sebagai referensi. Beban kerja diakses melalui titik akhir publik dan tidak memerlukan konektivitas jaringan privat ke sumber daya perusahaan lain.
Arsitektur ini dibangun berdasarkan arsitektur garis besar. Desain diperluas untuk menyediakan kontrol jaringan yang ketat untuk mencegah akses publik yang tidak sah dari internet ke sumber daya beban kerja.
Arsitektur ini sesuai jika Anda menyebarkan beban kerja dalam penyiapan perusahaan di mana integrasi dalam organisasi yang lebih luas diperlukan. Beban kerja menggunakan layanan bersama terpusat, membutuhkan konektivitas lokal, dan terintegrasi dengan beban kerja lain dalam perusahaan. Ini disebarkan dalam langganan zona pendaratan Azure yang mewarisi dari grup manajemen Corp.
Arsitektur ini memperluas referensi garis besar dengan mempertimbangkan App Services sebagai teknologi hosting aplikasi utama, menyediakan lingkungan yang mudah digunakan untuk penyebaran kontainer.
Kami menyarankan agar Anda menggunakan panduan desain yang disediakan untuk menavigasi keputusan desain utama untuk mencapai solusi yang optimal. Untuk informasi, lihat Apa saja area desain utamanya?
Tinjau praktik terbaik untuk merancang skenario aplikasi misi penting.