ISPsystem ให้อภัยและอำลา! ทำไมและเราเขียนแผงควบคุมเซิร์ฟเวอร์ของเราอย่างไรและอย่างไร

ISPsystem ให้อภัยและอำลา! ทำไมและเราเขียนแผงควบคุมเซิร์ฟเวอร์ของเราอย่างไรและอย่างไร

สวัสดี! เราเป็น "เทคโนโลยีโฮสติ้ง" และเปิดตัวเมื่อ 5 ปีที่แล้ว VDSน่า — โฮสติ้ง vds แรกที่สร้างขึ้นสำหรับนักพัฒนาโดยเฉพาะ เรามุ่งมั่นที่จะทำให้สะดวกเหมือน DigitalOcean แต่ด้วยการสนับสนุนของรัสเซีย วิธีการชำระเงิน และเซิร์ฟเวอร์ในรัสเซีย แต่ DigitalOcean ไม่ใช่แค่ความน่าเชื่อถือและราคาเท่านั้น แต่ยังเป็นบริการอีกด้วย

ซอฟต์แวร์จาก ISPsystem กลายเป็นเชือกที่มัดมือเราไปสู่บริการสุดเจ๋ง เมื่อสามปีที่แล้ว เราใช้การเรียกเก็บเงินของ Billmanager และแผงควบคุมเซิร์ฟเวอร์ VMmanager และตระหนักได้อย่างรวดเร็วว่าแทบจะเป็นไปไม่ได้เลยที่จะให้บริการที่ดีโดยไม่มีแผงควบคุมของเราเอง

ระบบ ISP ทำลายความสะดวกสบายได้อย่างไร

เป็นโรคจิต

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

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

ภัยคุกคามการหยุดทำงาน

การอัปเดตอาจทำให้เกิดการหยุดทำงานที่คาดเดาไม่ได้ซึ่งทำให้เกิดข้อผิดพลาดใหม่

การอัปเดตแต่ละครั้งคือลอตเตอรี: ฉันต้องปกปิดการเรียกเก็บเงินและเสียสละเทพเจ้าแห่งการอัปเดต - การอัปเดตสองสามครั้งทำให้หยุดทำงานเป็นเวลา 10-15 นาที ผู้ดูแลระบบของเราในเวลานี้กำลังจับตามอง - เราไม่เคยรู้ว่าเวลาหยุดทำงานจะกินเวลานานเท่าใดและไม่สามารถคาดเดาได้ว่าเมื่อใดที่ระบบ ISP จะตัดสินใจออกการอัปเดตใหม่

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

อินเทอร์เฟซแผงไม่สะดวก

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

อินเทอร์เฟซดังกล่าวต้องใช้เวลา - ทั้งของเราและของลูกค้าของเรา ไม่มีคำถามเกี่ยวกับความสะดวกสบายใด ๆ เช่นเดียวกับ DigitalOcean ในสถานการณ์เช่นนี้

วงจรชีวิตสั้นพร้อมการอัปเดต API บ่อยครั้ง

เราเขียนปลั๊กอินของเราเอง ตัวอย่างเช่น ปลั๊กอินที่มีวิธีการชำระเงินเพิ่มเติมซึ่งไม่ได้อยู่ใน VMManager

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

ไม่สามารถแก้ไขได้

อย่างแม่นยำยิ่งขึ้น เป็นไปได้ แต่ไม่มีประสิทธิภาพอย่างยิ่ง ข้อ จำกัด ใบอนุญาตไม่อนุญาตให้คุณเปลี่ยนแปลงซอร์สโค้ด คุณสามารถเขียนได้เฉพาะปลั๊กอินเท่านั้น ปลั๊กอินสูงสุด - บางรายการเมนู ตัวช่วยสร้างทีละขั้นตอน ระบบ ISP ได้รับการออกแบบมาสำหรับความสามารถรอบด้าน แต่เราต้องการโซลูชันพิเศษ

ดังนั้นการตัดสินใจจึงสุกงอมที่จะเขียนแผงของตัวเอง เราได้กำหนดเป้าหมาย:

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

และเราเริ่มพัฒนา

สถาปัตยกรรมพาเนลใหม่

เรามีทีมพัฒนาแบบพอเพียง ดังนั้นเราจึงเขียนคณะพูดคุยด้วยตัวเอง
งานหลักดำเนินการโดยวิศวกรสามคน - ผู้อำนวยการด้านเทคนิค Sergey เป็นผู้ออกแบบสถาปัตยกรรมและเขียนตัวแทนเซิร์ฟเวอร์ Alexey เรียกเก็บเงินและส่วนหน้าประกอบโดย Artysh ฟรอนต์เอนด์ของเรา

ขั้นตอนที่ 1: ตัวแทนเซิร์ฟเวอร์

ตัวแทนเซิร์ฟเวอร์คือเว็บเซิร์ฟเวอร์หลามที่จัดการไลบรารี libvirtซึ่งจะควบคุม ไฮเปอร์ไวเซอร์ Qemu-kvm.

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

ตามทฤษฎีแล้ว libvirt สามารถควบคุมได้โดยตรงจากการเรียกเก็บเงิน แต่สิ่งนี้ต้องการรหัสเพิ่มเติมมากเกินไป และเราตัดสินใจแยกฟังก์ชันเหล่านี้ระหว่างตัวแทนและการเรียกเก็บเงิน - การเรียกเก็บเงินเพียงแค่ส่งคำขอไปยังตัวแทนผ่าน JSON API

เอเจนต์เป็นสิ่งแรกที่เราทำ เนื่องจากเอเจนต์ไม่ต้องการอินเทอร์เฟซใดๆ และเป็นไปได้ที่จะทดสอบโดยตรงจากคอนโซลเซิร์ฟเวอร์

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

ขั้นตอนที่ 2 การเรียกเก็บเงิน

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

เราเรียกการเรียกเก็บเงินกันเองว่า "แผงควบคุม" ซึ่งไม่ได้มีเพียงเงินและบริการเท่านั้น แต่ยังรวมถึงการจัดการ การสนับสนุนลูกค้า และอื่นๆ อีกมากมาย

หากต้องการเปลี่ยนจากซอฟต์แวร์ระบบ ISPS จำเป็นต้องรักษาฟังก์ชันการทำงานก่อนหน้านี้ไว้อย่างสมบูรณ์สำหรับลูกค้า โอนการดำเนินการทางการเงินทั้งหมดของผู้ใช้จากการเรียกเก็บเงินแบบเก่าไปยังแบบใหม่ ตลอดจนบริการและการเชื่อมต่อทั้งหมดระหว่างกัน เราศึกษาสิ่งที่อยู่ในผลิตภัณฑ์ปัจจุบัน จากนั้นจึงศึกษาแนวทางแก้ไขของคู่แข่ง ซึ่งส่วนใหญ่เป็น DO และ Vultr เราดูข้อเสียและข้อดี รวบรวมความคิดเห็นจากผู้ที่ทำงานกับผลิตภัณฑ์เก่าจากระบบ ISP

การเรียกเก็บเงินใหม่ใช้สองสแต็ค: PHP แบบคลาสสิก, MySQL (และในอนาคตมีแผนที่จะเปลี่ยนเป็น PostgreSQL), Yii2 เป็นเฟรมเวิร์กที่แบ็กเอนด์และ VueJS ที่ด้านหน้า สแต็คทำงานเป็นอิสระจากกัน ได้รับการพัฒนาโดยผู้คนที่แตกต่างกัน และสื่อสารโดยใช้ JSON API สำหรับการพัฒนาแล้วและตอนนี้เราใช้ PHPStorm и เว็บสตอร์ม จาก JetBrains และรักพวกเขาอย่างสุดซึ้ง (เฮ้ พวก!)

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

ขั้นตอนที่ 3 อินเทอร์เฟซ

ISPsystem ให้อภัยและอำลา! ทำไมและเราเขียนแผงควบคุมเซิร์ฟเวอร์ของเราอย่างไรและอย่างไร
อินเทอร์เฟซเป็นผลงานทางความคิดของทีมเรา

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

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

การออกแบบหน้าการเรียกเก็บเงินเป็นแบบแรกที่ปรากฏขึ้น เนื่องจากเราได้สร้างปลั๊กอินการชำระเงินสำหรับระบบ ISP แล้ว

ส่วนหน้า

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

การเชื่อมต่อส่วนหน้ากับส่วนหลัง

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

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

ขั้นตอนที่ 4 แผนการทดสอบและการย้ายข้อมูล

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

จากนั้นเราก็เขียนสคริปต์ง่ายๆ ที่ถ่ายโอนฐานข้อมูลจากการเรียกเก็บเงินเก่าไปยังฐานข้อมูลใหม่

ฉันต้องทดสอบและตรวจสอบทุกอย่างใหม่อีกครั้ง เนื่องจากข้อมูลถูกรวมเข้าเป็นฐานข้อมูลใหม่จากฐานข้อมูลเก่าสามฐานข้อมูล: Billmanager, VMmanager และ IPmanager ของผู้จัดการ บางทีการย้ายข้อมูลการทดสอบอาจเป็นสิ่งที่ยากที่สุดที่เราพบในกระบวนการพัฒนาแผงควบคุมใหม่

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

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

ในสรุป: มันยังมีชีวิตอยู่!

จบด้วยดี

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

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

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

ทำอะไรต่อไป

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

แน่นอน เรายังคงมีการผจญภัยในขณะที่ผลิตภัณฑ์พัฒนาและซับซ้อนมากขึ้น เช่น เมื่อเราเพิ่ม HighLoad

ในบทความหน้า เราจะบอกคุณว่าอัตราค่าไฟฟ้า Hi-CPU เปิดตัวอย่างไร: เกี่ยวกับฮาร์ดแวร์ ซอฟต์แวร์ งานที่เราแก้ไข และสิ่งที่เราทำ

ที่มา: will.com

เพิ่มความคิดเห็น