ฮาเบอร์กำลังเปลี่ยนแปลงโลก เราเขียนบล็อกมานานกว่าหนึ่งปีแล้ว ประมาณหกเดือนที่แล้ว เราได้รับการตอบรับที่ค่อนข้างสมเหตุสมผลจากชาวเมือง Khabrovsk: “โดโด คุณพูดทุกที่ว่าคุณมีระบบของคุณเอง นี่เป็นระบบประเภทไหน? แล้วทำไมร้านพิซซ่าถึงต้องการมันล่ะ”
เรานั่งคิดและตระหนักว่าคุณพูดถูก เรากำลังพยายามอธิบายทุกอย่างด้วยมือของเรา แต่มันขาดตอนและไม่มีคำอธิบายที่สมบูรณ์ของระบบเลย การเดินทางอันยาวนานในการรวบรวมข้อมูล ค้นหาผู้เขียน และการเขียนบทความเกี่ยวกับ Dodo IS จึงเริ่มต้นขึ้น ไปกันเถอะ!
กิตติกรรมประกาศ: ขอขอบคุณสำหรับการแบ่งปันความคิดเห็นของคุณกับเรา ต้องขอบคุณเขาที่ในที่สุดเราก็ได้อธิบายระบบ รวบรวมเทคโนโลยีเรดาร์ และจะเปิดตัวคำอธิบายขนาดใหญ่เกี่ยวกับกระบวนการของเราในเร็วๆ นี้ หากไม่มีคุณเราคงนั่งอยู่แบบนี้ต่อไปอีก 5 ปี
ชุดบทความ "Dodo IS คืออะไร" บอกเกี่ยวกับ:
- หินใหญ่ก้อนเดียวในยุค Dodo IS (พ.ศ. 2011-2015) (กำลังดำเนินการ...)
- เส้นทาง Backoffice: แยกฐานและรถบัส (คุณอยู่ที่นี่)
- เส้นทางฝั่งลูกค้า: ซุ้มเหนือฐาน (2016-2017) (กำลังดำเนินการ...)
- ประวัติของไมโครเซอร์วิสที่แท้จริง (พ.ศ.2018-2019). (กำลังดำเนินการ...)
- เสร็จสิ้นการเลื่อยเสาหินและการรักษาเสถียรภาพของสถาปัตยกรรม (กำลังดำเนินการ...)
หากคุณสนใจที่จะเรียนรู้สิ่งอื่นเขียนในความคิดเห็น
ความคิดเห็นเกี่ยวกับคำอธิบายตามลำดับเวลาจากผู้เขียน
ฉันจัดประชุมพนักงานใหม่เรื่อง “สถาปัตยกรรมระบบ” เป็นประจำ เราเรียกสิ่งนี้ว่า “ข้อมูลเบื้องต้นเกี่ยวกับสถาปัตยกรรม Dodo IS” และเป็นส่วนหนึ่งของกระบวนการเตรียมความพร้อมสำหรับนักพัฒนาใหม่ เมื่อพูดถึงสถาปัตยกรรมของเราในรูปแบบใดรูปแบบหนึ่ง เกี่ยวกับคุณลักษณะต่างๆ ฉันได้พัฒนาแนวทางทางประวัติศาสตร์บางประการในการอธิบาย
ตามเนื้อผ้า เรามองว่าระบบเป็นชุดของส่วนประกอบ (ทางเทคนิคหรือระดับสูงกว่า) โมดูลธุรกิจที่โต้ตอบซึ่งกันและกันเพื่อให้บรรลุเป้าหมาย แม้ว่ามุมมองดังกล่าวจะสมเหตุสมผลสำหรับการออกแบบ แต่ก็ไม่เหมาะสำหรับการอธิบายและทำความเข้าใจเลย มีสาเหตุหลายประการ:
- ความเป็นจริงแตกต่างจากสิ่งที่อยู่บนกระดาษ ทุกอย่างไม่เป็นไปตามแผนที่วางไว้ และเราสนใจว่าทุกอย่างปรากฏและใช้งานได้จริงอย่างไร
- การนำเสนอข้อมูลอย่างสม่ำเสมอ ที่จริงแล้ว คุณสามารถเรียงตามลำดับเวลาตั้งแต่เริ่มต้นจนถึงสถานะปัจจุบันได้
- จากง่ายไปซับซ้อน ไม่เป็นสากล แต่ในกรณีของเราเป็นเช่นนั้น สถาปัตยกรรมได้ย้ายจากแนวทางที่ง่ายกว่าไปสู่แนวทางที่ซับซ้อนมากขึ้น บ่อยครั้งเนื่องจากความซับซ้อน ปัญหาของความเร็วและความเสถียรในการใช้งาน รวมถึงคุณสมบัติอื่น ๆ อีกมากมายจากรายการข้อกำหนดที่ไม่สามารถใช้งานได้ ( มีการพูดคุยกันเป็นอย่างดีถึงความแตกต่างระหว่างความซับซ้อนกับข้อกำหนดอื่นๆ)
ในปี 2011 สถาปัตยกรรม Dodo IS มีลักษณะดังนี้:
ภายในปี 2020 มันซับซ้อนขึ้นเล็กน้อยและกลายเป็นดังนี้:
วิวัฒนาการนี้เกิดขึ้นได้อย่างไร? เหตุใดจึงจำเป็นต้องมีส่วนต่าง ๆ ของระบบ? มีการตัดสินใจทางสถาปัตยกรรมอะไรบ้างและเพราะเหตุใด มาดูกันในบทความชุดนี้
ปัญหาแรกของปี 2016: เหตุใดบริการจึงควรออกจากเสาหิน?
บทความแรกในชุดจะเกี่ยวกับบริการที่แยกออกจากเสาหินแรก เพื่ออธิบายบริบท ฉันจะบอกคุณว่าเรามีปัญหาอะไรในระบบเมื่อต้นปี 2016 ซึ่งเราต้องจัดการกับการแยกบริการ
ฐานข้อมูล MySql เดียวที่แอปพลิเคชันทั้งหมดที่มีอยู่ใน Dodo IS ในขณะนั้นเขียนบันทึกไว้ ผลที่ตามมาคือ:
- ภาระหนัก (โดย 85% ของคำขอถูกอ่าน)
- ฐานกำลังเติบโต ด้วยเหตุนี้ต้นทุนและการสนับสนุนจึงกลายเป็นปัญหา
- จุดเดียวของความล้มเหลว หากแอปพลิเคชันตัวหนึ่งเขียนลงฐานข้อมูลอย่างกะทันหัน แอปพลิเคชันอื่นก็รู้สึกถึงผลกระทบ
- ความไร้ประสิทธิภาพในการจัดเก็บและการสืบค้น บ่อยครั้งที่ข้อมูลถูกจัดเก็บไว้ในโครงสร้างบางอย่างที่สะดวกสำหรับบางสถานการณ์ แต่ไม่ใช่สำหรับสถานการณ์อื่น ดัชนีช่วยให้การดำเนินการบางอย่างเร็วขึ้น แต่อาจทำให้การดำเนินการบางอย่างช้าลงได้
- ปัญหาบางอย่างได้รับการแก้ไขโดยแคชที่สร้างขึ้นอย่างเร่งรีบและการจำลองการอ่านไปยังฐานข้อมูล (ซึ่งจะกล่าวถึงในบทความแยกต่างหาก) แต่สิ่งเหล่านี้ทำให้เรามีเวลาเท่านั้นและไม่ได้แก้ไขปัญหาโดยพื้นฐาน
ปัญหาคือการมีอยู่ของเสาหินนั่นเอง. ผลที่ตามมาคือ:
- รุ่นพิเศษและหายาก
- ความยากลำบากอยู่ที่การพัฒนาความร่วมมือของคนจำนวนมาก
- ไม่สามารถแนะนำเทคโนโลยีใหม่ เฟรมเวิร์ก และไลบรารีใหม่ได้
มีการอธิบายปัญหาเกี่ยวกับฐานและเสาหินหลายครั้ง เช่น ในบริบทของการขัดข้องในต้นปี 2018 (, и ) ดังนั้นฉันจะไม่อยู่มากเกินไป ฉันขอบอกว่าเราต้องการให้ความยืดหยุ่นมากขึ้นในการพัฒนาบริการ ก่อนอื่นสิ่งนี้เกี่ยวข้องกับสิ่งที่โหลดและรูทมากที่สุดในระบบทั้งหมด - Auth และ Tracker
เส้นทาง Back Office: แยกฐานและรถบัส
การนำทางบท
โครงการเสาหินปี 2016
ต่อไปนี้เป็นบล็อกหลักของเสาหิน Dodo IS ปี 2016 และด้านล่างนี้คือรายละเอียดภารกิจหลัก
โต๊ะเก็บเงินจัดส่ง. การบัญชีสำหรับบริการจัดส่งการออกคำสั่งไปยังบริการจัดส่ง
ศูนย์ติดต่อ. เปิดรับออเดอร์ผ่านโอเปอเรเตอร์
เว็บไซต์. เว็บไซต์ของเรา (dodopizza.ru, dodopizza.co.uk, dodopizza.by ฯลฯ)
รับรองความถูกต้อง. บริการอนุญาตและรับรองความถูกต้องสำหรับ backoffice
ติดตาม. ติดตามการสั่งซื้อครัว บริการทำเครื่องหมายสถานะความพร้อมในการจัดเตรียมคำสั่งซื้อ
โต๊ะเงินสดร้านอาหาร. การรับออเดอร์ในร้านอาหาร แคชเชียร์ อินเตอร์เฟซ
ส่งออก. การอัปโหลดรายงานใน 1C สำหรับการบัญชี
การแจ้งเตือนและใบแจ้งหนี้. คำสั่งเสียงในห้องครัว (เช่น “พิซซ่าใหม่มาแล้ว”) + การพิมพ์ใบแจ้งหนี้สำหรับผู้จัดส่ง
ผู้จัดการกะ. อินเทอร์เฟซสำหรับการทำงานของผู้จัดการกะ: รายการคำสั่งซื้อ แผนภูมิประสิทธิภาพ การนำพนักงานเข้ากะ
ผู้จัดการสำนักงาน. อินเทอร์เฟซสำหรับการทำงานของแฟรนไชส์และผู้จัดการ: การรับพนักงาน, รายงานการทำงานของร้านพิชซ่า
คณะกรรมการร้านอาหาร. การแสดงเมนูบนทีวีในร้านพิซซ่า
ผู้ดูแลระบบ. การตั้งค่าสำหรับร้านพิซซ่าเฉพาะ: เมนู ราคา การบัญชี รหัสส่งเสริมการขาย โปรโมชั่น แบนเนอร์สำหรับเว็บไซต์ ฯลฯ
บัญชีส่วนบุคคลของพนักงาน. ตารางการทำงานของพนักงาน ข้อมูลเกี่ยวกับพนักงาน
คณะกรรมการแรงจูงใจในครัว. หน้าจอแยกต่างหากที่แขวนอยู่ในห้องครัวและแสดงความเร็วของเครื่องทำพิซซ่า
การสื่อสาร. กำลังส่ง SMS และอีเมล
พื้นที่จัดเก็บไฟล์. บริการรับและออกไฟล์คงที่ของตัวเอง
ความพยายามครั้งแรกในการแก้ปัญหาช่วยเราได้ แต่เป็นเพียงการทุเลาชั่วคราวเท่านั้น พวกเขาไม่ได้กลายเป็นโซลูชันของระบบ ดังนั้นจึงชัดเจนว่าต้องทำอะไรบางอย่างกับฐาน ตัวอย่างเช่น แบ่งฐานข้อมูลทั่วไปออกเป็นฐานข้อมูลเฉพาะอื่นๆ
เราเริ่มขนถ่ายเสาหิน: การแยก Auth และ Tracker
บริการหลักที่เขียนและอ่านจากฐานข้อมูลมากกว่าบริการอื่น:
- การรับรองความถูกต้อง บริการอนุญาตและรับรองความถูกต้องสำหรับ backoffice
- ตัวติดตาม ติดตามการสั่งซื้อครัว บริการทำเครื่องหมายสถานะความพร้อมในการจัดเตรียมคำสั่งซื้อ
การตรวจสอบสิทธิ์ทำอะไร?
Auth เป็นบริการที่ผู้ใช้เข้าสู่ระบบ back office (มีการเข้าสู่ระบบอิสระแยกต่างหากในฝั่งไคลเอ็นต์) นอกจากนี้ยังมีการอ้างอิงในคำขอเพื่อให้แน่ใจว่ามีสิทธิ์การเข้าถึงที่ถูกต้องและสิทธิ์เหล่านี้ไม่มีการเปลี่ยนแปลงนับตั้งแต่การเข้าสู่ระบบครั้งล่าสุด อุปกรณ์เข้าร้านพิซซ่าผ่านมัน
เช่น เราต้องการเปิดจอแสดงผลที่มีสถานะคำสั่งซื้อเสร็จสมบูรณ์บนทีวีที่แขวนอยู่ในห้องโถง จากนั้นเราเปิด auth.dodopizza.ru เลือก "เข้าสู่ระบบเป็นอุปกรณ์" รหัสจะปรากฏขึ้นซึ่งสามารถป้อนในหน้าพิเศษบนคอมพิวเตอร์ของผู้จัดการกะเพื่อระบุประเภทของอุปกรณ์ (อุปกรณ์) ตัวทีวีจะไปที่อินเทอร์เฟซที่ต้องการของร้านพิชซ่าและเริ่มแสดงชื่อลูกค้าที่มีคำสั่งซื้อพร้อม
โหลดมาจากไหน?
ผู้ใช้ backoffice ที่เข้าสู่ระบบแต่ละคนจะไปที่ฐานข้อมูลสำหรับแต่ละคำขอ ไปยังตารางผู้ใช้ ดึงผู้ใช้ออกจากที่นั่นผ่านการสืบค้น sql และตรวจสอบว่าเขามีสิทธิ์การเข้าถึงและสิทธิ์ที่จำเป็นในหน้านี้หรือไม่
อุปกรณ์แต่ละตัวทำเช่นเดียวกันกับตารางอุปกรณ์เท่านั้น โดยตรวจสอบบทบาทและการเข้าถึงของอุปกรณ์ การร้องขอจำนวนมากไปยังฐานข้อมูลหลักนำไปสู่การโหลดและสิ้นเปลืองทรัพยากรฐานข้อมูลทั่วไปในการดำเนินการเหล่านี้
กำลังยกเลิกการโหลดการตรวจสอบสิทธิ์
Auth มีโดเมนที่แยกออกมา นั่นคือ ข้อมูลเกี่ยวกับผู้ใช้ การเข้าสู่ระบบ หรืออุปกรณ์ที่เข้าสู่บริการ (ในอนาคตปัจจุบัน) และยังคงอยู่ตรงนั้น หากมีใครต้องการพวกเขาจะไปที่บริการนี้เพื่อรับข้อมูล
เคยเป็น. ขั้นตอนการทำงานในตอนแรกเป็นดังนี้:
ฉันอยากจะอธิบายเล็กน้อยว่ามันทำงานอย่างไร:
- คำขอภายนอกมาที่แบ็กเอนด์ (Asp.Net MVC ที่นั่น) โดยนำคุกกี้เซสชันมาด้วย ซึ่งใช้เพื่อรับข้อมูลเซสชันจาก Redis(1) มันมีข้อมูลเกี่ยวกับการเข้าถึง จากนั้นการเข้าถึงคอนโทรลเลอร์นั้นเปิดอยู่ (3,4) หรือไม่
- หากไม่มีสิทธิ์เข้าถึง คุณจะต้องดำเนินการตามขั้นตอนการอนุญาต เพื่อความง่าย จะแสดงเป็นส่วนหนึ่งของเส้นทางในแอตทริบิวต์เดียวกัน แม้ว่านี่จะเป็นการเปลี่ยนไปยังหน้าเข้าสู่ระบบก็ตาม ในกรณีที่เกิดสถานการณ์เชิงบวก เราจะได้รับเซสชั่นที่เติมอย่างถูกต้องและไปที่ Backoffice Controller
- หากมีข้อมูล คุณจะต้องตรวจสอบความเกี่ยวข้องในฐานข้อมูลผู้ใช้ บทบาทเปลี่ยนไปแล้วไม่ควรให้เข้าเพจตอนนี้เหรอ? ในกรณีนี้ หลังจากได้รับเซสชัน (1) คุณจะต้องไปที่ฐานข้อมูลโดยตรง และตรวจสอบการเข้าถึงของผู้ใช้โดยใช้เลเยอร์ลอจิกการรับรองความถูกต้อง (2) จากนั้นไปที่หน้าเข้าสู่ระบบหรือไปที่ตัวควบคุม นี่เป็นระบบที่เรียบง่ายแต่ไม่ได้มาตรฐานทั้งหมด
- หากขั้นตอนทั้งหมดเสร็จสิ้น เราจะข้ามตรรกะในตัวควบคุมและวิธีการต่อไป
ข้อมูลผู้ใช้จะถูกแยกออกจากข้อมูลอื่น ๆ ทั้งหมด โดยจัดเก็บไว้ในตารางสมาชิกแยกต่างหาก ฟังก์ชันจากเลเยอร์ตรรกะ AuthService อาจกลายเป็นวิธี API ได้เป็นอย่างดี ขอบเขตของโดเมนถูกกำหนดไว้ค่อนข้างชัดเจน: ผู้ใช้ บทบาทของพวกเขา การเข้าถึงข้อมูล การออกและการเพิกถอนการเข้าถึง ดูเหมือนว่าทุกอย่างสามารถย้ายไปที่บริการอื่นได้
กลายเป็น. นั่นคือสิ่งที่พวกเขาทำ:
แนวทางนี้มีปัญหาหลายประการ ตัวอย่างเช่น การเรียกเมธอดภายในกระบวนการไม่เหมือนกับการเรียกบริการภายนอกผ่าน http เวลาแฝง ความน่าเชื่อถือ การสนับสนุน และความโปร่งใสของการดำเนินการแตกต่างอย่างสิ้นเชิง Andrey Morevsky พูดรายละเอียดเพิ่มเติมเกี่ยวกับปัญหาเหล่านี้ในรายงานของเขา .
บริการตรวจสอบสิทธิ์และบริการอุปกรณ์จะใช้สำหรับแบ็คออฟฟิศ นั่นคือ สำหรับบริการและอินเทอร์เฟซที่ใช้ในการผลิต การรับรองความถูกต้องสำหรับบริการไคลเอ็นต์ (เช่น เว็บไซต์หรือแอปพลิเคชันบนมือถือ) จะเกิดขึ้นแยกกันโดยไม่ต้องใช้การรับรองความถูกต้อง การแยกใช้เวลาประมาณหนึ่งปี และตอนนี้เรากำลังดำเนินการในหัวข้อนี้อีกครั้ง โดยถ่ายโอนระบบไปยังบริการการรับรองความถูกต้องใหม่ (ด้วยโปรโตคอลมาตรฐาน)
เหตุใดการแยกจึงใช้เวลานานมาก?
มีปัญหามากมายระหว่างทางที่ทำให้เราช้าลง:
- เราต้องการถ่ายโอนข้อมูลเกี่ยวกับผู้ใช้ อุปกรณ์ และการตรวจสอบสิทธิ์จากฐานข้อมูลของประเทศไปไว้ในที่เดียว ในการดำเนินการนี้ เราต้องถ่ายโอนตารางและการใช้งานทั้งหมดจากตัวระบุ int ไปยังตัวระบุ UUId ส่วนกลาง (เราเพิ่งปรับปรุงโค้ดนี้ใหม่ และโครงการโอเพ่นซอร์ส ). การจัดเก็บข้อมูลผู้ใช้ (เนื่องจากเป็นข้อมูลส่วนบุคคล) มีข้อจำกัด และสำหรับบางประเทศจำเป็นต้องจัดเก็บแยกต่างหาก แต่จะต้องมีรหัสผู้ใช้ทั่วโลก
- ตารางจำนวนมากในฐานข้อมูลมีข้อมูลการตรวจสอบเกี่ยวกับผู้ใช้ที่ดำเนินการ สิ่งนี้จำเป็นต้องมีกลไกเพิ่มเติมเพื่อให้แน่ใจว่ามีความสอดคล้องกัน
- หลังจากสร้างบริการ API แล้ว การถ่ายโอนไปยังระบบอื่นใช้เวลานานและค่อยเป็นค่อยไป สวิตช์ต้องเกิดขึ้นได้อย่างราบรื่นสำหรับผู้ใช้และจำเป็นต้องทำงานด้วยตนเอง
โครงการลงทะเบียนอุปกรณ์ในร้านพิชซ่า:
สถาปัตยกรรมทั่วไปหลังจากแยกบริการ Auth และอุปกรณ์:
หมายเหตุ. ในปี 2020 เรากำลังดำเนินการกับ Auth เวอร์ชันใหม่ ซึ่งอิงตามมาตรฐานการให้สิทธิ์ OAuth 2.0 มาตรฐานนี้ค่อนข้างซับซ้อน แต่มีประโยชน์สำหรับการพัฒนาบริการการตรวจสอบสิทธิ์ตั้งแต่ต้นทางถึงปลายทาง ในบทความ "» พวกเรา Alexey Chernyaev พยายามพูดถึงมาตรฐานให้เรียบง่ายและชัดเจนที่สุดเท่าที่จะทำได้ เพื่อที่คุณจะได้ประหยัดเวลาในการศึกษามัน
Tracker ทำอะไร?
ตอนนี้เกี่ยวกับบริการที่สองที่โหลด ตัวติดตามทำหน้าที่สองบทบาท:
- ประการหนึ่ง หน้าที่คือแสดงให้พนักงานในครัวเห็นว่าคำสั่งซื้อใดที่กำลังดำเนินการอยู่ ผลิตภัณฑ์ใดบ้างที่ต้องเตรียมในขณะนี้
- ในทางกลับกัน เปลี่ยนกระบวนการทั้งหมดในครัวให้เป็นดิจิทัล
เมื่อมีสินค้าใหม่ (เช่น พิซซ่า) ปรากฏในคำสั่งซื้อ สินค้าดังกล่าวจะไปที่สถานีติดตาม "กลิ้ง" ที่สถานีนี้มีช่างทำพิซซ่าที่หยิบขนมปังตามขนาดที่ต้องการแล้วม้วนออกมา หลังจากนั้นเขาก็ทำเครื่องหมายบนแท็บเล็ตติดตามว่าเขาทำงานเสร็จแล้วและส่งฐานแป้งที่รีดออกไปยังสถานีถัดไป - "ไส้" .
ที่นั่น คนทำพิซซ่าคนถัดไปวางพิซซ่าบนหน้าพิซซ่า จากนั้นทำเครื่องหมายบนแท็บเล็ตว่าเขาทำงานเสร็จแล้วและวางพิซซ่าลงในเตาอบ (นี่คือสถานีแยกต่างหากที่ต้องทำเครื่องหมายบนแท็บเล็ตด้วย) ระบบดังกล่าวมีมาตั้งแต่เริ่มแรกใน Dodo และตั้งแต่เริ่มต้น Dodo IS ช่วยให้คุณสามารถติดตามและแปลงการดำเนินงานทั้งหมดให้เป็นดิจิทัลได้อย่างสมบูรณ์ นอกจากนี้ ตัวติดตามยังแนะนำวิธีการเตรียมผลิตภัณฑ์เฉพาะ ดำเนินการผลิตภัณฑ์แต่ละประเภทตามแผนการผลิตของตนเอง เก็บเวลาปรุงอาหารที่เหมาะสมที่สุดสำหรับผลิตภัณฑ์ และติดตามการดำเนินการทั้งหมดเกี่ยวกับผลิตภัณฑ์
นี่คือลักษณะของหน้าจอแท็บเล็ตที่สถานีติดตาม Raskatka
โหลดมาจากไหน?
ร้านพิซซ่าแต่ละร้านมีแท็บเล็ตประมาณห้าเม็ดพร้อมเครื่องติดตาม ในปี 2016 เรามีร้านพิซซ่ามากกว่า 100 แห่ง (และตอนนี้มีมากกว่า 600 แห่ง) แท็บเล็ตแต่ละเครื่องส่งคำขอไปยังแบ็กเอนด์ทุกๆ 10 วินาทีและรวบรวมข้อมูลจากตารางคำสั่งซื้อ (เชื่อมโยงกับลูกค้าและที่อยู่) องค์ประกอบของคำสั่งซื้อ (เชื่อมโยงกับผลิตภัณฑ์และการระบุปริมาณ) และตารางแรงจูงใจ (ติดตาม เวลากด) เมื่อผู้ผลิตพิซซ่าคลิกที่ผลิตภัณฑ์บนตัวติดตาม บันทึกในตารางเหล่านี้ทั้งหมดจะได้รับการอัปเดต ตารางคำสั่งซื้อเป็นแบบทั่วไป โดยจะมีการแทรกเมื่อรับคำสั่งซื้อ อัปเดตจากส่วนอื่น ๆ ของระบบ และการอ่านค่าจำนวนมากพร้อมกัน เช่น บนทีวีที่แขวนอยู่ในร้านพิซซ่า และแสดงคำสั่งซื้อสำเร็จรูปแก่ลูกค้า
ในช่วงที่ต้องต่อสู้กับโหลด เมื่อทุกอย่างและทุกคนถูกแคชและถ่ายโอนไปยังฐานข้อมูลจำลองแบบอะซิงโครนัส การดำเนินการเหล่านี้กับตัวติดตามจะยังคงไปที่ฐานข้อมูลหลัก ไม่ควรเกิดความล่าช้า ข้อมูลจะต้องเป็นข้อมูลล่าสุด ไม่ซิงค์กันเป็นสิ่งที่ยอมรับไม่ได้
นอกจากนี้ การไม่มีตารางและดัชนีของเราเองทำให้เราไม่สามารถเขียนคำสั่งเฉพาะเจาะจงเพิ่มเติมที่เหมาะกับการใช้งานของเราได้ ตัวอย่างเช่น อาจมีประสิทธิภาพสำหรับตัวติดตามที่จะมีดัชนีสำหรับร้านพิซซ่าบนโต๊ะคำสั่งซื้อ เรามักจะขูดคำสั่งซื้อร้านพิซซ่าจากฐานข้อมูลตัวติดตามเสมอ ในเวลาเดียวกันในการยอมรับคำสั่งซื้อไม่สำคัญว่าร้านพิชซ่าจะเข้าข่ายไหนสิ่งสำคัญกว่าคือลูกค้ารายใดที่สั่งซื้อนี้ ซึ่งหมายความว่าจำเป็นต้องมีดัชนีบนไคลเอนต์ ตัวติดตามไม่จำเป็นสำหรับการจัดเก็บรหัสใบเสร็จรับเงินหรือโปรโมชั่นโบนัสที่เกี่ยวข้องกับคำสั่งซื้อในตารางคำสั่งซื้อ บริการติดตามของเราไม่สนใจข้อมูลนี้ ในฐานข้อมูลเสาหินทั่วไป ตารางอาจเป็นเพียงการประนีประนอมระหว่างผู้ใช้ทั้งหมดเท่านั้น นี่เป็นหนึ่งในปัญหาดั้งเดิม
เคยเป็น. ในตอนแรกสถาปัตยกรรมจะเป็นดังนี้:
แม้ว่าจะถูกแยกออกเป็นกระบวนการที่แยกจากกัน แต่ฐานโค้ดส่วนใหญ่ก็ยังคงใช้ร่วมกันในบริการต่างๆ ทุกสิ่งที่อยู่ด้านล่างตัวควบคุมได้รับการรวมเป็นหนึ่งเดียวและอาศัยอยู่ในที่เก็บข้อมูลเดียว มีการใช้วิธีการทั่วไปในการบริการ พื้นที่เก็บข้อมูล และฐานข้อมูลทั่วไปที่มีตารางทั่วไป
กำลังยกเลิกการโหลด Tracker
ปัญหาหลักของตัวติดตามคือข้อมูลจะต้องซิงโครไนซ์ระหว่างฐานข้อมูลที่แตกต่างกัน นี่คือความแตกต่างที่สำคัญจากการแบ่งบริการ Auth คำสั่งซื้อและสถานะสามารถเปลี่ยนแปลงได้และควรแสดงในบริการต่างๆ
เรารับคำสั่งซื้อที่จุดชำระเงินร้านอาหาร (นี่คือบริการ) โดยจัดเก็บไว้ในฐานข้อมูลในสถานะ "ยอมรับแล้ว" หลังจากนั้นควรไปที่ตัวติดตามซึ่งจะเปลี่ยนสถานะอีกหลายครั้ง: จาก "ครัว" เป็น "บรรจุแล้ว" ในกรณีนี้ อิทธิพลภายนอกบางอย่างจากแคชเชียร์หรืออินเทอร์เฟซ Shift Manager อาจเกิดขึ้นกับคำสั่งซื้อ ฉันจะแจ้งสถานะคำสั่งซื้อพร้อมคำอธิบายในตาราง:
รูปแบบการเปลี่ยนแปลงสถานะคำสั่งซื้อมีลักษณะดังนี้:
สถานะเปลี่ยนไประหว่างระบบต่างๆ และที่นี่ตัวติดตามไม่ใช่ระบบสุดท้ายที่ข้อมูลถูกล็อค เราได้เห็นแนวทางที่เป็นไปได้หลายประการสำหรับการแยกในกรณีนี้:
- เรารวมการดำเนินการตามคำสั่งซื้อทั้งหมดไว้ในบริการเดียว ในกรณีของเรา ตัวเลือกนี้ต้องใช้บริการมากเกินไปในการประมวลผลคำสั่งซื้อ ถ้าเราหยุดอยู่ตรงนั้น เราก็คงจะจบลงด้วยหินใหญ่ก้อนที่สอง เราคงไม่ได้แก้ไขปัญหา
- ระบบหนึ่งทำการเรียกไปยังอีกระบบหนึ่ง ตัวเลือกที่สองน่าสนใจกว่า แต่ด้วยเหตุนี้ การโทรต่อเนื่องจึงเกิดขึ้นได้ () การเชื่อมต่อของส่วนประกอบต่างๆ สูงขึ้น และยากต่อการจัดการ
- เราจัดกิจกรรมและการแลกเปลี่ยนบริการแต่ละครั้งผ่านกิจกรรมเหล่านี้ เป็นผลให้เลือกตัวเลือกที่สามตามบริการทั้งหมดเริ่มแลกเปลี่ยนกิจกรรมระหว่างกัน
การที่เราเลือกตัวเลือกที่สามหมายความว่าตัวติดตามจะมีฐานข้อมูลของตัวเอง และสำหรับการเปลี่ยนแปลงลำดับทุกครั้ง ตัวติดตามจะส่งเหตุการณ์เกี่ยวกับเรื่องนี้ ซึ่งบริการอื่น ๆ จะสมัครเป็นสมาชิกและจะรวมไว้ในฐานข้อมูลหลักด้วย ในการทำเช่นนี้ เราต้องการบริการบางอย่างที่จะรับประกันการส่งข้อความระหว่างบริการต่างๆ
เมื่อถึงเวลานั้น เรามี RabbitMQ อยู่ในสแต็กแล้ว จึงเป็นการตัดสินใจขั้นสุดท้ายที่จะใช้เป็นนายหน้าข้อความ แผนภาพแสดงการเปลี่ยนคำสั่งซื้อจากแคชเชียร์ร้านอาหารผ่านตัวติดตาม โดยจะเปลี่ยนสถานะและแสดงบนอินเทอร์เฟซคำสั่งซื้อของผู้จัดการ กลายเป็น:
เส้นทางการสั่งซื้อทีละขั้นตอน
เส้นทางคำสั่งซื้อเริ่มต้นที่หนึ่งในบริการแหล่งที่มาของคำสั่งซื้อ นี่คือแคชเชียร์ร้านอาหาร:
- คำสั่งซื้อพร้อมแล้วที่จุดชำระเงิน และถึงเวลาส่งไปยังเครื่องมือติดตาม เหตุการณ์ที่สมัครติดตามตัวติดตามจะถูกโยนทิ้ง
- ตัวติดตามที่ยอมรับคำสั่งซื้อจะบันทึกลงในฐานข้อมูลของตัวเอง สร้างเหตุการณ์ "คำสั่งซื้อที่ยอมรับโดยตัวติดตาม" และส่งไปยัง RMQ
- ตัวจัดการหลายตัวสมัครใช้งานบัสเหตุการณ์แบบกำหนดเองแล้ว สำหรับเรา สิ่งที่ซิงโครไนซ์กับฐานข้อมูลเสาหินเป็นสิ่งสำคัญ
- ตัวจัดการได้รับเหตุการณ์ เลือกจากข้อมูลที่สำคัญ: ในกรณีของเรา นี่คือสถานะคำสั่งซื้อ "ยอมรับโดย Tracker" และอัปเดตเอนทิตีคำสั่งซื้อในฐานข้อมูลหลัก
หากมีคนต้องการคำสั่งซื้อจากตารางคำสั่งซื้อแบบเสาหินโดยเฉพาะ ก็สามารถอ่านได้จากที่นั่นเช่นกัน ตัวอย่างเช่น นี่คือสิ่งที่อินเทอร์เฟซคำสั่งซื้อใน Shift Manager ต้องการ:
บริการอื่น ๆ ทั้งหมดสามารถสมัครรับกิจกรรมการสั่งซื้อจากตัวติดตามเพื่อใช้งานเองได้
หากหลังจากผ่านไประยะหนึ่ง คำสั่งซื้อถูกนำไปใช้จริง สถานะของคำสั่งซื้อจะเปลี่ยนไปในฐานข้อมูล (ฐานข้อมูลตัวติดตาม) ก่อน จากนั้นเหตุการณ์ "OrderInWork" จะถูกสร้างขึ้นทันที นอกจากนี้ยังเข้าสู่ RMQ จากการซิงโครไนซ์ในฐานข้อมูลขนาดใหญ่และส่งไปยังบริการอื่น ๆ อาจมีปัญหาต่าง ๆ ตามเส้นทางนี้ รายละเอียดเพิ่มเติมเกี่ยวกับปัญหาเหล่านี้สามารถพบได้ในรายงานของ Zhenya Peshkov .
สถาปัตยกรรมขั้นสุดท้ายหลังจากการเปลี่ยนแปลงใน Auth และ Tracker
สรุป: ในตอนแรก ฉันมีความคิดที่จะรวมประวัติศาสตร์เก้าปีของระบบ Dodo IS ไว้ในบทความเดียว ฉันต้องการพูดคุยเกี่ยวกับขั้นตอนของวิวัฒนาการอย่างรวดเร็วและง่ายดาย อย่างไรก็ตาม เมื่อนั่งลงเพื่อศึกษาเนื้อหา ฉันก็ตระหนักว่าทุกอย่างซับซ้อนและน่าสนใจมากกว่าที่คิด
เมื่อพิจารณาถึงคุณประโยชน์ (หรือขาดไป) ของเนื้อหาดังกล่าว ฉันจึงได้ข้อสรุปว่าการพัฒนาอย่างต่อเนื่องเป็นไปไม่ได้หากไม่มีบันทึกเหตุการณ์ที่ครบถ้วน รายละเอียดย้อนหลัง และการวิเคราะห์การตัดสินใจในอดีตของตน
ฉันหวังว่าคุณจะพบว่ามีประโยชน์และน่าสนใจในการเรียนรู้เกี่ยวกับการเดินทางของเรา ตอนนี้ฉันกำลังเผชิญกับตัวเลือกว่าจะอธิบายส่วนใดของระบบ Dodo IS ในบทความถัดไป: เขียนความคิดเห็นหรือโหวต
เฉพาะผู้ใช้ที่ลงทะเบียนเท่านั้นที่สามารถเข้าร่วมในการสำรวจได้ , โปรด.
คุณต้องการเรียนรู้ส่วนใดของ Dodo IS ในบทความถัดไป
-
ลด 24,1%หินใหญ่ก้อนเดียวในยุค Dodo IS (2011-2015)14
-
ลด 24,1%ปัญหาแรกและแนวทางแก้ไข (พ.ศ. 2015-2016)14
-
ลด 20,7%เส้นทางส่วนลูกค้า: ด้านหน้าอาคารเหนือฐาน (2016-2017)12
-
ลด 36,2%ประวัติความเป็นมาของไมโครเซอร์วิสจริง (2018-2019)21
-
ลด 44,8%เสร็จสิ้นการตัดเสาหินและรักษาเสถียรภาพของสถาปัตยกรรม26
-
ลด 29,3%เกี่ยวกับแผนการพัฒนาระบบเพิ่มเติม17
-
ลด 19,0%ฉันไม่อยากรู้อะไรเกี่ยวกับ Dodo IS11
ผู้ใช้ 58 คนโหวต ผู้ใช้ 6 รายงดออกเสียง
ที่มา: will.com