กําหนดข้อกําหนดการรวม

การออกแบบการรวมที่ประสบความสําเร็จเริ่มต้นด้วยการทําความเข้าใจมิติพื้นฐานสามมิติ: ปริมาณและความถี่ ทิศทาง และความสามารถ มิติเหล่านี้ช่วยให้คุณประเมินความต้องการทางธุรกิจ ข้อจํากัดของระบบ และความจําเป็นในการปรับขนาด

ตัวอย่างเช่น สมมติว่าคุณมีเป้าหมายระดับสูง เช่น การเชื่อมต่อ SAP ไปยัง Dataverse หรือส่งการแจ้งเตือนทุกครั้งที่มีการอัปเดตไปยังเคสที่ผู้ใช้ทํางานอยู่ จุดเริ่มต้นในการออกแบบการรวมคืออะไร

ขั้นตอนแรกคือการแยกย่อยความต้องการลงในสามองค์ประกอบหลักของการรวมระบบ

• ปริมาณและความถี่ เป็นส่วนประกอบหลักอันดับแรกในกระบวนการตัดสินใจ ซึ่งช่วยกําหนดชนิดของเครื่องมือที่คุณจําเป็นต้องใช้เพื่อใช้ข้อกําหนดทางธุรกิจ

• ทิศทาง ซึ่งเป็นองค์ประกอบถัดไป กล่าวถึงที่ข้อมูลไหลจากและไปยังที่ใด การทําความเข้าใจทิศทางช่วยให้คุณตั้งค่ารูปแบบสําหรับการรวมที่ประสบความสําเร็จ

• ความสามารถ หรือความสามารถของแต่ละระบบในการรับ ประมวลผล และส่งข้อมูลเป็นขั้นตอนสุดท้าย ใช้วิธีการ "ลิงก์ที่อ่อนแอที่สุด" เพื่อประเมินความสามารถเพื่อระบุข้อจํากัดและความเป็นไปได้

ปริมาตรและความถี่

มิตินี้กําหนดปริมาณข้อมูลที่โอนย้ายและความถี่ในการโอนย้าย ปริมาณและความถี่มีบทบาทร่วมกันในการออกแบบสถาปัตยกรรมการรวมระบบ ในขณะที่อาจปรากฏขึ้นคล้ายกัน แต่มีผลต่อการออกแบบโซลูชันด้วยวิธีที่แตกต่างกัน คอมโพเนนต์ต่อไปนี้อธิบายรายละเอียดวิธีการที่ปริมาณและความถี่โต้ตอบ และมีผลต่อการตัดสินใจในการรวม

เปรียบเทียบปริมาณเทียบกับความถี่

สถานการณ์การรวมสองแบบอาจเกี่ยวข้องกับปริมาณรวมเดียวกัน เช่น 60,000 รายการต่อชั่วโมงและ 1,000 รายการต่อนาที แต่มีความถี่แตกต่างกัน ในขณะที่ทั้งสองปริมาณรายชั่วโมงเท่ากัน ความคาดหวังนาทีต่อนาทีจะเปลี่ยนแปลงการออกแบบโซลูชัน

• อย่าถือว่าโซลูชันหนึ่งโซลูชันพอดีกับทั้งสองอย่าง
• ตรวจสอบความสามารถของระบบในการจัดการโหลดความถี่ที่สูงกว่า
• พิจารณาการสร้างโซลูชันแยกต่างหากหากรูปแบบหนึ่งมีการใช้ทรัพยากรมากหรือไม่ค่อยใช้

ชนิดของทริกเกอร์

ทริกเกอร์กำหนดวิธีและเวลาที่การผสานรวมจะทำงาน เลือกทริกเกอร์ที่เหมาะสมตามความสามารถในการคาดการณ์และโหลดระบบ

ทริกเกอร์ตามกำหนดการ (หรือที่เรียกว่า "ชุดงาน"):

• เรียกใช้ตามช่วงเวลาคงที่
• ง่ายต่อการคาดการณ์และจัดการ
• เหมาะสําหรับรูปแบบการเติบโตของข้อมูลที่มีเสถียรภาพ

ทริกเกอร์ที่ขับเคลื่อนด้วยเหตุการณ์: เหตุการณ์สามารถเป็นการเลือกปุ่ม การเปลี่ยนแปลงในระเบียนในระบบใดระบบหนึ่ง หรือการเรียกใช้ API

• เปิดใช้งานตามการดําเนินการของผู้ใช้หรือเหตุการณ์ของระบบ
• ยากกว่าที่จะคาดเดา
• สามารถดีดขึ้นโดยไม่คาดคิดโดยเฉพาะอย่างยิ่งในระบบที่เชื่อมต่อกับสาธารณะ

ความผันผวนตามฤดูกาล

ปริมาณข้อมูลผันผวนกับวงจรทางธุรกิจ วางแผนสําหรับการผสานรวมตามฤดูกาลทั้งแบบกําหนดเวลาและตามเหตุการณ์

• รอบการเรียกเก็บเงินรายเดือนหรือรายไตรมาสอาจทำให้เกิดความผันผวนที่คาดการณ์ได้
• ฤดูภาษีหรือกำหนดเวลาการบริการรัฐบาลสามารถสร้างความผันผวนที่ไม่สามารถคาดเดาได้
• ใช้ระบบป้องกันเพื่อป้องกันการโอเวอร์โหลดในช่วงเวลาสูงสุด

ความร่วมมือของผู้มีส่วนได้เสีย

พูดคุยเกี่ยวกับปริมาณและความถี่ด้วยเจ้าของกระบวนการและผู้ใช้ทางธุรกิจ ตรวจสอบความถูกต้องของสมมติฐานกับเวิร์กโฟลว์จริง

• ผู้ใช้ทางธุรกิจอาจไม่ทราบกระบวนการทั้งหมด
• สถาปนิกต้องตรวจสอบและยืนยันความเป็นจริงในการดําเนินงาน

แผนสําหรับอนาคต

ออกแบบโซลูชันการรวมโดยคำนึงถึงการเติบโต

• กําหนดสภาพการทํางานอย่างชัดเจน
• รวมถึงแผนระยะยาวที่ปรับขนาดได้
• ประเมินเมื่อจําเป็นต้องปรับมาตราส่วน

ทิศทาง

ทิศทางกําหนดการไหลของข้อมูลระหว่างระบบ กําหนดว่าข้อมูลมาจากที่ใดและตําแหน่งที่จัดส่งเพื่อจัดรูปร่างวิธีที่คุณกําหนดค่าและดําเนินการรวม เมื่อกําหนดทิศทางของกระแสข้อมูล บัญชีสําหรับความพร้อมใช้งานของระบบ ข้อกําหนดการปฏิบัติตามกฎระเบียบ และมาตรการด้านความปลอดภัยเพื่อให้แน่ใจว่ามีการดําเนินงานที่เชื่อถือได้และปลอดภัย ตัวอย่างเช่น ข้อมูลอาจมาจากระบบส่วนตัวที่ไม่สามารถใช้งานได้เสมอไปหรืออาจอยู่ภายใต้การปฏิบัติตามกฎระเบียบและข้อบังคับด้านความปลอดภัยที่เข้มงวด

ผู้ถือผลประโยชน์ร่วมและการปฏิบัติตามกฎระเบียบ

การปฏิบัติตามกฎระเบียบมีบทบาทสําคัญในการออกแบบการรวมและแตกต่างกันไปในระบบ ปรึกษากับสถาปนิกโครงสร้างพื้นฐานและเจ้าหน้าที่รักษาความปลอดภัยเพื่อให้แน่ใจว่าการเชื่อมต่อเป็นไปตามมาตรฐานการรักษาความปลอดภัยขององค์กรและมาตรฐานด้านการกํากับดูแล

• สภาพแวดล้อมด้านความปลอดภัยสูงมักกําหนดการควบคุมการเข้าถึงที่เข้มงวดซึ่งมีผลต่อสถาปัตยกรรมการรวม
• ระบบภายในองค์กรแบบดั้งเดิมอาจจํากัดการเชื่อมต่อขาเข้า ในกรณีดังกล่าว ให้ออกแบบการรวมเพื่อให้ระบบเดิมเริ่มการสื่อสารกับแอปพลิเคชันระบบคลาวด์

ความสามารถ

ประสิทธิภาพการรวมขึ้นอยู่กับความสามารถของแต่ละระบบที่เกี่ยวข้อง ระบบที่อ่อนแอที่สุดในห่วงโซ่จํากัดผลลัพธ์โดยรวม

• ประเมินความสามารถของระบบตามความต้องการทางธุรกิจ
• ระบุปัญหาคอขวดที่อาจส่งผลต่อการถ่ายโอนข้อมูลที่มีความถี่สูงหรือปริมาณมาก
• พิจารณาการปรับปรุงถ้าระบบไม่สามารถตอบสนองความคาดหวังด้านประสิทธิภาพการทํางาน

ความสามารถและความถี่

ความถี่ส่งผลต่อวิธีการที่ระบบจัดการการถ่ายโอนข้อมูลได้ดีเพียงใด ระบบที่ทํางานได้ดีวันละครั้งอาจล้มเหลวภายใต้การโหลดรายวันหลายรายการ

• จับคู่ความสามารถของระบบกับความถี่ที่ต้องการ
• อย่าสันนิษฐานว่าปริมาณเพียงอย่างเดียวเป็นตัวกําหนดความเป็นไปได้

Caching

การแคชเป็นโซลูชันทั่วไปเมื่อระบบไม่สามารถตอบสนองความต้องการด้านประสิทธิภาพการทํางาน

• ใช้เครื่องมือเช่น Azure Synapse Link สําหรับ Dataverse เพื่อทําซ้ําข้อมูลลงในที่เก็บข้อมูลที่ปรับขนาดได้
• ทําความเข้าใจเกี่ยวกับการแลกเปลี่ยน: การแคชช่วยปรับปรุงเวลาการตอบสนอง แต่อาจส่งข้อมูลที่ล้าสมัย
• ตรวจสอบให้แน่ใจว่าข้อมูลยังคงเป็นข้อมูลใหม่เพื่อป้องกันผลลัพธ์ที่ไม่ถูกต้องในกระบวนการแบบเรียลไทม์

การแปลงข้อมูลและตรรกะทางธุรกิจ

ความสามารถของระบบประกอบด้วยความสามารถในการดําเนินการแปลงและตรรกะทางธุรกิจที่จําเป็นเพื่อตอบสนองความต้องการทางธุรกิจ

• ประเมินว่าระบบแต่ละระบบสามารถทําอะไรได้บ้างก่อนระหว่างและหลังการถ่ายโอนข้อมูล
• พิจารณาความซับซ้อนของข้อมูลต้นทาง ความต้องการการแปลง และการประมวลผลระบบเป้าหมาย

ตัวอย่างเช่น การส่งออกมุมมอง SQL ที่มีขั้นตอนการจัดเก็บไปยัง Dataverse อาจจําเป็นต้องมีการปรับใช้งานเที่ยวบินกลางและการดําเนินการปลั๊กอินหลังขาเข้า

ผู้ถือผลประโยชน์ร่วมด้านความสามารถ

ผู้ดูแลระบบมีข้อมูลเชิงลึกเกี่ยวกับความสามารถของระบบ มีส่วนร่วมกับทีมไอทีแบบรวมศูนย์หรือแบบกระจายจากศูนย์กลางเพื่อตรวจสอบความถูกต้องของสมมติฐาน

• ประเมินแต่ละระบบก่อนที่จะเลือกรูปแบบการรวม
• ยืนยันว่าความสามารถทางเทคนิคสอดคล้องกับความคาดหวังทางธุรกิจ

รวมข้อมูลเข้าด้วยกัน

การออกแบบการรวมที่มีประสิทธิภาพเริ่มต้นด้วยการทําความเข้าใจคอมโพเนนต์หลักสามอย่าง สรุป:

• ปริมาณและความถี่ กําหนดปริมาณข้อมูลที่จะถ่ายโอนและความถี่ เมตริกเหล่านี้มีผลต่อตัวเลือกของเครื่องมือ ความคาดหวังด้านประสิทธิภาพ และการวางแผนความสามารถในการปรับขนาด
• ทิศทาง ระบุต้นทางและปลายทางของข้อมูล ซึ่งช่วยกําหนดวิธีการไหลของข้อมูลระหว่างระบบและรับประกันการปฏิบัติตามข้อกําหนดด้านความปลอดภัยและข้อกําหนดด้านการกํากับดูแล
• ความสามารถ วัดความสามารถแต่ละความสามารถของระบบในการส่ง รับ และประมวลผลข้อมูล ซึ่งเน้นถึงข้อจํากัดด้านประสิทธิภาพและช่วยระบุปัญหาคอขวดที่อาจเกิดขึ้นในกระบวนการรวม

แต่ละคอมโพเนนต์สอดคล้องโดยตรงไปยังข้อกำหนดทางธุรกิจเบื้องต้น วิเคราะห์ร่วมกับผู้เกี่ยวข้อง ปริมาณ ความถี่ ทิศทาง และความสามารถส่งผลต่อกระบวนการรวมโดยรวมอย่างไร

การทํางานร่วมกันของผู้มีส่วนได้เสียเป็นสิ่งจําเป็นในระหว่างการวิเคราะห์ ข้อมูลป้อนเข้าของพวกเขาสามารถปรับรูปร่างวิธีการรวมได้

• เจ้าของกระบวนการ มีข้อกําหนดทางธุรกิจเบื้องต้น
• สถาปนิกโครงสร้างพื้นฐานและเจ้าหน้าที่รักษาความปลอดภัย ช่วยให้มั่นใจว่าการปฏิบัติตามกฎระเบียบและการเชื่อมต่อที่ปลอดภัย
• ผู้ดูแลระบบ ประเมินความสามารถและข้อจํากัดของระบบ

สถานการณ์ตัวอย่าง

ลองมารวมทุกอย่างเข้าด้วยกันผ่านสถานการณ์ตัวอย่าง สมมติว่าข้อกําหนดทางธุรกิจคือการสร้างกระบวนการรวมที่เก็บข้อมูลกรณีที่ซิงค์กันระหว่างลูกค้าภายนอกและวิศวกรบริการภายในที่ทํางานในกรณีต่าง ๆ ลูกค้าสามารถเพิ่มข้อคิดเห็นไปยังกรณีผ่านทางเว็บไซต์ ในขณะที่วิศวกรสามารถเพิ่มข้อมูลกรณีผ่านทางแอป Power ได้

ปริมาณคำขอและความถี่ของทริกเกอร์

ปริมาณและความถี่จะกําหนดปริมาณข้อมูลที่ระบบถ่ายโอนและความถี่ในการถ่ายโอนข้อมูลดังกล่าว ในสถานการณ์นี้ ลูกค้าขับเคลื่อนการสร้างกรณีเป็นหลัก ดังนั้นปริมาณจะขึ้นอยู่กับจํานวนลูกค้าที่บริษัทให้บริการและวิถีการเติบโตที่คาดการณ์ไว้

ปริมาณรวมของการอัปเดตอาจคํานวณเป็น:

[Customers] × [Cases per customer] × [Average updates per case]

แสดงภาพตัวเลขนี้บนแผนภูมิเพื่อแสดงวิธีการขยายเมื่อเวลาผ่านไป ตัวอย่างเช่น ถ้าคุณเริ่มต้นด้วยการอัปเดต 10 ล้านครั้งต่อปี และคาดว่าจะมี 20% เพิ่มขึ้นในแต่ละปี แผนภูมิควรจะเพิ่มขึ้นอย่างต่อเนื่องในการอัปเดตปีต่อปี

ใช้ข้อมูลในอดีตและการคาดการณ์การเติบโตเพื่อประเมินโหลดในอนาคต ตัวอย่างเช่น ถ้าระบบจัดการการอัปเดต 10 ล้านครั้งต่อปีในวันนี้ และเพิ่มขึ้นที่ 20% ทุกปี การรวมต้องสนับสนุนการอัปเดต 25 ล้านครั้งต่อปีในช่วงห้าปี

การวิเคราะห์ความถี่จะแสดงยอดสูงสุดรายเดือน หากความต้องการปัจจุบันคือ 3.2 ล้านคําขอต่อเดือนความต้องการในอนาคตอาจถึง 8 ล้านต่อเดือน ออกแบบการรวมเพื่อให้ตรงตามค่าเกณฑ์ประสิทธิภาพเหล่านี้

เพื่อให้แน่ใจว่าการผสานรวมยังคงมีผลในช่วงเวลาผลตอบแทนต่อการลงทุน (ROI) ห้าปีทั่วไป ออกแบบโซลูชันเพื่อสนับสนุนคําขออย่างน้อย 25 ล้านคําขอต่อปี บัญชีการวางแผนความจุนี้สําหรับการเติบโตที่คาดการณ์และช่วยให้โซลูชันยังคงปรับขนาดได้และเชื่อถือได้เมื่อความต้องการทางธุรกิจพัฒนาขึ้น

ส่วนความถี่ของไดรฟ์ข้อมูลคือความสามารถของระบบที่เกี่ยวข้องกับการจัดการข้อมูลภายในหนึ่งปี อีกครั้ง เราสามารถสร้างแผนภูมิข้อมูลในอดีตเพื่อทําความเข้าใจวิธีการใช้ความถี่

ทิศทางและการไหลของข้อมูล

ทิศทางกําหนดการไหลของข้อมูลระหว่างระบบ สถานการณ์นี้ประกอบด้วยสตรีมข้อมูลที่แตกต่างกันสี่รายการ:

• กระแสข้อมูลจากเว็บไซต์เพื่อเขียนอัปเดตกรณีลงใน Dataverse
• สตรีมอื่นสําหรับเว็บไซต์เพื่ออ่านอัปเดตจาก Dataverse
• สตรีมข้อมูลที่สามที่วิศวกรเขียนอัปเดตลงใน Dataverse จาก Power App
• สตรีมข้อมูลสุดท้ายเพื่ออ่านการอัปเดตใน Power App

ไดอะแกรมนี้แสดงรูปแบบการรวมโดยตรง ซึ่งแสดงวิธีการย้ายข้อมูลระหว่างเว็บไซต์ Dataverse และ Power App ผ่านสตรีมข้อมูลที่แตกต่างกันสี่รายการ:

การทําความเข้าใจโฟลว์เหล่านี้ช่วยให้คุณกําหนดค่าการรวมข้อมูลที่ปลอดภัยและมีประสิทธิภาพ ใช้รูปแบบโดยตรงหรือถูกแยกส่วนตามความสามารถของระบบและความต้องการของประสิทธิภาพการทํางาน

ศักยภาพในการปฏิบัติ

ในการรวมตัวอย่างนี้ ตัวเชื่อมต่อที่มีอยู่ภายในทําให้กระบวนการเป็นไปอย่างคล่องตัว เมื่อดึงข้อมูลกรณีจาก Dataverse ให้ใช้ตัวกรองและตั้งค่าขีดจํากัดคําขอเพื่อปรับการดึงข้อมูลให้เหมาะสมและแสดงเฉพาะข้อมูลที่จําเป็นในแอป สําหรับเว็บไซต์ เผยแพร่จุดสิ้นสุดโดยใช้ ทริกเกอร์ Power Automate HTTP เพื่อเปิดใช้งานการอ่านและเขียนข้อมูล ประเมินความจุของทั้งโฟลว์ Power Automate และ Dataverse เพื่อให้แน่ใจว่าพวกเขาสนับสนุนการโหลดที่คาดการณ์ ตรวจสอบ ขีดจํากัดของโฟลว์อัตโนมัติ กําหนดเวลา และโต้ตอบแบบทันที เพื่อหลีกเลี่ยงไม่ให้เกินข้อจํากัดของแพลตฟอร์ม

ใช้ การวิเคราะห์ข้อมูลเพื่อ ติดตามการใช้งานในปัจจุบัน ถ้า Dataverse เข้าใกล้การโหลดคําขอที่คาดการณ์ พิจารณาเพิ่มบัฟเฟอร์ป้องกันในรูปแบบของ Azure Data Lake

แผนภาพนี้แสดงรูปแบบการอ่านที่ไม่เชื่อมต่อกัน โดยที่ Data Lake ถูกแทรกเข้ามาระหว่าง Dataverse และเว็บไซต์ เพื่อช่วยลดภาระการใช้งานการอ่านและเพิ่มประสิทธิภาพในการปรับขนาด

กลยุทธ์นี้ช่วยลดปริมาณการอ่านข้อมูลจาก Dataverse และป้องกันข้อผิดพลาดการควบคุมปริมาณ (เช่น HTTP 429 คําขอมากเกินไป)

หากต้องการลดการขึ้นต่อกันให้มากขึ้น ให้แยกส่วนคําขอสร้างและอัปเดตจากเว็บไซต์โดยใช้บริการจัดคิว เช่น Azure Service Bus

แผนภาพนี้แสดงรูปแบบการรวมที่แยกออกจากกันโดยสมบูรณ์ ซึ่งทั้งการอ่านและการเขียนจะถูกถ่ายผ่าน Data Lake และคิวเพื่อเพิ่มความน่าเชื่อถือสูงสุดและปกป้อง Dataverse จากความต้องการที่พุ่งสูงขึ้น:

ออกแบบโฟลว์ระบบคลาวด์เพื่อจัดการข้อผิดพลาด ใช้ตรรกะใหม่ และทําตาม แนวทางปฏิบัติที่ดีที่สุด สําหรับความน่าเชื่อถือ เมื่อเลือกรูปแบบการรวม ให้จัดลําดับความสําคัญโซลูชันที่ตรงกับความต้องการทางธุรกิจด้วยความซับซ้อนน้อยที่สุด ปรับสมดุลความสามารถทางเทคนิคให้สอดคล้องกับข้อกําหนดด้านต้นทุน การออกใบอนุญาต และการบํารุงรักษา เลือกวิธีที่ง่ายที่สุดที่ปฏิบัติตามข้อกําหนดและหลีกเลี่ยงการลงทุนที่ไม่จําเป็น

ขั้นตอนถัดไป

สํารวจรูปแบบทั่วไปในการแปลการวิเคราะห์ความต้องการของคุณให้เป็นสถาปัตยกรรมการรวมที่ปรับขนาดได้และใช้งานได้จริง

แหล่งข้อมูลที่เกี่ยวข้อง

• Azure Synapse Link สำหรับ Dataverse คืออะไร
• เพิ่มการรับรองความถูกต้อง OAuth สําหรับทริกเกอร์คําขอ HTTP
• ขีดจํากัดของโฟลว์อัตโนมัติ จัดกําหนดการ และโต้ตอบแบบทันที
• ดูและดาวน์โหลดการวิเคราะห์ Microsoft Dataverse
• สร้างลิงก์ Azure Synapse สําหรับ Dataverse ด้วย Azure Data Lake
• คิว หัวข้อ และการสมัครใช้งานของ Service Bus