เมื่อคุณทำงานด้านไอที คุณจะเริ่มสังเกตเห็นว่าระบบมีลักษณะเฉพาะของตัวเอง พวกเขาสามารถยืดหยุ่น เงียบ ประหลาด และเข้มงวดได้ พวกเขาสามารถดึงดูดหรือขับไล่ ไม่ทางใดก็ทางหนึ่ง คุณต้อง "เจรจา" กับพวกเขา วางแผนระหว่าง "หลุมพราง" และสร้างห่วงโซ่ปฏิสัมพันธ์ของพวกเขา
ดังนั้นเราจึงได้รับเกียรติในการสร้างแพลตฟอร์มคลาวด์ และด้วยเหตุนี้ เราจึงต้อง "ชักชวน" ระบบย่อยสองสามระบบให้ทำงานร่วมกับเรา โชคดีที่เรามี "ภาษา API" มือตรง และความกระตือรือร้นอย่างมาก
บทความนี้จะไม่ฮาร์ดคอร์ทางเทคนิค แต่จะอธิบายถึงปัญหาที่เราพบขณะสร้างระบบคลาวด์ ฉันตัดสินใจที่จะอธิบายเส้นทางของเราในรูปแบบของจินตนาการทางเทคนิคเล็กน้อยเกี่ยวกับวิธีการที่เรามองหาภาษากลางที่มีระบบและสิ่งที่เกิดขึ้น
ยินดีต้อนรับสู่แมว
จุดเริ่มต้นของการเดินทาง
ก่อนหน้านี้ ทีมงานของเราได้รับมอบหมายให้เปิดตัวแพลตฟอร์มคลาวด์สำหรับลูกค้าของเรา เรามีการสนับสนุนด้านการจัดการ ทรัพยากร กลุ่มฮาร์ดแวร์ และอิสระในการเลือกเทคโนโลยีเพื่อใช้งานส่วนซอฟต์แวร์ของบริการ
นอกจากนี้ยังมีข้อกำหนดหลายประการ:
- บริการต้องการบัญชีส่วนตัวที่สะดวกสบาย
- แพลตฟอร์มจะต้องรวมเข้ากับระบบการเรียกเก็บเงินที่มีอยู่
- ซอฟต์แวร์และฮาร์ดแวร์: OpenStack + Tungsten Fabric (Open Contrail) ซึ่งวิศวกรของเราได้เรียนรู้ที่จะ “ทำอาหาร” ได้ค่อนข้างดี
เราจะแจ้งให้คุณทราบอีกครั้งเกี่ยวกับวิธีการรวบรวมทีม อินเทอร์เฟซบัญชีส่วนบุคคลได้รับการพัฒนาและการตัดสินใจในการออกแบบ หากชุมชน Habra สนใจ
เครื่องมือที่เราตัดสินใจใช้:
- Python + Flask + Swagger + SQLAlchemy - ชุด Python มาตรฐานที่สมบูรณ์
- Vue.js สำหรับส่วนหน้า;
- เราตัดสินใจโต้ตอบระหว่างส่วนประกอบและบริการโดยใช้ Celery บน AMQP
ฉันจะอธิบายโดยคาดหวังคำถามเกี่ยวกับการเลือก Python ภาษาได้ค้นพบช่องทางเฉพาะในบริษัทของเรา และวัฒนธรรมเล็กๆ ก็ยังได้พัฒนาไปโดยรอบ ดังนั้นจึงมีการตัดสินใจที่จะเริ่มสร้างบริการบนนั้น นอกจากนี้ความรวดเร็วของการพัฒนาในปัญหาดังกล่าวมักจะเป็นตัวชี้ขาด
เอาล่ะ เรามาเริ่มทำความรู้จักกันดีกว่า
บิลเงียบ - การเรียกเก็บเงิน
เรารู้จักผู้ชายคนนี้มานานแล้ว เขามักจะนั่งข้างฉันและนับบางอย่างอย่างเงียบ ๆ บางครั้งเขาส่งต่อคำขอของผู้ใช้มาให้เรา ออกใบแจ้งหนี้ให้กับลูกค้า และบริการที่ได้รับการจัดการ เป็นคนธรรมดาที่ทำงานหนัก จริงอยู่มีปัญหาอยู่ เขาเป็นคนเงียบๆ บางครั้งก็ครุ่นคิดและมักจะคิดอยู่ในใจของตัวเอง
การเรียกเก็บเงินเป็นระบบแรกที่เราพยายามผูกมิตรด้วย และปัญหาแรกที่เราพบคือเมื่อประมวลผลบริการ
ตัวอย่างเช่น เมื่อสร้างหรือลบ งานจะเข้าสู่คิวการเรียกเก็บเงินภายใน ดังนั้นจึงมีการใช้ระบบการทำงานแบบอะซิงโครนัสกับบริการ ในการประมวลผลประเภทบริการของเรา เราจำเป็นต้อง "วาง" งานของเราไว้ในคิวนี้ และที่นี่เราประสบปัญหา: ขาดเอกสาร
เมื่อพิจารณาจากคำอธิบายของซอฟต์แวร์ API ยังคงเป็นไปได้ที่จะแก้ไขปัญหานี้ แต่เราไม่มีเวลาทำวิศวกรรมย้อนกลับ ดังนั้นเราจึงนำตรรกะภายนอกและจัดคิวงานไว้ด้านบนของ RabbitMQ การดำเนินการกับบริการเริ่มต้นโดยลูกค้าจากบัญชีส่วนตัวของเขา กลายเป็น "งาน" ของ Celery ที่แบ็กเอนด์ และดำเนินการในด้านการเรียกเก็บเงินและ OpenStack คื่นฉ่ายทำให้การจัดการงาน จัดระเบียบการทำซ้ำ และตรวจสอบสถานะค่อนข้างสะดวก คุณสามารถอ่านเพิ่มเติมเกี่ยวกับ “ขึ้นฉ่าย” ได้ เช่น .
นอกจากนี้การเรียกเก็บเงินไม่ได้หยุดโครงการที่เงินหมด ในการสื่อสารกับนักพัฒนา เราพบว่าเมื่อคำนวณสถิติ (และเราจำเป็นต้องใช้ตรรกะประเภทนี้ทุกประการ) กฎการหยุดมีความสัมพันธ์กันที่ซับซ้อน แต่โมเดลเหล่านี้ไม่สอดคล้องกับความเป็นจริงของเรา นอกจากนี้เรายังปรับใช้ผ่านงานบน Celery โดยนำตรรกะการจัดการบริการไปไว้ที่ด้านหลัง
ปัญหาทั้งสองข้างต้นทำให้โค้ดบวมเล็กน้อย และในอนาคตเราจะต้องปรับโครงสร้างใหม่เพื่อย้ายตรรกะสำหรับการทำงานกับงานไปไว้ในบริการที่แยกจากกัน นอกจากนี้เรายังจำเป็นต้องจัดเก็บข้อมูลบางอย่างเกี่ยวกับผู้ใช้และบริการของพวกเขาไว้ในตารางของเราเพื่อรองรับตรรกะนี้
ปัญหาอีกประการหนึ่งคือความเงียบ
Billy ตอบกลับคำขอ API บางรายการว่า "ตกลง" อย่างเงียบๆ ตัวอย่างเช่น เมื่อเราชำระเงินตามสัญญาระหว่างการทดสอบ (จะมีรายละเอียดเพิ่มเติมในภายหลัง) คำขอได้รับการดำเนินการอย่างถูกต้องและเราไม่พบข้อผิดพลาดใดๆ
ฉันต้องศึกษาบันทึกในขณะที่ทำงานกับระบบผ่าน UI ปรากฎว่าการเรียกเก็บเงินเองก็ดำเนินการตามคำขอที่คล้ายกัน โดยเปลี่ยนขอบเขตเป็นผู้ใช้เฉพาะ เช่น ผู้ดูแลระบบ โดยส่งผ่านพารามิเตอร์ su
โดยทั่วไป แม้จะมีช่องว่างในเอกสารประกอบและข้อบกพร่องเล็กน้อยของ API แต่ทุกอย่างก็ค่อนข้างดี บันทึกสามารถอ่านได้แม้ภายใต้ภาระงานหนัก หากคุณเข้าใจว่ามีโครงสร้างอย่างไรและควรมองหาอะไร โครงสร้างของฐานข้อมูลดูหรูหราแต่ค่อนข้างสมเหตุสมผลและในบางแง่ก็น่าดึงดูดด้วยซ้ำ
โดยสรุป ปัญหาหลักที่เราพบในขั้นตอนการโต้ตอบนั้นเกี่ยวข้องกับคุณลักษณะการใช้งานของระบบเฉพาะ:
- “คุณสมบัติ” ที่ไม่มีเอกสารซึ่งส่งผลกระทบต่อเราไม่ทางใดก็ทางหนึ่ง
- แหล่งที่มาปิด (การเรียกเก็บเงินเขียนด้วยภาษา C ++) ดังนั้นจึงเป็นไปไม่ได้ที่จะแก้ไขปัญหา 1 ด้วยวิธีอื่นใดนอกเหนือจาก "การลองผิดลองถูก"
โชคดีที่ผลิตภัณฑ์มี API ที่ค่อนข้างกว้างขวาง และเราได้รวมระบบย่อยต่อไปนี้เข้ากับบัญชีส่วนตัวของเรา:
- โมดูลการสนับสนุนด้านเทคนิค - คำขอจากบัญชีส่วนตัวของคุณเป็นแบบ "พร็อกซี" เพื่อเรียกเก็บเงินอย่างโปร่งใสสำหรับลูกค้าบริการ
- โมดูลทางการเงิน - ช่วยให้คุณสามารถออกใบแจ้งหนี้ให้กับลูกค้าปัจจุบัน ตัดค่าใช้จ่าย และสร้างเอกสารการชำระเงิน
- โมดูลควบคุมบริการ - สำหรับสิ่งนี้ เราต้องใช้ตัวจัดการของเราเอง ความสามารถในการขยายของระบบมีบทบาทสำคัญต่อเรา และเราได้ "สอน" Billy เกี่ยวกับบริการรูปแบบใหม่
มันค่อนข้างยุ่งยากนิดหน่อย แต่ไม่ทางใดก็ทางหนึ่ง ฉันคิดว่าบิลลี่กับฉันจะเข้ากันได้
เดินผ่านทุ่งทังสเตน – ผ้าทังสเตน
ทุ่งทังสเตนมีเส้นลวดหลายร้อยเส้นกระจายข้อมูลหลายพันชิ้นผ่านพวกมัน ข้อมูลจะถูกรวบรวมเป็น "แพ็กเก็ต" แยกวิเคราะห์ สร้างเส้นทางที่ซับซ้อนราวกับใช้เวทย์มนตร์
นี่คือโดเมนของระบบที่สองที่เราต้องผูกมิตร - Tungsten Fabric (TF) ซึ่งเดิมคือ OpenContrail หน้าที่ของมันคือการจัดการอุปกรณ์เครือข่ายโดยมอบซอฟต์แวร์ที่เป็นนามธรรมให้กับเราในฐานะผู้ใช้ TF - SDN สรุปตรรกะที่ซับซ้อนของการทำงานกับอุปกรณ์เครือข่าย มีบทความดีๆ เกี่ยวกับเทคโนโลยีมาฝากครับ เช่น .
ระบบถูกรวมเข้ากับ OpenStack (อธิบายไว้ด้านล่าง) ผ่านทางปลั๊กอินนิวตรอน
การโต้ตอบของบริการ OpenStack
เจ้าหน้าที่จากแผนกปฏิบัติการแนะนำเราให้รู้จักกับระบบนี้ เราใช้ API ของระบบเพื่อจัดการสแต็กเครือข่ายของบริการของเรา มันไม่ได้ทำให้เราเกิดปัญหาร้ายแรงหรือความไม่สะดวกใดๆ เลย (ฉันไม่สามารถพูดแทนคนจาก OE ได้) แต่มีการโต้ตอบที่แปลกประหลาดบางประการ
คำสั่งแรกมีลักษณะดังนี้: คำสั่งที่ต้องส่งข้อมูลจำนวนมากไปยังคอนโซลอินสแตนซ์เมื่อเชื่อมต่อผ่าน SSH เพียงแค่ "วางสาย" การเชื่อมต่อ ในขณะที่ทุกอย่างทำงานผ่าน VNC อย่างถูกต้อง
สำหรับผู้ที่ไม่คุ้นเคยกับปัญหามันดูค่อนข้างตลก: ls /root ทำงานได้อย่างถูกต้องในขณะที่ด้านบน "ค้าง" โดยสมบูรณ์ โชคดีที่เราเคยพบปัญหาที่คล้ายกันมาก่อน ตัดสินใจโดยการปรับ MTU บนเส้นทางจากโหนดประมวลผลไปยังเราเตอร์ อย่างไรก็ตาม นี่ไม่ใช่ปัญหาของ TF
ปัญหาต่อไปก็อยู่ใกล้แค่เอื้อม ในช่วงเวลา "ที่สวยงาม" ครั้งหนึ่ง ความมหัศจรรย์ของการกำหนดเส้นทางก็หายไปเช่นนั้น TF หยุดจัดการเส้นทางบนอุปกรณ์แล้ว
เราทำงานร่วมกับ OpenStack จากระดับผู้ดูแลระบบ และหลังจากนั้นก็ย้ายไปยังระดับผู้ใช้ที่ต้องการ ดูเหมือนว่า SDN จะ "จี้" ขอบเขตของผู้ใช้ที่ดำเนินการดังกล่าว ความจริงก็คือบัญชีผู้ดูแลระบบเดียวกันนั้นใช้เพื่อเชื่อมต่อ TF และ OpenStack ในขั้นตอนการเปลี่ยนมาใช้ผู้ใช้ “เวทมนตร์” ก็หายไป มีการตัดสินใจสร้างบัญชีแยกต่างหากเพื่อทำงานกับระบบ สิ่งนี้ทำให้เราสามารถทำงานได้โดยไม่ทำลายฟังก์ชันการรวมระบบ
ซิลิคอนไลฟ์ฟอร์ม - OpenStack
สิ่งมีชีวิตซิลิโคนรูปร่างแปลกประหลาดอาศัยอยู่ใกล้กับทุ่งทังสเตน สิ่งสำคัญที่สุดคือดูเหมือนเด็กโตที่สามารถบดขยี้เราได้ด้วยการแกว่งเพียงครั้งเดียว แต่ไม่มีความก้าวร้าวที่ชัดเจนจากเขา มันไม่ได้ทำให้เกิดความกลัว แต่ขนาดของมันทำให้เกิดความกลัว เช่นเดียวกับความซับซ้อนของสิ่งที่เกิดขึ้นรอบตัว
OpenStack เป็นแกนหลักของแพลตฟอร์มของเรา
OpenStack มีระบบย่อยหลายระบบ ซึ่งปัจจุบันเราใช้ Nova, Glance และ Cinder มากที่สุด แต่ละคนมี API ของตัวเอง Nova รับผิดชอบทรัพยากรการประมวลผลและการสร้างอินสแตนซ์ Cinder รับผิดชอบในการจัดการวอลุ่มและสแน็ปช็อต Glance เป็นบริการรูปภาพที่จัดการเทมเพลต OS และข้อมูลเมตาบนไดรฟ์ข้อมูลเหล่านั้น
แต่ละบริการทำงานในคอนเทนเนอร์ และนายหน้าข้อความคือ “white rabbit” - RabbitMQ
ระบบนี้ทำให้เราเกิดปัญหาที่ไม่คาดคิดที่สุด
และปัญหาแรกก็เกิดขึ้นไม่นานเมื่อเราพยายามเชื่อมต่อโวลุ่มเพิ่มเติมกับเซิร์ฟเวอร์ Cinder API ปฏิเสธที่จะทำงานนี้โดยสิ้นเชิง แม่นยำยิ่งขึ้นหากคุณเชื่อว่า OpenStack การเชื่อมต่อจะถูกสร้างขึ้น แต่ไม่มีอุปกรณ์ดิสก์ในเซิร์ฟเวอร์เสมือน
เราตัดสินใจเลี่ยงและขอให้ดำเนินการแบบเดียวกันจาก Nova API ผลลัพธ์คืออุปกรณ์เชื่อมต่ออย่างถูกต้องและสามารถเข้าถึงได้ภายในเซิร์ฟเวอร์ ดูเหมือนว่าปัญหาจะเกิดขึ้นเมื่อ Block-Storage ไม่ตอบสนองต่อ Cinder
ความยากลำบากอีกประการหนึ่งรอเราอยู่เมื่อทำงานกับดิสก์ ไม่สามารถตัดการเชื่อมต่อไดรฟ์ข้อมูลระบบจากเซิร์ฟเวอร์ได้
อีกครั้ง OpenStack เองก็ "สาบาน" ว่ามันได้ทำลายการเชื่อมต่อและตอนนี้คุณสามารถทำงานแยกกันได้อย่างถูกต้อง แต่ API โดยเด็ดขาดไม่ต้องการดำเนินการบนดิสก์
ที่นี่เราตัดสินใจที่จะไม่ต่อสู้เป็นพิเศษ แต่เปลี่ยนมุมมองของเราเกี่ยวกับตรรกะของบริการ หากมีอินสแตนซ์ จะต้องมีวอลุ่มระบบด้วย ดังนั้นผู้ใช้จึงไม่สามารถลบหรือปิดการใช้งาน "ดิสก์" ของระบบโดยไม่ลบ "เซิร์ฟเวอร์"
OpenStack เป็นชุดระบบที่ค่อนข้างซับซ้อนซึ่งมีตรรกะการโต้ตอบและ API ที่หรูหราของตัวเอง เราได้รับความช่วยเหลือจากเอกสารที่มีรายละเอียดพอสมควร และแน่นอนว่าต้องมีการลองผิดลองถูก (เราจะอยู่ตรงไหนถ้าไม่มีมัน)
ทดสอบการทำงาน
เราทำการทดสอบเปิดตัวในเดือนธันวาคมปีที่แล้ว ภารกิจหลักคือการทดสอบโครงการของเราในโหมดการต่อสู้จากด้านเทคนิคและจากฝั่ง UX ผู้ชมได้รับการคัดเลือกและปิดการทดสอบแล้ว อย่างไรก็ตาม เรายังมีตัวเลือกในการขอเข้าถึงการทดสอบบนเว็บไซต์ของเราอีกด้วย
แน่นอนว่าการทดสอบนั้นไม่ได้ปราศจากช่วงเวลาที่สนุกสนาน เพราะนี่คือจุดเริ่มต้นของการผจญภัยของเรา
ประการแรก เราประเมินความสนใจในโครงการนี้ค่อนข้างไม่ถูกต้อง และต้องเพิ่มโหนดประมวลผลอย่างรวดเร็วในระหว่างการทดสอบ เป็นกรณีทั่วไปสำหรับคลัสเตอร์ แต่ก็มีความแตกต่างบางประการเช่นกัน เอกสารประกอบสำหรับเวอร์ชันเฉพาะของ TF ระบุเวอร์ชันเฉพาะของเคอร์เนลที่ทดสอบการทำงานกับ vRouter เราตัดสินใจเปิดตัวโหนดที่มีเคอร์เนลที่ใหม่กว่า ส่งผลให้ TF ไม่ได้รับเส้นทางจากโหนด ฉันต้องม้วนเมล็ดกลับอย่างเร่งด่วน
ความอยากรู้อีกประการหนึ่งเกี่ยวข้องกับการทำงานของปุ่ม "เปลี่ยนรหัสผ่าน" ในบัญชีส่วนตัวของคุณ
เราตัดสินใจใช้ JWT เพื่อจัดระเบียบการเข้าถึงบัญชีส่วนตัวของเราเพื่อไม่ให้ทำงานกับเซสชัน เนื่องจากระบบมีความหลากหลายและกระจัดกระจาย เราจึงจัดการโทเค็นของเราเอง โดยเราจะ "รวม" เซสชันจากการเรียกเก็บเงินและโทเค็นจาก OpenStack เมื่อเปลี่ยนรหัสผ่าน โทเค็นจะ "เสีย" แน่นอน เนื่องจากข้อมูลผู้ใช้ไม่ถูกต้องอีกต่อไปและจำเป็นต้องออกใหม่
เรามองไม่เห็นจุดนี้ และไม่มีทรัพยากรเพียงพอที่จะทำงานชิ้นนี้ให้เสร็จอย่างรวดเร็ว เราต้องตัดฟังก์ชันการทำงานออกก่อนเริ่มการทดสอบ
ขณะนี้เราออกจากระบบผู้ใช้หากรหัสผ่านมีการเปลี่ยนแปลง
แม้จะมีความแตกต่างเหล่านี้ แต่การทดสอบก็เป็นไปด้วยดี ในอีกไม่กี่สัปดาห์ คนประมาณ 300 คนก็แวะมา เราสามารถดูผลิตภัณฑ์ผ่านสายตาของผู้ใช้ ทดสอบการใช้งานจริง และรวบรวมความคิดเห็นคุณภาพสูง
จะยังคง
สำหรับพวกเราหลายๆ คน นี่เป็นโครงการแรกของขนาดนี้ เราได้เรียนรู้บทเรียนอันมีค่ามากมายเกี่ยวกับวิธีการทำงานเป็นทีมและการตัดสินใจด้านสถาปัตยกรรมและการออกแบบ วิธีบูรณาการระบบที่ซับซ้อนเข้ากับทรัพยากรเพียงเล็กน้อยและนำไปใช้จริง
แน่นอนว่ามีบางอย่างที่ต้องทำทั้งในแง่ของโค้ดและอินเทอร์เฟซของการรวมระบบ โครงการนี้ยังค่อนข้างใหม่ แต่เราเต็มไปด้วยความทะเยอทะยานที่จะขยายให้เป็นบริการที่เชื่อถือได้และสะดวกสบาย
เราก็สามารถโน้มน้าวระบบได้แล้ว บิลจัดการการนับ การเรียกเก็บเงิน และคำขอของผู้ใช้ในตู้เสื้อผ้าของเขาตามหน้าที่ “ความมหัศจรรย์” ของสนามทังสเตนทำให้เรามีการสื่อสารที่มั่นคง และมีเพียง OpenStack เท่านั้นที่บางครั้งก็ไม่แน่นอน โดยตะโกนประมาณว่า “'WSREP ยังไม่ได้เตรียมโหนดสำหรับการใช้งานแอปพลิเคชัน” แต่นั่นเป็นเรื่องราวที่แตกต่างอย่างสิ้นเชิง...
เราเพิ่งเปิดตัวบริการ
คุณสามารถค้นหารายละเอียดทั้งหมดได้จากเรา .
ทีมพัฒนา CLO
ลิงค์ที่มีประโยชน์
OpenStack
ผ้าทังสเตน
ที่มา: will.com