IOSOR ความรู้
เมื่อใดที่การจำกัดเทแนนต์แบบฝังตัวต้องหยุดการส่ง
ขีดจำกัดการแบ่งปันอย่างเป็นธรรมภายในผลิตภัณฑ์ ISV ต้องหยุดการส่งสำหรับเทแนนต์นั้นอย่างเด็ดขาด — ห้ามส่งคืน API 200 หลอกลวงว่าจัดส่งสำเร็จเมื่อชนขีดจำกัด
SaaS แบบฝังตัวสำหรับมัลติเทแนนต์จำเป็นต้องมีขีดจำกัดการแบ่งปันอย่างเป็นธรรม เพื่อไม่ให้เทแนนต์ที่ใช้งานหนักรายเดียวใช้ ยอดเงินชำระล่วงหน้าร่วม จนหมด หรือกระทบต่อเทแนนต์อื่น ขีดจำกัดที่เพียงแค่แสดงคำเตือนบนแดชบอร์ดในขณะที่ API ยังคงรับการส่งข้อมูลเป็นเรื่องที่ไร้ประโยชน์ เมื่อเทแนนต์ชนขีดจำกัด การส่งสำหรับเทแนนต์นั้นต้องหยุดลงพร้อมกับข้อผิดพลาดของผลิตภัณฑ์ที่ชัดเจนและสถานะ API ที่ไม่สำเร็จ การตอบกลับ 200 เท็จจะทำลายการกระทบยอดและส่งเสริมการใช้งานที่ไม่ถูกต้อง
ขีดจำกัดจะอยู่ในชั้นผลิตภัณฑ์ ISV — ไม่ใช่สิ่งทดแทนขีดจำกัดอัตราซับเทแนนต์ของพาร์ทเนอร์ และไม่ใช่การทิ้งคิวแบบเงียบๆ การหยุดที่โปร่งใสหมายถึง: UI ของ SaaS แสดงว่าหยุดชั่วคราวหรือชนขีดจำกัด บริการฝังตัวปฏิเสธการส่งใหม่สำหรับ tenant ID นั้น และทีมปฏิบัติการสามารถส่งออกข้อมูลผู้ที่ชนขีดจำกัดได้
กำหนดสัญญาการหยุดก่อนเริ่มทราฟฟิกทดลอง: หน่วยของขีดจำกัด (ข้อความ / ค่าใช้จ่าย / วัน) หน้าต่างการรีเซ็ต ผู้ที่มีสิทธิ์ปรับเพิ่ม และสิ่งที่ผู้ใช้ปลายทางจะเห็น
เมื่อชนขีดจำกัดต้องปฏิเสธการส่ง ไม่ใช่เตือนแบบนุ่มนวลตลอดไป
การเตือนแบบนุ่มนวลเป็นเพียงการแจ้งเตือนล่วงหน้าเท่านั้น เมื่อถึงขีดจำกัดสูงสุด บริการฝังตัวจะส่งคืนข้อผิดพลาดเกี่ยวกับขีดจำกัดเทแนนต์และไม่เรียกใช้ messaging API สำหรับคำขอใหม่ ข้อความที่อยู่ในคิวอาจดำเนินการจนเสร็จ แต่คำขอ OTP และแคมเปญใหม่จะต้องรอการรีเซ็ตหรือการอนุมัติการเพิ่มขีดจำกัด
บันทึกการปฏิเสธพร้อม tenant ID กฎขีดจำกัด และประทับเวลา ทีมสนับสนุนจำเป็นต้องใช้ข้อมูลนี้เมื่อลูกค้าแจ้งว่าระบบส่งข้อความทำงานผิดปกติ
ห้ามออกสถานะจัดส่งสำเร็จบนเส้นทางที่ถูกจำกัด
| การตอบกลับ | อนุญาตเมื่อใด | ข้อห้ามเมื่อ |
|---|---|---|
| ผลิตภัณฑ์ถูกจำกัด / หยุดชั่วคราว | ถึงขีดจำกัดสูงสุด | เส้นทางปฏิเสธตามขีดจำกัด |
| HTTP ไม่สำเร็จ / ข้อผิดพลาด | ปฏิเสธตามขีดจำกัด | — |
| จัดส่งสำเร็จ / 200 | เส้นทางยอมรับจริง | ปฏิเสธตามขีดจำกัด |
| การทิ้งแบบเงียบ | ไม่เคย | เสมอ |
| การทิ้งแบบเงียบและการส่งคืน 200 เท็จมีลักษณะเหมือนคิวล้นที่แกล้งทำเป็นสำเร็จ |
ปรับขีดจำกัดผลิตภัณฑ์ให้สอดคล้องกับเส้นหยุดกระเป๋าเงิน
เทแนนต์อาจยังอยู่ภายใต้ขีดจำกัดของตนเอง ในขณะที่เส้นหยุดกระเป๋าเงินของ ISV เป็นสีแดงแล้ว ในกรณีนี้ เส้นทางฝังตัวทั้งหมดจะหยุดชั่วคราว — ไม่ใช่เฉพาะเทแนนต์ที่ใช้งานหนัก กระเป๋าเงินที่มีสถานะปกติไม่ได้เว้นเว้นให้เทแนนต์ที่ใช้โควตาของตนหมดแล้ว ใช้ภาษาสถานะร่วมกัน: เทแนนต์ถูกจำกัด VS บัญชีถูกหยุดชั่วคราว
คำขอเพิ่มขีดจำกัดต้องมีผู้อนุมัติที่ระบุชื่อ การเพิ่มขีดจำกัดแบบไม่จำกัดด้วยตนเองจะทำลายหลักการแบ่งปันอย่างเป็นธรรม
ทดสอบการหยุดใน Staging ด้วยเทแนนต์ที่ใช้งานหนัก
ก่อนใช้งานจริง ให้ทำการซ้อมใน Staging: ให้เทแนนต์รายหนึ่งส่ง OTP จำนวนมากจนชนขีดจำกัด เทแนนต์อื่นยังคงส่งได้ตามปกติ และรายงานการส่งออกแสดงแถวการปฏิเสธโดยไม่มีสถานะสำเร็จเท็จ หากเทแนนต์อื่นหยุดทำงาน แสดงว่าขอบเขตของขีดจำกัดถูกตั้งค่าไม่ถูกต้อง
เส้นทางปฏิบัติการที่เกี่ยวข้อง
- การบังคับใช้ขีดจำกัดอัตราอย่างปลอดภัยสำหรับบัญชีมัลติเทแนนต์
- คิวล้น: หยุด ไม่ใช่การทิ้งแบบเงียบๆ
- เส้นหยุดกระเป๋าเงินก่อนทราฟฟิกใช้งานจริง
เริ่มต้นกับ IOSOR
เปิดคอนโซล IOSOR แล้วตั้งค่าขีดจำกัดส่วนแบ่งแฟร์แชร์ของซับเทแนนต์เพื่อบังคับปฏิเสธคำขอที่ประตูส่งทันทีเมื่อถึงโควตา กำหนดค่าการแมปการตอบกลับของ API เพื่อให้เทแนนต์ที่ถึงขีดจำกัดได้รับข้อผิดพลาดสถานะที่ชัดเจนแทนที่จะเป็นเพย์โหลดที่ยอมรับ ดำเนินการทดสอบในระบบ staging กับเทแนนต์ที่มีปริมาณมากเพื่อให้แน่ใจว่าทราฟฟิกของเทแนนต์อื่นยังคงไหลลื่น ขณะที่การส่งที่ถูกจำกัดถูกบันทึกเป็นรายการบันทึกการปฏิเสธที่ชัดเจน
สรุป IOSOR
คำเตือนแบบอ่อนไม่สามารถปกป้องคิวปลายทางได้เมื่อซับเทแนนต์เดี่ยวมีปริมาณพุ่งสูง คู่มือการดำเนินงานนี้พิสูจน์แล้วว่าขีดจำกัดแฟร์แชร์ต้องทำหน้าที่เป็นการปฏิเสธที่ประตูส่งทันที โดยรักษาระการแยก 100 เปอร์เซ็นต์ระหว่างการชนขีดจำกัดของเทแนนต์และเส้นหยุดวอลเล็ตส่วนกลาง
ควรส่งคืนการตอบกลับสถานะที่จำกัดที่แตกต่างกันไปยังเลเยอร์แอปพลิเคชันของคุณ เพื่อให้ซับเทแนนต์สามารถขอเพิ่มขีดจำกัดได้อย่างเหมาะสม ห้ามส่งคืนการยอมรับสถานะ 200 ปอมหรือรายงานการส่งมอบปลอมสำหรับการพยายามที่ถูกจำกัด เนื่องจากความสำเร็จปลอมเหล่านี้จะปกปิดความล้มเหลวในการส่งมอบจริงและทำลายความสามารถในการตรวจสอบของเทแนนต์
คู่มือนี้มีประโยชน์ไหม?
คู่มือที่เกี่ยวข้อง
- การฝัง API เปรียบเทียบกับพอร์ทัลพาร์ทเนอร์ไวท์เลเบล
ผลิตภัณฑ์ SaaS ที่ฝังการส่งข้อความจะอยู่บนพื้นผิว ISV พอร์ทัลพาร์ทเนอร์ไวท์เลเบลจะอยู่ภายใต้ Partner — ห้ามผสมผสานแบรนด์ คีย์ และความเป็นเจ้าของฝ่ายปฏิบัติการ
- การส่งของผู้ใช้ปลายทางยังคงตัดบัญชีแยกประเภทเติมเงินเดียว
การส่งแบบฝังยังคงตัดเงินจากกระเป๋าเงินเติมเงินของ ISV อย่าสร้างบัญชีแยกประเภทที่สองที่ผลิตภัณฑ์ไม่ได้ให้เงินทุน — การถือครอง การลองใหม่ และ idempotency ยังคงโปร่งใส