การส่งข้อความที่เชื่อถือได้ในระบบแบบกระจาย

ปัญหาการเขียนแบบคู่ การสร้างระบบกระจายที่เชื่อถือได้ มีความพร้อมใช้งานสูง และปรับขนาดได้นั้นต้องปฏิบัติตามเทคนิค หลักการ และรูปแบบเฉพาะ การออกแบบระบบดังกล่าวต้องจัดการกับความท้าทายมากมาย ปัญหาที่พบได้บ่อยและเป็นพื้นฐานที่สุดประการหนึ่งคือ ปัญหาการเขียนแบบคู่ เป็นความท้าทายที่เกิดขึ้นในระบบแบบกระจาย โดยเฉพาะอย่างยิ่งเมื่อต้องจัดการกับแหล่งข้อมูลหรือฐานข้อมูลหลายแหล่งที่จำเป็นต้องซิงค์กัน ซึ่งหมายถึงความยากลำบากในการทำให้แน่ใจว่าการเปลี่ยนแปลงข้อมูลถูกเขียนลงในที่เก็บข้อมูลต่างๆ เช่น ฐานข้อมูลหรือแคช โดยไม่เกิดปัญหา เช่น ข้อมูลไม่สอดคล้องกัน ขัดแย้งกัน หรือเกิดปัญหาคอขวดด้านประสิทธิภาพ “ปัญหาการเขียนแบบคู่” สถาปัตยกรรมไมโครเซอร์วิสและฐานข้อมูลรูปแบบต่อบริการนั้นมอบประโยชน์มากมายให้กับคุณ เช่น การปรับใช้และการปรับขนาดแบบอิสระ ความล้มเหลวที่แยกจากกัน และความเร็วในการพัฒนาที่อาจเพิ่มขึ้น อย่างไรก็ตาม การดำเนินการต่างๆ จำเป็นต้องมีการเปลี่ยนแปลงระหว่างไมโครเซอร์วิสหลายรายการ ซึ่งบังคับให้คุณต้องคิดหาโซลูชันที่เชื่อถือได้เพื่อแก้ไขปัญหานี้ ตัวอย่างที่แทบจะเป็นจริง ลองพิจารณาสถานการณ์ที่โดเมนของเราเกี่ยวข้องกับการยอมรับใบสมัครสินเชื่อ การประเมินใบสมัคร และส่งการแจ้งเตือนไปยังลูกค้า ด้วยจิตวิญญาณแห่งหลักการความรับผิดชอบเดี่ยว กฎของคอนเวย์ และแนวทางการออกแบบตามโดเมน หลังจากเซสชันการระดมเหตุการณ์หลายเซสชัน โดเมนทั้งหมดถูกแยกออกเป็นสามโดเมนย่อยซึ่งมีบริบทที่มีขอบเขตชัดเจน มีขอบเขตชัดเจน โมเดลโดเมน และภาษาที่แพร่หลาย มีหน้าที่ในการจัดทำและรวบรวมใบสมัครสินเชื่อใหม่ ส่วนระบบ จะประเมินใบสมัครเหล่านี้และตัดสินใจโดยอิงจากข้อมูลที่ให้มา กระบวนการประเมินนี้ซึ่งรวมถึง KYC/KYB การป้องกันการฉ้อโกง และการตรวจสอบความเสี่ยงด้านเครดิตอาจใช้เวลานาน จึงจำเป็นต้องสามารถจัดการใบสมัครหลายพันฉบับพร้อมกันได้ ดังนั้น ฟังก์ชันนี้จึงได้รับการมอบหมายให้กับไมโครเซอร์วิสเฉพาะที่มีฐานข้อมูลของตัวเอง ซึ่งช่วยให้ปรับขนาดได้อย่างอิสระ ระบบแรก ที่สอง นอกจากนี้ ระบบย่อยเหล่านี้ยังได้รับการจัดการโดยทีมงานสองทีมที่แตกต่างกัน โดยแต่ละทีมมีรอบการเผยแพร่ ข้อตกลงระดับบริการ (SLA) และข้อกำหนดด้านการปรับขนาดเป็นของตัวเอง ก็มีบริการการแจ้งเตือนพิเศษเพื่อส่งการแจ้งเตือนไปยังลูกค้า ในที่สุด นี่คือคำอธิบายโดยละเอียดของกรณีการใช้งานหลักของระบบ: ลูกค้าส่งใบสมัครสินเชื่อ บริการสมัครสินเชื่อจะบันทึกใบสมัครใหม่ด้วยสถานะ “รอดำเนินการ” และเริ่มกระบวนการประเมินโดยส่งต่อใบสมัครไปยังบริการประเมิน ฝ่ายบริการประเมินจะประเมินใบสมัครสินเชื่อที่เข้ามา และแจ้งผลการตัดสินใจให้ฝ่ายบริการสมัครสินเชื่อทราบในภายหลัง เมื่อได้รับการตัดสินใจแล้ว บริการสมัครสินเชื่อจะอัปเดตสถานะการสมัครสินเชื่อตามนั้น และเรียกใช้บริการการแจ้งเตือนเพื่อแจ้งผลให้ลูกค้าทราบ บริการการแจ้งเตือนจะประมวลผลคำขอนี้และส่งการแจ้งเตือนให้กับลูกค้าผ่านทางอีเมล SMS หรือวิธีการสื่อสารอื่น ๆ ที่ต้องการตามการตั้งค่าของลูกค้า ในตอนแรกมันอาจจะดูเป็นระบบที่เรียบง่ายและดั้งเดิม แต่มาดูกันว่าบริการสมัครสินเชื่อดำเนินการคำสั่งส่งใบสมัครสินเชื่ออย่างไร เราพิจารณาแนวทางสองแนวทางสำหรับการโต้ตอบบริการ: ในแนวทางนี้ บริการจะอัปเดตฐานข้อมูลภายใน (การคอมมิท) จากนั้นจึงเผยแพร่เหตุการณ์หรือข้อความไปยังบริการอื่น การคอมมิทในพื้นที่ครั้งแรกแล้วจึงเผยแพร่: ในทางกลับกัน วิธีนี้เกี่ยวข้องกับการเผยแพร่เหตุการณ์หรือข้อความก่อนที่จะยืนยันการเปลี่ยนแปลงไปยังฐานข้อมูลภายในเครื่อง เผยแพร่ก่อนแล้วจึงยืนยันภายในเครื่อง: ทั้งสองวิธีมีข้อเสียและมีความปลอดภัยต่อการสื่อสารในระบบแบบกระจายเพียงบางส่วนเท่านั้น นี่คือแผนภาพลำดับการใช้แนวทางแรก ในสถานการณ์นี้ บริการใบสมัครสินเชื่อจะใช้แนวทาง ซึ่งจะทำการยืนยันธุรกรรมก่อน จากนั้นจึงพยายามส่งการแจ้งเตือนไปยังระบบอื่น อย่างไรก็ตาม กระบวนการนี้อาจล้มเหลวได้ หากเกิดปัญหากับเครือข่าย เช่น บริการประเมินผลไม่พร้อมใช้งาน หรือบริการใบสมัครสินเชื่อพบข้อผิดพลาด Out of Memory (OOM) และเกิดการขัดข้อง ในกรณีดังกล่าว ข้อความจะสูญหาย ทำให้บริการประเมินผลไม่ได้รับแจ้งเกี่ยวกับใบสมัครสินเชื่อใหม่ เว้นแต่จะมีการดำเนินการเพิ่มเติม First-Local-Commit-Then-Publish และคนที่สอง ในสถานการณ์ เครื่อง บริการใบสมัครสินเชื่อจะต้องเผชิญกับความเสี่ยงที่ร้ายแรงยิ่งขึ้น โดยอาจแจ้งบริการการประเมินเกี่ยวกับใบสมัครใหม่ แต่ไม่สามารถบันทึกการอัปเดตนี้ลงในเครื่องได้เนื่องจากปัญหาต่างๆ เช่น ปัญหาฐานข้อมูล ข้อผิดพลาดของหน่วยความจำ หรือข้อบกพร่องของโค้ด แนวทางนี้สามารถนำไปสู่ความไม่สอดคล้องกันอย่างมีนัยสำคัญในข้อมูล ซึ่งอาจก่อให้เกิดปัญหาที่ร้ายแรงได้ ขึ้นอยู่กับว่าบริการตรวจสอบสินเชื่อจัดการกับใบสมัครที่เข้ามาอย่างไร การเผยแพร่ครั้งแรกแล้วจึงส่งไปยัง ดังนั้น เราจะต้องระบุโซลูชันที่เสนอกลไกที่แข็งแกร่งสำหรับการเผยแพร่กิจกรรมไปยังผู้บริโภคภายนอก แต่ก่อนที่จะเจาะลึกถึงโซลูชันที่เป็นไปได้ เราควรชี้แจงประเภทของการรับประกันการส่งข้อความที่สามารถทำได้ในระบบแบบกระจายเสียก่อน การรับประกันการส่งข้อความ มีการรับประกันสี่ประเภทที่เราสามารถทำได้ ไม่มีการรับประกัน ไม่มีการรับประกันว่าข้อความจะถูกส่งไปยังปลายทาง แนวทาง เป็นแนวทางสำหรับเรื่องนี้ ผู้บริโภคอาจได้รับข้อความเพียงครั้งเดียว หลายครั้ง หรือไม่ได้รับเลย แรก-ส่งภายใน-จากนั้นจึงเผยแพร่ จัดส่งได้ครั้งเดียวเท่านั้น การส่งครั้งละมากที่สุดหมายถึงข้อความจะถูกส่งไปยังปลายทางครั้งละมากที่สุด 1 ครั้ง แนวทาง สามารถนำไปใช้ในลักษณะนี้ได้เช่นกันโดยใช้นโยบายการลองใหม่อีกครั้งของความพยายามที่มีค่าหนึ่ง First-Local-Commit-Then-Publish อย่างน้อยหนึ่งครั้งการจัดส่ง ผู้บริโภคจะได้รับและประมวลผลทุกข้อความแต่บางครั้งอาจได้รับข้อความเดียวกันมากกว่าหนึ่งครั้ง จัดส่งอย่างแม่นยำเพียงครั้งเดียว\จัดส่งอย่างแม่นยำเพียงครั้งเดียวหมายความว่าผู้บริโภคจะได้รับข้อความอย่างมีประสิทธิภาพเพียงครั้งเดียว ในทางเทคนิคแล้ว เป็นไปได้ที่จะบรรลุเป้าหมายด้วยธุรกรรม Kafka และการใช้งานอุดมคติเฉพาะของผู้ผลิตและผู้บริโภค ในกรณีส่วนใหญ่ การรับประกันการจัดส่งแบบ จะแก้ไขปัญหาต่างๆ มากมายโดยรับรองว่าข้อความจะถูกส่งอย่างน้อยหนึ่งครั้ง แต่ผู้บริโภคจะต้องเป็นอุดมคติ อย่างไรก็ตาม เมื่อพิจารณาถึงความล้มเหลวของเครือข่ายที่หลีกเลี่ยงไม่ได้ ตรรกะของผู้บริโภคทั้งหมดจะต้องเป็นอุดมคติเพื่อหลีกเลี่ยงการประมวลผลข้อความซ้ำ โดยไม่คำนึงถึงการรับประกันของผู้ผลิต ดังนั้น ข้อกำหนดนี้จึงไม่ใช่ข้อเสียมากนัก แต่เป็นการสะท้อนความเป็นจริง 'อย่างน้อยหนึ่งครั้ง' โซลูชั่น มีวิธีแก้ไขปัญหานี้อยู่มากมาย ซึ่งมีทั้งข้อดีและข้อเสีย ความมุ่งมั่นสองขั้นตอน ตามข้อมูลของ Wikipedia โปรโตคอล Two-Phase Commit (2PC) คือโปรโตคอลธุรกรรมแบบกระจายที่ใช้ในวิทยาการคอมพิวเตอร์และระบบจัดการฐานข้อมูลเพื่อรับรองความสอดคล้องและความน่าเชื่อถือของธุรกรรมแบบกระจาย โปรโตคอลนี้ได้รับการออกแบบมาสำหรับสถานการณ์ที่ทรัพยากรหลายรายการ (เช่น ฐานข้อมูล) จำเป็นต้องเข้าร่วมในธุรกรรมเดียว และโปรโตคอลนี้จะช่วยให้แน่ใจว่าทรัพยากรทั้งหมดจะยอมรับธุรกรรมหรือยกเลิกธุรกรรมทั้งหมด ดังนั้นจึงรักษาความสอดคล้องของข้อมูลไว้ได้ โปรโตคอลนี้ฟังดูเหมือนเป็นสิ่งที่เราต้องการพอดี แต่โปรโตคอล Two-Phase Commit มีข้อเสียหลายประการ: หากทรัพยากรที่เข้าร่วมหนึ่งรายการไม่มีการตอบสนองหรือประสบกับความล้มเหลว กระบวนการทั้งหมดอาจถูกบล็อกจนกว่าจะแก้ไขปัญหาได้ ซึ่งอาจนำไปสู่ปัญหาด้านประสิทธิภาพและความพร้อมใช้งานที่อาจเกิดขึ้นได้ Two-Phase Commit ไม่มีกลไกการทนทานต่อความผิดพลาดในตัว แต่จะใช้กลไกภายนอกหรือการแทรกแซงด้วยตนเองเพื่อจัดการกับความผิดพลาด ฐานข้อมูลสมัยใหม่ไม่ทั้งหมดรองรับ Two-Phase Commit ฐานข้อมูลร่วมกัน วิธีแก้ปัญหาที่ชัดเจนที่สุดสำหรับสถาปัตยกรรมไมโครเซอร์วิสคือการใช้รูปแบบ (หรือบางครั้งอาจใช้รูปแบบต่อต้านก็ได้) — ฐานข้อมูลที่ใช้ร่วมกัน แนวทางนี้ใช้งานง่ายมากหากคุณต้องการความสอดคล้องของธุรกรรมระหว่างตารางต่างๆ ในฐานข้อมูลที่แตกต่างกัน เพียงใช้ฐานข้อมูลที่ใช้ร่วมกันเพียงแห่งเดียวสำหรับไมโครเซอร์วิสเหล่านี้ ข้อเสียของแนวทางนี้ ได้แก่ การนำจุดล้มเหลวเพียงจุดเดียวมาใช้ ขัดขวางการปรับขนาดฐานข้อมูลอิสระ และจำกัดความสามารถในการใช้โซลูชันฐานข้อมูลที่แตกต่างกันซึ่งเหมาะสมที่สุดสำหรับข้อกำหนดและกรณีการใช้งานที่เฉพาะเจาะจง นอกจากนี้ จำเป็นต้องปรับเปลี่ยนฐานโค้ดของไมโครเซอร์วิสเพื่อรองรับธุรกรรมแบบกระจายรูปแบบดังกล่าว กล่องจดหมายขาออกสำหรับทำธุรกรรม ' ' เป็นรูปแบบการออกแบบที่ใช้ในระบบแบบกระจายเพื่อให้แน่ใจว่ามีการเผยแพร่ข้อความที่เชื่อถือได้ แม้ว่าระบบส่งข้อความจะไม่น่าเชื่อถือก็ตาม โดยเกี่ยวข้องกับการเก็บเหตุการณ์ในตาราง 'กล่องขาออกเชิงธุรกรรม' ที่กำหนดไว้ภายในธุรกรรมเดียวกันกับการดำเนินการนั้นเอง แนวทางนี้สอดคล้องกับคุณสมบัติ ACID ของฐานข้อมูลเชิงสัมพันธ์ ในทางกลับกัน ฐานข้อมูล No-SQL จำนวนมากไม่รองรับคุณสมบัติ ACID อย่างสมบูรณ์ โดยเลือกใช้หลักการของทฤษฎีบท CAP และปรัชญา BASE ซึ่งให้ความสำคัญกับความพร้อมใช้งานและความสอดคล้องในที่สุดมากกว่าความสอดคล้องอย่างเคร่งครัด กล่องขาออกเชิงธุรกรรม กล่องขาออกของธุรกรรมให้ และสามารถนำไปปฏิบัติได้หลายวิธี: การรับประกันอย่างน้อยหนึ่งครั้ง การติดตามบันทึกธุรกรรม ผู้จัดพิมพ์โพลสำรวจ แนวทาง หมายถึงการใช้โซลูชันเฉพาะฐานข้อมูล เช่น CDC (การจับข้อมูลการเปลี่ยนแปลง) ข้อเสียหลักของแนวทางดังกล่าวมีดังนี้: การติดตามบันทึกธุรกรรม โซลูชันเฉพาะฐานข้อมูล ความหน่วงเวลาที่เพิ่มขึ้นเนื่องจากข้อมูลจำเพาะของการใช้งาน CDC อีกวิธีหนึ่งคือ ซึ่งอำนวยความสะดวกในการออฟโหลด outbox โดยการโพลล์ตาราง outbox ข้อเสียหลักของวิธีนี้คือฐานข้อมูลอาจโหลดมากขึ้น ซึ่งอาจนำไปสู่ต้นทุนที่สูงขึ้น นอกจากนี้ ฐานข้อมูล No-SQL ไม่รองรับการค้นหาที่มีประสิทธิภาพสำหรับเซกเมนต์เอกสารเฉพาะทั้งหมด ดังนั้น การดึงเอกสารทั้งหมดจึงอาจส่งผลให้ประสิทธิภาพลดลง Polling Publisher นี่คือแผนภาพลำดับขนาดเล็กที่อธิบายวิธีการทำงาน ฟังตัวเอง ความท้าทายหลักในการใช้รูปแบบ Transactional Outbox อยู่ที่การพึ่งพาคุณสมบัติ ACID ของฐานข้อมูล ซึ่งอาจทำได้โดยตรงในฐานข้อมูล OLTP ทั่วไป แต่ก่อให้เกิดความท้าทายในขอบเขตของ NoSQL เพื่อแก้ไขปัญหานี้ วิธีแก้ปัญหาที่เป็นไปได้คือการใช้บันทึกการผนวก (เช่น Kafka) ตั้งแต่เริ่มการประมวลผลคำขอ แทนที่จะประมวลผลคำสั่ง 'ส่งใบสมัครสินเชื่อ' โดยตรง เราจะส่งคำสั่งนั้นไปยังหัวข้อ Kafka ภายในทันที จากนั้นจึงส่งคืนผลลัพธ์ 'ที่ยอมรับ' ไปยังไคลเอนต์ อย่างไรก็ตาม เนื่องจากมีแนวโน้มสูงที่คำสั่งนั้นยังต้องได้รับการประมวลผล เราจึงไม่สามารถแจ้งผลลัพธ์ให้ลูกค้าทราบได้ในทันที เพื่อจัดการกับความสอดคล้องที่อาจเกิดขึ้นในที่สุดนี้ เราสามารถใช้เทคนิคต่างๆ เช่น การโพลล์แบบยาว การโพลล์ที่เริ่มต้นโดยไคลเอนต์ การอัปเดต UI ในแง่ดี หรือการใช้ WebSockets หรือ Server-Sent Events สำหรับการแจ้งเตือน อย่างไรก็ตาม นี่เป็นหัวข้อที่แตกต่างกันโดยสิ้นเชิง ดังนั้น ให้เรากลับไปที่หัวข้อเริ่มต้นของเรา เราส่งข้อความในหัวข้อ Kafka ภายใน จากนั้น Loan Application Service จะใช้ข้อความนี้ — คำสั่งเดียวกับที่ได้รับจากไคลเอนต์ — และเริ่มดำเนินการ ขั้นแรกจะดำเนินการตรรกะทางธุรกิจบางอย่าง หลังจากดำเนินการตรรกะนี้สำเร็จแล้วและผลลัพธ์ยังคงอยู่ จึงจะเผยแพร่ข้อความใหม่ในหัวข้อ Kafka สาธารณะ ลองมาดูซูโดโค้ดสักหน่อย public async Task HandleAsync(SubmitLoanApplicationCommand command, ...) { //First, process business logic var loanApplication = await _loanApplicationService.HandleCommandAsync(command, ...); //Then, send new events to public Kafka topic producer.Send(new LoanApplicationSubmittedEvent(loanApplication.Id)); //Then, commit offset consumer.Commit(); } ไม่ต้องกังวล เนื่องจากยังไม่ได้ดำเนินการออฟเซ็ต ข้อความจะถูกลองใหม่อีกครั้ง จะเกิดอะไรขึ้นหากการประมวลผลลอจิกทางธุรกิจล้มเหลว ไม่ต้องกังวล เนื่องจากตรรกะทางธุรกิจเป็นอุดมคติ จึงไม่สร้างใบสมัครสินเชื่อซ้ำ แต่จะพยายามส่งข้อความไปยังหัวข้อ Kafka สาธารณะอีกครั้ง จะเกิดอะไรขึ้นหากการส่งเหตุการณ์ใหม่ไปยัง Kafka ล้มเหลว ไม่ต้องกังวล เนื่องจากตรรกะทางธุรกิจเป็นอุดมคติ จึงไม่สร้างใบสมัครสินเชื่อซ้ำ แต่จะส่งข้อความไปยังหัวข้อ Kafka สาธารณะอีกครั้ง และหวังว่าการคอมมิตออฟเซ็ตจะประสบความสำเร็จในครั้งนี้ จะเกิดอะไรขึ้นหากส่งข้อความถึง Kafka แต่การคอมมิตออฟเซ็ตล้มเหลว ข้อเสียหลักของแนวทางนี้ ได้แก่ ความซับซ้อนที่เพิ่มขึ้นที่เกี่ยวข้องกับรูปแบบการเขียนโปรแกรมใหม่ ความสอดคล้องในที่สุด (เนื่องจากไคลเอนต์จะไม่ทราบผลลัพธ์ทันที) และข้อกำหนดที่ตรรกะทางธุรกิจทั้งหมดต้องเป็นอุดมคติ การจัดหาแหล่งกิจกรรม การหาแหล่งที่มาของเหตุการณ์คืออะไร และสามารถนำมาใช้ในกรณีนี้ได้อย่างไร การหาแหล่งที่มาของเหตุการณ์เป็นรูปแบบสถาปัตยกรรมซอฟต์แวร์ที่ใช้สร้างแบบจำลองสถานะของระบบโดยบันทึกการเปลี่ยนแปลงทั้งหมดในข้อมูลเป็นชุดของเหตุการณ์ที่ไม่เปลี่ยนแปลง เหตุการณ์เหล่านี้แสดงถึงข้อเท็จจริงหรือการเปลี่ยนแปลงสถานะ และทำหน้าที่เป็นแหล่งข้อมูลเดียวสำหรับสถานะปัจจุบันของระบบ ดังนั้น ในทางเทคนิคแล้ว การนำระบบการหาแหล่งที่มาของเหตุการณ์มาใช้จะทำให้เรามีเหตุการณ์ทั้งหมดใน EventStore อยู่แล้ว และผู้บริโภคสามารถใช้ EventStore นี้เป็นแหล่งข้อมูลเดียวสำหรับสิ่งที่เกิดขึ้นได้ ไม่จำเป็นต้องมีโซลูชันฐานข้อมูลเฉพาะเพื่อติดตามการเปลี่ยนแปลงทั้งหมดหรือข้อกังวลเกี่ยวกับการสั่งซื้อ ปัญหาเดียวคือการนั่งอ่าน เนื่องจากต้องเล่นเหตุการณ์ทั้งหมดซ้ำจึงจะได้สถานะจริงของเอนทิตี บทสรุป ในบทความนี้ เราได้ทบทวนแนวทางต่างๆ ในการสร้างระบบส่งข้อความที่เชื่อถือได้ในระบบแบบกระจาย มีคำแนะนำหลายประการที่เราอาจพิจารณาขณะสร้างระบบที่มีลักษณะเหล่านี้ พัฒนาผู้บริโภคที่มีอุดมคติเสมอเนื่องจากความล้มเหลวของเครือข่ายเป็นสิ่งที่หลีกเลี่ยงไม่ได้ ใช้ อย่างระมัดระวังโดยต้องเข้าใจข้อกำหนดการรับประกันอย่างชัดเจน First-Local-Commit-Then-Publish อย่าใช้แนวทาง เนื่องจากอาจส่งผลให้เกิดความไม่สอดคล้องกันของข้อมูลในระบบได้ การเผยแพร่ก่อนแล้วจึงส่งไปยังเครื่อง หากการตัดสินใจเลือกฐานข้อมูลที่มีอยู่มีแนวโน้มว่าจะเปลี่ยนแปลงไป หรือกลยุทธ์ทางเทคนิคบ่งชี้ว่าต้องเลือกโซลูชันการจัดเก็บข้อมูลที่ดีที่สุดสำหรับปัญหานั้นๆ อย่าสร้างไลบรารีที่แชร์กันโดยการผูกกับโซลูชันฐานข้อมูลเช่น CDC ใช้แนวทาง เป็นโซลูชันมาตรฐานในการรับการรับประกันอย่างน้อยหนึ่งครั้ง Transactional Outbox พิจารณาใช้แนวทาง เมื่อมีการใช้ฐานข้อมูล No-SQL การฟังด้วยตนเอง ครั้งหน้าเราจะมาดูตัวอย่างการใช้งาน Transactional Outbox ในทางปฏิบัติกัน คุณ!