4 กลยุทธ์การปรับใช้สำหรับไมโครเซอร์วิสที่ยืดหยุ่น

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

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

การปรับใช้ Canary

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

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

การทดสอบ A / B

การทดสอบ A / B คล้ายกับการปรับใช้ Canary โดยมีข้อแตกต่างที่สำคัญอย่างหนึ่ง ในขณะที่การปรับใช้ Canary มีแนวโน้มที่จะมุ่งเน้นไปที่การระบุจุดบกพร่องและปัญหาคอขวดด้านประสิทธิภาพการทดสอบ A / B มุ่งเน้นไปที่การวัดการยอมรับของผู้ใช้เกี่ยวกับคุณสมบัติแอปพลิเคชันใหม่ ตัวอย่างเช่นนักพัฒนาอาจต้องการทราบว่าคุณลักษณะใหม่ ๆ ได้รับความนิยมจากผู้ใช้หรือไม่ค้นหาได้ง่ายหรือ UI ทำงานได้อย่างถูกต้องหรือไม่

รูปแบบนี้ใช้การกำหนดเส้นทางซอฟต์แวร์เพื่อเปิดใช้งานและทดสอบคุณลักษณะเฉพาะกับกลุ่มการเข้าชมที่แตกต่างกันการเปิดเผยคุณลักษณะใหม่ตามเปอร์เซ็นต์การเข้าชมที่ระบุหรือเฉพาะกลุ่มที่ จำกัด เซ็กเมนต์การกำหนดเส้นทาง A และ B อาจส่งทราฟฟิกไปยังรุ่นต่างๆของซอฟต์แวร์หรืออินสแตนซ์บริการอาจใช้ซอฟต์แวร์รุ่นเดียวกัน แต่มีแอตทริบิวต์การกำหนดค่าที่แตกต่างกัน (ตามที่ระบุใน orchestrator หรือที่อื่น ๆ )

การปรับใช้สีน้ำเงิน - เขียว

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

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

เงาจราจร

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

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

สี่กลยุทธ์หนึ่งเป้าหมาย

เทคนิคการกำหนดเส้นทางเหล่านี้นำเสนอวิธีการที่แตกต่างกัน แต่เกี่ยวข้องกันในการช่วยในการค้นพบการบรรเทาและการทดสอบข้อบกพร่องในแอปพลิเคชันที่ใช้ไมโครเซอร์วิส เครื่องมือเหล่านี้เป็นเครื่องมือที่มีศักยภาพในการจัดการกับข้อบกพร่องปัญหาด้านประสิทธิภาพและช่องโหว่ด้านความปลอดภัยโดยเฉพาะอย่างยิ่งเมื่อนำไปใช้เป็นส่วนหนึ่งของไปป์ไลน์การรวมและการจัดส่งแบบต่อเนื่องแบบ end-to-end (CI / CD)

วิธีใดต่อไปนี้ที่เหมาะสมที่สุดสำหรับกรณีของคุณส่วนใหญ่จะขึ้นอยู่กับข้อกังวลใดที่สำคัญที่สุด ตัวอย่างเช่นการยกเครื่อง UI ครั้งใหญ่จะได้รับประโยชน์อย่างมากจากการทดสอบ A / B ในขณะที่การปรับใช้สีน้ำเงิน - เขียวอาจเป็นสิ่งที่ประเมินค่าไม่ได้เพื่อดูว่าคุณลักษณะใหม่อาจส่งผลต่อประสิทธิภาพของที่เก็บข้อมูลที่มีอยู่อย่างไร

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

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

Manuel Zapf เป็นหัวหน้าฝ่าย OSS ผลิตภัณฑ์ของ Containous ซึ่งเป็น บริษัท เครือข่ายระบบคลาวด์ที่อยู่เบื้องหลังโครงการโอเพ่นซอร์ส Traefik และ Maesh

-

New Tech Forum เป็นสถานที่สำหรับสำรวจและพูดคุยเกี่ยวกับเทคโนโลยีสำหรับองค์กรที่เกิดขึ้นใหม่ในเชิงลึกและเชิงกว้างที่ไม่เคยมีมาก่อน การเลือกเป็นเรื่องส่วนตัวขึ้นอยู่กับการเลือกใช้เทคโนโลยีที่เราเชื่อว่ามีความสำคัญและเป็นที่สนใจของผู้อ่านมากที่สุด ไม่ยอมรับหลักประกันทางการตลาดสำหรับการตีพิมพ์และขอสงวนสิทธิ์ในการแก้ไขเนื้อหาที่มีส่วนร่วมทั้งหมด ส่งคำถามทั้งหมดไปที่ [email protected]