ประวัติความเป็นมาของสถาปัตยกรรม Dodo IS: เสาหินยุคแรก

หรือ บริษัท ที่ไม่มีความสุขทุกแห่งที่มีเสาหินก้อนเดียวก็ไม่มีความสุขในแบบของมันเอง

การพัฒนาระบบ Dodo IS เริ่มขึ้นทันที เช่นเดียวกับธุรกิจ Dodo Pizza ในปี 2011 มันขึ้นอยู่กับแนวคิดของการแปลงกระบวนการทางธุรกิจให้เป็นดิจิทัลอย่างสมบูรณ์และสมบูรณ์และ ด้วยตัวเองซึ่งในปี 2011 ทำให้เกิดคำถามและความสงสัยมากมาย แต่เป็นเวลา 9 ปีแล้วที่เราเดินตามเส้นทางนี้ - ด้วยการพัฒนาของเราเองซึ่งเริ่มต้นด้วยเสาหิน

บทความนี้เป็น "คำตอบ" สำหรับคำถามที่ว่า "ทำไมต้องเขียนสถาปัตยกรรมใหม่และทำการเปลี่ยนแปลงขนาดใหญ่และระยะยาวเช่นนี้" ย้อนกลับไปที่บทความก่อนหน้า "ประวัติสถาปัตยกรรม Dodo IS: วิถีแห่ง Back Office". ฉันจะเริ่มต้นด้วยการพัฒนา Dodo IS เริ่มต้นอย่างไร สถาปัตยกรรมดั้งเดิมมีลักษณะอย่างไร โมดูลใหม่ปรากฏขึ้นอย่างไร และเพราะเหตุใดจึงต้องทำการเปลี่ยนแปลงขนาดใหญ่

ชุดบทความ "Dodo IS คืออะไร" บอกเกี่ยวกับ:

1. เสาหินยุคแรกใน Dodo IS (2011-2015) (คุณอยู่ที่นี่)

2. เส้นทาง Back Office: แยกฐานและรถบัส.

3. เส้นทางฝั่งลูกค้า: ซุ้มเหนือฐาน (2016-2017) (กำลังดำเนินการ...)

4. ประวัติของไมโครเซอร์วิสที่แท้จริง (พ.ศ.2018-2019). (กำลังดำเนินการ...)

5. เสร็จสิ้นการเลื่อยเสาหินและการรักษาเสถียรภาพของสถาปัตยกรรม (กำลังดำเนินการ...)

สถาปัตยกรรมเบื้องต้น

ในปี 2011 สถาปัตยกรรม Dodo IS มีลักษณะดังนี้:

โมดูลแรกในสถาปัตยกรรมคือการยอมรับคำสั่ง กระบวนการทางธุรกิจคือ:

• ลูกค้าเรียกร้านพิชซ่า

• ผู้จัดการรับสาย

• รับคำสั่งซื้อทางโทรศัพท์

• กรอกข้อมูลแบบคู่ขนานในอินเทอร์เฟซการยอมรับคำสั่งซื้อ โดยคำนึงถึงข้อมูลเกี่ยวกับลูกค้า ข้อมูลรายละเอียดคำสั่งซื้อ ที่อยู่จัดส่ง 

อินเทอร์เฟซของระบบข้อมูลมีลักษณะดังนี้ ...

เวอร์ชันแรกตั้งแต่เดือนตุลาคม 2011:

ปรับปรุงเล็กน้อยในเดือนมกราคม 2012

Dodo Pizza Information System จัดส่งร้านพิซซ่า

ทรัพยากรสำหรับการพัฒนาโมดูลการสั่งซื้อครั้งแรกมีจำกัด เราต้องทำอะไรมากมาย รวดเร็ว และกับทีมเล็กๆ ทีมเล็กๆ คือนักพัฒนา 2 คนที่วางรากฐานสำหรับระบบในอนาคตทั้งหมด

การตัดสินใจครั้งแรกของพวกเขากำหนดชะตากรรมของกองเทคโนโลยี:

• แบ็กเอนด์บน ASP.NET MVC ภาษา C# ผู้พัฒนาคือ dotnetchiki สแต็กนี้คุ้นเคยและถูกใจสำหรับพวกเขา

• ส่วนหน้าบน Bootstrap และ JQuery: ส่วนต่อประสานกับผู้ใช้ในรูปแบบและสคริปต์ที่เขียนเอง 

• ฐานข้อมูล MySQL: ไม่มีค่าลิขสิทธิ์ ใช้งานง่าย

• เซิร์ฟเวอร์บน Windows Server เนื่องจาก .NET สามารถอยู่ภายใต้ Windows เท่านั้น (เราจะไม่พูดถึง Mono)

ทางร่างกาย ทั้งหมดนี้แสดงออกใน "การอุทิศที่เจ้าภาพ" 

สถาปัตยกรรมแอปพลิเคชันการรับคำสั่งซื้อ

จากนั้นทุกคนก็พูดถึง microservices และ SOA ถูกใช้ในโครงการขนาดใหญ่เป็นเวลา 5 ปีเช่น WCF เปิดตัวในปี 2006 แต่แล้วพวกเขาก็เลือกวิธีแก้ปัญหาที่เชื่อถือได้และได้รับการพิสูจน์แล้ว

นี่คือ

Asp.Net MVC คือ Razor ซึ่งตามคำขอจากแบบฟอร์มหรือจากไคลเอนต์ แสดงผลหน้า HTML ด้วยการแสดงผลเซิร์ฟเวอร์ บนไคลเอ็นต์ สคริปต์ CSS และ JS แสดงข้อมูลอยู่แล้ว และถ้าจำเป็น ให้ดำเนินการคำขอ AJAX ผ่าน JQuery

คำขอบนเซิร์ฟเวอร์สิ้นสุดในคลาส *Controller ซึ่งการประมวลผลและการสร้างหน้า HTML สุดท้ายเกิดขึ้นในเมธอด คอนโทรลเลอร์ทำการร้องขอไปยังเลเยอร์ของลอจิกที่เรียกว่า *บริการ แต่ละบริการสอดคล้องกับบางแง่มุมของธุรกิจ:

• ตัวอย่างเช่น DepartmentStructureService ให้ข้อมูลเกี่ยวกับร้านพิซซ่า แผนกต่างๆ แผนกคือกลุ่มร้านพิซซ่าที่ดำเนินการโดยแฟรนไชส์รายเดียว

• การรับคำสั่งซื้อบริการยอมรับและคำนวณองค์ประกอบของคำสั่งซื้อ

• และ SmsService ส่ง SMS โดยเรียกบริการ API เพื่อส่ง SMS

บริการประมวลผลข้อมูลจากฐานข้อมูล จัดเก็บตรรกะทางธุรกิจ แต่ละบริการมีที่เก็บ *อย่างน้อยหนึ่งแห่งที่มีชื่อที่เหมาะสม พวกเขามีแบบสอบถามไปยังขั้นตอนการจัดเก็บในฐานข้อมูลและเลเยอร์ของผู้ทำแผนที่ มีตรรกะทางธุรกิจในที่เก็บข้อมูล โดยเฉพาะอย่างยิ่งในที่เก็บข้อมูลที่ออกรายงาน ไม่ได้ใช้ ORM ทุกคนพึ่งพา sql ที่เขียนด้วยมือ 

นอกจากนี้ยังมีเลเยอร์ของโมเดลโดเมนและคลาสตัวช่วยทั่วไป เช่น คลาส Order ที่จัดเก็บคำสั่งซื้อ ที่เดียวกันใน Layer มีตัวช่วยสำหรับแปลงข้อความที่แสดงตามสกุลเงินที่เลือก

ทั้งหมดนี้สามารถแสดงด้วยแบบจำลองดังกล่าว:

ช่องทางการสั่งซื้อ

พิจารณาวิธีเริ่มต้นง่ายๆ ในการสร้างคำสั่งซื้อดังกล่าว

ในขั้นต้นไซต์เป็นแบบคงที่ มันมีราคาอยู่และที่ด้านบน - หมายเลขโทรศัพท์และคำจารึก "ถ้าคุณต้องการพิซซ่า - โทรตามหมายเลขและสั่งซื้อ" ในการสั่งซื้อ เราจำเป็นต้องใช้ขั้นตอนง่ายๆ: 

• ลูกค้าเยี่ยมชมไซต์คงที่พร้อมราคา เลือกผลิตภัณฑ์และโทรไปที่หมายเลขที่แสดงบนเว็บไซต์

• ลูกค้าตั้งชื่อผลิตภัณฑ์ที่ต้องการเพิ่มในคำสั่งซื้อ

• ให้ที่อยู่และชื่อของเขา

• ผู้ประกอบการยอมรับคำสั่งซื้อ

• คำสั่งซื้อจะแสดงในอินเทอร์เฟซคำสั่งซื้อที่ยอมรับ

ทุกอย่างเริ่มต้นด้วยการแสดงเมนู ผู้ใช้-ผู้ดำเนินการที่เข้าสู่ระบบยอมรับได้ครั้งละหนึ่งคำสั่งเท่านั้น ดังนั้น รถเข็นร่างสามารถเก็บไว้ในเซสชันของเขา (เซสชันของผู้ใช้จะถูกเก็บไว้ในหน่วยความจำ) มีวัตถุรถเข็นที่มีผลิตภัณฑ์และข้อมูลลูกค้า

ลูกค้าตั้งชื่อผลิตภัณฑ์ ผู้ประกอบการคลิก + ถัดจากผลิตภัณฑ์ และคำขอจะถูกส่งไปยังเซิร์ฟเวอร์ ข้อมูลเกี่ยวกับผลิตภัณฑ์จะถูกดึงออกมาจากฐานข้อมูล และข้อมูลเกี่ยวกับผลิตภัณฑ์จะถูกเพิ่มลงในรถเข็น

หมายเหตุ. ใช่ ที่นี่คุณไม่สามารถดึงผลิตภัณฑ์จากฐานข้อมูล แต่ถ่ายโอนจากส่วนหน้า แต่เพื่อความชัดเจน ฉันแสดงเส้นทางจากฐานข้อมูลอย่างชัดเจน 

จากนั้นป้อนที่อยู่และชื่อของลูกค้า 

เมื่อคุณคลิก "สร้างคำสั่งซื้อ":

• คำขอถูกส่งไปที่ OrderController.SaveOrder()

• เราได้รับรถเข็นจากเซสชัน มีสินค้าในปริมาณที่เราต้องการ

• เราเสริมรถเข็นด้วยข้อมูลเกี่ยวกับไคลเอนต์และส่งต่อไปยังเมธอด AddOrder ของคลาส Transmission Order ซึ่งจะบันทึกลงในฐานข้อมูล 

• ฐานข้อมูลมีตารางที่มีคำสั่งซื้อ ส่วนประกอบของคำสั่งซื้อ ลูกค้า และเชื่อมต่อกันทั้งหมด

• อินเทอร์เฟซการแสดงคำสั่งซื้อจะไปและดึงคำสั่งซื้อล่าสุดออกมาและแสดง

โมดูลใหม่

การรับคำสั่งเป็นสิ่งสำคัญและจำเป็น คุณไม่สามารถทำธุรกิจพิซซ่าได้หากคุณไม่มีคำสั่งขาย ดังนั้นระบบจึงเริ่มได้รับฟังก์ชัน - ประมาณปี 2012 ถึง 2015 ในช่วงเวลานี้บล็อกต่าง ๆ ของระบบปรากฏขึ้นซึ่งฉันจะเรียก โมดูลตรงข้ามกับแนวคิดของบริการหรือผลิตภัณฑ์ 

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

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

ในทางเทคนิคแล้ว โมดูลได้รับการออกแบบเป็น Area (แนวคิดดังกล่าวยังคงอยู่ใน แกน asp.net). มีไฟล์แยกต่างหากสำหรับส่วนหน้า รุ่น และคลาสคอนโทรลเลอร์ของตัวเอง เป็นผลให้ระบบเปลี่ยนไปจากนี้ ...

...ในสิ่งนี้:

บางโมดูลถูกนำไปใช้โดยไซต์แยกต่างหาก (โปรเจ็กต์ปฏิบัติการ) เนื่องจากฟังก์ชันการทำงานที่แยกจากกันโดยสิ้นเชิง และส่วนหนึ่งเกิดจากการพัฒนาที่แยกจากกันเล็กน้อยและมุ่งเน้นมากขึ้น นี้:

• เว็บไซต์ - การแปล เว็บไซต์ dodopizza.ru

• ส่งออก: อัปโหลดรายงานจาก Dodo IS สำหรับ 1C 

• บัญชีส่วนบุคคล - บัญชีส่วนตัวของพนักงาน ได้รับการพัฒนาแยกกันและมีจุดเริ่มต้นและการออกแบบแยกต่างหาก

• fs — โครงการสำหรับการโฮสต์สถิตยศาสตร์ ต่อมาเราก็ย้ายออกจากมัน ย้ายสแตติกทั้งหมดไปที่ Akamai CDN 

บล็อกที่เหลืออยู่ในแอปพลิเคชัน BackOffice 

คำอธิบายชื่อ:

• แคชเชียร์ - แคชเชียร์ร้านอาหาร.

• ShiftManager - อินเทอร์เฟซสำหรับบทบาท "Shift Manager": สถิติการดำเนินงานเกี่ยวกับการขายร้านพิชซ่า, ความสามารถในการวางผลิตภัณฑ์ในรายการหยุด, เปลี่ยนลำดับ

• OfficeManager - อินเทอร์เฟซสำหรับบทบาท "Pizzeria Manager" และ "Franchisee" นี่คือฟังก์ชั่นที่รวบรวมไว้สำหรับการตั้งค่าร้านพิชซ่า โปรโมชั่นโบนัส การรับและการทำงานร่วมกับพนักงาน รายงาน

• PublicScreens - อินเทอร์เฟซสำหรับทีวีและแท็บเล็ตที่แขวนอยู่ในร้านพิซซ่า ทีวีแสดงเมนู ข้อมูลโฆษณา สถานะการสั่งซื้อเมื่อจัดส่ง 

พวกเขาใช้เลเยอร์บริการทั่วไป บล็อกคลาสโดเมน Dodo.Core ทั่วไป และฐานร่วมกัน บางครั้งพวกเขายังคงนำไปสู่การเปลี่ยนผ่านซึ่งกันและกัน รวมถึงแต่ละไซต์ เช่น dodopizza.ru หรือ personal.dopizza.ru ไปที่บริการทั่วไป

เมื่อโมดูลใหม่ปรากฏขึ้น เราพยายามนำรหัสบริการที่สร้างไว้แล้ว ขั้นตอนการจัดเก็บ และตารางในฐานข้อมูลกลับมาใช้ใหม่ให้ได้มากที่สุด 

เพื่อความเข้าใจที่ดีขึ้นเกี่ยวกับขนาดของโมดูลที่สร้างขึ้นในระบบ นี่คือไดอะแกรมจากปี 2012 พร้อมแผนการพัฒนา:

ภายในปี 2015 ทุกอย่างอยู่ในแผนที่และยิ่งกว่านั้นอยู่ในขั้นตอนการผลิต

• การยอมรับคำสั่งซื้อได้ขยายเป็นบล็อกแยกต่างหากของ Contact Center ซึ่งผู้ดำเนินการยอมรับคำสั่งซื้อ

• มีจอสาธารณะพร้อมเมนูและข้อมูลแขวนอยู่ในร้านพิซซ่า

• ห้องครัวมีโมดูลที่เล่นข้อความเสียง "New Pizza" โดยอัตโนมัติเมื่อมีคำสั่งซื้อใหม่เข้ามา และยังพิมพ์ใบแจ้งหนี้สำหรับผู้จัดส่งอีกด้วย สิ่งนี้ทำให้กระบวนการในครัวง่ายขึ้นอย่างมาก ช่วยให้พนักงานไม่ต้องเสียสมาธิกับการทำงานง่ายๆ จำนวนมาก

• หน่วยจัดส่งกลายเป็น Delivery Checkout ที่แยกจากกัน โดยคำสั่งซื้อจะออกให้กับผู้จัดส่งที่เข้ากะก่อนหน้านี้ เวลาทำงานของเขาถูกนำมาพิจารณาในการคำนวณเงินเดือน 

ในระหว่างปี 2012 ถึง 2015 มีผู้พัฒนามากกว่า 10 ราย เปิดร้านพิซซ่า 35 แห่ง ติดตั้งระบบในโรมาเนียและเตรียมพร้อมสำหรับการเปิดร้านในสหรัฐอเมริกา นักพัฒนาไม่ได้จัดการกับงานทั้งหมดอีกต่อไป แต่ถูกแบ่งออกเป็นทีม แต่ละคนเชี่ยวชาญในส่วนของระบบของตนเอง 

ปัญหา

รวมถึงเพราะสถาปัตยกรรม (แต่ไม่ใช่เท่านั้น)

ความโกลาหลในฐาน

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

แต่กว่า 4 ปีของการพัฒนา ฐานข้อมูลมีประมาณ 600 ตาราง 1500 กระบวนงานที่จัดเก็บ ซึ่งหลายรายการมีตรรกะด้วย อนิจจาขั้นตอนการจัดเก็บไม่ก่อให้เกิดประโยชน์มากนักเมื่อทำงานกับ MySQL พวกมันไม่ถูกแคชโดยฐาน และการจัดเก็บลอจิกไว้ในนั้นทำให้การพัฒนาและการดีบักซับซ้อนขึ้น การใช้รหัสซ้ำยังเป็นเรื่องยาก

หลายตารางไม่มีดัชนีที่เหมาะสมในทางตรงกันข้ามมีดัชนีจำนวนมากซึ่งทำให้ยากต่อการแทรก จำเป็นต้องแก้ไขประมาณ 20 ตาราง - การทำธุรกรรมเพื่อสร้างคำสั่งซื้ออาจใช้เวลาประมาณ 3-5 วินาที 

ข้อมูลในตารางไม่ได้อยู่ในรูปแบบที่เหมาะสมเสมอไป. ที่ไหนสักแห่งจำเป็นต้องทำดีนอร์มัลไลเซชัน ส่วนหนึ่งของข้อมูลที่ได้รับเป็นประจำอยู่ในคอลัมน์ในรูปแบบของโครงสร้าง XML ซึ่งเพิ่มเวลาการดำเนินการ เพิ่มคิวรีให้ยาวขึ้น และทำให้การพัฒนาซับซ้อนขึ้น

มีการผลิตมากในตารางเดียวกัน คำขอที่แตกต่างกัน. ตารางยอดนิยมได้รับผลกระทบโดยเฉพาะอย่างยิ่งเช่นตารางที่กล่าวถึงข้างต้น คำสั่งซื้อ หรือโต๊ะ ร้านพีสสะ. พวกเขาใช้เพื่อแสดงอินเทอร์เฟซการปฏิบัติงานในครัว การวิเคราะห์ เว็บไซต์อื่นติดต่อพวกเขา (dodopizza.ru) ซึ่งในเวลาใดก็ตาม อาจมีคำขอจำนวนมากเข้ามาในทันที 

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

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

การทำงานร่วมกันและการทำให้งงงวยในรหัส

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

บริการ (คลาสภายในโครงการขนาดใหญ่เสาเดียว) สามารถโทรหากันเพื่อเพิ่มข้อมูลของพวกเขา

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

ตรรกะอยู่ในตัวควบคุมหรือในคลาสบริการ 

สิ่งเหล่านี้ดูเหมือนจะเป็นปัญหาเล็กน้อย แต่ทำให้การพัฒนาช้าลงอย่างมากและคุณภาพลดลง ซึ่งนำไปสู่ความไม่เสถียรและจุดบกพร่อง 

ความซับซ้อนของการพัฒนาขนาดใหญ่

ความยากลำบากเกิดขึ้นในการพัฒนาตัวเอง. จำเป็นต้องสร้างบล็อกต่าง ๆ ของระบบและในแบบคู่ขนาน การปรับความต้องการของส่วนประกอบแต่ละส่วนให้เป็นโค้ดเดียวกลายเป็นเรื่องยากขึ้นเรื่อยๆ มันไม่ง่ายเลยที่จะตกลงและเอาใจช่วยส่วนประกอบทั้งหมดในเวลาเดียวกัน นอกจากนี้ ยังมีข้อจำกัดในด้านเทคโนโลยี โดยเฉพาะอย่างยิ่งในส่วนของฐานและส่วนหน้า จำเป็นต้องละทิ้ง jQuery ไปสู่เฟรมเวิร์กระดับสูง โดยเฉพาะอย่างยิ่งในแง่ของการบริการลูกค้า (เว็บไซต์)

ในบางส่วนของระบบ สามารถใช้ฐานข้อมูลที่เหมาะสมกว่านี้ได้. ตัวอย่างเช่น ภายหลังเรามีการใช้กรณีการย้ายจาก Redis ไปยัง CosmosDB เพื่อจัดเก็บตะกร้าใบสั่งซื้อ 

เห็นได้ชัดว่าทีมและนักพัฒนาที่เกี่ยวข้องในสาขาของตนต้องการอิสระมากขึ้นสำหรับบริการของตน ทั้งในแง่ของการพัฒนาและการเปิดตัว รวมความขัดแย้ง ปล่อยปัญหา หากสำหรับนักพัฒนา 5 คน ปัญหานี้ไม่มีนัยสำคัญ ดังนั้นหากมี 10 คนและมากกว่านั้นด้วยการเติบโตที่วางแผนไว้ ทุกอย่างจะจริงจังมากขึ้น และข้างหน้าคือการพัฒนาแอปพลิเคชั่นมือถือ (เริ่มในปี 2017 และในปี 2018 คือ ฤดูใบไม้ร่วงใหญ่). 

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

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

บล็อก Power of the Mind ใส่เครื่องบันทึกเงินสดในร้านอาหารได้อย่างไร

หากการเติบโตของเครือข่ายร้านพิชซ่า (และปริมาณการโหลด) ยังคงดำเนินต่อไปในจังหวะเดียวกัน หลังจากนั้นไม่นาน การล่มสลายจะทำให้ระบบไม่เพิ่มขึ้น แสดงให้เห็นถึงปัญหาที่เราเริ่มเผชิญในปี 2015 นี่คือเรื่องราวดังกล่าว 

ในบล็อก "พลังจิต” เป็นวิดเจ็ตที่แสดงข้อมูลเกี่ยวกับรายได้สำหรับปีของเครือข่ายทั้งหมด วิดเจ็ตเข้าถึง Dodo public API ซึ่งให้ข้อมูลนี้ สถิตินี้สามารถดูได้ที่ http://dodopizzastory.com/. วิดเจ็ตแสดงอยู่ในทุกหน้าและทำการร้องขอด้วยตัวจับเวลาทุกๆ 20 วินาที คำขอไปที่ api.dopizza.ru และร้องขอ:

• จำนวนร้านพิซซ่าในเครือข่าย

• รายได้รวมของเครือข่ายตั้งแต่ต้นปี

• รายได้สำหรับวันนี้

คำขอสถิติเกี่ยวกับรายได้ส่งตรงไปยังฐานข้อมูลและเริ่มขอข้อมูลคำสั่งซื้อ รวบรวมข้อมูลทันทีและแจ้งจำนวนเงิน 

โต๊ะเก็บเงินในร้านอาหารไปที่โต๊ะรับออเดอร์เดียวกัน ยกเลิกการโหลดรายการออเดอร์ที่ได้รับสำหรับวันนี้ และเพิ่มออเดอร์ใหม่เข้าไป เครื่องบันทึกเงินสดส่งคำขอทุก 5 วินาทีหรือเมื่อรีเฟรชหน้า

แผนภาพมีลักษณะดังนี้:

ฤดูใบไม้ร่วงปีหนึ่ง Fyodor Ovchinnikov เขียนบทความขนาดยาวและเป็นที่นิยมในบล็อกของเขา ผู้คนจำนวนมากมาที่บล็อกและเริ่มอ่านทุกอย่างอย่างละเอียด ในขณะที่แต่ละคนที่เข้ามาอ่านบทความ วิดเจ็ตรายได้ก็ทำงานอย่างถูกต้องและร้องขอ API ทุกๆ 20 วินาที

API เรียกขั้นตอนการจัดเก็บเพื่อคำนวณผลรวมของคำสั่งซื้อทั้งหมดตั้งแต่ต้นปีสำหรับร้านพิซซ่าทั้งหมดในเครือข่าย การรวมอิงตามตารางคำสั่งซื้อซึ่งเป็นที่นิยมมาก โต๊ะเงินสดทั้งหมดของร้านอาหารที่เปิดอยู่ในเวลานั้นไปที่มัน โต๊ะเงินสดหยุดตอบสนอง ไม่รับคำสั่งซื้อ พวกเขายังไม่ได้รับการยอมรับจากไซต์ ไม่ปรากฏบนตัวติดตาม ผู้จัดการกะไม่เห็นพวกเขาในอินเทอร์เฟซของเขา 

นี่ไม่ใช่เรื่องราวเดียว ภายในฤดูใบไม้ร่วงปี 2015 ทุกวันศุกร์ โหลดในระบบมีความสำคัญมาก หลายครั้งที่เราปิด API สาธารณะ และครั้งหนึ่งเราต้องปิดไซต์ด้วยซ้ำเพราะไม่มีอะไรช่วยได้ มีแม้กระทั่งรายการบริการที่มีคำสั่งปิดเครื่องภายใต้ภาระหนัก

จากนี้ไปการต่อสู้ของเรากับโหลดและเพื่อความเสถียรของระบบจะเริ่มต้นขึ้น (ตั้งแต่ฤดูใบไม้ร่วงปี 2015 ถึงฤดูใบไม้ร่วงปี 2018) นั่นคือตอนที่มันเกิดขึ้น"ฤดูใบไม้ร่วงที่ดี". นอกจากนี้ บางครั้งความล้มเหลวก็เกิดขึ้น บางอย่างก็อ่อนไหวมาก แต่ช่วงเวลาทั่วไปของความไม่แน่นอนถือว่าผ่านไปแล้ว

การเติบโตของธุรกิจอย่างรวดเร็ว

ทำไมถึงทำทันทีไม่ได้? เพียงดูแผนภูมิต่อไปนี้

นอกจากนี้ในปี 2014-2015 มีการเปิดตัวในโรมาเนียและกำลังเตรียมการเปิดตัวในสหรัฐอเมริกา

เครือข่ายเติบโตอย่างรวดเร็ว เปิดประเทศใหม่ มีร้านพิซซ่ารูปแบบใหม่ เช่น ร้านพิชซ่าเปิดที่ศูนย์อาหาร ทั้งหมดนี้ต้องการความใส่ใจอย่างมากโดยเฉพาะกับการขยายฟังก์ชัน Dodo IS หากไม่มีฟังก์ชั่นทั้งหมดเหล่านี้, ไม่มีการติดตามในครัว, การบัญชีสำหรับผลิตภัณฑ์และการสูญเสียในระบบ, การแสดงการออกคำสั่งในห้องโถงศูนย์อาหาร, เราแทบจะไม่ต้องพูดถึงสถาปัตยกรรมที่ “ถูกต้อง” และแนวทางที่ “ถูกต้อง” การพัฒนาในขณะนี้

อุปสรรคอีกประการหนึ่งในการแก้ไขสถาปัตยกรรมอย่างทันท่วงทีและการให้ความสนใจกับปัญหาทางเทคนิคโดยทั่วไปคือวิกฤตในปี 2014 สิ่งเหล่านี้สร้างโอกาสให้กับทีมในการเติบโตอย่างมาก โดยเฉพาะอย่างยิ่งสำหรับธุรกิจใหม่อย่าง Dodo Pizza

วิธีแก้ปัญหาด่วนที่ช่วยได้

ปัญหาที่จำเป็นในการแก้ไข ตามอัตภาพ การแก้ปัญหาสามารถแบ่งออกเป็น 2 กลุ่ม:

• รถเร็วที่ดับไฟและให้ความปลอดภัยเพียงเล็กน้อยและซื้อเวลาให้เราเปลี่ยนแปลง

• เป็นระบบและยาว การรื้อปรับระบบของโมดูลจำนวนหนึ่ง การแบ่งสถาปัตยกรรมเสาหินเป็นบริการแยกต่างหาก (ส่วนใหญ่ไม่ใช่บริการระดับไมโคร แต่เป็นบริการระดับมหภาคและมีบางอย่างเกี่ยวกับเรื่องนี้ รายงานของ Andrey Morevskiy). 

รายการการเปลี่ยนแปลงด่วนแบบแห้งมีดังนี้:

ขยายฐานมาสเตอร์

แน่นอน สิ่งแรกที่ทำเพื่อจัดการกับโหลดคือการเพิ่มความจุของเซิร์ฟเวอร์ สิ่งนี้ทำขึ้นสำหรับฐานข้อมูลหลักและสำหรับเว็บเซิร์ฟเวอร์ อนิจจาเป็นไปได้ถึงขีด จำกัด หนึ่งเท่านั้นจากนั้นจึงมีราคาแพงเกินไป

ตั้งแต่ปี 2014 เราได้ย้ายไปที่ Azure เรายังเขียนเกี่ยวกับหัวข้อนี้ในเวลานั้นในบทความ "Dodo Pizza ส่งพิซซ่าโดยใช้ Microsoft Azure Cloud ได้อย่างไร". แต่หลังจากการเพิ่มขึ้นของเซิร์ฟเวอร์สำหรับฐาน พวกเขาก็สู้ราคา 

แบบจำลองพื้นฐานสำหรับการอ่าน

มีการสร้างแบบจำลองสองแบบสำหรับฐาน:

อ่านแบบจำลอง สำหรับคำขออ้างอิง. ใช้เพื่ออ่านไดเร็กทอรี ประเภท เมือง ถนน ร้านพิชซ่า ผลิตภัณฑ์ (โดเมนที่เปลี่ยนช้า) และในอินเทอร์เฟซที่ยอมรับการหน่วงเวลาเล็กน้อยได้ มี 2 ​​แบบจำลองเหล่านี้ เรารับประกันความพร้อมใช้งานในลักษณะเดียวกับต้นแบบ

ReadReplica สำหรับคำขอรายงาน. ฐานข้อมูลนี้มีความพร้อมใช้งานต่ำกว่า แต่รายงานทั้งหมดไปที่ฐานข้อมูลนี้ ให้พวกเขามีคำขอจำนวนมากสำหรับการคำนวณข้อมูลขนาดใหญ่ใหม่ แต่จะไม่ส่งผลกระทบต่อฐานข้อมูลหลักและอินเทอร์เฟซการปฏิบัติงาน 

แคชในรหัส

ไม่มีแคชที่ใดก็ได้ในรหัส (เลย) สิ่งนี้นำไปสู่การร้องขอเพิ่มเติมที่ไม่จำเป็นเสมอไปไปยังฐานข้อมูลที่โหลด แคชเป็นอันดับแรกทั้งในหน่วยความจำและในบริการแคชภายนอก นั่นคือ Redis ทุกอย่างไม่ถูกต้องตามเวลา การตั้งค่าถูกระบุในรหัส

เซิร์ฟเวอร์แบ็กเอนด์หลายตัว

แบ็กเอนด์ของแอปพลิเคชันจำเป็นต้องปรับขนาดเพื่อรองรับปริมาณงานที่เพิ่มขึ้น จำเป็นต้องสร้างคลัสเตอร์จากเซิร์ฟเวอร์ iis หนึ่งเครื่อง เราได้กำหนดเวลาใหม่ เซสชั่นการสมัคร ตั้งแต่หน่วยความจำไปจนถึง RedisCache ซึ่งทำให้สามารถสร้างเซิร์ฟเวอร์หลายตัวที่อยู่เบื้องหลังโหลดบาลานเซอร์อย่างง่ายด้วย Round robin ในตอนแรก Redis เดียวกันถูกใช้เป็นแคช จากนั้นจึงแยกออกเป็นหลาย ๆ อัน 

เป็นผลให้สถาปัตยกรรมมีความซับซ้อนมากขึ้น ...

… แต่ความตึงเครียดบางส่วนก็ถูกขจัดออกไป

จากนั้นจำเป็นต้องทำซ้ำส่วนประกอบที่โหลดซึ่งเราดำเนินการ เราจะพูดถึงเรื่องนี้ในส่วนถัดไป

ที่มา: will.com