บทความนี้ประกอบด้วยรูปแบบทั่วไปบางประการเพื่อช่วยให้วิศวกรทำงานกับบริการขนาดใหญ่ที่ผู้ใช้หลายล้านคนเข้าถึงได้
จากประสบการณ์ของผู้เขียน นี่ไม่ใช่รายการที่ครบถ้วนสมบูรณ์ แต่แท้จริงแล้ว มีประสิทธิภาพ คำแนะนำ เอาล่ะ มาเริ่มกันเลย
แปลด้วยการสนับสนุน .
ระดับแรก
มาตรการที่แสดงด้านล่างนี้ค่อนข้างง่ายในการดำเนินการ แต่มีผลกระทบสูง หากคุณยังไม่เคยลองใช้มาก่อน คุณจะประหลาดใจกับการปรับปรุงที่สำคัญ
โครงสร้างพื้นฐานเป็นรหัส
ส่วนแรกของคำแนะนำคือการใช้โครงสร้างพื้นฐานเป็นโค้ด ซึ่งหมายความว่าคุณต้องมีวิธีทางโปรแกรมในการปรับใช้โครงสร้างพื้นฐานทั้งหมด ฟังดูซับซ้อน แต่จริงๆ แล้วเรากำลังพูดถึงโค้ดต่อไปนี้:
การปรับใช้เครื่องเสมือน 100 เครื่อง
- กับอูบุนตู
- RAM คนละ 2 GB
- พวกเขาจะมีรหัสต่อไปนี้
- ด้วยพารามิเตอร์เหล่านี้
คุณสามารถติดตามการเปลี่ยนแปลงในโครงสร้างพื้นฐานของคุณและเปลี่ยนกลับเป็นการเปลี่ยนแปลงได้อย่างรวดเร็วโดยใช้การควบคุมเวอร์ชัน
ความทันสมัยในตัวฉันบอกว่าคุณสามารถใช้ Kubernetes/Docker เพื่อทำทั้งหมดที่กล่าวมาข้างต้นได้ และเขาก็พูดถูก
นอกจากนี้คุณยังสามารถจัดเตรียมการทำงานอัตโนมัติโดยใช้ Chef, Puppet หรือ Terraform
การบูรณาการและการส่งมอบอย่างต่อเนื่อง
ในการสร้างบริการที่ปรับขนาดได้ สิ่งสำคัญคือต้องมีไปป์ไลน์การสร้างและทดสอบสำหรับคำขอดึงแต่ละรายการ แม้ว่าการทดสอบจะง่ายมาก แต่อย่างน้อยก็จะทำให้แน่ใจได้ว่าโค้ดที่คุณปรับใช้นั้นคอมไพล์แล้ว
แต่ละครั้งในขั้นตอนนี้ คุณจะตอบคำถาม: แอสเซมบลีของฉันจะคอมไพล์และผ่านการทดสอบหรือไม่ นี่อาจดูเหมือนเป็นแถบต่ำ แต่ช่วยแก้ปัญหาได้มากมาย
ไม่มีอะไรสวยงามไปกว่าการได้เห็นเห็บเหล่านี้
สำหรับเทคโนโลยีนี้ คุณสามารถประเมิน Github, CircleCI หรือ Jenkins ได้
โหลดบาลานเซอร์
ดังนั้นเราจึงต้องการเรียกใช้โหลดบาลานเซอร์เพื่อเปลี่ยนเส้นทางการรับส่งข้อมูลและให้แน่ใจว่าโหลดเท่ากันบนโหนดทั้งหมด หรือบริการจะดำเนินต่อไปในกรณีที่เกิดความล้มเหลว:
โหลดบาลานเซอร์มักจะกระจายการรับส่งข้อมูลได้ดี แนวทางปฏิบัติที่ดีที่สุดคือการสมดุลมากเกินไปเพื่อที่คุณจะได้ไม่มีจุดล้มเหลวแม้แต่จุดเดียว
โดยทั่วไปแล้ว โหลดบาลานเซอร์จะได้รับการกำหนดค่าในระบบคลาวด์ที่คุณใช้
RayID, ID ความสัมพันธ์หรือ UUID สำหรับคำขอ
คุณเคยพบข้อผิดพลาดของแอปพลิเคชันโดยมีข้อความเช่นนี้: "บางอย่างผิดพลาด. บันทึกรหัสนี้และส่งไปที่ทีมสนับสนุนของเรา"?
ตัวระบุที่ไม่ซ้ำกัน ID ความสัมพันธ์ RayID หรือรูปแบบใดๆ เป็นตัวระบุเฉพาะที่ช่วยให้คุณสามารถติดตามคำขอตลอดวงจรการใช้งาน ซึ่งจะทำให้คุณสามารถติดตามเส้นทางคำขอทั้งหมดในบันทึกได้
ผู้ใช้ส่งคำขอไปยังระบบ A จากนั้นผู้ติดต่อ A B ซึ่งติดต่อกับ C จะเก็บไว้ใน X จากนั้นคำขอจะถูกส่งกลับไปยัง A
หากคุณต้องเชื่อมต่อกับเครื่องเสมือนจากระยะไกลและพยายามติดตามเส้นทางคำขอ (และเชื่อมโยงด้วยตนเองว่ามีการโทรใดบ้าง) คุณจะเป็นบ้า การมีตัวระบุที่ไม่ซ้ำใครทำให้ชีวิตง่ายขึ้นมาก นี่เป็นหนึ่งในสิ่งที่ง่ายที่สุดที่คุณสามารถทำได้เพื่อประหยัดเวลาในขณะที่บริการของคุณเติบโตขึ้น
ระดับกลาง
คำแนะนำที่นี่ซับซ้อนกว่าคำแนะนำก่อนหน้านี้ แต่เครื่องมือที่เหมาะสมจะทำให้งานง่ายขึ้น โดยให้ผลตอบแทนจากการลงทุนแม้แต่กับบริษัทขนาดเล็กและขนาดกลาง
การบันทึกแบบรวมศูนย์
ยินดีด้วย! คุณได้ปรับใช้เครื่องเสมือน 100 เครื่อง วันรุ่งขึ้น CEO จะมาร้องเรียนเกี่ยวกับข้อผิดพลาดที่เขาได้รับขณะทดสอบบริการ รายงานรหัสที่เกี่ยวข้องที่เราพูดถึงข้างต้น แต่คุณจะต้องตรวจสอบบันทึกของเครื่อง 100 เครื่องเพื่อค้นหาเครื่องที่ทำให้เกิดข้อขัดข้อง และจะต้องพบก่อนการนำเสนอในวันพรุ่งนี้
แม้ว่านี่จะดูเหมือนเป็นการผจญภัยที่สนุกสนาน แต่ทางที่ดีที่สุดคือต้องแน่ใจว่าคุณสามารถค้นหานิตยสารทั้งหมดได้ในที่เดียว ฉันแก้ไขปัญหาการรวมศูนย์บันทึกโดยใช้ฟังก์ชันในตัวของสแต็ก ELK: รองรับการรวบรวมบันทึกที่ค้นหาได้ นี่จะช่วยแก้ปัญหาในการหาวารสารเฉพาะได้จริงๆ เป็นโบนัส คุณสามารถสร้างแผนภูมิและสิ่งสนุก ๆ เช่นนั้นได้
ฟังก์ชั่นสแต็ค ELK
ตัวแทนตรวจสอบ
เมื่อบริการของคุณเริ่มทำงานแล้ว คุณต้องตรวจสอบให้แน่ใจว่าบริการทำงานได้อย่างราบรื่น วิธีที่ดีที่สุดในการทำเช่นนี้คือเรียกใช้หลายรายการ ตัวแทนซึ่งทำงานแบบขนานและตรวจสอบว่าทำงานและดำเนินการขั้นพื้นฐานหรือไม่
ณ จุดนี้คุณตรวจสอบสิ่งนั้น โครงสร้างการวิ่งรู้สึกดีและทำงานได้ดี.
สำหรับโปรเจ็กต์ขนาดเล็กถึงขนาดกลาง ฉันขอแนะนำ Postman สำหรับการตรวจสอบและจัดทำเอกสาร API แต่โดยทั่วไป คุณเพียงต้องการให้แน่ใจว่าคุณมีวิธีที่จะทราบเมื่อไฟฟ้าขัดข้องเกิดขึ้น และได้รับการแจ้งเตือนอย่างทันท่วงที
การปรับขนาดอัตโนมัติขึ้นอยู่กับโหลด
มันง่ายมาก หากคุณมีคำขอบริการ VM และมีการใช้หน่วยความจำใกล้ถึง 80% คุณสามารถเพิ่มทรัพยากรหรือเพิ่ม VM ให้กับคลัสเตอร์ได้ การดำเนินการอัตโนมัติของการดำเนินการเหล่านี้เหมาะอย่างยิ่งสำหรับการเปลี่ยนแปลงพลังงานแบบยืดหยุ่นภายใต้โหลด แต่คุณควรระมัดระวังเกี่ยวกับจำนวนเงินที่คุณใช้และกำหนดวงเงินที่สมเหตุสมผลเสมอ
ด้วยบริการคลาวด์ส่วนใหญ่ คุณสามารถกำหนดค่าให้ปรับขนาดอัตโนมัติโดยใช้เซิร์ฟเวอร์จำนวนมากขึ้นหรือเซิร์ฟเวอร์ที่มีประสิทธิภาพมากขึ้นได้
ระบบการทดลอง
วิธีที่ดีในการเปิดตัวการอัปเดตอย่างปลอดภัยคือการทดสอบบางอย่างกับผู้ใช้ 1% เป็นเวลาหนึ่งชั่วโมง แน่นอนว่าคุณได้เห็นกลไกดังกล่าวในการดำเนินการแล้ว ตัวอย่างเช่น Facebook แสดงบางส่วนของผู้ชมด้วยสีที่แตกต่างกันหรือเปลี่ยนขนาดตัวอักษรเพื่อดูว่าผู้ใช้รับรู้ถึงการเปลี่ยนแปลงอย่างไร สิ่งนี้เรียกว่าการทดสอบ A/B
แม้แต่การเปิดตัวคุณลักษณะใหม่ก็สามารถเริ่มต้นเป็นการทดสอบแล้วจึงกำหนดวิธีการเผยแพร่ได้ คุณยังได้รับความสามารถในการ "จดจำ" หรือเปลี่ยนการกำหนดค่าได้ทันทีตามฟังก์ชันที่ทำให้บริการของคุณเสื่อมถอย
ระดับสูง
ต่อไปนี้เป็นเคล็ดลับที่ค่อนข้างปฏิบัติได้ยาก คุณอาจต้องการทรัพยากรเพิ่มขึ้นอีกเล็กน้อย ดังนั้นบริษัทขนาดเล็กหรือขนาดกลางจะประสบปัญหาในการจัดการเรื่องนี้
การปรับใช้สีน้ำเงิน-เขียว
นี่คือสิ่งที่ฉันเรียกว่าวิธีการแฉ "Erlang" Erlang ถูกนำมาใช้กันอย่างแพร่หลายเมื่อบริษัทโทรศัพท์ปรากฏตัวขึ้น ซอฟต์สวิตช์เริ่มถูกนำมาใช้เพื่อกำหนดเส้นทางการโทร วัตถุประสงค์หลักของซอฟต์แวร์บนสวิตช์เหล่านี้คือการไม่วางสายระหว่างการอัพเกรดระบบ Erlang มีวิธีที่ดีในการโหลดโมดูลใหม่โดยไม่ทำให้โมดูลก่อนหน้าเสียหาย
ขั้นตอนนี้ขึ้นอยู่กับการมีอยู่ของโหลดบาลานเซอร์ สมมติว่าคุณมีซอฟต์แวร์เวอร์ชัน N แล้วคุณต้องการปรับใช้เวอร์ชัน N+1
คุณ เราทำได้ เพียงหยุดบริการและเปิดตัวเวอร์ชันถัดไปตามเวลาที่เหมาะกับผู้ใช้ของคุณและหยุดทำงานชั่วคราว แต่สมมติว่าคุณมี จริงๆ เงื่อนไข SLA ที่เข้มงวด ดังนั้น SLA 99,99% หมายความว่าคุณสามารถออฟไลน์ได้ เท่านั้น ภายใน 52 นาทีต่อปี
หากคุณต้องการบรรลุตัวบ่งชี้ดังกล่าวจริงๆ คุณต้องปรับใช้สองรายการพร้อมกัน:
- อันที่อยู่ตอนนี้ (N);
- เวอร์ชันถัดไป (N+1)
คุณบอกให้โหลดบาลานเซอร์เปลี่ยนเส้นทางเปอร์เซ็นต์การรับส่งข้อมูลไปยังเวอร์ชันใหม่ (N+1) ในขณะที่คุณตรวจสอบการถดถอยอย่างจริงจัง
ที่นี่เรามีการปรับใช้ N สีเขียวที่ทำงานได้ดี เรากำลังพยายามย้ายไปยังเวอร์ชันถัดไปของการปรับใช้นี้
ก่อนอื่น เราจะส่งการทดสอบเล็กๆ น้อยๆ เพื่อดูว่าการปรับใช้ N+1 ของเราทำงานกับปริมาณการรับส่งข้อมูลเพียงเล็กน้อยหรือไม่:
สุดท้ายนี้ เรามีชุดการตรวจสอบอัตโนมัติซึ่งในที่สุดเราจะดำเนินการจนกว่าการปรับใช้งานจะเสร็จสมบูรณ์ ถ้าคุณ มากมาก ระวัง คุณยังสามารถบันทึกการปรับใช้ N ของคุณตลอดไปเพื่อการย้อนกลับอย่างรวดเร็วในกรณีที่การถดถอยไม่ดี:
หากคุณต้องการไปยังระดับที่สูงขึ้นไปอีก ให้ปล่อยให้ทุกอย่างในการปรับใช้สีน้ำเงิน-เขียวทำงานโดยอัตโนมัติ
การตรวจจับความผิดปกติและการบรรเทาผลกระทบอัตโนมัติ
เนื่องจากคุณมีการบันทึกแบบรวมศูนย์และการรวบรวมบันทึกที่ดี คุณจึงสามารถกำหนดเป้าหมายที่สูงขึ้นได้แล้ว ตัวอย่างเช่น คาดการณ์ความล้มเหลวในเชิงรุก ฟังก์ชั่นต่างๆ จะถูกติดตามบนจอภาพและในบันทึก รวมถึงไดอะแกรมต่างๆ ที่ถูกสร้างขึ้น และคุณสามารถคาดการณ์ได้ล่วงหน้าว่าจะเกิดอะไรขึ้น:
เมื่อตรวจพบความผิดปกติ คุณจะเริ่มตรวจสอบเบาะแสบางส่วนที่บริการมอบให้ ตัวอย่างเช่น การเพิ่มขึ้นอย่างรวดเร็วของโหลด CPU อาจบ่งชี้ว่าฮาร์ดไดรฟ์ทำงานล้มเหลว ในขณะที่คำขอที่เพิ่มขึ้นอย่างรวดเร็วอาจบ่งชี้ว่าคุณจำเป็นต้องขยายขนาด ข้อมูลทางสถิติประเภทนี้ช่วยให้คุณสามารถให้บริการเชิงรุกได้
ด้วยข้อมูลเชิงลึกเหล่านี้ คุณสามารถปรับขนาดในทุกมิติและเปลี่ยนแปลงคุณลักษณะของเครื่อง ฐานข้อมูล การเชื่อมต่อ และทรัพยากรอื่นๆ ได้ในเชิงรุกและเชิงโต้ตอบ
Вотивсё!
รายการลำดับความสำคัญนี้จะช่วยคุณประหยัดปัญหาได้มากหากคุณกำลังเพิ่มบริการคลาวด์
ผู้เขียนบทความต้นฉบับขอเชิญผู้อ่านแสดงความคิดเห็นและทำการเปลี่ยนแปลง บทความนี้เผยแพร่ในรูปแบบโอเพ่นซอร์ส ดึงคำขอโดยผู้เขียน .
มีอะไรให้อ่านอีกในหัวข้อ:
ที่มา: will.com