การแปลงเอกสารหลายสิบหรือหลายร้อยไฟล์ไม่ใช่การร้องขอเดียวที่มี payload ขนาดใหญ่ แต่เป็นกระบวนการทำงานที่ต้องการการจัดคิว, การควบคุมความพร้อมพร้อมทำงานพร้อมกัน, การจัดเก็บ, การลองใหม่, การตรวจสอบ, และวิธีที่เชื่อถือได้ในการนำเสนอผลลัพธ์ภายในแอปพลิเคชันของคุณ
สำหรับทีมที่พัฒนาบน Windows และ .NET, Doconut สามารถให้ชั้นการแสดงผลแบบฝังหลังจากไฟล์ได้รับการประมวลผล การแยกส่วนนี้สำคัญ: บริการแปลงของคุณเตรียมผลลัพธ์, ในขณะที่ Doconut SDK ให้ผู้ใช้ดูเอกสารที่รองรับภายในเว็บแอปของคุณเอง
เข้าใจบทบาทของการแปลงและการแสดงผล
เครื่องยนต์การแปลงแบบกลุ่มและตัวดูเอกสารแก้ไขปัญหาที่แตกต่างกัน:
- ชั้นการแปลง รับไฟล์ต้นฉบับและสร้างผลลัพธ์ที่ต้องการ
- ชั้นการประสานงาน ควบคุมคิว, การลองใหม่, เวลาหมด, และสถานะงาน
- ชั้นการจัดเก็บ เก็บไฟล์อินพุตและเอาต์พุตไว้เท่าที่จำเป็น
- ชั้นการแสดงผล แสดงเอกสารที่ประมวลผลแล้วภายในแอปของคุณ
การแยกความรับผิดชอบเหล่านี้ทำให้ระบบง่ายต่อการขยายและแก้ไขปัญหา อีกทั้งยังทำให้คุณเปลี่ยนตัวแปลงหรือผู้ให้บริการจัดเก็บโดยไม่ต้องออกแบบประสบการณ์เอกสารใหม่ทั้งหมด
ทำไมการประมวลผลแบบกลุ่มจึงสำคัญ
- การใช้ทรัพยากรที่ควบคุมได้ — การแปลงอาจใช้ CPU, หน่วยความจำ, และพื้นที่ดิสก์อย่างมาก คิวช่วยป้องกันไม่ให้งานจำนวนมากทำงานพร้อมกันเกินไป
- การลองใหม่ที่เชื่อถือได้ — ความล้มเหลือชั่วคราวของการจัดเก็บหรือบริการสามารถลองใหม่ได้โดยไม่ต้องให้ผู้ใช้อัปโหลดไฟล์ซ้ำ
- สถานะงานที่ชัดเจน — เอกสารแต่ละไฟล์สามารถเคลื่อนผ่านสถานะที่คาดการณ์ได้ เช่น อยู่ในคิว, กำลังประมวลผล, เสร็จสิ้น, หรือล้มเหลว
- การมองเห็นการทำงาน — ระยะเวลา, สาเหตุการล้มเหลว, ขนาดไฟล์, และจำนวนการลองใหม่สามารถบันทึกได้สำหรับทุกงาน
คอขวดทั่วไปในการแปลงแบบกลุ่ม
| คอขวด | อาการทั่วไป | การบรรเทาเชิงปฏิบัติ |
|---|---|---|
| ไฟล์ขนาดใหญ่ | การอัปโหลดหมดเวลา หรือ worker ใช้หน่วยความจำเต็ม | บังคับใช้ขีดจำกัดขนาดตามเอกสาร, สตรีมไฟล์เมื่อเป็นไปได้, และปฏิเสธอินพุตที่ไม่รองรับก่อนจัดคิว |
| งานที่ใช้เวลานาน | คำขอยังคงเปิดอยู่จนกระทั่งพร็อกซีอัพสตรีมปิด | ส่งคืนตัวระบุงานทันทีและประมวลผลไฟล์ใน worker เบื้องหลัง |
| การเพิ่มขึ้นของทราฟฟิก | การใช้ CPU และหน่วยความจำเพิ่มขึ้นอย่างรวดเร็วเมื่อผู้ใช้หลายคนอัปโหลดพร้อมกัน | จำกัดความพร้อมของ worker และใช้ back‑pressure ที่คิว |
| ความล้มเหลวชั่วคราว | การพึ่งพาการจัดเก็บหรือการแปลงล้มเหลวเป็นระยะสั้น | ใช้การลองใหม่ที่จำกัดพร้อมการหน่วงเวลาแบบเอ็กซ์โปเนนเชียลและเก็บข้อผิดพลาดต้นฉบับ |
| การเก็บรักษาไม่จำกัด | เอกสารชั่วคราวสะสมและเพิ่มค่าใช้จ่ายหรือความเสี่ยง | กำหนดกฎวงจรชีวิตสำหรับไฟล์ต้นฉบับและไฟล์ผลลัพธ์ |
| ไฟล์ที่ไม่รองรับหรือเสียหาย | worker ล้มเหลวซ้ำ ๆ กับอินพุตเดียวกัน | ตรวจสอบรูปแบบ, ขนาด, และความสมบูรณ์พื้นฐานของไฟล์ก่อนประมวลผล |
สิ่งที่ปลายทางการแปลงแบบโฮสต์อาจไม่ให้
ก่อนเลือกผู้ให้บริการการแปลง, ยืนยันว่าพวกเขารองรับ:
- รูปแบบอินพุตหลายรูปแบบและผลลัพธ์ที่แอปของคุณต้องการ
- ขีดจำกัดขนาดไฟล์และจำนวนหน้าอย่างชัดเจน
- งานแบบอะซิงโครนัสแทนการร้องขอ HTTP ที่ใช้เวลานาน
- คำขอที่ปลอดภัยต่อการลองใหม่หรือเป็น idempotent
- การประมวลผลตามภูมิภาคและการควบคุมการเก็บรักษา
- การตอบสนองข้อผิดพลาดอย่างละเอียดและบันทึกการดำเนินงาน
หน้าแปลงไฟล์เดี่ยวฟรีมักไม่สามารถทดแทน API แบบกลุ่มสำหรับการผลิตได้ เอกสารขีดจำกัดที่คุณยอมรับและออกแบบคิวให้สอดคล้องกับขีดจำกัดเหล่านั้น
สถาปัตยกรรม Windows และ .NET ที่ใช้งานได้จริง
1. ตรวจสอบก่อนจัดคิว
ตรวจสอบประเภทไฟล์ที่ระบุ, ลายเซ็นไฟล์จริง, ขนาดไฟล์, และข้อจำกัดทางธุรกิจก่อนสร้างงาน ให้เหตุผลที่ชัดเจนกับไฟล์ที่ถูกปฏิเสธเพื่อไม่ให้ถูกลองใหม่เป็นความล้มเหลือชั่วคราว
2. ใช้คิวที่ทนทาน
คิวที่ทนทานแยกการอัปโหลดออกจากการแปลง Azure Service Bus, RabbitMQ, หรือคิวอื่นที่สนับสนุนโดยโครงสร้างพื้นฐานของคุณ สามารถกระจายงานให้กับ worker .NET บน Windows
เก็บข้อความให้เล็กที่สุด เก็บเอกสารในที่จัดเก็บที่ปลอดภัยและใส่เพียงตัวระบุงานและอ้างอิงที่จัดเก็บลงคิว
3. จำกัดความพร้อมทำงานพร้อมกัน
จำนวน worker ที่มากไม่ได้หมายความว่าจะได้อัตราการผ่านสูงกว่าเสมอ เครื่องยนต์การแปลงอาจแข่งขันกันเพื่อใช้ CPU, หน่วยความจำ, พื้นที่ดิสก์ชั่วคราว, ฟอนต์, หรือส่วนประกอบที่มีลิขสิทธิ์ เริ่มต้นด้วยความพร้อมทำงานที่ระมัดระวัง, วัดผลกับเอกสารจริง, และเพิ่มเมื่อโฮสต์ยังคงเสถียร
4. ทำให้งานเป็น idempotent
ข้อความอาจถูกส่งมากกว่าหนึ่งครั้ง Worker ควรตรวจจับว่างานนั้นเสร็จแล้วและหลีกเลี่ยงการสร้างผลลัพธ์ซ้ำ คีย์ผลลัพธ์ที่กำหนดหรือบันทึกงานพร้อมสถานะการเสร็จสามารถให้การป้องกันนี้ได้
5. เก็บผลลัพธ์อย่างปลอดภัย
ใช้ที่จัดเก็บออบเจ็กต์ที่ได้รับการปกป้องหรือคลังข้อมูลที่ควบคุม ใช้การเข้ารหัสที่พัก, จำกัดสิทธิ์การให้บริการ, และใช้ URL ชั่วคราวเมื่อจำเป็น
6. เพิ่มชั้นการแสดงผล
เมื่อการประมวลผลเสร็จ, แอปของคุณสามารถทำให้เอกสารพร้อมสำหรับตัวดูแบบฝังได้ Doconut Viewer เป็น SDK ตัวดูเอกสาร .NET ที่ออกแบบมาสำหรับการรวมการแสดงผลเอกสารในเว็บแอป
ตัวดูควรรับอ้างอิงเอกสารผ่านกระบวนการที่ได้รับการอนุญาตของแอปของคุณ อย่าเปิดเผย URL สาธารณะถาวรหรือข้อมูลประจำตัวการจัดเก็บในโค้ดฝั่งไคลเอนต์
พิจารณาด้านความปลอดภัยและความเป็นส่วนตัว
เก็บไฟล์ไว้ภายในขอบเขตความเชื่อถือที่ตั้งใจ
ทำแผนที่เส้นทางเต็มของเอกสาร: การอัปโหลด, การจัดเก็บชั่วคราว, worker แปลง, การจัดเก็บผลลัพธ์, การแสดงผล, และการลบ ทุกส่วนควรมีสิทธิ์เพียงเท่าที่จำเป็น
ปกป้องข้อมูลระหว่างการส่งและที่พัก
ใช้ HTTPS สำหรับการอัปโหลดและการเรียกบริการภายใน เปิดใช้งานการเข้ารหัสที่จัดเก็บและเก็บความลับในบริการจัดการความลับของแพลตฟอร์มแทนไฟล์กำหนดค่าในระบบควบคุมเวอร์ชัน
ใช้ระยะเวลาการเก็บรักษาที่สั้น
ตั้งกฎการเก็บรักษาแยกต่างหากสำหรับไฟล์ต้นฉบับ, ผลลัพธ์ที่แปลงแล้ว, ไฟล์ชั่วคราว, และงานที่ล้มเหลว ตรวจสอบให้แน่ใจว่าการทำความสะอาดครอบคลุมการอัปโหลดที่ถูกละทิ้งและการล่มของ worker ด้วย
ถือการควบคุมของตัวดูเป็นคุณลักษณะการใช้งาน, ไม่ใช่การป้องกันแบบสมบูรณ์
การซ่อนปุ่มดาวน์โหลดหรือพิมพ์อาจสนับสนุนกระบวนการทำงานที่ตั้งใจ, แต่ไม่สามารถรับประกันว่าผู้ใช้ที่ได้รับอนุญาตจะไม่จับภาพข้อมูลที่แสดงได้ แอปที่ต้องการความปลอดภัยสูงยังต้องมีการตรวจสอบสิทธิ์, การกำหนดสิทธิ์, การบันทึกการตรวจสอบ, และนโยบายเอกสารที่เหมาะสม
บันทึกข้อมูลการตรวจสอบที่มีประโยชน์
บันทึกตัวระบุงาน, เวลา, การเปลี่ยนแปลงสถานะ, ระยะเวลา, จำนวนการลองใหม่, และรายละเอียดข้อผิดพลาดที่ทำให้เป็นข้อมูลส่วนบุคคล บันทึกไม่ควรมีเนื้อหาเอกสาร, URL ที่ลงนาม, โทเค็นการเข้าถึง, หรือข้อมูลส่วนบุคคลที่ไม่จำเป็น
เคล็ดลับการดำเนินงานสำหรับแบชที่เชื่อถือได้
ติดตามเอกสารแต่ละไฟล์อย่างอิสระ
แบชที่มี 100 ไฟล์ไม่ควรเป็นผลลัพธ์เดียวที่มองไม่เห็น ให้ติดตามแต่ละไฟล์แยกกันแล้วคำนวณสถานะของแบชจากผลลัพธ์ย่อยเหล่านั้น
แยกความแตกต่างระหว่างข้อผิดพลาดชั่วคราวและถาวร
การหมดเวลาและความล้มเหลวของการจัดเก็บชั่วคราวอาจทำให้ต้องลองใหม่ได้ ส่วนไฟล์ที่เข้ารหัส, เสียหาย, หรือไม่รองรับมักต้องการการดำเนินการจากผู้ใช้ การลองใหม่กับข้อผิดพลาดถาวรจะเสียทรัพยากรและทำให้แบชทั้งหมดล่าช้า
ตั้งขีดจำกัดอย่างชัดเจน
เผยแพร่ขนาดไฟล์สูงสุด, จำนวนหน้า, ขนาดแบช, และเวลาการประมวลผล ขีดจำกัดเหล่านี้ปกป้องบริการและให้ลูกค้ามีความคาดหวังที่แน่นอน
วัดกระบวนการทำงานทั้งหมด
ตรวจสอบเวลารอคิว, ระยะเวลาการแปลง, ขนาดผลลัพธ์, ความพร้อมของตัวดู, อัตราการล้มเหลว, และความสำเร็จของการทำความสะอาด ความเร็วการแปลงอย่างเดียวไม่อธิบายประสบการณ์ผู้ใช้ทั้งหมด
ที่ที่ Doconut เข้ากันได้
Doconut มีตำแหน่งที่เหมาะสมที่สุดเป็นส่วนประกอบการแสดงผลเอกสารในสถาปัตยกรรมนี้ มันช่วยทีม .NET ฝังการดูเอกสารในแอปของตนเองในขณะที่ระบบรอบข้างยังรับผิดชอบการอัปโหลด, งานแปลง, การให้สิทธิ์, การจัดเก็บ, และการเก็บรักษา
แนวทางนี้มีประโยชน์เมื่อคุณต้องการ:
- ตัวดูที่รวมเข้ากับแอป ASP.NET
- การสนับสนุนรูปแบบเอกสารธุรกิจที่เกินกว่า PDF
- การควบคุมประสบการณ์แอปและกระบวนการเข้าถึงเอกสาร
- โมเดลการปรับใช้ที่สอดคล้องกับข้อกำหนดโครงสร้างพื้นฐานของคุณเอง
ตรวจสอบรายละเอียดผลิตภัณฑ์ปัจจุบัน, รูปแบบที่รองรับ, ข้อกำหนด, และทรัพยากรการรวมบน เว็บไซต์ Doconut ก่อนสรุปสถาปัตยกรรมของคุณ
สรุปประเด็นสำคัญ
- ปฏิบัติงานแปลงแบบกลุ่มเป็นกระบวนการอะซิงโครนัส, ไม่ใช่การร้องขอเว็บที่ใช้เวลานาน
- ตรวจสอบไฟล์ก่อนจัดคิวและติดตามเอกสารแต่ละไฟล์อย่างอิสระ
- ใช้ความพร้อมทำงานที่จำกัด, งานที่เป็น idempotent, การจัดเก็บที่ปลอดภัย, และการเก็บรักษาที่ชัดเจน
- แยกข้อผิดพลาดถาวรออกจากข้อผิดพลาดที่สามารถลองใหม่ได้
- ใช้ Doconut เป็นชั้นการแสดงผลแบบฝังขณะแอปของคุณควบคุมการแปลง, การจัดเก็บ, และการเข้าถึง
เพิ่มการดูเอกสารในแอป .NET ของคุณ
หากแอป .NET บน Windows ของคุณต้องการประสบการณ์การแสดงตัวอย่างเอกสารแบบบูรณาการ, สำรวจ Doconut Viewer และตรวจสอบ การดาวน์โหลดและเอกสารประกอบ ที่มีให้.