สวัสดี! ฉันชื่อ Vadim Madison ฉันเป็นผู้นำการพัฒนา Avito System Platform มีการกล่าวมากกว่าหนึ่งครั้งว่าเราในบริษัทกำลังย้ายจากสถาปัตยกรรมเสาหินไปสู่ไมโครเซอร์วิสอย่างไร ถึงเวลาแบ่งปันวิธีที่เราเปลี่ยนแปลงโครงสร้างพื้นฐานของเราเพื่อรับประโยชน์สูงสุดจากไมโครเซอร์วิส และป้องกันตัวเราเองจากการหลงทางในไมโครเซอร์วิสเหล่านั้น PaaS ช่วยเราได้อย่างไร วิธีที่เราใช้ทำให้การปรับใช้ง่ายขึ้นและลดการสร้างไมโครเซอร์วิสได้ในคลิกเดียว โปรดอ่านต่อ ไม่ใช่ทุกสิ่งที่ฉันเขียนถึงด้านล่างนี้จะถูกนำมาใช้อย่างสมบูรณ์ใน Avito บางส่วนเป็นเพียงวิธีที่เราพัฒนาแพลตฟอร์มของเรา

(และในตอนท้ายของบทความนี้ ผมจะพูดถึงโอกาสในการเข้าร่วมสัมมนาสามวันจากผู้เชี่ยวชาญด้านสถาปัตยกรรมไมโครเซอร์วิส Chris Richardson)

เรามาถึงไมโครเซอร์วิสได้อย่างไร

Avito เป็นหนึ่งในเว็บไซต์ลับที่ใหญ่ที่สุดในโลก โดยมีการเผยแพร่โฆษณาใหม่มากกว่า 15 ล้านรายการต่อวัน แบ็กเอนด์ของเรายอมรับคำขอมากกว่า 20 คำขอต่อวินาที ปัจจุบันเรามีไมโครเซอร์วิสหลายร้อยรายการ

เราได้สร้างสถาปัตยกรรมไมโครเซอร์วิสมาหลายปีแล้ว เป็นอย่างไร - เพื่อนร่วมงานของเราโดยละเอียด บอก ที่ส่วนของเราที่ RIT++ 2017 ที่ CodeFest 2017 (ดู. วีดีโอ) Sergey Orlov และ Mikhail Prokopchuk อธิบายรายละเอียดว่าทำไมเราจึงต้องเปลี่ยนไปใช้ไมโครเซอร์วิส และ Kubernetes มีบทบาทอย่างไรที่นี่ ตอนนี้เรากำลังทำทุกอย่างเพื่อลดต้นทุนการปรับขนาดที่มีอยู่ในสถาปัตยกรรมดังกล่าวให้เหลือน้อยที่สุด

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

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

วิธีเอาชนะยุค “ไมโครเซอร์วิสแฟรกเมนต์”

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

นอกจากนี้ เพื่อให้สถาปัตยกรรมไมโครเซอร์วิสมีประสิทธิภาพ จำเป็นต้องสร้างกระบวนการต่างๆ มากมาย กล่าวคือ:

• การทำไม้;
• ขอติดตาม (เยเกอร์);
• การรวมข้อผิดพลาด (ยาม);
• สถานะ ข้อความ เหตุการณ์จาก Kubernetes (การประมวลผลสตรีมเหตุการณ์)
• ขีดจำกัดการแข่งขัน / เซอร์กิตเบรกเกอร์ (คุณสามารถใช้ Hystrix ได้);
• การควบคุมการเชื่อมต่อบริการ (เราใช้ Netramesh)
• การตรวจสอบ (Grafana);
• การชุมนุม (TeamCity);
• การสื่อสารและการแจ้งเตือน (Slack, อีเมล);
• การติดตามงาน; (จิรา)
• จัดทำเอกสารต่างๆ

เพื่อให้แน่ใจว่าระบบจะไม่สูญเสียความสมบูรณ์และยังคงมีประสิทธิภาพเมื่อมีการขยายขนาด เราได้คิดใหม่เกี่ยวกับการจัดองค์กรของไมโครเซอร์วิสใน Avito

เราจัดการไมโครเซอร์วิสอย่างไร

ความช่วยเหลือต่อไปนี้ในการใช้ "นโยบายปาร์ตี้" แบบครบวงจรในไมโครเซอร์วิส Avito จำนวนมาก:

• การแบ่งโครงสร้างพื้นฐานออกเป็นชั้น ๆ
• แนวคิดแพลตฟอร์มเป็นบริการ (PaaS)
• ตรวจสอบทุกสิ่งที่เกิดขึ้นกับไมโครเซอร์วิส

ชั้นนามธรรมของโครงสร้างพื้นฐานประกอบด้วยสามชั้น เริ่มจากบนลงล่างกัน

A. Top - ตาข่ายบริการ ในตอนแรกเราลองใช้ Istio แต่ปรากฏว่าใช้ทรัพยากรมากเกินไป ซึ่งแพงเกินไปสำหรับปริมาณของเรา ดังนั้นวิศวกรอาวุโสในทีมสถาปัตยกรรม Alexander Lukyanchenko จึงได้พัฒนาโซลูชันของเขาเอง - เนตราเมช (มีให้ใน Open Source) ซึ่งปัจจุบันเราใช้ในการผลิตและใช้ทรัพยากรน้อยกว่า Istio หลายเท่า (แต่ไม่ได้ทำทุกอย่างที่ Istio สามารถอวดได้)
B. ปานกลาง - Kubernetes เราปรับใช้และดำเนินการไมโครเซอร์วิสกับมัน
C. ด้านล่าง - โลหะเปลือย เราไม่ได้ใช้คลาวด์หรือสิ่งต่าง ๆ เช่น OpenStack แต่อาศัย Bare Metal ทั้งหมด

เลเยอร์ทั้งหมดถูกรวมเข้าด้วยกันโดย PaaS และแพลตฟอร์มนี้ก็ประกอบด้วยสามส่วน

I. เครื่องกำเนิดไฟฟ้าควบคุมผ่านยูทิลิตี้ CLI เธอคือผู้ที่ช่วยนักพัฒนาสร้างไมโครเซอร์วิสด้วยวิธีที่ถูกต้องและใช้ความพยายามน้อยที่สุด

ครั้งที่สอง นักสะสมรวม พร้อมการควบคุมเครื่องมือทั้งหมดผ่านแดชบอร์ดทั่วไป

สาม. พื้นที่จัดเก็บ. เชื่อมต่อกับตัวกำหนดเวลาที่จะตั้งค่าทริกเกอร์สำหรับการดำเนินการที่สำคัญโดยอัตโนมัติ ด้วยระบบดังกล่าว จึงไม่พลาดงานใดงานหนึ่งเพียงเพราะมีคนลืมตั้งค่างานใน Jira เราใช้เครื่องมือภายในที่เรียกว่า Atlas สำหรับสิ่งนี้

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

ไปป์ไลน์การพัฒนาไมโครเซอร์วิสมาตรฐานทำงานอย่างไร

โดยทั่วไปแล้ว ห่วงโซ่การสร้างไมโครเซอร์วิสจะมีลักษณะดังนี้:

CLI-push → การรวมอย่างต่อเนื่อง → อบ → ปรับใช้ → การทดสอบประดิษฐ์ → การทดสอบ Canary → การทดสอบการบีบ → การผลิต → การบำรุงรักษา

มาดูกันตามลำดับนี้

CLI-ผลักดัน

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

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

— สร้างบริการตามเทมเพลต — ทีละขั้นตอน ในโหมด “ตัวช่วยสร้าง” เรามีเทมเพลตสำหรับภาษาการเขียนโปรแกรมหลักในแบ็กเอนด์ Avito: PHP, Golang และ Python

- ทีละคำสั่งจะปรับใช้สภาพแวดล้อมสำหรับการพัฒนาท้องถิ่นบนเครื่องเฉพาะ - เปิดตัว Minikube แผนภูมิ Helm จะถูกสร้างขึ้นและเปิดใช้งานโดยอัตโนมัติใน kubernetes ในพื้นที่

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

— มันทำการประกอบแบบสดด้วยตัวมันเอง สมมติว่านักพัฒนาแก้ไขบางสิ่งในไมโครเซอร์วิสผ่าน IDE ของเขา ยูทิลิตี้เห็นการเปลี่ยนแปลงในระบบไฟล์และสร้างแอปพลิเคชันใหม่ (สำหรับ Golang) และรีสตาร์ทตามนั้น สำหรับ PHP เราเพียงส่งต่อไดเร็กทอรีภายในคิวบ์ จากนั้นระบบจะโหลดการรีโหลดแบบสด "อัตโนมัติ"

— สร้างการทดสอบอัตโนมัติ ในรูปแบบช่องว่างแต่ค่อนข้างเหมาะกับการใช้งาน

• การใช้งานไมโครเซอร์วิส.

การปรับใช้ไมโครเซอร์วิสเคยเป็นงานที่น่าเบื่อสำหรับเรา จำเป็นต้องมีสิ่งต่อไปนี้:

I. ด็อคเกอร์ไฟล์.

ครั้งที่สอง การกำหนดค่า
สาม. แผนภูมิหางเสือ ซึ่งตัวมันเองยุ่งยากและประกอบด้วย:

— แผนภูมิเอง
— แม่แบบ;
— ค่าเฉพาะโดยคำนึงถึงสภาพแวดล้อมที่แตกต่างกัน

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

ใช่ และใน app.toml เองก็ไม่มีอะไรให้ทำแม้แต่นาทีเดียว เราระบุตำแหน่งและจำนวนสำเนาของบริการที่จะเพิ่ม (บนเซิร์ฟเวอร์ dev, ในการแสดงชั่วคราว, ในการใช้งานจริง) และระบุการขึ้นต่อกันของบริการ สังเกตเส้นขนาด = "เล็ก" ในบล็อก [เครื่องยนต์] นี่คือขีดจำกัดที่จะจัดสรรให้กับบริการผ่าน Kubernetes

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

• การตรวจสอบขั้นพื้นฐาน การตรวจสอบดังกล่าวยังเป็นแบบอัตโนมัติอีกด้วย
จำเป็นต้องติดตาม:
— มี Dockerfile หรือไม่;
— มี app.toml ไหม;
- มีเอกสารให้ไหม?
— การพึ่งพาอาศัยกันเป็นลำดับหรือไม่?
— มีการตั้งค่ากฎการแจ้งเตือนหรือไม่
จนถึงจุดสุดท้าย: เจ้าของบริการเองเป็นผู้กำหนดว่าเมตริกผลิตภัณฑ์ใดที่จะตรวจสอบ

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

I. คำอธิบายโดยย่อของบริการ. ประโยคเล็กๆ น้อยๆ เกี่ยวกับสิ่งที่มันทำและเหตุใดจึงจำเป็น

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

สาม. รันบุ๊ก. คำแนะนำสั้นๆ เกี่ยวกับการเริ่มบริการและความซับซ้อนในการจัดการ

IV. คำถามที่พบบ่อยซึ่งจะเป็นการดีที่จะคาดการณ์ถึงปัญหาที่เพื่อนร่วมงานของคุณอาจพบเมื่อทำงานกับบริการ

V. คำอธิบายของตำแหน่งข้อมูลสำหรับ API. หากจู่ๆ คุณไม่ระบุจุดหมายปลายทาง เพื่อนร่วมงานที่มีไมโครเซอร์วิสเกี่ยวข้องกับคุณจะต้องจ่ายเงินให้แน่นอน ตอนนี้เราใช้ Swagger และโซลูชันของเราเรียกว่า Brief สำหรับสิ่งนี้

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

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

สุดท้ายนี้ การตรวจสอบเอกสารประกอบคล้ายกับการตรวจสอบโค้ดถือเป็นแนวปฏิบัติที่ดี

การบูรณาการอย่างต่อเนื่อง

• กำลังเตรียมที่เก็บข้อมูล
• การสร้างไปป์ไลน์ใน TeamCity
• กำหนดสิทธิ.
• ค้นหาเจ้าของบริการ มีรูปแบบไฮบริดอยู่ที่นี่ - การทำเครื่องหมายด้วยตนเองและระบบอัตโนมัติขั้นต่ำจาก PaaS โครงการอัตโนมัติโดยสมบูรณ์จะล้มเหลวเมื่อมีการโอนบริการเพื่อสนับสนุนทีมพัฒนาอื่น หรือ ตัวอย่างเช่น หากนักพัฒนาบริการลาออก
• การลงทะเบียนบริการใน Atlas (ดูด้านบน). กับเจ้าของและผู้พึ่งพาทั้งหมด
• การตรวจสอบการโยกย้าย เราตรวจสอบว่ามีสิ่งใดที่อาจเป็นอันตรายหรือไม่ ตัวอย่างเช่น หนึ่งในนั้นจะมีตารางแก้ไขหรืออย่างอื่นปรากฏขึ้นซึ่งสามารถทำลายความเข้ากันได้ของสคีมาข้อมูลระหว่างบริการเวอร์ชันต่างๆ จากนั้นการโยกย้ายจะไม่ดำเนินการ แต่อยู่ในการสมัครสมาชิก - PaaS จะต้องส่งสัญญาณให้เจ้าของบริการเมื่อใช้งานได้อย่างปลอดภัย

อบ

ขั้นต่อไปคือบริการบรรจุภัณฑ์ก่อนการใช้งาน

• การสร้างแอปพลิเคชัน ตามแบบคลาสสิก - ในรูปนักเทียบท่า
• การสร้างแผนภูมิ Helm สำหรับตัวบริการและทรัพยากรที่เกี่ยวข้อง รวมถึงฐานข้อมูลและแคช สร้างขึ้นโดยอัตโนมัติตามการกำหนดค่า app.toml ที่สร้างขึ้นในขั้นตอนการกด CLI
• การสร้างตั๋วสำหรับผู้ดูแลระบบเพื่อเปิดพอร์ต (เมื่อจำเป็น)
• รันการทดสอบหน่วยและการคำนวณการครอบคลุมโค้ด. หากการครอบคลุมโค้ดต่ำกว่าเกณฑ์ที่ระบุ เป็นไปได้มากว่าบริการจะไม่ไปต่อ - เพื่อการปรับใช้ หากใกล้จะยอมรับได้ บริการจะได้รับค่าสัมประสิทธิ์ "การมองในแง่ร้าย" จากนั้นหากไม่มีการปรับปรุงตัวบ่งชี้เมื่อเวลาผ่านไป นักพัฒนาจะได้รับการแจ้งเตือนว่าไม่มีความคืบหน้าในแง่ของการทดสอบ ( และจำเป็นต้องทำอะไรสักอย่างเกี่ยวกับเรื่องนี้)
• การบัญชีสำหรับข้อจำกัดของหน่วยความจำและ CPU. เราเขียนไมโครเซอร์วิสใน Golang เป็นหลักและรันใน Kubernetes ดังนั้นความละเอียดอ่อนประการหนึ่งที่เกี่ยวข้องกับลักษณะเฉพาะของภาษา Golang: โดยค่าเริ่มต้น เมื่อเริ่มต้น ระบบจะใช้คอร์ทั้งหมดบนเครื่อง หากคุณไม่ได้ตั้งค่าตัวแปร GOMAXPROCS อย่างชัดเจน และเมื่อมีการเปิดตัวบริการดังกล่าวหลายอย่างบนเครื่องเดียวกัน พวกเขาก็จะเริ่มต้น แย่งชิงทรัพยากรรบกวนกัน กราฟด้านล่างแสดงการเปลี่ยนแปลงเวลาดำเนินการหากคุณเรียกใช้แอปพลิเคชันโดยไม่มีความขัดแย้งและอยู่ในโหมดการแข่งขันเพื่อชิงทรัพยากร (ที่มาของกราฟคือ ที่นี่).

เวลาดำเนินการ ยิ่งน้อยยิ่งดี สูงสุด: 643ms ขั้นต่ำ: 42ms ภาพถ่ายสามารถคลิกได้

ใช้เวลาในการผ่าตัด ยิ่งน้อยยิ่งดี สูงสุด: 14091 ns ขั้นต่ำ: 151 ns ภาพถ่ายสามารถคลิกได้

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

ปรับใช้

• การตรวจสอบแบบแผน ก่อนที่คุณจะเริ่มส่งมอบแอสเซมบลีการบริการไปยังสภาพแวดล้อมที่คุณต้องการ คุณต้องตรวจสอบสิ่งต่อไปนี้:
- จุดสิ้นสุด API
— การปฏิบัติตามการตอบสนองจุดสิ้นสุด API กับสคีมา
— รูปแบบบันทึก
— การตั้งค่าส่วนหัวสำหรับการร้องขอไปยังบริการ (ปัจจุบันนี้ทำได้โดย netramesh)
— การตั้งค่าโทเค็นของเจ้าของเมื่อส่งข้อความไปยังบัสเหตุการณ์ สิ่งนี้จำเป็นสำหรับการติดตามการเชื่อมต่อของบริการต่างๆ บนรถบัส คุณสามารถส่งทั้งข้อมูล idempotent ไปยังบัส ซึ่งไม่ได้เพิ่มการเชื่อมต่อของบริการ (ซึ่งดี) และข้อมูลธุรกิจที่เสริมความแข็งแกร่งให้กับการเชื่อมต่อของบริการ (ซึ่งแย่มาก!) และเมื่อการเชื่อมต่อนี้กลายเป็นปัญหา การทำความเข้าใจว่าใครเขียนและอ่านบัสจะช่วยแยกบริการได้อย่างเหมาะสม

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

การทดสอบสังเคราะห์

• การทดสอบวงปิด สำหรับสิ่งนี้ เรากำลังใช้โอเพ่นซอร์ส Hoverfly.io. ขั้นแรก จะบันทึกโหลดจริงบนบริการ จากนั้นเพียงในวงปิด - จะจำลองมัน

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

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

ก) เราดูที่ภาระทั้งหมด
- เล็กเกินไป - เป็นไปได้มากว่าบางอย่างไม่ทำงานเลยหากโหลดลดลงกะทันหันหลายครั้ง
- ใหญ่เกินไป - จำเป็นต้องปรับให้เหมาะสม

b) เราดูจุดตัดตาม RPS
ที่นี่เราจะดูความแตกต่างระหว่างเวอร์ชันปัจจุบันและเวอร์ชันก่อนหน้าและปริมาณทั้งหมด ตัวอย่างเช่น หากบริการสร้าง 100 rps แสดงว่าเขียนได้ไม่ดี หรือนี่คือความจำเพาะ แต่ไม่ว่าในกรณีใด นี่เป็นเหตุผลที่ต้องพิจารณาบริการอย่างใกล้ชิด
ในทางกลับกัน หากมี RPS มากเกินไป อาจมีข้อบกพร่องบางอย่างและจุดสิ้นสุดบางจุดหยุดดำเนินการเพย์โหลด และอีกจุดหนึ่งก็ถูกทริกเกอร์ return true;

การทดสอบนกขมิ้น

หลังจากที่เราผ่านการทดสอบสังเคราะห์แล้ว เราจะทดสอบไมโครเซอร์วิสกับผู้ใช้จำนวนไม่มาก เราเริ่มต้นอย่างระมัดระวัง โดยมีส่วนแบ่งเพียงเล็กน้อยจากกลุ่มเป้าหมายของบริการ - น้อยกว่า 0,1% ในขั้นตอนนี้ เป็นสิ่งสำคัญมากที่จะต้องรวมเมตริกทางเทคนิคและผลิตภัณฑ์ที่ถูกต้องไว้ในการตรวจสอบ เพื่อให้แสดงปัญหาในบริการโดยเร็วที่สุด เวลาขั้นต่ำสำหรับการทดสอบคานารีคือ 5 นาที ส่วนการทดสอบหลักคือ 2 ชั่วโมง สำหรับบริการที่ซับซ้อน เราจะตั้งเวลาด้วยตนเอง
มาวิเคราะห์กัน:
— ตัวชี้วัดเฉพาะภาษา โดยเฉพาะผู้ปฏิบัติงาน php-fpm
— ข้อผิดพลาดใน Sentry;
— สถานะการตอบสนอง
— เวลาตอบสนอง ที่แน่นอนและโดยเฉลี่ย
— เวลาแฝง;
— ข้อยกเว้น ประมวลผลและไม่ได้รับการจัดการ
— ตัวชี้วัดผลิตภัณฑ์

การทดสอบการบีบ

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

การผลิต

• การปรับขนาด เมื่อเราเปิดตัวบริการสู่การใช้งานจริง เราจะติดตามดูว่าบริการจะขยายขนาดอย่างไร จากประสบการณ์ของเรา การตรวจสอบเฉพาะตัวบ่งชี้ CPU เท่านั้นไม่ได้ผล การปรับขนาดอัตโนมัติด้วยการเปรียบเทียบ RPS ในรูปแบบบริสุทธิ์ใช้งานได้เฉพาะกับบริการบางอย่างเท่านั้น เช่น การสตรีมออนไลน์ ดังนั้นเราจึงดูที่ตัวชี้วัดผลิตภัณฑ์เฉพาะแอปพลิเคชันเป็นอันดับแรก

ด้วยเหตุนี้ เมื่อปรับขนาดเราจะวิเคราะห์:
- ตัวบ่งชี้ CPU และ RAM
— จำนวนคำขอในคิว
- เวลาตอบสนอง,
— การคาดการณ์ตามข้อมูลในอดีตที่สะสม

เมื่อปรับขนาดบริการ สิ่งสำคัญคือต้องตรวจสอบการขึ้นต่อกันเพื่อที่เราจะได้ไม่ปรับขนาดบริการแรกในห่วงโซ่ และบริการที่เข้าถึงจะล้มเหลวภายใต้ภาระงาน เพื่อสร้างภาระที่ยอมรับได้สำหรับกลุ่มบริการทั้งหมด เราจะดูข้อมูลประวัติของบริการที่ "ใกล้เคียงที่สุด" (ขึ้นอยู่กับการรวมกันของตัวบ่งชี้ CPU และ RAM ควบคู่ไปกับตัววัดเฉพาะแอป) และเปรียบเทียบกับข้อมูลประวัติ ของบริการการเริ่มต้นและอื่น ๆ ตลอด "ห่วงโซ่การพึ่งพา" "จากบนลงล่าง

Обслуживание

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

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

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

แผงควบคุม

กล่าวโดยสรุป แดชบอร์ดคือแผงควบคุมของ PaaS ทั้งหมดของเรา

• ข้อมูลจุดเดียวเกี่ยวกับบริการ พร้อมด้วยข้อมูลเกี่ยวกับความครอบคลุมของการทดสอบ จำนวนภาพ จำนวนสำเนาการผลิต เวอร์ชัน ฯลฯ
• เครื่องมือสำหรับการกรองข้อมูลตามบริการและป้ายกำกับ (เครื่องหมายของการเป็นหน่วยธุรกิจ ฟังก์ชั่นผลิตภัณฑ์ ฯลฯ )
• เครื่องมือสำหรับการผสานรวมกับเครื่องมือโครงสร้างพื้นฐานสำหรับการติดตาม การบันทึก และการตรวจสอบ
• เอกสารการบริการจุดเดียว
• มุมมองเดียวของกิจกรรมทั้งหมดในบริการ

เบ็ดเสร็จ

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

ฉันให้รายงานในหัวข้อนี้สำหรับ HighLoad++ 2018 คุณสามารถดูได้ วีดีโอ и การเสนอ.

โบนัสแทร็กสำหรับผู้ที่อ่านจนจบ

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

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

คุณสามารถสมัครเข้าร่วมได้ ใน Google ฟอร์มนี้. จากคุณ - คำตอบสำหรับคำถามว่าทำไมคุณต้องเข้าร่วมการฝึกอบรมและข้อมูลเกี่ยวกับวิธีการติดต่อคุณ ตอบเป็นภาษาอังกฤษ เพราะคริสจะเลือกผู้เข้าร่วมที่จะเข้ารับการฝึกอบรมด้วยตนเอง
เราจะประกาศชื่อของผู้เข้าร่วมการฝึกอบรมในการอัปเดตโพสต์นี้และบนโซเชียลเน็ตเวิร์ก Avito สำหรับนักพัฒนา (AvitoTech ใน Facebook, vkontakte, พูดเบาและรวดเร็ว) ภายในวันที่ 19 กรกฎาคม

ที่มา: will.com