Kongsi melalui

Cadangan untuk mengendalikan kerosakan sementara

Terpakai kepada cadangan senarai semak Kebolehpercayaan Well-Architected ini Power Platform :

RE:05 Mengukuhkan daya tahan beban kerja anda dengan melaksanakan pengendalian ralat dan pengendalian kerosakan sementara. Bina keupayaan ke dalam penyelesaian untuk mengendalikan kegagalan komponen dan ralat sementara.

Panduan ini menerangkan cadangan untuk mengendalikan kerosakan sementara dalam aplikasi awan anda. Semua aplikasi yang berkomunikasi dengan perkhidmatan jauh dan sumber mestilah sensitif kepada kerosakan sementara. Ini adalah benar terutamanya untuk aplikasi yang dijalankan dalam awan, di mana, disebabkan sifat persekitaran dan ketersambungan melalui internet, jenis kesalahan ini mungkin akan dihadapi dengan lebih kerap. Kesalahan sementara termasuk kehilangan seketika sambungan rangkaian kepada komponen dan perkhidmatan, ketidaksediaan sementara perkhidmatan dan tamat masa yang berlaku apabila perkhidmatan sibuk. Kesilapan ini selalunya membetulkan diri sendiri, jadi, jika tindakan itu diulang selepas penangguhan yang sesuai, kemungkinan besar ia akan berjaya.

Strategi reka bentuk utama

Kesalahan sementara boleh berlaku dalam mana-mana persekitaran, pada mana-mana platform atau sistem pengendalian, dan dalam sebarang jenis aplikasi.

Cabaran

Kesalahan sementara boleh memberi kesan yang ketara ke atas persepsi ketersediaan aplikasi, walaupun ia telah diuji secara menyeluruh dalam semua keadaan yang boleh dijangka. Untuk memastikan bahawa Power Platform beban kerja anda boleh beroperasi dengan pasti, anda perlu memastikan bahawa beban kerja anda boleh bertindak balas terhadap cabaran berikut:

  • Aplikasi mesti dapat mengesan ralat apabila ia berlaku dan menentukan sama ada ralat itu berkemungkinan bersifat sementara, tahan lama atau merupakan kegagalan terminal. Sumber yang berbeza mungkin akan mengembalikan respons yang berbeza apabila berlaku kerosakan, dan respons ini juga boleh berbeza-beza bergantung pada konteks operasi. Sebagai contoh, respons untuk ralat semasa aplikasi mendapatkan data daripada penyambung tersuai mungkin berbeza daripada respons apabila aplikasi menjalankan aliran awan dan menunggu respons.

  • Aplikasi mesti boleh mencuba semula operasi jika ia menentukan bahawa kerosakan itu mungkin bersifat sementara.

  • Aplikasi mesti menggunakan strategi yang sesuai untuk percubaan semula. Strategi menentukan bilangan kali aplikasi harus mencuba semula, kelewatan antara setiap percubaan dan tindakan yang perlu diambil selepas percubaan yang gagal. Bilangan percubaan yang sesuai dan kelewatan antara setiap satu selalunya sukar untuk ditentukan. Strategi berbeza-beza bergantung pada jenis sumber dan pada keadaan operasi semasa sumber dan aplikasi.

Garis panduan am

Garis panduan berikut boleh membantu anda mereka bentuk mekanisme pengendalian kerosakan sementara yang sesuai untuk aplikasi anda.

Tentukan sama ada terdapat mekanisme cuba semula terbina dalam

Sesetengah perkhidmatan yang anda sambungkan mungkin telah menyediakan mekanisme pengendalian kerosakan sementara. Dasar cuba semula yang digunakannya biasanya disesuaikan dengan sifat dan keperluan perkhidmatan sasaran. Sebagai alternatif, antara muka REST untuk perkhidmatan mungkin mengembalikan maklumat yang boleh membantu anda menentukan sama ada percubaan semula adalah sesuai dan berapa lama untuk menunggu sebelum percubaan cuba semula seterusnya.

Anda harus menggunakan mekanisme cuba semula terbina dalam apabila ia tersedia, melainkan anda mempunyai keperluan khusus dan difahami dengan baik yang menjadikan tingkah laku cuba semula yang berbeza lebih sesuai.

Tentukan sama ada operasi itu sesuai untuk mencuba semula

Lakukan operasi cuba semula hanya apabila ralat adalah sementara (biasanya ditunjukkan oleh sifat ralat) dan apabila terdapat sekurang-kurangnya kemungkinan operasi itu akan berjaya apabila dicuba semula. Tiada gunanya mencuba semula operasi yang mencuba operasi tidak sah, seperti mengemas kini baris dalam Microsoft Dataverse yang tidak wujud atau pengguna tidak mempunyai kebenaran atau memanggil titik akhir API yang tidak wujud.

Laksanakan percubaan semula hanya apabila anda boleh menentukan kesan penuh berbuat demikian dan apabila syaratnya difahami dengan baik dan boleh disahkan. Ingat bahawa ralat yang dikembalikan daripada sumber dan perkhidmatan di luar kawalan anda mungkin berubah dari semasa ke semasa dan anda mungkin perlu menyemak semula logik pengesanan kesalahan sementara anda.

Apabila anda membangunkan komponen atau perkhidmatan individu yang dipanggil daripada aplikasi anda, pastikan anda mengembalikan kod ralat dan mesej yang membantu pelanggan menentukan sama ada mereka perlu mencuba semula operasi yang gagal. Pertimbangkan untuk menunjukkan sama ada pelanggan perlu mencuba semula operasi; contohnya, dengan mengembalikan nilai isTransient . Jika anda membina perkhidmatan web, pertimbangkan untuk mengembalikan ralat tersuai yang ditakrifkan dalam kontrak perkhidmatan anda.

Tentukan kiraan dan selang percubaan semula yang sesuai

Optimumkan kiraan cuba semula dan selang untuk jenis kes penggunaan. Jika anda tidak mencuba semula cukup masa, aplikasi tidak dapat menyelesaikan operasi dan mungkin akan gagal. Jika anda mencuba semula terlalu banyak kali, atau dengan selang masa yang terlalu pendek antara percubaan, aplikasi mungkin menyimpan sumber untuk tempoh yang lama, yang menjejaskan kesihatan aplikasi.

Sesuaikan nilai untuk selang masa dan bilangan percubaan cuba semula dengan jenis operasi. Sebagai contoh, jika operasi adalah sebahagian daripada interaksi pengguna, selang harus pendek dan hanya beberapa percubaan semula harus dicuba. Dengan menggunakan pendekatan ini, anda boleh mengelak daripada membuat pengguna menunggu jawapan. Jika operasi adalah sebahagian daripada aliran kerja yang berjalan lama atau kritikal, di mana membatalkan dan memulakan semula proses adalah mahal atau memakan masa, adalah wajar untuk menunggu lebih lama antara percubaan dan mencuba semula lebih banyak kali.

Perlu diingat bahawa menentukan selang yang sesuai antara percubaan semula adalah bahagian yang paling sukar untuk mereka bentuk strategi yang berjaya. Strategi biasa menggunakan jenis selang percubaan semula berikut:

  • Selang eksponen. Aplikasi menunggu masa yang singkat sebelum percubaan semula pertama dan kemudian secara eksponen meningkatkan masa antara setiap percubaan semula berikutnya. Contohnya, ia mungkin mencuba semula operasi selepas 3 saat, 12 saat, 30 saat dan seterusnya.

  • Selang tetap. Aplikasi menunggu untuk tempoh masa yang sama antara setiap percubaan.

  • Cuba semula segera. Kadangkala kerosakan sementara adalah ringkas, dan mencuba semula operasi dengan segera adalah sesuai kerana ia mungkin berjaya jika kesalahan itu dibersihkan dalam masa yang diperlukan untuk menghantar permintaan seterusnya. Walau bagaimanapun, tidak boleh ada lebih daripada satu percubaan cuba semula serta-merta. Anda harus beralih kepada strategi alternatif, seperti selang eksponen atau tindakan sandaran, jika percubaan semula segera gagal.

Sebagai garis panduan umum, gunakan strategi selang eksponen untuk operasi latar belakang, dan gunakan strategi percubaan semula selang segera atau tetap untuk operasi interaktif. Dalam kedua-dua kes, anda harus memilih kelewatan dan kiraan cuba semula supaya kependaman maksimum untuk semua percubaan cuba semula berada dalam keperluan kependaman hujung ke hujung yang diperlukan.

Pertimbangkan gabungan semua faktor yang menyumbang kepada tamat masa maksimum keseluruhan untuk operasi yang dicuba semula. Faktor ini termasuk masa yang diperlukan untuk sambungan yang gagal menghasilkan respons, kelewatan antara percubaan mencuba semula dan bilangan percubaan semula maksimum. Jumlah semua masa ini boleh mengakibatkan masa operasi keseluruhan yang panjang, terutamanya apabila anda menggunakan strategi kelewatan eksponen di mana selang antara percubaan semula berkembang pesat selepas setiap kegagalan. Jika proses mesti memenuhi perjanjian peringkat perkhidmatan (SLA) khusus, masa operasi keseluruhan, termasuk semua tamat masa dan kelewatan, mestilah dalam had yang ditakrifkan dalam SLA.

Jangan laksanakan strategi cuba semula yang terlalu agresif. Ini ialah strategi yang mempunyai selang yang terlalu pendek atau percubaan semula yang terlalu kerap. Mereka boleh memberi kesan buruk pada sumber atau perkhidmatan sasaran. Strategi ini mungkin menghalang sumber atau perkhidmatan daripada pulih daripada keadaan terlebih beban dan ia akan terus menyekat atau menolak permintaan. Senario ini menghasilkan lingkaran ganas, di mana semakin banyak permintaan dihantar ke sumber atau perkhidmatan. Akibatnya, keupayaannya untuk pulih semakin berkurangan.

Pertimbangkan tamat masa operasi apabila anda memilih selang cuba semula untuk mengelak daripada melancarkan percubaan berikutnya dengan serta-merta (contohnya, jika tempoh tamat masa adalah serupa dengan selang percubaan semula).

Gunakan jenis ralat atau kod ralat dan mesej yang dikembalikan daripada perkhidmatan untuk mengoptimumkan bilangan percubaan semula dan selang antaranya. Sebagai contoh, beberapa pengecualian atau kod ralat (seperti kod HTTP 503, Perkhidmatan tidak tersedia, dengan pengepala Cuba Semula Selepas dalam respons) mungkin menunjukkan tempoh ralat itu mungkin berlarutan atau perkhidmatan itu gagal dan tidak akan bertindak balas kepada sebarang percubaan berikutnya.

Elakkan anticorak

Dalam kebanyakan kes, elakkan pelaksanaan yang termasuk lapisan pendua kod cuba semula. Elakkan reka bentuk yang termasuk mekanisme percubaan semula melata atau yang melaksanakan percubaan semula pada setiap peringkat operasi yang melibatkan hierarki permintaan, melainkan anda mempunyai keperluan khusus untuk berbuat demikian. Dalam keadaan luar biasa ini, gunakan dasar yang menghalang bilangan percubaan semula dan tempoh kelewatan yang berlebihan dan pastikan anda memahami akibatnya. Sebagai contoh, katakan satu komponen membuat permintaan kepada komponen lain, yang kemudiannya mengakses perkhidmatan sasaran. Jika anda melaksanakan percubaan semula dengan kiraan tiga pada kedua-dua panggilan, terdapat sembilan percubaan semula secara keseluruhan terhadap perkhidmatan. Banyak perkhidmatan dan sumber melaksanakan mekanisme percubaan semula terbina dalam. Anda harus menyiasat cara anda boleh menyahdayakan atau mengubah suai mekanisme ini jika anda perlu melaksanakan percubaan semula pada tahap yang lebih tinggi.

Jangan sekali-kali melaksanakan mekanisme percubaan semula yang tidak berkesudahan. Melakukannya berkemungkinan menghalang sumber atau perkhidmatan daripada pulih daripada situasi beban berlebihan dan menyebabkan pendikit dan sambungan yang ditolak berterusan untuk masa yang lebih lama.

Jangan sekali-kali melakukan percubaan semula segera lebih daripada sekali.

Elakkan menggunakan selang percubaan semula tetap apabila anda mengakses perkhidmatan dan sumber pada Azure, terutamanya apabila anda mempunyai bilangan percubaan semula yang tinggi. Pendekatan terbaik dalam senario ini ialah strategi selang eksponen.

Uji strategi dan pelaksanaan percubaan semula anda

Uji sepenuhnya strategi percubaan semula anda dalam satu set keadaan seluas mungkin, terutamanya apabila kedua-dua aplikasi dan sumber atau perkhidmatan sasaran yang digunakannya berada di bawah beban yang melampau. Untuk menyemak tingkah laku semasa ujian, anda boleh:

  • Suntik kerosakan sementara dan tidak sementara ke dalam perkhidmatan. Contohnya, hantar permintaan tidak sah atau tambah kod yang mengesan permintaan ujian dan bertindak balas dengan pelbagai jenis ralat.

  • Cipta mockup sumber atau perkhidmatan yang mengembalikan pelbagai ralat yang mungkin dikembalikan oleh perkhidmatan sebenar. Meliputi semua jenis ralat yang strategi percubaan semula anda direka bentuk untuk dikesan.

  • Untuk perkhidmatan tersuai yang anda cipta dan gunakan, paksa ralat sementara berlaku dengan menyahdayakan atau membebankan perkhidmatan buat sementara waktu. (Jangan cuba membebankan sebarang sumber kongsi atau perkhidmatan dikongsi dalam Azure.)

  • Apabila menguji daya tahan aplikasi web klien terhadap kesalahan sementara, gunakan alat pembangun penyemak imbas atau keupayaan rangka kerja ujian anda untuk mengejek atau menyekat permintaan rangkaian.

  • Lakukan faktor beban tinggi dan ujian serentak untuk memastikan mekanisme dan strategi percubaan semula berfungsi dengan betul dalam keadaan ini. Ujian ini juga membantu memastikan bahawa percubaan semula tidak memberi kesan buruk kepada operasi pelanggan atau menyebabkan pencemaran silang antara permintaan.

Urus konfigurasi dasar percubaan semula

Dasar percubaan semula ialah gabungan semua elemen strategi percubaan semula anda. Ia mentakrifkan mekanisme pengesanan yang menentukan sama ada kesalahan berkemungkinan sementara, jenis selang untuk digunakan (seperti tetap atau eksponen), nilai selang sebenar dan bilangan kali untuk mencuba semula.

Manfaatkan strategi percubaan semula terbina dalam atau lalai tetapi hanya apabila ia sesuai untuk senario anda. Strategi ini biasanya generik. Dalam sesetengah senario, mereka mungkin semua yang anda perlukan, tetapi dalam senario lain mereka tidak menawarkan pelbagai pilihan untuk memenuhi keperluan khusus anda. Untuk menentukan nilai yang paling sesuai, anda perlu melakukan ujian untuk memahami cara tetapan mempengaruhi aplikasi anda.

Log dan jejaki kerosakan sementara dan tidak sementara

Sebagai sebahagian daripada strategi percubaan semula anda, sertakan pengendalian pengecualian dan instrumentasi lain yang mencatat percubaan semula. Kegagalan sementara sekali-sekala dan percubaan semula dijangka dan tidak menunjukkan masalah. Walau bagaimanapun, bilangan percubaan yang kerap dan semakin meningkat selalunya merupakan penunjuk masalah yang mungkin menyebabkan kegagalan atau yang merendahkan prestasi dan ketersediaan aplikasi.

Log kesalahan sementara sebagai entri amaran dan bukannya sebagai entri ralat supaya sistem pemantauan tidak mengesannya sebagai ralat aplikasi yang mungkin mencetuskan amaran palsu.

Pertimbangkan untuk menyimpan nilai dalam entri log anda yang menunjukkan sama ada percubaan semula disebabkan oleh pendikit dalam perkhidmatan atau oleh jenis kesalahan lain, seperti kegagalan sambungan, supaya anda boleh membezakannya semasa analisis data. Peningkatan dalam bilangan ralat pendikit selalunya merupakan penunjuk kecacatan reka bentuk dalam aplikasi atau keperluan untuk menambah kapasiti premium kepada persekitaran.

Pertimbangkan untuk melaksanakan sistem telemetri dan pemantauan yang boleh menimbulkan amaran apabila bilangan dan kadar kegagalan, purata bilangan percubaan semula atau masa keseluruhan yang berlalu sebelum operasi berjaya meningkat.

Urus operasi yang terus gagal

Pertimbangkan cara mengendalikan operasi yang terus gagal pada setiap percubaan. Situasi seperti ini tidak dapat dielakkan.

Walaupun strategi percubaan semula mentakrifkan bilangan maksimum kali operasi perlu dicuba semula, ia tidak menghalang aplikasi daripada mengulangi operasi dengan bilangan percubaan semula yang sama. Sebagai contoh, menyerahkan borang dalam permohonan anda mungkin mencetuskan aliran. Strategi percubaan semula mungkin mengesan tamat masa sambungan dan menganggapnya sebagai kesalahan sementara. Aliran akan mencuba semula operasi beberapa kali yang ditentukan dan kemudian berputus asa. Walau bagaimanapun, apabila pengguna yang sama atau baharu cuba menyerahkan borang sekali lagi, operasi dicuba sekali lagi, walaupun ia mungkin terus gagal.

Aplikasi ini boleh menguji perkhidmatan secara berkala, secara sekejap-sekejap dan dengan selang masa yang panjang antara permintaan, untuk mengesan apabila ia tersedia. Selang masa yang sesuai bergantung pada faktor seperti kritikal operasi dan sifat perkhidmatan. Ia mungkin antara beberapa minit dan beberapa jam. Apabila ujian berjaya, aplikasi boleh meneruskan operasi biasa dan menghantar permintaan kepada perkhidmatan yang baru dipulihkan.

Sementara itu, anda mungkin boleh melakukan beberapa operasi alternatif berdasarkan harapan bahawa perkhidmatan itu akan tersedia tidak lama lagi. Sebagai contoh, mungkin sesuai untuk menyimpan permintaan untuk perkhidmatan dalam baris gilir atau stor data dan mencubanya semula kemudian. Atau anda mungkin perlu mengembalikan mesej kepada pengguna untuk menunjukkan bahawa aplikasi tidak tersedia.

Pertimbangan lain

Apabila anda memutuskan nilai untuk bilangan percubaan semula dan selang percubaan semula untuk dasar, pertimbangkan sama ada operasi pada perkhidmatan atau sumber adalah sebahagian daripada operasi yang telah lama berjalan atau berbilang langkah. Mungkin sukar atau mahal untuk mengimbangi semua langkah operasi lain yang telah berjaya apabila seseorang gagal. Dalam kes ini, selang masa yang panjang dan sebilangan besar percubaan semula mungkin boleh diterima, selagi strategi itu tidak menyekat operasi lain dengan menahan atau mengunci sumber yang terhad.

Pertimbangkan sama ada mencuba semula operasi yang sama boleh menyebabkan ketidakkonsistenan dalam data. Jika beberapa bahagian proses berbilang langkah diulang dan operasi tidak idempoten, ketidakkonsistenan mungkin berlaku. Contohnya, jika operasi yang memasukkan rekod ke dalam Microsoft Dataverse diulang, ia mungkin menyebabkan nilai yang salah dalam jadual. Atau, jika anda mengulangi operasi yang menghantar pemberitahuan kepada pengguna, mereka mungkin menerima mesej pendua.

Pertimbangkan skop operasi yang dicuba semula. Sebagai contoh, mungkin lebih mudah untuk melaksanakan kod percubaan semula pada tahap yang merangkumi beberapa operasi dan mencuba semula semuanya jika satu gagal. Walau bagaimanapun, berbuat demikian mungkin mengakibatkan isu idempotensi atau operasi rollback yang tidak perlu.

Jika anda memilih skop percubaan semula yang merangkumi beberapa operasi, pertimbangkan jumlah kependaman kesemuanya apabila anda menentukan selang percubaan semula, apabila anda memantau masa berlalu operasi dan sebelum anda menimbulkan amaran untuk kegagalan.

Power Platform Kemudahan

Bahagian berikut menerangkan mekanisme yang boleh anda gunakan untuk menguruskan kesalahan sementara.

Power Automate

Power Automate termasuk ciri untuk mencuba semula tindakan jika gagal. Konfigurasikan ini pada tahap setiap tindakan. Ketahui tentang mengurangkan risiko dan merancang pengendalian ralat dalam Power Automate projek. Power Automate juga menawarkan tindakan untuk mengembalikan ralat dan data tersuai kepada apl atau aliran panggilan.

Sesetengah aliran sementara boleh disebabkan oleh had pemprosesan dan permintaan. Ketahui tentang had aliran automatik, berjadual dan segera serta had dan peruntukan permintaan.

Konfigurasikan pengendalian ralat dan pengecualian dalam aliran awan dengan menggunakan skop dan seting jalan-selepas.

Power Apps

Power Apps Apl kanvas menyediakan keupayaan untuk menyemak status sambungan, membolehkan mereka berkelakuan berbeza jika apl berada di luar talian. Ketahui cara membangunkan apl kanvas berkeupayaan luar talian.

Anda juga boleh menggunakan fungsi Error, IfError, IsError dan IsBlankOrError dalam apl kanvas untuk memutuskan perkara yang perlu dilakukan seterusnya jika ralat berlaku.

Ketahui lebih lanjut tentang pengendalian kerosakan sementara dalam Power Apps:

Azure dan penyambung tersuai

Jika beban kerja anda menyambung ke perkhidmatan Azure, ketahui cara mengendalikan kerosakan sementara menggunakan Rangka Kerja Azure Well-Architected.

Untuk mengurus respons penyambung tersuai kepada ralat, ikut piawaian pengekodan.

Application Insights

Gunakan penyepaduan Application Insights untuk log masuk ralat Power Automate dan Power Apps:

Kesinambungan perniagaan dan pemulihan bencana untuk aplikasi SaaS Dynamics 365

Senarai semak kebolehpercayaan

Rujuk set lengkap cadangan.

Senarai semak kebolehpercayaan