อะไรสามารถบังคับให้บริษัทขนาดใหญ่อย่าง Lamoda ซึ่งมีกระบวนการที่คล่องตัวและบริการที่เชื่อมโยงถึงกันหลายสิบรายการต้องเปลี่ยนแนวทางไปอย่างมาก แรงจูงใจอาจแตกต่างกันอย่างสิ้นเชิง: ตั้งแต่ด้านกฎหมายจนถึงความปรารถนาที่จะทดลองซึ่งมีอยู่ในโปรแกรมเมอร์ทุกคน
แต่ไม่ได้หมายความว่าคุณไม่สามารถนับสิทธิประโยชน์เพิ่มเติมได้ Sergey Zaika จะบอกคุณว่าคุณสามารถชนะอะไรได้บ้างหากคุณใช้ API ที่ขับเคลื่อนด้วยเหตุการณ์บน Kafka (). จะมีการพูดคุยเกี่ยวกับภาพใหญ่และการค้นพบที่น่าสนใจอย่างแน่นอน - การทดลองไม่สามารถทำได้หากไม่มีพวกเขา
ข้อจำกัดความรับผิดชอบ: บทความนี้อ้างอิงจากเนื้อหาจากการพบปะที่ Sergey จัดขึ้นในเดือนพฤศจิกายน 2018 บน HighLoad++ ประสบการณ์สดในการทำงานร่วมกับ Kafka ของ Lamoda ดึงดูดผู้ฟังไม่น้อยไปกว่ารายงานอื่นๆ ตามกำหนดการ เราคิดว่านี่เป็นตัวอย่างที่ดีเยี่ยมของความจริงที่ว่าคุณสามารถและควรพบคนที่มีความคิดเหมือนกันเสมอ และผู้จัดงาน HighLoad++ จะพยายามสร้างบรรยากาศที่เอื้อต่อสิ่งนี้ต่อไป
เกี่ยวกับกระบวนการ
Lamoda เป็นแพลตฟอร์มอีคอมเมิร์ซขนาดใหญ่ที่มีศูนย์ติดต่อ บริการจัดส่ง (และบริษัทในเครือหลายแห่ง) สตูดิโอถ่ายภาพ โกดังขนาดใหญ่ และทั้งหมดนี้ทำงานบนซอฟต์แวร์ของตัวเอง มีวิธีการชำระเงินมากมาย พันธมิตร b2b ที่อาจใช้บริการบางส่วนหรือทั้งหมดเหล่านี้ และต้องการทราบข้อมูลล่าสุดเกี่ยวกับผลิตภัณฑ์ของตน นอกจากนี้ Lamoda ยังดำเนินงานในสามประเทศนอกเหนือจากสหพันธรัฐรัสเซีย และทุกอย่างมีความแตกต่างกันเล็กน้อย โดยรวมแล้วอาจมีวิธีกำหนดค่าคำสั่งซื้อใหม่มากกว่าร้อยวิธีซึ่งจะต้องดำเนินการในลักษณะของตัวเอง ทั้งหมดนี้ทำงานด้วยความช่วยเหลือจากบริการมากมายที่บางครั้งสื่อสารด้วยวิธีที่ไม่ชัดเจน นอกจากนี้ยังมีระบบกลางที่มีหน้าที่หลักคือสถานะคำสั่งซื้อ เราเรียกเธอว่า BOB ฉันทำงานกับเธอ
เครื่องมือการคืนเงินพร้อม API ที่ขับเคลื่อนด้วยเหตุการณ์
คำว่าขับเคลื่อนด้วยเหตุการณ์นั้นค่อนข้างถูกแฮ็ก ต่อไปอีกหน่อยเราจะให้รายละเอียดเพิ่มเติมว่าสิ่งนี้หมายถึงอะไร ฉันจะเริ่มต้นด้วยบริบทที่เราตัดสินใจลองใช้แนวทาง API ที่ขับเคลื่อนด้วยเหตุการณ์ใน Kafka
ในร้านค้าใดๆ นอกเหนือจากคำสั่งซื้อที่ลูกค้าชำระเงินแล้ว ยังมีบางครั้งที่ร้านค้าต้องคืนเงินเนื่องจากสินค้าไม่เหมาะกับลูกค้า นี่เป็นกระบวนการที่ค่อนข้างสั้น: เราจะชี้แจงข้อมูลหากจำเป็น และโอนเงิน
แต่การกลับมามีความซับซ้อนมากขึ้นเนื่องจากการเปลี่ยนแปลงทางกฎหมาย และเราต้องใช้ไมโครเซอร์วิสแยกต่างหาก
แรงจูงใจของเรา:
- กฎหมาย FZ-54 กล่าวโดยสรุป กฎหมายกำหนดให้ต้องรายงานต่อสำนักงานภาษีเกี่ยวกับธุรกรรมทางการเงินทุกรายการ ไม่ว่าจะเป็นการคืนสินค้าหรือใบเสร็จรับเงิน ภายในระยะเวลา SLA สั้นๆ เพียงไม่กี่นาที ในฐานะบริษัทอีคอมเมิร์ซ เราดำเนินธุรกิจค่อนข้างมาก ในทางเทคนิค นี่หมายถึงความรับผิดชอบใหม่ (และการบริการใหม่) และการปรับปรุงระบบที่เกี่ยวข้องทั้งหมด
- บ๊อบแยก เป็นโครงการภายในของบริษัทเพื่อลดภาระ BOB จากความรับผิดชอบที่ไม่ใช่งานหลักจำนวนมาก และลดความซับซ้อนโดยรวม
แผนภาพนี้แสดงระบบหลักของ Lamoda ตอนนี้ส่วนใหญ่มีมากกว่านั้น กลุ่มไมโครเซอร์วิส 5-10 กลุ่มรอบๆ เสาหินที่กำลังหดตัว. พวกมันเติบโตอย่างช้าๆ แต่เราพยายามทำให้พวกมันเล็กลง เนื่องจากการปรับใช้ชิ้นส่วนที่เลือกไว้ตรงกลางนั้นน่ากลัว - เราไม่สามารถปล่อยให้มันร่วงหล่นได้ เราถูกบังคับให้จองการแลกเปลี่ยนทั้งหมด (ลูกศร) และคำนึงถึงข้อเท็จจริงที่ว่าการแลกเปลี่ยนใด ๆ อาจไม่พร้อมใช้งาน
BOB มีการแลกเปลี่ยนค่อนข้างมาก: ระบบการชำระเงิน ระบบการจัดส่ง ระบบการแจ้งเตือน ฯลฯ
ในทางเทคนิค BOB คือ:
- โค้ด ~150 บรรทัด + การทดสอบ ~100 บรรทัด
- php7.2 + Zend 1 และส่วนประกอบ Symfony 3;
- >100 API และ ~50 การผสานรวมขาออก
- 4 ประเทศที่มีตรรกะทางธุรกิจเป็นของตัวเอง
การปรับใช้ BOB มีราคาแพงและเจ็บปวด จำนวนโค้ดและปัญหาที่แก้ไขได้มากจนไม่มีใครสามารถใส่ใจทุกอย่างได้ โดยทั่วไปมีเหตุผลหลายประการที่ทำให้ง่ายขึ้น
กระบวนการส่งคืน
ในขั้นต้น มีสองระบบที่เกี่ยวข้องในกระบวนการ: BOB และการชำระเงิน ตอนนี้มีอีกสองตัวปรากฏขึ้น:
- บริการด้านการเงินซึ่งจะดูแลปัญหาด้านการเงินและการสื่อสารกับบริการภายนอก
- Refund Tool ซึ่งมีการแลกเปลี่ยนใหม่เพื่อไม่ให้ BOB ขยายตัว
ตอนนี้กระบวนการมีลักษณะดังนี้:
- BOB ได้รับคำขอคืนเงิน
- BOB พูดถึงเครื่องมือการคืนเงินนี้
- เครื่องมือการคืนเงินแจ้งการชำระเงิน: “คืนเงิน”
- การชำระเงินจะคืนเงิน
- Refund Tool และ BOB ซิงโครไนซ์สถานะซึ่งกันและกัน เพราะตอนนี้ทั้งคู่ต้องการมัน เรายังไม่พร้อมที่จะเปลี่ยนไปใช้เครื่องมือการคืนเงินโดยสมบูรณ์ เนื่องจาก BOB มี UI, รายงานสำหรับการบัญชี และโดยทั่วไปแล้ว ข้อมูลจำนวนมากที่ไม่สามารถถ่ายโอนได้อย่างง่ายดาย คุณต้องนั่งบนเก้าอี้สองตัว
- คำขอจัดเก็บภาษีหายไป
ด้วยเหตุนี้เราจึงสร้างอีเว้นท์บัสบน Kafka ซึ่งเป็นอีเว้นท์บัสซึ่งทุกอย่างเริ่มต้นขึ้น ไชโย ตอนนี้เรามีจุดเสียจุดเดียว (เสียดสี)
ข้อดีข้อเสียค่อนข้างชัดเจน เราสร้างรถบัสขึ้นมา ซึ่งหมายความว่าตอนนี้บริการทั้งหมดขึ้นอยู่กับรถบัสแล้ว สิ่งนี้ทำให้การออกแบบง่ายขึ้น แต่ทำให้เกิดความล้มเหลวเพียงจุดเดียวในระบบ คาฟคาจะพัง กระบวนการจะหยุดลง
API ที่ขับเคลื่อนด้วยเหตุการณ์คืออะไร
คำตอบที่ดีสำหรับคำถามนี้อยู่ในรายงานของ Martin Fowler (GOTO 2017) .
สรุปสิ่งที่เราทำ:
- สรุปการแลกเปลี่ยนแบบอะซิงโครนัสทั้งหมดผ่าน การจัดเก็บเหตุการณ์. แทนที่จะแจ้งให้ผู้บริโภคที่สนใจทุกคนทราบเกี่ยวกับการเปลี่ยนแปลงสถานะบนเครือข่าย เราจะเขียนกิจกรรมเกี่ยวกับการเปลี่ยนแปลงสถานะเป็นที่เก็บข้อมูลแบบรวมศูนย์ และผู้บริโภคที่สนใจในหัวข้อนี้จะอ่านทุกสิ่งที่ปรากฏขึ้นจากที่นั่น
- เหตุการณ์ในกรณีนี้คือการแจ้งเตือน (การแจ้งเตือน) มีบางอย่างเปลี่ยนแปลงไปที่ไหนสักแห่ง เช่น สถานะคำสั่งซื้อมีการเปลี่ยนแปลง ผู้บริโภคที่สนใจข้อมูลบางอย่างที่มาพร้อมกับการเปลี่ยนแปลงสถานะที่ไม่รวมอยู่ในการแจ้งเตือนสามารถค้นหาสถานะได้ด้วยตนเอง
- ตัวเลือกสูงสุดคือการจัดหากิจกรรมที่ครบครัน การโอนของรัฐซึ่งในเหตุการณ์ประกอบด้วยข้อมูลทั้งหมดที่จำเป็นสำหรับการประมวลผล: ข้อมูลมาจากไหนและสถานะไปที่ใด ข้อมูลเปลี่ยนแปลงไปอย่างไร ฯลฯ คำถามเดียวคือความเป็นไปได้และปริมาณข้อมูลที่คุณสามารถจัดเก็บได้
ในการเปิดตัวเครื่องมือการคืนเงิน เราใช้ตัวเลือกที่สาม การประมวลผลเหตุการณ์ที่ง่ายขึ้นนี้เนื่องจากไม่จำเป็นต้องดึงข้อมูลโดยละเอียด อีกทั้งยังช่วยขจัดสถานการณ์ที่แต่ละเหตุการณ์ใหม่ทำให้เกิดการชี้แจงคำขอรับจากผู้บริโภคจำนวนมาก
บริการขอคืนเงินเครื่องมือ ไม่ได้โหลดดังนั้น Kafka จึงมีรสชาติของปากกามากกว่าความจำเป็น ฉันไม่คิดว่าถ้าบริการคืนเงินกลายเป็นโครงการที่มีภาระสูง ธุรกิจก็จะมีความสุข
การแลกเปลี่ยน Async ตามที่เป็นอยู่
สำหรับการแลกเปลี่ยนแบบอะซิงโครนัส แผนก PHP มักจะใช้ RabbitMQ เรารวบรวมข้อมูลสำหรับคำขอ จัดไว้ในคิว และผู้ใช้บริการเดียวกันจะอ่านและส่งคำขอ (หรือไม่ได้ส่ง) สำหรับ API นั้น Lamoda ใช้งาน Swagger อย่างจริงจัง เราออกแบบ API อธิบายเป็นภาษา Swagger และสร้างโค้ดไคลเอนต์และเซิร์ฟเวอร์ นอกจากนี้เรายังใช้ JSON RPC 2.0 ที่ได้รับการปรับปรุงเล็กน้อยอีกด้วย
ในบางสถานที่มีการใช้บัส ESB บางแห่งใช้งานบน activeMQ แต่โดยทั่วไปแล้ว RabbitMQ - มาตรฐาน.
การแลกเปลี่ยน Async TO BE
เมื่อออกแบบการแลกเปลี่ยนผ่านบัสเหตุการณ์ สามารถตรวจสอบการเปรียบเทียบได้ เราอธิบายการแลกเปลี่ยนข้อมูลในอนาคตผ่านคำอธิบายโครงสร้างเหตุการณ์ในทำนองเดียวกัน ในรูปแบบ yaml เราต้องทำการสร้างโค้ดด้วยตัวเอง ตัวสร้างจะสร้าง DTO ตามข้อกำหนดและสอนไคลเอนต์และเซิร์ฟเวอร์ให้ทำงานกับพวกมัน รุ่นแบ่งออกเป็นสองภาษา - golang และ php.ini. สิ่งนี้ช่วยให้ห้องสมุดมีความสอดคล้องกัน เครื่องกำเนิดเขียนด้วยภาษา golang จึงเป็นที่มาของชื่อ gogi
การจัดหากิจกรรมบน Kafka เป็นเรื่องปกติ มีวิธีแก้ไขปัญหาจาก Kafka Confluent เวอร์ชันองค์กรหลักอยู่นั่นเอง ซึ่งเป็นโซลูชันจากพี่น้องโดเมนของเรา Zalando ของเรา แรงจูงใจในการเริ่มต้นด้วยวานิลลาคาฟคา - นี่หมายถึงการปล่อยให้โซลูชันเป็นอิสระจนกว่าเราจะตัดสินใจว่าจะใช้มันทุกที่ในที่สุดหรือไม่ และยังปล่อยให้ตัวเองมีที่ว่างสำหรับการซ้อมรบและการปรับปรุง: เราต้องการการสนับสนุนสำหรับเรา เจสัน อาร์พีซี 2.0, เครื่องกำเนิดสำหรับสองภาษา มาดูกันว่ามีอะไรอีกบ้าง
เป็นเรื่องน่าขันที่แม้ในกรณีที่มีความสุขเช่นนี้ เมื่อมีธุรกิจโดยคร่าวที่คล้ายคลึงกันอย่าง Zalando ซึ่งสร้างโซลูชันคร่าวๆ ที่คล้ายกัน เราก็ไม่สามารถใช้มันได้อย่างมีประสิทธิภาพ
รูปแบบสถาปัตยกรรมเมื่อเปิดตัวมีดังนี้ เราอ่านโดยตรงจาก Kafka แต่เขียนผ่าน events-bus เท่านั้น มีอะไรพร้อมให้อ่านมากมายใน Kafka: โบรกเกอร์, บาลานเซอร์ และพร้อมสำหรับการปรับขนาดแนวนอน ไม่มากก็น้อย ฉันต้องการรักษาสิ่งนี้ไว้ เราต้องการทำให้การบันทึกเสร็จสมบูรณ์ผ่าน Gateway หรือที่รู้จักในชื่อ Events-bus และนี่คือสาเหตุ
เหตุการณ์รถบัส
หรือรถอีเว้นท์ นี่เป็นเพียงเกตเวย์ http ไร้สถานะ ซึ่งมีบทบาทสำคัญหลายประการ:
- การผลิตการตรวจสอบ — เราตรวจสอบว่าเหตุการณ์เป็นไปตามข้อกำหนดของเรา
- ระบบหลักของเหตุการณ์นั่นคือนี่เป็นระบบหลักและเป็นระบบเดียวใน บริษัท ที่ตอบคำถามว่าเหตุการณ์ใดที่โครงสร้างใดถือว่าถูกต้อง การตรวจสอบความถูกต้องเกี่ยวข้องกับประเภทข้อมูลและแจงนับเพื่อระบุเนื้อหาอย่างเคร่งครัด
- ฟังก์ชันแฮช สำหรับการแบ่งส่วน - โครงสร้างข้อความ Kafka คือคีย์-ค่า และการใช้แฮชของคีย์จะคำนวณว่าจะวางไว้ที่ใด
Why
เราทำงานในบริษัทขนาดใหญ่ที่มีกระบวนการที่คล่องตัว ทำไมต้องเปลี่ยนแปลงอะไร? นี่คือการทดลองและเราคาดว่าจะได้รับผลประโยชน์หลายประการ
การแลกเปลี่ยน 1:n+1 (หนึ่งต่อหลาย)
Kafka ทำให้การเชื่อมต่อผู้บริโภครายใหม่เข้ากับ API เป็นเรื่องง่ายมาก
สมมติว่าคุณมีไดเร็กทอรีที่คุณต้องอัปเดตในหลายระบบพร้อมกัน (และในระบบใหม่บางระบบ) ก่อนหน้านี้ เราได้คิดค้นชุดที่ใช้ set-API และระบบหลักได้รับแจ้งที่อยู่ของผู้บริโภค ขณะนี้ระบบหลักส่งการอัปเดตไปยังหัวข้อนี้และทุกคนที่สนใจจะอ่าน มีระบบใหม่ปรากฏขึ้น - เราลงทะเบียนสำหรับหัวข้อนี้ ใช่ มัดรวมด้วย แต่ง่ายกว่า
ในกรณีของเครื่องมือการคืนเงินซึ่งเป็นส่วนหนึ่งของ BOB จะสะดวกสำหรับเราที่จะซิงค์ข้อมูลเหล่านั้นผ่าน Kafka การชำระเงินแจ้งว่ามีการคืนเงินแล้ว: BOB, RT พบเกี่ยวกับสิ่งนี้, เปลี่ยนสถานะของพวกเขา, Fiscalization Service พบเกี่ยวกับสิ่งนี้และออกเช็ค
เรามีแผนที่จะสร้างบริการการแจ้งเตือนแบบรวมที่จะแจ้งให้ลูกค้าทราบเกี่ยวกับข่าวสารเกี่ยวกับคำสั่งซื้อ/การคืนสินค้าของเขา ตอนนี้ความรับผิดชอบนี้ถูกกระจายออกไประหว่างระบบต่างๆ การสอนบริการการแจ้งเตือนให้รับข้อมูลที่เกี่ยวข้องจาก Kafka และตอบกลับข้อมูลดังกล่าวก็เพียงพอแล้ว (และปิดใช้งานการแจ้งเตือนเหล่านี้ในระบบอื่น) ไม่จำเป็นต้องมีการแลกเปลี่ยนโดยตรงใหม่
ที่ขับเคลื่อนด้วยข้อมูล
ข้อมูลระหว่างระบบจะมีความโปร่งใส ไม่ว่าคุณจะมี "องค์กรนองเลือด" อะไรก็ตาม และไม่ว่างานในมือของคุณจะล้นขนาดไหน Lamoda มีแผนกวิเคราะห์ข้อมูลที่รวบรวมข้อมูลจากระบบและจัดวางให้อยู่ในรูปแบบที่สามารถนำมาใช้ซ้ำได้ ทั้งสำหรับธุรกิจและระบบอัจฉริยะ Kafka ช่วยให้คุณสามารถให้ข้อมูลจำนวนมากแก่พวกเขาได้อย่างรวดเร็ว และอัปเดตข้อมูลให้ทันสมัยอยู่เสมอ
บันทึกการจำลองแบบ
ข้อความจะไม่หายไปหลังจากถูกอ่าน เช่นเดียวกับใน RabbitMQ เมื่อเหตุการณ์มีข้อมูลเพียงพอสำหรับการประมวลผล เราจะมีประวัติการเปลี่ยนแปลงล่าสุดกับออบเจ็กต์ และหากต้องการ ความสามารถในการนำการเปลี่ยนแปลงเหล่านี้ไปใช้
ระยะเวลาการจัดเก็บบันทึกการจำลองขึ้นอยู่กับความเข้มข้นของการเขียนในหัวข้อนี้ Kafka ช่วยให้คุณกำหนดขีดจำกัดเวลาในการจัดเก็บและปริมาณข้อมูลได้อย่างยืดหยุ่น สำหรับหัวข้อที่เข้มข้น ผู้บริโภคทุกคนจะต้องมีเวลาอ่านข้อมูลก่อนที่จะหายไป แม้ว่าจะใช้งานไม่ได้ในระยะสั้นก็ตาม โดยปกติแล้วจะสามารถเก็บข้อมูลไว้สำหรับ หน่วยของวันซึ่งก็เพียงพอแล้วสำหรับการสนับสนุน
ต่อไปเป็นการเล่าเอกสารเล็กน้อยสำหรับผู้ที่ไม่คุ้นเคยกับคาฟคา (ภาพก็มาจากเอกสารด้วย)
AMQP มีคิว: เราเขียนข้อความไปยังคิวสำหรับผู้ใช้บริการ โดยทั่วไปแล้ว คิวหนึ่งจะถูกประมวลผลโดยระบบหนึ่งที่มีตรรกะทางธุรกิจเดียวกัน หากคุณต้องการแจ้งเตือนหลายระบบ คุณสามารถสอนให้แอปพลิเคชันเขียนไปยังหลายคิวหรือกำหนดค่าการแลกเปลี่ยนด้วยกลไก fanout ซึ่งจะโคลนระบบเหล่านั้นเอง
คาฟคาก็มีนามธรรมที่คล้ายกัน หัวข้อที่คุณเขียนข้อความ แต่จะไม่หายไปหลังจากอ่าน ตามค่าเริ่มต้น เมื่อคุณเชื่อมต่อกับ Kafka คุณจะได้รับข้อความทั้งหมดและมีตัวเลือกในการบันทึกจุดที่คุณค้างไว้ นั่นคือคุณอ่านตามลำดับคุณไม่สามารถทำเครื่องหมายข้อความว่าอ่านแล้วได้ แต่ให้บันทึกรหัสที่คุณสามารถอ่านต่อได้ รหัสที่คุณชำระเรียกว่าออฟเซ็ต และกลไกคือคอมมิตออฟเซ็ต
ดังนั้นจึงสามารถนำตรรกะต่างๆ มาใช้ได้ ตัวอย่างเช่น เรามี BOB ใน 4 อินสแตนซ์สำหรับประเทศต่างๆ - Lamoda อยู่ในรัสเซีย คาซัคสถาน ยูเครน เบลารุส เนื่องจากใช้งานแยกกัน จึงมีการกำหนดค่าและตรรกะทางธุรกิจที่แตกต่างกันเล็กน้อย เราระบุในข้อความที่อ้างถึงประเทศนั้น ผู้บริโภค BOB แต่ละรายในแต่ละประเทศอ่านด้วย groupId ที่แตกต่างกัน และหากข้อความใช้ไม่ได้กับพวกเขา พวกเขาจะข้ามไป กล่าวคือ กระทำการชดเชย +1 ทันที หากบริการการชำระเงินของเราอ่านหัวข้อเดียวกัน ก็จะดำเนินการดังกล่าวกับกลุ่มที่แยกจากกัน ดังนั้นค่าชดเชยจึงไม่ตัดกัน
ข้อกำหนดกิจกรรม:
- ความสมบูรณ์ของข้อมูล ฉันต้องการให้กิจกรรมมีข้อมูลเพียงพอเพื่อให้สามารถประมวลผลได้
- ความสมบูรณ์ เรามอบหมายให้ Events-bus ทำการตรวจสอบว่าเหตุการณ์มีความสอดคล้องและสามารถประมวลผลได้
- การสั่งซื้อเป็นสิ่งสำคัญ ในกรณีที่คืนสินค้าเราถูกบังคับให้ทำงานกับประวัติ ด้วยการแจ้งเตือน คำสั่งซื้อไม่สำคัญ หากเป็นการแจ้งเตือนที่เป็นเนื้อเดียวกัน อีเมลจะเหมือนกันไม่ว่าคำสั่งซื้อใดจะมาถึงก่อน ในกรณีของการคืนเงิน มีกระบวนการที่ชัดเจน หากเราเปลี่ยนแปลงคำสั่งซื้อ จะมีข้อยกเว้นเกิดขึ้น การคืนเงินจะไม่ถูกสร้างขึ้นหรือดำเนินการ - เราจะไปอยู่ในสถานะอื่น
- ความสม่ำเสมอ เรามีร้านค้า และตอนนี้เราสร้างกิจกรรมแทน API เราต้องการวิธีในการส่งข้อมูลเกี่ยวกับกิจกรรมใหม่และการเปลี่ยนแปลงกิจกรรมที่มีอยู่ไปยังบริการของเราอย่างรวดเร็วและประหยัด ซึ่งสามารถทำได้โดยใช้ข้อกำหนดทั่วไปในที่เก็บ git และเครื่องสร้างโค้ดที่แยกต่างหาก ดังนั้นจึงมีการประสานงานไคลเอนต์และเซิร์ฟเวอร์ในบริการที่แตกต่างกัน
คาฟคาในลาโมดา
เรามีการติดตั้ง Kafka สามแบบ:
- บันทึก;
- วิจัยและพัฒนา;
- เหตุการณ์รถบัส
วันนี้เรากำลังพูดถึงเฉพาะประเด็นสุดท้ายเท่านั้น ที่ events-bus เราไม่มีการติดตั้งที่ใหญ่มาก - 3 โบรกเกอร์ (เซิร์ฟเวอร์) และมีเพียง 27 หัวข้อเท่านั้น ตามกฎแล้ว หนึ่งหัวข้อคือหนึ่งกระบวนการ แต่นี่เป็นจุดที่ละเอียดอ่อน และเราจะพูดถึงมันตอนนี้
ด้านบนคือกราฟ rps ขั้นตอนการคืนเงินจะมีเครื่องหมายเส้นสีฟ้าคราม (ใช่ เส้นบนแกน X) และเส้นสีชมพูคือกระบวนการอัปเดตเนื้อหา
แค็ตตาล็อก Lamoda มีผลิตภัณฑ์นับล้านรายการ และข้อมูลได้รับการอัปเดตตลอดเวลา คอลเลกชันบางชิ้นล้าสมัยมีการเปิดตัวคอลเลกชั่นใหม่เพื่อทดแทนและมีโมเดลใหม่ ๆ ปรากฏในแค็ตตาล็อกอยู่ตลอดเวลา เราพยายามคาดการณ์ว่าอะไรจะน่าสนใจสำหรับลูกค้าของเราในวันพรุ่งนี้ ดังนั้นเราจึงซื้อสิ่งใหม่ ๆ ถ่ายรูปและอัปเดตกล่องแสดงผลอยู่เสมอ
Pink Peaks คือการอัพเดตสินค้า นั่นคือ การเปลี่ยนแปลงสินค้า จะเห็นได้ว่าหนุ่มๆ ถ่ายรูป ถ่ายรูปแล้วซ้ำอีก! - โหลดชุดกิจกรรม
กรณีการใช้งาน Lamoda Events
เราใช้สถาปัตยกรรมที่สร้างขึ้นสำหรับการดำเนินการต่อไปนี้:
- การติดตามสถานะการคืนสินค้า: คำกระตุ้นการตัดสินใจและการติดตามสถานะจากระบบที่เกี่ยวข้องทั้งหมด การชำระเงิน สถานะ การเงิน การแจ้งเตือน ที่นี่เราได้ทดสอบแนวทาง สร้างเครื่องมือ รวบรวมจุดบกพร่องทั้งหมด เขียนเอกสาร และบอกเพื่อนร่วมงานของเราถึงวิธีใช้งาน
- กำลังอัปเดตการ์ดผลิตภัณฑ์: การกำหนดค่า ข้อมูลเมตา คุณลักษณะ ระบบหนึ่งอ่าน (ซึ่งแสดง) และหลายเขียน
- อีเมล พุช และ SMS: เก็บออเดอร์แล้ว, ออเดอร์เข้าแล้ว, รับคืนแล้ว ฯลฯ มีเยอะมาก
- สต๊อก, ต่ออายุคลังสินค้า — การอัปเดตเชิงปริมาณของรายการเฉพาะตัวเลข: ถึงคลังสินค้า, การคืนสินค้า จำเป็นที่ระบบทั้งหมดที่เกี่ยวข้องกับการจองสินค้าจะต้องดำเนินการด้วยข้อมูลที่เป็นปัจจุบันที่สุด ปัจจุบันระบบอัพเดตสต็อกค่อนข้างซับซ้อน Kafka จะทำให้ง่ายขึ้น
- การวิเคราะห์ข้อมูล (แผนก R&D), เครื่องมือ ML, การวิเคราะห์, สถิติ เราต้องการให้ข้อมูลมีความโปร่งใส Kafka เหมาะสมอย่างยิ่งสำหรับสิ่งนี้
ตอนนี้ส่วนที่น่าสนใจมากขึ้นเกี่ยวกับการกระแทกครั้งใหญ่และการค้นพบที่น่าสนใจที่เกิดขึ้นในช่วงหกเดือนที่ผ่านมา
ปัญหาการออกแบบ
สมมติว่าเราต้องการทำสิ่งใหม่ เช่น โอนกระบวนการจัดส่งทั้งหมดไปที่ Kafka ขณะนี้ส่วนหนึ่งของกระบวนการถูกนำไปใช้ในการประมวลผลคำสั่งซื้อใน BOB มีแบบจำลองสถานะที่อยู่เบื้องหลังการโอนใบสั่งไปยังบริการจัดส่ง การเคลื่อนย้ายไปยังคลังสินค้าระดับกลาง และอื่นๆ มีเสาหินทั้งหมดหรือสองเสา พร้อมด้วย API จำนวนมากสำหรับการส่งมอบโดยเฉพาะ พวกเขารู้มากขึ้นเกี่ยวกับการจัดส่ง
สิ่งเหล่านี้ดูเหมือนจะคล้ายกัน แต่การประมวลผลคำสั่งซื้อใน BOB และระบบการจัดส่งมีสถานะที่แตกต่างกัน ตัวอย่างเช่น บริการจัดส่งบางแห่งไม่ได้ส่งสถานะขั้นกลาง แต่จะส่งเฉพาะสถานะสุดท้ายเท่านั้น: "จัดส่งแล้ว" หรือ "สูญหาย" ในทางกลับกัน รายงานโดยละเอียดเกี่ยวกับการเคลื่อนย้ายสินค้า ทุกคนมีกฎการตรวจสอบของตนเอง สำหรับบางคน อีเมลนั้นถูกต้อง ซึ่งหมายความว่าอีเมลจะได้รับการประมวลผล สำหรับคนอื่นมันไม่ถูกต้อง แต่คำสั่งซื้อจะยังคงได้รับการดำเนินการเนื่องจากมีหมายเลขโทรศัพท์สำหรับติดต่อและบางคนจะบอกว่าคำสั่งซื้อดังกล่าวจะไม่ได้รับการดำเนินการเลย
กระแสข้อมูล
ในกรณีของคาฟคา ปัญหาในการจัดการกระแสข้อมูลก็เกิดขึ้น งานนี้เกี่ยวข้องกับการเลือกกลยุทธ์โดยพิจารณาจากหลาย ๆ ประเด็น มาดูกันทั้งหมดเลย
ในหัวข้อเดียวหรือต่างกัน?
เรามีข้อกำหนดการจัดงาน ใน BOB เราเขียนว่าจำเป็นต้องจัดส่งคำสั่งซื้อดังกล่าว และระบุ: หมายเลขคำสั่งซื้อ ส่วนประกอบ SKU และบาร์โค้ดบางส่วน ฯลฯ เมื่อสินค้ามาถึงคลังสินค้า ผู้จัดส่งจะสามารถรับสถานะ การประทับเวลา และทุกสิ่งที่จำเป็นได้ แต่เราต้องการรับข้อมูลอัปเดตเกี่ยวกับข้อมูลนี้ใน BOB เรามีกระบวนการย้อนกลับในการรับข้อมูลจากการจัดส่ง นี่เป็นเหตุการณ์เดียวกันหรือไม่? หรือนี่เป็นการแลกเปลี่ยนแยกต่างหากที่สมควรได้รับหัวข้อของตัวเอง?
เป็นไปได้มากว่าพวกเขาจะคล้ายกันมากและความพยายามที่จะสร้างหัวข้อเดียวนั้นไม่มีมูลความจริงเนื่องจากหัวข้อที่แยกจากกันหมายถึงผู้บริโภคที่แยกจากกัน การกำหนดค่าที่แยกจากกัน การสร้างทั้งหมดนี้ที่แยกจากกัน แต่ไม่ใช่ข้อเท็จจริง
สนามใหม่หรือกิจกรรมใหม่?
แต่ถ้าคุณใช้เหตุการณ์เดียวกัน ปัญหาอื่นก็เกิดขึ้นอีก ตัวอย่างเช่น ระบบการนำส่งบางระบบไม่สามารถสร้าง DTO ประเภทที่ BOB สามารถสร้างได้ เราส่ง ID ไปให้พวกเขาแล้ว แต่พวกเขาไม่ได้บันทึกเพราะไม่ต้องการมัน และจากมุมมองของการเริ่มต้นกระบวนการ Event-Bus ฟิลด์นี้เป็นสิ่งที่จำเป็น
หากเราแนะนำกฎสำหรับ event-bus ที่ฟิลด์นี้จำเป็น เราจะถูกบังคับให้ตั้งกฎการตรวจสอบเพิ่มเติมใน BOB หรือในตัวจัดการเหตุการณ์เริ่มต้น การตรวจสอบความถูกต้องเริ่มแพร่กระจายไปทั่วบริการ - ซึ่งไม่สะดวกนัก
ปัญหาอีกประการหนึ่งคือการล่อลวงให้พัฒนาอย่างค่อยเป็นค่อยไป เราได้รับแจ้งว่ามีบางอย่างจำเป็นต้องเพิ่มเข้าไปในงาน และบางที ถ้าเราลองคิดดู มันควรจะเป็นงานแยกต่างหาก แต่ในโครงการของเรา กิจกรรมที่แยกจากกันจะเป็นหัวข้อที่แยกจากกัน หัวข้อแยกต่างหากคือกระบวนการทั้งหมดที่ฉันอธิบายไว้ข้างต้น นักพัฒนามักอยากเพิ่มฟิลด์อื่นลงในสคีมา JSON แล้วสร้างใหม่
ส่วนเรื่องคืนเงินก็มาถึงงานอีเว้นท์ในรอบครึ่งปี เรามีเหตุการณ์เมตาหนึ่งเหตุการณ์ที่เรียกว่าการอัปเดตการคืนเงิน ซึ่งมีฟิลด์ประเภทที่อธิบายว่าการอัปเดตนี้คืออะไรจริงๆ ด้วยเหตุนี้ เราจึงมีสวิตช์ที่ “ยอดเยี่ยม” พร้อมด้วยเครื่องมือตรวจสอบความถูกต้องซึ่งบอกเราถึงวิธีตรวจสอบเหตุการณ์นี้ด้วยประเภทนี้
เวอร์ชันเหตุการณ์
เพื่อตรวจสอบข้อความใน Kafka คุณสามารถใช้ แต่จำเป็นต้องวางมันทันทีและใช้ Confluent ในกรณีของเรา เราต้องระมัดระวังในการกำหนดเวอร์ชัน จะไม่สามารถอ่านข้อความจากบันทึกการจำลองซ้ำได้เสมอไป เนื่องจากโมเดลมี "ซ้าย" โดยพื้นฐานแล้ว จะต้องสร้างเวอร์ชันเพื่อให้โมเดลสามารถใช้งานร่วมกันได้แบบย้อนหลัง เช่น ทำให้ฟิลด์เป็นทางเลือกชั่วคราว หากความแตกต่างรุนแรงเกินไป เราจะเริ่มเขียนหัวข้อใหม่และโอนลูกค้าเมื่อพวกเขาอ่านหัวข้อเก่าจบ
รับประกันลำดับการอ่านพาร์ติชั่น
หัวข้อภายใน Kafka แบ่งออกเป็นพาร์ติชัน สิ่งนี้ไม่สำคัญมากในขณะที่เรากำลังออกแบบเอนทิตีและการแลกเปลี่ยน แต่มันสำคัญเมื่อตัดสินใจว่าจะใช้และปรับขนาดอย่างไร
ในกรณีปกติ คุณจะเขียนหนึ่งหัวข้อในคาฟคา ตามค่าเริ่มต้น จะใช้หนึ่งพาร์ติชัน และข้อความทั้งหมดในหัวข้อนี้จะไปที่พาร์ติชั่นนั้น และผู้บริโภคก็อ่านข้อความเหล่านี้ตามลำดับ สมมติว่าตอนนี้เราจำเป็นต้องขยายระบบเพื่อให้ผู้บริโภคสองคนอ่านข้อความได้ ตัวอย่างเช่น หากคุณกำลังส่ง SMS คุณสามารถบอก Kafka ให้สร้างพาร์ติชันเพิ่มเติมได้ และ Kafka จะเริ่มแบ่งข้อความออกเป็นสองส่วน - ครึ่งหนึ่งที่นี่ ครึ่งหนึ่งที่นี่
คาฟคาแบ่งพวกมันอย่างไร? แต่ละข้อความมีเนื้อหา (ซึ่งเราจัดเก็บ JSON) และคีย์ คุณสามารถแนบฟังก์ชันแฮชเข้ากับคีย์นี้ได้ ซึ่งจะกำหนดว่าข้อความจะเข้าไปอยู่ในพาร์ติชันใด
ในกรณีของเราเกี่ยวกับการคืนเงิน นี่เป็นสิ่งสำคัญ หากเราใช้สองพาร์ติชัน ก็มีโอกาสที่ผู้บริโภคแบบขนานจะประมวลผลเหตุการณ์ที่สองก่อนเหตุการณ์แรกและจะเกิดปัญหา ฟังก์ชันแฮชช่วยให้แน่ใจว่าข้อความที่มีคีย์เดียวกันจะไปอยู่ในพาร์ติชันเดียวกัน
เหตุการณ์เทียบกับคำสั่ง
นี่เป็นอีกปัญหาหนึ่งที่เราพบ เหตุการณ์ คือเหตุการณ์หนึ่ง เราบอกว่ามีบางอย่างเกิดขึ้นที่ไหนสักแห่ง (มีบางอย่างเกิดขึ้น) เช่น สินค้าถูกยกเลิกหรือมีการคืนเงิน หากมีคนฟังเหตุการณ์เหล่านี้ ดังนั้นตาม "สินค้าที่ถูกยกเลิก" เอนทิตีการคืนเงินจะถูกสร้างขึ้น และ "การคืนเงินเกิดขึ้น" จะถูกเขียนไว้ที่ใดที่หนึ่งในการตั้งค่า
แต่โดยปกติแล้ว เมื่อคุณออกแบบกิจกรรม คุณคงไม่ต้องการที่จะเขียนกิจกรรมเหล่านั้นอย่างไร้ประโยชน์ คุณพึ่งพาความจริงที่ว่าจะมีใครสักคนมาอ่านงานกิจกรรมเหล่านั้น มีสิ่งล่อใจอย่างมากที่จะเขียนว่าไม่ใช่ what_happened (item_canceled,refunded) แต่เป็นบางอย่างที่ควรจะ_เป็น_done เช่น สินค้าพร้อมส่งคืน
ในด้านหนึ่ง เป็นการแนะนำว่าจะมีการนำกิจกรรมไปใช้อย่างไร ในทางกลับกัน มันฟังดูไม่ค่อยเหมือนชื่อเหตุการณ์ปกติมากนัก นอกจากนี้ยังอยู่ไม่ไกลจากที่นี่ถึงคำสั่ง do_something แต่คุณไม่รับประกันว่าจะมีคนอ่านเหตุการณ์นี้ และถ้าคุณอ่านมัน คุณก็อ่านมันได้สำเร็จ และถ้าคุณอ่านมันได้สำเร็จ แสดงว่าคุณได้ทำอะไรบางอย่าง และสิ่งนั้นก็ประสบความสำเร็จ ทันทีที่เหตุการณ์กลายเป็นสิ่งที่ควรทำ คำติชมก็จำเป็น และนั่นคือปัญหา
ในการแลกเปลี่ยนแบบอะซิงโครนัสใน RabbitMQ เมื่อคุณอ่านข้อความ ให้ไปที่ http คุณจะได้รับการตอบกลับ - อย่างน้อยก็ได้รับข้อความนั้น เมื่อคุณเขียนถึง Kafka มีข้อความที่คุณเขียนถึง Kafka แต่คุณไม่รู้อะไรเลยเกี่ยวกับวิธีการประมวลผล
ดังนั้นในกรณีของเรา เราต้องแนะนำเหตุการณ์การตอบกลับและตั้งค่าการตรวจสอบเพื่อว่าหากมีการส่งเหตุการณ์จำนวนมาก หลังจากเวลาดังกล่าวและในช่วงเวลาดังกล่าว จำนวนเหตุการณ์การตอบกลับที่เท่ากันควรจะมาถึง หากไม่เกิดขึ้น แสดงว่ามีบางอย่างผิดปกติเกิดขึ้น ตัวอย่างเช่น หากเราส่งเหตุการณ์ "item_ready_to_refund" เราคาดหวังว่าจะสร้างการคืนเงิน เงินจะถูกส่งคืนให้กับลูกค้า และกิจกรรม "money_refunded" จะถูกส่งถึงเรา แต่นี่ยังไม่แน่นอน ดังนั้นจึงจำเป็นต้องมีการตรวจสอบ
ความแตกต่าง
มีปัญหาที่ค่อนข้างชัดเจน: หากคุณอ่านจากหัวข้อตามลำดับและมีข้อความที่ไม่ดีผู้บริโภคจะตกหล่นและคุณจะไม่ไปต่อ คุณต้องการ หยุดผู้บริโภคทุกคนกระทำการชดเชยเพิ่มเติมเพื่ออ่านต่อ
เรารู้เกี่ยวกับมัน เรานับมัน แต่มันก็เกิดขึ้น และสิ่งนี้เกิดขึ้นเนื่องจากเหตุการณ์นั้นถูกต้องจากมุมมองของ events-bus เหตุการณ์นั้นถูกต้องจากมุมมองของเครื่องมือตรวจสอบแอปพลิเคชัน แต่ไม่ถูกต้องจากมุมมองของ PostgreSQL เพราะในระบบของเรา MySQL ด้วย UNSIGNED INT ระบบจะมี PostgreSQL เพียงกับ INT ขนาดของเขาเล็กกว่าเล็กน้อยและรหัสไม่พอดี Symfony เสียชีวิตโดยมีข้อยกเว้น แน่นอนว่าเราพบข้อยกเว้นเพราะเราพึ่งพามันและกำลังจะกระทำการชดเชยนี้ แต่ก่อนหน้านั้นเราต้องการเพิ่มตัวนับปัญหาเนื่องจากข้อความได้รับการประมวลผลไม่สำเร็จ ตัวนับในโครงการนี้อยู่ในฐานข้อมูลด้วย และ Symfony ได้ปิดการสื่อสารกับฐานข้อมูลแล้ว และข้อยกเว้นที่สองฆ่ากระบวนการทั้งหมดโดยไม่มีโอกาสกระทำการชดเชย
บริการพักอยู่ระยะหนึ่ง - โชคดีที่ Kafka ก็ไม่แย่นักเพราะข้อความยังคงอยู่ เมื่อกู้คืนงานแล้ว คุณก็สามารถอ่านให้จบได้ สะดวกสบาย.
คาฟคามีความสามารถในการตั้งค่าออฟเซ็ตตามอำเภอใจผ่านเครื่องมือ แต่ในการทำเช่นนี้คุณต้องหยุดผู้บริโภคทั้งหมด - ในกรณีของเราให้เตรียมรุ่นแยกต่างหากซึ่งจะไม่มีผู้บริโภคการปรับใช้ใหม่ จากนั้นในคาฟคา คุณสามารถเปลี่ยนออฟเซ็ตโดยใช้เครื่องมือ จากนั้นข้อความก็จะผ่านไป
ความแตกต่างอีกอย่างหนึ่ง - บันทึกการจำลองเทียบกับ rdkafka.so - เกี่ยวข้องกับลักษณะเฉพาะของโครงการของเรา เราใช้ PHP และตามกฎแล้วใน PHP ไลบรารีทั้งหมดจะสื่อสารกับ Kafka ผ่านที่เก็บ rdkafka.so จากนั้นจะมี wrapper บางชนิด บางทีนี่อาจเป็นปัญหาส่วนตัวของเรา แต่กลับกลายเป็นว่าการอ่านซ้ำสิ่งที่เราอ่านไปแล้วนั้นไม่ใช่เรื่องง่าย โดยทั่วไปมีปัญหาด้านซอฟต์แวร์
เมื่อย้อนกลับไปถึงลักษณะเฉพาะของการทำงานกับพาร์ติชั่นนั้นเขียนไว้ในเอกสารประกอบ ผู้บริโภค >= พาร์ติชันหัวข้อ. แต่ฉันรู้เรื่องนี้ช้ากว่าที่ฉันต้องการ หากคุณต้องการขยายขนาดและมีผู้บริโภคสองคน คุณต้องมีพาร์ติชันอย่างน้อยสองพาร์ติชัน นั่นคือถ้าคุณมีพาร์ติชั่นหนึ่งซึ่งมีข้อความสะสมถึง 20 ข้อความและคุณสร้างพาร์ติชั่นใหม่ จำนวนข้อความจะไม่เท่ากันในเร็วๆ นี้ ดังนั้น ในการที่จะมีคอนซูเมอร์สองตัวแบบขนาน คุณจะต้องจัดการกับพาร์ติชัน
การตรวจสอบ
ฉันคิดว่าวิธีที่เราติดตามดูจะยิ่งชัดเจนยิ่งขึ้นว่ามีปัญหาอะไรบ้างในแนวทางที่มีอยู่
ตัวอย่างเช่น เราคำนวณจำนวนผลิตภัณฑ์ในฐานข้อมูลที่เปลี่ยนสถานะเมื่อเร็วๆ นี้ และด้วยเหตุนี้ เหตุการณ์จึงควรเกิดขึ้นตามการเปลี่ยนแปลงเหล่านี้ และเราจะส่งหมายเลขนี้ไปยังระบบการตรวจสอบของเรา จากนั้นจากคาฟคา เราจะได้เลขตัวที่สอง ว่ามีการบันทึกเหตุการณ์จริงกี่เหตุการณ์ แน่นอนว่าความแตกต่างระหว่างตัวเลขทั้งสองนี้ควรเป็นศูนย์เสมอ
นอกจากนี้ คุณยังต้องตรวจสอบว่าผู้ผลิตกำลังดำเนินการอย่างไร เหตุการณ์บัสได้รับข้อความหรือไม่ และผู้บริโภคกำลังดำเนินการอย่างไร ตัวอย่างเช่น ในแผนภูมิด้านล่าง Refund Tool ทำงานได้ดี แต่ BOB มีปัญหาบางอย่างอย่างชัดเจน (จุดสูงสุดสีน้ำเงิน)
ฉันได้กล่าวถึงความล่าช้าของกลุ่มผู้บริโภคแล้ว โดยคร่าวๆ นี่คือจำนวนข้อความที่ยังไม่ได้อ่าน โดยทั่วไปแล้ว ผู้บริโภคของเราทำงานอย่างรวดเร็ว ดังนั้นความล่าช้ามักจะเป็น 0 แต่บางครั้งอาจมีจุดสูงสุดในระยะสั้น คาฟคาสามารถทำสิ่งนี้ได้ทันที แต่คุณต้องกำหนดช่วงเวลาที่แน่นอน
มีโครงการ ซึ่งจะให้ข้อมูลเพิ่มเติมเกี่ยวกับคาฟคาแก่คุณ เพียงใช้ API กลุ่มผู้บริโภคเพื่อให้สถานะการทำงานของกลุ่มนี้ นอกจากตกลงและล้มเหลวแล้ว ยังมีคำเตือนอีกด้วย และคุณจะพบว่าผู้บริโภคของคุณไม่สามารถรับมือกับก้าวของการผลิตได้ - พวกเขาไม่มีเวลาพิสูจน์อักษรสิ่งที่เขียน ระบบค่อนข้างชาญฉลาดและใช้งานง่าย
นี่คือลักษณะการตอบสนองของ API นี่คือกลุ่ม bob-live-fifa, การคืนเงินพาร์ติชัน.update.v1, สถานะตกลง, ความล่าช้า 0 - การชดเชยสุดท้ายสุดท้ายเช่นนั้น
การตรวจสอบ updated_at SLA (ติดอยู่) ฉันพูดถึงแล้ว ตัวอย่างเช่น สินค้าได้เปลี่ยนสถานะเป็นพร้อมสำหรับการคืนสินค้า เราติดตั้ง Cron ซึ่งบอกว่าหากภายใน 5 นาทีวัตถุนี้ยังไม่ได้รับการคืนเงิน (เราจะคืนเงินผ่านระบบการชำระเงินอย่างรวดเร็ว) แสดงว่ามีบางอย่างผิดปกติเกิดขึ้นอย่างแน่นอนและนี่เป็นกรณีของการสนับสนุนอย่างแน่นอน ดังนั้นเราจึงใช้ Cron ซึ่งอ่านข้อความดังกล่าว และหากมีค่ามากกว่า 0 ก็จะส่งการแจ้งเตือน
สรุปการใช้เหตุการณ์จะสะดวกเมื่อ:
- ข้อมูลเป็นสิ่งจำเป็นสำหรับหลายระบบ
- ผลลัพธ์ของการประมวลผลไม่สำคัญ
- มีงานหรืองานเล็กๆ น้อยๆ
ดูเหมือนว่าบทความนี้มีหัวข้อที่เฉพาะเจาะจงมาก - API แบบอะซิงโครนัสบน Kafka แต่ฉันอยากจะแนะนำหลายสิ่งหลายอย่างในคราวเดียว
อันดับแรกถัดไป เราต้องรอจนถึงเดือนพฤศจิกายนในเดือนเมษายนจะมีเวอร์ชันเซนต์ปีเตอร์สเบิร์กและในเดือนมิถุนายนเราจะพูดถึงเรื่องปริมาณมากในโนโวซีบีร์สค์
ประการที่สอง ผู้เขียนรายงาน Sergei Zaika เป็นสมาชิกของคณะกรรมการโครงการของการประชุมใหม่ของเราเกี่ยวกับการจัดการความรู้ . การประชุมแบบวันเดียวจะจัดขึ้นในวันที่ 26 เมษายน แต่โปรแกรมจะเข้มข้นมาก
และจะเป็นในเดือนพฤษภาคม и (รวม DevOpsConf ด้วย) - คุณยังสามารถแนะนำหัวข้อของคุณที่นั่น พูดคุยเกี่ยวกับประสบการณ์ของคุณ และบ่นเกี่ยวกับกรวยที่ยัดไส้ของคุณ
ที่มา: will.com