ออกแบบสำหรับการสื่อสาร API สถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์เป็นกระบวนทัศน์ที่ช่วยให้การมีเพศสัมพันธ์ต่ำระหว่างบริการ โดยเฉพาะอย่างยิ่ง ในสถาปัตยกรรมไมโครเซอร์วิส ไม่จำเป็นต้องใช้บริการเพื่อทำความรู้จักซึ่งกันและกันและค้นหาซึ่งกันและกันโดยใช้ API แบบซิงโครนัส สิ่งนี้ช่วยให้เราลดเวลาแฝง (หลีกเลี่ยง “ไมโครเซอร์วิสนรก”) และทำให้เปลี่ยนบริการแยกกันได้ง่ายขึ้น
โดยสรุป วิธีการนี้ใช้นายหน้าข้อความซึ่งจัดการหัวข้อ จำนวนหนึ่ง (หรือที่เรียกว่าบันทึกหรือสตรีม ) บริการหนึ่งสร้างหัวข้อในขณะที่บริการอื่นใช้จากหัวข้อ
กล่องดำเล็ก ๆ เหล่านี้แต่ละกล่องน่าจะต้องการมีสถานะของตัวเองเพื่อที่จะทำงานของมัน (บริการไร้สัญชาติมีอยู่จริง แต่สำหรับบางสิ่งที่จะไร้สัญชาติอย่างแท้จริง มีข้อแลกเปลี่ยนและจุดบกพร่องหลายประการที่คุณต้องแก้ไข และมักจะสะท้อนถึงสถาปัตยกรรมไมโครเซอร์วิสที่ซับซ้อนมากขึ้น บ่อยครั้งกว่านั้น สถาปัตยกรรมเหล่านี้สามารถอธิบายได้ว่าเป็น “ แจกโคลนก้อนโต”)
เป้าหมายของเราในการแนะนำนายหน้าข้อความคือการลดการพึ่งพาระหว่างกล่องเหล่านี้ ซึ่งหมายความว่าหากบริการ A มีข้อมูลบางอย่าง บริการ B ไม่ควรขอข้อมูลนั้นโดยตรงจากบริการ A เพราะบริการ A จะเผยแพร่ข้อมูลนั้นในหัวข้อ จากนั้นบริการ B สามารถใช้ข้อมูลและบันทึกลงในที่เก็บข้อมูลของตนเองหรือทำงานบางอย่างกับข้อมูลนั้นได้
เพิกเฉยต่อความท้าทายทางเทคนิคมากขึ้นด้วยแนวทางนี้ในด้านการผลิตหรือการบริโภค (เช่น การจับคู่การผลิตข้อความกับธุรกรรมฐานข้อมูล) ข้อมูลประเภทใดที่เป็นประโยชน์ในการส่งผ่านหัวข้อต่างๆ เราจะย้ายข้อมูลที่เก็บไว้จากบริการหนึ่งไปยังอีกบริการหนึ่งอย่างง่ายดายและปลอดภัยได้อย่างไร หัวข้อและบริการของเรามีลักษณะอย่างไรในสถานการณ์ต่างๆ
มาเริ่มตอบคำถามเหล่านั้นกันเลย
คาฟแกสก์
สำหรับวัตถุประสงค์ของการสนทนานี้ ฉันจะใช้Apache Kafkaเป็นเทคโนโลยีที่อยู่ภายใต้ตัวกลางของข้อความดังกล่าว นอกเหนือจากข้อดีในด้านต่างๆ เช่น ความสามารถในการปรับขนาด กู้คืน และประมวลผลสิ่งต่างๆ อย่างรวดเร็ว Kafka ยังมีคุณสมบัติบางอย่างที่ทำให้หัวข้อต่างๆ มีประโยชน์มากกว่าคิวธรรมดาหรือบัสข้อความ:
- ข้อความมีคีย์ที่เกี่ยวข้อง สามารถใช้คีย์เหล่านี้ใน กลยุทธ์การ บีบอัด (ซึ่งจะลบข้อความทั้งหมดที่มีคีย์เดียวกัน ยกเว้นข้อความล่าสุด) สิ่งนี้มีประโยชน์ใน หัวข้อที่มีเนื้อหา รุนแรงซึ่งฉันจะพูดถึงเพิ่มเติมด้านล่าง
- ข้อความจะถูกลบโดยการตั้งค่าการบีบอัดหรือการเก็บรักษา เท่านั้น (เช่น ลบข้อความใดๆ ที่เก่ากว่าเจ็ดวัน) ซึ่งจะไม่ถูกลบด้วยตนเองหรือทันทีที่เห็น
- ผู้บริโภคจำนวนเท่าใดก็ได้ (หรือมากกว่านั้นคือกลุ่มผู้บริโภค) สามารถอ่านจากหัวข้อเดียวกันได้ และแต่ละคนจะจัดการออฟเซ็ตของตนเอง
ผลที่สุดของคุณสมบัติเหล่านี้คือข้อความจะอยู่อย่างถาวรในหัวข้อ—หรือจนกว่าจะถูกล้างโดยการเก็บรักษาหรือการบดอัด—และทำหน้าที่เป็นบันทึกความจริง
คาฟคายังอนุญาตให้คุณจัดโครงสร้างข้อมูลของคุณ คุณสามารถส่งข้อมูลไบต์ชนิดใดก็ได้ผ่าน Kafka แต่ขอแนะนำอย่างยิ่งให้ใช้กรอบงานสคี มาเช่นAvroหรือProtobuf ฉันจะก้าวไปอีกขั้นและแนะนำว่าทุกข้อความในหัวข้อควรใช้สคีมาเดียวกัน มีประโยชน์มากมายสำหรับสิ่งนี้ แต่นั่นเป็นหัวข้อสำหรับบทความอื่น
ด้วยคุณสมบัติเหล่านี้และข้อมูลที่มีโครงสร้างแข็งแกร่ง เราสามารถออกแบบหัวข้อสำหรับแต่ละสถานการณ์ต่อไปนี้:
- หัวข้อเอนทิตี – “นี่คือสถานะปัจจุบันของ X”
- หัวข้อกิจกรรม – “X เกิดขึ้น”
- หัวข้อคำขอและคำตอบ” – “Please do X” → “X has been done”
หัวข้อเอนทิตี: แหล่งที่มาของความจริง
หัวข้อเอนทิตีเป็นหนึ่งในวิธีที่มีประโยชน์มากที่สุดในการใช้ Kafka เพื่อส่งต่อข้อมูลระหว่างบริการต่างๆ หัวข้อเอนทิตีรายงาน สถานะปัจจุบัน ของ วัตถุ
ตัวอย่างเช่น สมมติว่าคุณมีCustomersบริการที่รู้จักลูกค้าทั้งหมดที่บริษัทของคุณทำงานด้วย ในโลกที่ซิงโครนัส คุณต้องให้บริการนั้นตั้งค่า API เพื่อให้บริการอื่นๆ ทั้งหมดที่จำเป็นต้องทราบเกี่ยวกับลูกค้าจะต้องสืบค้นข้อมูลนั้น เมื่อใช้ Kafka คุณจะมีบริการนั้นเผยแพร่ไปยังCustomers หัวข้อแทน ซึ่งบริการอื่นๆ ทั้งหมดใช้มา
บริการผู้บริโภคสามารถถ่ายโอนข้อมูลนี้ไปยังฐานข้อมูลของตนเองได้โดยตรง สิ่งที่ยอดเยี่ยมเกี่ยวกับกระบวนทัศน์นี้คือแต่ละบริการสามารถจัดเก็บข้อมูลได้ตามต้องการ พวกเขาสามารถละทิ้งเขตข้อมูลหรือคอลัมน์ที่พวกเขาไม่สนใจ หรือแมปกับโครงสร้างข้อมูลหรือการแสดงข้อมูลที่แตกต่างกัน สิ่งสำคัญที่สุดคือ แต่ละบริการเป็นเจ้าของข้อมูลของตนเอง หากOrdersบริการของคุณจำเป็นต้องรู้เกี่ยวกับลูกค้า ไม่จำเป็นต้องขอ เพราะจะมีอยู่แล้วในฐานข้อมูลของตนเอง ออกแบบสำหรับการสื่อสาร API
คุณสมบัติอย่างหนึ่งของ Kafka คือข้อเท็จจริงที่ว่าทุกข้อความมีคีย์ที่ สอดคล้องกัน ซึ่ง มีประสิทธิภาพมากในการเปิดใช้หัวข้อประเภทนี้ คุณตั้งค่าคีย์เป็นตัวระบุใดๆ ก็ตามที่คุณต้องการสำหรับลูกค้ารายนั้น—รหัสบางชนิด จากนั้นคุณสามารถพึ่งพา Kafka เพื่อให้แน่ใจว่าในที่สุดคุณจะเห็นเพียงระเบียนเดียวสำหรับลูกค้าที่มี ID นั้น: ลูกค้าเวอร์ชันล่าสุด
คุณสมบัติอื่น – การแบ่งพาร์ติชั่น – ทำให้มั่นใจได้ว่าคำสั่งนั้นรับประกันสำหรับข้อความใด ๆ ที่มีคีย์เดียวกัน ซึ่งหมายความว่าคุณจะไม่มีวันใช้ข้อความผิดระเบียบ ดังนั้นเมื่อใดก็ตามที่คุณพบลูกค้ารายนั้น คุณจะทราบข้อเท็จจริงว่าเป็นเวอร์ชันล่าสุดของลูกค้ารายนั้นที่คุณยังไม่เคยเห็น
ผู้บริโภคสามารถเพิ่มข้อมูลลูกค้าลงในฐานข้อมูล—แทรกเข้าไปหากไม่มีอยู่ อัปเดตหากมี คาฟคายังมีแบบแผนในการระบุการลบ: ข้อความที่มีคีย์แต่เพย์โหลดเป็นโมฆะ หรือที่เรียกว่าหลุมฝังศพ สิ่งนี้บ่งชี้ว่าควรลบเรกคอร์ด เนื่องจากการบีบอัด ข้อความที่ไม่ใช่หลุมฝังศพทั้งหมดจะหายไปในที่สุด ไม่เหลืออะไรเลยนอกจากบันทึกการลบ (และสามารถบีบอัดอัตโนมัติได้เช่นกัน)
เนื่องจากหัวข้อเอนทิตีแสดงถึงมุมมองภายนอกในสถานะของบริการที่มีอยู่ คุณจึงสามารถส่งออกข้อมูลเพียงเล็กน้อยเท่าที่คุณต้องการ คุณสามารถปรับปรุงข้อมูลนั้นในภายหลังได้โดยการเพิ่มฟิลด์ให้กับข้อมูลที่ส่งออกและเผยแพร่อีกครั้ง (การลบฟิลด์นั้นยากกว่า เนื่องจากคุณจะต้องติดตามผู้ใช้ข้อมูลทั้งหมดเพื่อดูว่าพวกเขาใช้ฟิลด์เหล่านั้นจริงหรือไม่)
หัวข้อของเอนทิตีนั้นยอดเยี่ยม แต่มาพร้อมกับข้อแม้ที่สำคัญข้อหนึ่ง: พวกมันให้ความสอดคล้องกันในท้ายที่สุด เนื่องจากหัวข้อเป็นแบบอะซิงโครนัส คุณจึงไม่สามารถรับประกันได้ว่าสิ่งที่คุณมีในฐานข้อมูลของคุณตรงกับฐานข้อมูลของโปรดิวเซอร์ทุกประการ ซึ่งอาจล้าสมัยเป็นวินาทีหรือแม้แต่นาทีหากโบรกเกอร์ของคุณประสบปัญหาการชะลอตัว ถ้าคุณ:
- ต้องการให้ข้อมูลของคุณมีความถูกต้อง 100 เปอร์เซ็นต์ ณ เวลาที่ใช้งานหรือ
- คุณต้องรวบรวมข้อมูลจากมากกว่าหนึ่งแหล่ง และทั้งสองแหล่งมีลิงก์ที่ต้องตรงกันอย่างสมบูรณ์
ดังนั้นการใช้การประมวลผลแบบอะซิงโครนัสอาจไม่ใช่สิ่งที่คุณต้องการ: คุณต้องพึ่งพาการสืบค้น API แบบเก่าที่ดี
หัวข้อเหตุการณ์: บันทึกข้อเท็จจริง
หัวข้อกิจกรรมแตกต่างจากหัวข้อเอนทิตีอย่างสิ้นเชิง หัวข้อเหตุการณ์ระบุว่ามีบางสิ่งเกิดขึ้น แทนที่จะให้ข้อมูลชิ้นใดชิ้นหนึ่งที่เป็นเวอร์ชันล่าสุด หัวข้อเหตุการณ์ให้บันทึก “โง่ๆ” ของสิ่งที่เกิดขึ้น
(โปรดทราบว่าฉันจะไม่ครอบคลุมถึงการจัดหาเหตุการณ์ซึ่งใช้เหตุการณ์เพื่อสร้างสถานะของเรกคอร์ดใหม่ ฉันพบว่ารูปแบบนั้นเป็นการใช้เฉพาะกลุ่มในบริบทเฉพาะ และฉันไม่เคยใช้มันในการผลิต)
เหตุการณ์ส่วนใหญ่ใช้ด้วยเหตุผลสองประการ:
- รวบรวมข้อมูลเกี่ยวกับพฤติกรรมของผู้ใช้หรือแอปพลิเคชัน สิ่งนี้มักจะให้อำนาจแก่การวิเคราะห์และการตัดสินใจด้วยตนเองหรือโดยอัตโนมัติ
- ปิดงานหรือฟังก์ชันบางอย่างเมื่อมีเหตุการณ์เฉพาะเกิดขึ้น นี่คือพื้นฐานของ สถาปัตยกรรมการ ออกแบบท่าเต้นซึ่งเป็นการออกแบบแบบกระจายอำนาจที่แต่ละระบบรู้เฉพาะอินพุตของตนเอง
ตรงข้ามกับหัวข้อเอนทิตี หัวข้อเหตุการณ์สามารถจับภาพสิ่งที่เกิดขึ้นในช่วงเวลาที่แน่นอนเท่านั้น คุณไม่สามารถเพิ่มข้อมูลลงไปโดยพลการได้ เนื่องจากข้อมูลนั้นอาจมีการเปลี่ยนแปลง ตัวอย่างเช่น หากคุณต้องการเพิ่มที่อยู่ของลูกค้าในกิจกรรมการสั่งซื้อในภายหลัง คุณจะต้องอ้างอิงข้ามที่อยู่ณ เวลาที่เหตุการณ์นั้นเกิดขึ้นซึ่งโดยปกติแล้วจะเป็นการทำงานมากกว่าที่คุ้มค่า
หากต้องการย้ำว่า หัวข้อเอนทิตีควรมีฟิลด์น้อยที่สุดเท่าที่จะเป็นไปได้เนื่องจากการเพิ่มฟิลด์นั้นค่อนข้างง่ายและลบออกได้ยาก ในทางกลับกัน หัวข้อเหตุการณ์ควรมีฟิลด์มากที่สุดเท่าที่คุณคิดว่าจำเป็นเพราะคุณไม่สามารถเพิ่มข้อมูลต่อท้ายข้อเท็จจริงได้
หัวข้อเหตุการณ์ไม่ต้องการคีย์ข้อความเนื่องจากไม่ได้แสดงถึงการอัปเดตของวัตถุเดียวกัน ควรแบ่งพาร์ติชันอย่างถูกต้อง เนื่องจากคุณอาจต้องการทำงานกับเหตุการณ์ที่เกิดขึ้นกับเรกคอร์ดเดียวกันตามลำดับ
หัวข้อคำขอและการตอบสนอง: Async API
หัวข้อ คำขอและการตอบสนองเป็นเสียงที่ฟังดูเหมือนไม่มากก็น้อย:
- ลูกค้าส่งข้อความร้องขอผ่านหัวข้อไปยังผู้บริโภค
- ผู้บริโภคดำเนินการบางอย่าง จากนั้นส่งข้อความตอบกลับผ่านหัวข้อกลับไปยังผู้บริโภค
รูปแบบนี้มีประโยชน์โดยทั่วไปน้อยกว่ารูปแบบก่อนหน้าเล็กน้อย โดยทั่วไป รูปแบบนี้จะสร้างสถาปัตยกรรมการประสานซึ่งบริการจะบอกบริการอื่นๆ อย่างชัดเจนว่าต้องทำอะไร มีเหตุผลสองสามประการที่คุณอาจต้องการใช้หัวข้อเพื่อขับเคลื่อนสิ่งนี้แทน API แบบซิงโครนัส:
- คุณต้องการรักษาการเชื่อมต่อต่ำระหว่างบริการที่นายหน้าข้อความมอบให้เรา หากบริการที่ทำงานมีการเปลี่ยนแปลงตลอดเวลา บริการที่ใช้งานจริงก็ไม่จำเป็นต้องทราบเรื่องนี้ เนื่องจากเป็นเพียงการส่งคำขอไปยังหัวข้อหนึ่งๆ แทนที่จะถามบริการโดยตรง
- งานใช้เวลานานกว่าจะเสร็จสิ้น ถึงจุดที่คำขอซิงโครนัสมักจะหมดเวลา ในกรณีนี้ คุณอาจตัดสินใจใช้ หัวข้อ ตอบกลับแต่ยังคงส่งคำขอพร้อมกัน
- คุณกำลังใช้ตัวรับส่งข้อความสำหรับการสื่อสารส่วนใหญ่ของคุณอยู่แล้ว และต้องการใช้การบังคับใช้สคีมาที่มีอยู่และความเข้ากันได้แบบย้อนกลับที่ได้รับการสนับสนุนโดยอัตโนมัติโดยเครื่องมือที่ใช้กับคาฟคา
ข้อเสียอย่างหนึ่งของรูปแบบนี้คือคุณจะไม่ได้รับคำตอบในทันทีว่าคำขอนั้นสำเร็จหรือไม่ หรืออย่างน้อยก็ได้รับสำเร็จ บ่อยครั้งในสถานการณ์ “ดำเนินการบางอย่าง” ข้อมูลนี้มีประโยชน์มากที่จะทราบทันที โดยเฉพาะอย่างยิ่งหากเป็นธุรกรรมเชิงตรรกะบางประเภท
หากคุณใช้รูปแบบนี้ คุณอาจเปลี่ยนรูปแบบปกติของสถาปัตยกรรม Kafka และมีผู้ผลิต หลายราย ที่มีผู้บริโภค เพียงราย เดียว ในกรณีนี้ผู้บริโภคเป็นเจ้าของสคีมา ไม่ใช่ผู้ผลิต ซึ่งเป็นวิธีการทำงานที่ไม่ชัดเจน
เข้าร่วมและปรับปรุงหัวข้อ
กรณีการใช้งานทั่วไปสำหรับไมโครเซอร์วิสคือการรวมสองหัวข้อเข้าด้วยกันหรือปรับปรุงหัวข้อที่มีอยู่ด้วยข้อมูลเพิ่มเติม ตัวอย่างเช่น ที่Flippเราอาจมีหัวข้อที่มีข้อมูลผลิตภัณฑ์และหัวข้ออื่นที่เพิ่มหมวดหมู่ให้กับผลิตภัณฑ์ตามข้อมูลที่ป้อนเข้ามา
มีเครื่องมือที่มีอยู่แล้วที่ช่วยในกรณีการใช้งานเหล่า นี้เช่นKafka Streams สิ่งเหล่านี้มีประโยชน์ แต่มีข้อผิดพลาดมากมายที่เกี่ยวข้องกับการใช้:
- หัวข้อของคุณต้องมีสคีมาหลักเดียวกัน การเปลี่ยนแปลงใด ๆ กับคีย์สคีมาอาจต้องแบ่งพาร์ติชันใหม่ ซึ่งอาจมีราคาแพง
- หัวข้อของคุณควรมีปริมาณ งานพอๆ กัน หากหัวข้อใดหัวข้อหนึ่งใหญ่กว่า มาก หรือมี ข้อความ มากกว่าอีกหัวข้อหนึ่ง แสดงว่าคุณติดอยู่กับหัวข้อที่แย่ที่สุดของทั้งสองหัวข้อ คุณอาจลงเอยด้วยการเข้าร่วมหัวข้อ “เล็ก เร็ว” (อัปเดตจำนวนมาก ข้อความเล็ก) กับหัวข้อ “ใหญ่ ช้า” (อัปเดตน้อยลง ข้อความใหญ่ขึ้น) และต้องแสดงหัวข้อ “ใหญ่ เร็ว” ซึ่งอาจทำลาย บริการดาวน์สตรีมของคุณ
- คุณกำลังเพิ่มการใช้ข้อมูลของคุณเป็นสองเท่าทุกครั้งที่คุณเปลี่ยนหัวข้อหนึ่งเป็นอีกหัวข้อหนึ่ง แม้ว่าคุณจะได้รับประโยชน์จากบริการที่มีสถานะน้อยกว่า แต่คุณก็จ่ายตามราคาสำหรับโบรกเกอร์ของคุณและยังมีลิงค์อื่นในห่วงโซ่ที่สามารถใช้งานไม่ได้
- ข้อมูลภายในของบริการเหล่านี้อาจไม่ชัดเจนและเข้าใจยาก ตัวอย่างเช่น โดยค่าเริ่มต้น พวกเขาใช้ Kafka เป็นสถานะภายใน ส่งผลให้ตัวจัดการข้อความมีความเครียดมากขึ้นและหัวข้อชั่วคราวจำนวนมาก
ที่ Flipp เราเริ่มเลิกใช้ Kafka Streams และชอบใช้การเขียนบางส่วนไปยังที่เก็บข้อมูล หากหัวข้อจำเป็นต้องเข้าร่วม เราใช้เครื่องมืออย่างDeimosเพื่อทำให้การดัมพ์ทุกอย่างไปยังฐานข้อมูลในเครื่องเป็นเรื่องง่าย และสร้างอีกครั้งโดยใช้สคีมาและจังหวะที่เหมาะสม
บทสรุป
โบรกเกอร์ข้อความและหัวข้อเป็นวิธีการที่สมบูรณ์ในการขยายสถาปัตยกรรมของคุณ ลดการพึ่งพา และเพิ่มความปลอดภัยและความสามารถในการปรับขนาด การออกแบบระบบและหัวข้อของคุณเป็นงานที่ไม่สำคัญ และฉันได้นำเสนอรูปแบบบางอย่างที่ฉันพบว่ามีประโยชน์ เช่นเดียวกับสิ่งอื่นๆ สิ่งเหล่านี้ไม่ได้ถูกออกแบบมาเพื่อใช้ในทุกสถานการณ์ แต่มีหลายกรณีที่การใช้สิ่งเหล่านี้จะทำให้สถาปัตยกรรมมีความแข็งแกร่ง มีประสิทธิภาพ และบำรุงรักษาได้มากขึ้น
Face-sso (By K&O) หากท่านสนใจ เครื่องสแกนใบหน้ารุ่นต่างๆ หลากหลายรุ่น หรือ ติดตั้งระบบสแกนใบหน้า สามารถติดต่อสอบถามได้โดยตรง เรามีแอดมินคอยคอบคำถาม 24 ชั้วโมงที่ Line OA เครื่องสแกนใบหน้า สามารถ ขอราคาพิเศษได้ ตามงบประมาณที่เหมาะสม สอบถามได้สบายใจทั้ง เรื่องค่าบริการ ราคา และ งบประมาณ มั่นใจเพราะเป็นราคาที่สุด คุ้มค่าที่สุด
หากท่านมีความสนใจ บทความ หรือ Technology สามารถติดต่อได้ตามเบอร์ที่ให้ไว้ด้านล่างนี้
Tel.086-594-5494
Tel.095-919-6699
