บันทึก. แปล: ผู้เขียนบทความนี้ (Luc Perkins) เป็นผู้สนับสนุนนักพัฒนาในองค์กร CNCF ซึ่งเป็นที่ตั้งของโครงการ Open Source เช่น Linkerd, SMI (Service Mesh Interface) และ Kuma (ยังไงก็ตาม คุณเคยสงสัยบ้างไหมว่าทำไม Istio ถึงเป็น ไม่อยู่ในรายการนี้เหรอ? .) เป็นอีกครั้งที่พยายามทำให้ชุมชน DevOps มีความเข้าใจที่ดีขึ้นเกี่ยวกับกระแสนิยมที่เรียกว่า "service mesh" เขาได้แสดงรายการความสามารถเฉพาะ 16 ประการที่โซลูชันดังกล่าวมีให้
วันนี้ ― หนึ่งในหัวข้อที่ร้อนแรงที่สุดในสาขาวิศวกรรมซอฟต์แวร์ (และถูกต้องด้วย!) ฉันคิดว่าเทคโนโลยีนี้มีแนวโน้มที่ดีอย่างไม่น่าเชื่อ และอยากเห็นการนำเทคโนโลยีนี้ไปใช้อย่างกว้างขวาง (เมื่อเหมาะสมแน่นอน) อย่างไรก็ตาม มันยังคงล้อมรอบไปด้วยรัศมีแห่งความลึกลับสำหรับคนส่วนใหญ่ ขณะเดียวกันแม้แต่ผู้ที่ รู้จักกันดี บ่อยครั้งเป็นเรื่องยากที่จะอธิบายข้อดีของมันและว่ามันคืออะไร (รวมถึงของคุณด้วยจริงๆ ด้วย) ในบทความนี้ฉันจะพยายามแก้ไขสถานการณ์โดยแสดงรายการต่างๆ กรณีการใช้งาน "บริการตาข่าย"*.
* บันทึก แปล: ที่นี่และเพิ่มเติมในบทความว่าการแปลนี้ (“service mesh”) จะใช้สำหรับ service mesh ที่ยังคงเป็นคำใหม่
แต่ก่อนอื่นฉันต้องการแสดงความคิดเห็นเล็กน้อย:
- ฉันไม่เคยทำงานกับ service mesh หรือใช้งานนอกโครงการที่เริ่มต้นเพื่อการศึกษาของฉันเอง ในทางกลับกัน ฉันเป็นคนที่เขียนเอกสารจำนวนมากเกี่ยวกับ Service Mesh ภายในของ Twitter ในปี 2015 (ตอนนั้นยังไม่เรียกว่า "Service Mesh" ด้วยซ้ำ) และมีส่วนร่วมในการพัฒนาเว็บไซต์และเอกสารประกอบสำหรับ นั่นก็หมายถึงอะไรบางอย่าง
- รายการของฉันเป็นเพียงการประมาณและไม่สมบูรณ์ อาจมีกรณีการใช้งานที่ฉันไม่รู้จัก และตัวเลือกใหม่มีแนวโน้มที่จะเกิดขึ้นเมื่อเวลาผ่านไปเมื่อเทคโนโลยีพัฒนาและความนิยมเพิ่มขึ้น
- ในเวลาเดียวกัน ไม่ใช่ว่าการใช้งาน Service Mesh ที่มีอยู่ทั้งหมดจะรองรับกรณีการใช้งานทั้งหมดที่ระบุไว้ ดังนั้นข้อความของฉันเช่น "service mesh สามารถ ... " ควรอ่านว่า "ส่วนบุคคล และบางทีการใช้งาน service mesh ที่ได้รับความนิยมทั้งหมดสามารถ..."
- ลำดับของตัวอย่างไม่ได้สร้างความแตกต่างใดๆ
รายชื่อตัวเลือก:
- การค้นพบบริการ
- การเข้ารหัส;
- การรับรองความถูกต้องและการอนุญาต
- การปรับสมดุลโหลด
- วงจรแตก;
- การปรับขนาดอัตโนมัติ;
- การปรับใช้นกขมิ้น
- การปรับใช้สีน้ำเงิน-เขียว
- ตรวจสุขภาพ;
- การปลดภาระ;
- การสะท้อนการจราจร
- ฉนวนกันความร้อน
- การจำกัดอัตราการร้องขอ การลองใหม่และการหมดเวลา
- การวัดและส่งข้อมูลทางไกล;
- การตรวจสอบ;
- การสร้างภาพ
1. การค้นพบบริการ
TL; DR: เชื่อมต่อกับบริการอื่น ๆ บนเครือข่ายโดยใช้ชื่อง่ายๆ
บริการควรจะสามารถ "ค้นหา" ซึ่งกันและกันได้โดยอัตโนมัติโดยใช้ชื่อที่เพียงพอ - ตัวอย่างเช่น service.api.production, pets/staging หรือ cassandra. สภาพแวดล้อมคลาวด์มีความยืดหยุ่น และชื่อเดียวสามารถซ่อนอินสแตนซ์ของบริการได้หลายรายการ เป็นที่ชัดเจนว่าในสถานการณ์เช่นนี้ เป็นไปไม่ได้ทางกายภาพที่จะฮาร์ดโค้ดที่อยู่ IP ทั้งหมด
นอกจากนี้ เมื่อบริการหนึ่งพบอีกบริการหนึ่ง ก็ควรจะสามารถส่งคำขอไปยังบริการนั้นได้โดยไม่ต้องกลัวว่าคำขอเหล่านั้นจะไปอยู่ที่อินพุตของอินสแตนซ์ที่เสียหาย กล่าวอีกนัยหนึ่ง Service Mesh จะต้องตรวจสอบความสมบูรณ์ของอินสแตนซ์บริการทั้งหมดและรักษารายชื่อโฮสต์ให้ทันสมัยที่สุดเท่าที่จะเป็นไปได้
แต่ละตาข่ายบริการใช้กลไกการค้นหาบริการที่แตกต่างกัน วิธีที่พบบ่อยที่สุดในขณะนี้คือการมอบหมายให้กับกระบวนการภายนอก เช่น Kubernetes DNS ในอดีตบน Twitter เราใช้ระบบการตั้งชื่อเพื่อจุดประสงค์นี้ . นอกจากนี้ เทคโนโลยี Service Mesh ยังช่วยให้กลไกการตั้งชื่อแบบกำหนดเองเกิดขึ้นได้ (แม้ว่าฉันจะยังไม่เห็นการนำ SM ไปใช้ฟังก์ชันดังกล่าวก็ตาม)
2. การเข้ารหัส
TL; DR: กำจัดการรับส่งข้อมูลที่ไม่ได้เข้ารหัสระหว่างบริการ และทำให้กระบวนการนี้เป็นแบบอัตโนมัติและปรับขนาดได้
เป็นเรื่องดีที่รู้ว่าผู้โจมตีไม่สามารถเจาะเครือข่ายภายในของคุณได้ ไฟร์วอลล์ทำหน้าที่ได้ดีในเรื่องนี้ แต่จะเกิดอะไรขึ้นถ้าแฮกเกอร์เข้าไปข้างใน? เขาจะสามารถทำทุกอย่างที่ต้องการกับการรับส่งข้อมูลภายในบริการได้หรือไม่? หวังว่าสิ่งนี้จะไม่เกิดขึ้นเลย เพื่อป้องกันสถานการณ์นี้ คุณควรใช้เครือข่ายแบบ Zero-Trust ซึ่งมีการเข้ารหัสการรับส่งข้อมูลระหว่างบริการทั้งหมด โครงข่ายบริการที่ทันสมัยส่วนใหญ่บรรลุเป้าหมายนี้ผ่านการทำงานร่วมกัน (TLS ร่วมกัน, mTLS) ในบางกรณี mTLS ทำงานได้บนคลาวด์และคลัสเตอร์ทั้งหมด (ฉันคิดว่าสักวันหนึ่งการสื่อสารระหว่างดาวเคราะห์จะถูกจัดเรียงในลักษณะเดียวกัน)
แน่นอนว่าสำหรับบริการ mTLS ไม่จำเป็น. แต่ละบริการสามารถดูแล TLS ของตัวเองได้ แต่นั่นหมายความว่าคุณจะต้องหาวิธีสร้างใบรับรอง แจกจ่ายให้กับโฮสต์บริการ และรวมโค้ดในแอปพลิเคชันที่จะโหลดใบรับรองเหล่านี้จากไฟล์ ใช่ อย่าลืมต่ออายุใบรับรองเหล่านี้เป็นระยะๆ Service Meshes จะทำให้ mTLS เป็นระบบอัตโนมัติ เช่น ซึ่งจะทำให้กระบวนการออกและหมุนเวียนใบรับรองเป็นไปโดยอัตโนมัติ
3. การรับรองความถูกต้องและการอนุญาต
TL; DR: กำหนดว่าใครคือผู้ร้องขอ และกำหนดสิ่งที่พวกเขาได้รับอนุญาตให้ทำก่อนที่คำขอจะเข้าถึงบริการด้วยซ้ำ
บริการมักต้องการทราบ ใคร ดำเนินการตามคำขอ (การรับรองความถูกต้อง) และใช้ข้อมูลนี้ในการตัดสินใจ ที่ เอนทิตีที่กำหนดได้รับอนุญาตให้ทำ (การอนุญาต) ในกรณีนี้สรรพนาม “ใคร” สามารถซ่อนได้:
- บริการอื่นๆ สิ่งนี้เรียกว่า "การรับรองความถูกต้อง" เพื่อน" ตัวอย่างเช่นการบริการ
webต้องการเข้าถึงบริการdb. Service Mesh มักจะแก้ปัญหาดังกล่าวโดยใช้ mTLS: ใบรับรองในกรณีนี้ทำหน้าที่เป็นตัวระบุที่จำเป็น - ผู้ใช้มนุษย์บางคน สิ่งนี้เรียกว่า "การรับรองความถูกต้อง" ขอ" ตัวอย่างเช่น ผู้ใช้
haxor69ต้องการซื้อโคมไฟใหม่ Service meshes มีกลไกต่างๆ เช่น .พวกเราหลายคนได้ทำสิ่งนี้ในรหัสแอปพลิเคชัน มีคำขอเข้ามาเราดูตาราง
usersค้นหาผู้ใช้และเปรียบเทียบรหัสผ่าน จากนั้นตรวจสอบคอลัมน์permissionsฯลฯ ในกรณีของ Service Mesh สิ่งนี้จะเกิดขึ้นก่อนที่คำขอจะไปถึงบริการด้วยซ้ำ
เมื่อเราทราบแล้วว่าคำขอมาจากใคร เราจำเป็นต้องพิจารณาว่าหน่วยงานนี้ได้รับอนุญาตให้ทำอะไร Service Mesh บางตัวอนุญาตให้คุณตั้งค่านโยบายพื้นฐาน (เกี่ยวกับใครสามารถทำอะไรได้บ้าง) เป็นไฟล์ YAML หรือบนบรรทัดคำสั่ง ในขณะที่บางตัวเสนอการผสานรวมกับเฟรมเวิร์ก เช่น . เป้าหมายสูงสุดคือการให้บริการของคุณที่จะยอมรับคำขอใดๆ โดยถือว่าอย่างปลอดภัยมาจากแหล่งที่เชื่อถือได้ и อนุญาตให้ดำเนินการนี้
4. โหลดบาลานซ์
TL; DR: กระจายโหลดระหว่างอินสแตนซ์บริการตามรูปแบบเฉพาะ
“บริการ” ภายในส่วนบริการมักประกอบด้วยอินสแตนซ์ที่เหมือนกันหลายอินสแตนซ์ ตัวอย่างเช่นวันนี้บริการ cache ประกอบด้วย 5 ชุด และพรุ่งนี้จำนวนอาจเพิ่มเป็น 11 ชุด ส่งคำขอไปที่ cacheจะต้องแจกจ่ายตามวัตถุประสงค์เฉพาะ ตัวอย่างเช่น ลดเวลาแฝงหรือเพิ่มความน่าจะเป็นในการไปยังอินสแตนซ์ที่ใช้งานได้ อัลกอริธึมที่ใช้กันมากที่สุดคือ Round-robin แต่ก็มีอัลกอริธึมอื่นๆ อีกมากมาย เช่น วิธีถ่วงน้ำหนัก (ถ่วงน้ำหนัก) ข้อความค้นหา (คุณสามารถเลือกเป้าหมายที่ต้องการได้) โทร (แหวน) การแฮช (โดยใช้การแฮชที่สอดคล้องกันในโฮสต์อัปสตรีม) หรือวิธีการร้องขอน้อยที่สุด (การตั้งค่ากำหนดให้กับอินสแตนซ์ที่มีคำขอน้อยที่สุด)
บาลานเซอร์แบบคลาสสิกมีฟังก์ชันอื่นๆ เช่น การแคช HTTP และการป้องกัน DDoS แต่ไม่เกี่ยวข้องกับการรับส่งข้อมูลตะวันออก-ตะวันตกมากนัก (นั่นคือ สำหรับการรับส่งข้อมูลที่ไหลภายในศูนย์ข้อมูล - การแปลโดยประมาณ) (ขอบเขตทั่วไปของโครงข่ายบริการ) แน่นอนว่าไม่จำเป็นต้องใช้ Service Mesh สำหรับการทำ Load Balancing แต่ช่วยให้คุณสามารถตั้งค่าและควบคุมนโยบายการปรับสมดุลสำหรับแต่ละบริการจากชั้นควบคุมแบบรวมศูนย์ได้ จึงขจัดความจำเป็นในการเรียกใช้และกำหนดค่า Load Balancer แยกต่างหากใน Network Stack .
5. การตัดวงจร
TL; DR: หยุดการรับส่งข้อมูลไปยังบริการที่มีปัญหาและควบคุมความเสียหายในสถานการณ์ที่เลวร้ายที่สุด
หากบริการไม่สามารถรับมือกับการรับส่งข้อมูลได้ด้วยเหตุผลบางประการ Service Mesh จะมีตัวเลือกมากมายสำหรับการแก้ปัญหานี้ (ส่วนอื่น ๆ จะมีการหารือในส่วนที่เหมาะสม) การตัดวงจรเป็นตัวเลือกที่รุนแรงที่สุดในการตัดการเชื่อมต่อบริการจากการรับส่งข้อมูล อย่างไรก็ตาม มันไม่สมเหตุสมผลเลยโดยตัวมันเอง - จำเป็นต้องมีแผนสำรอง อาจมีแรงดันย้อนกลับ () ไปยังบริการที่ส่งคำขอ (อย่าลืมกำหนดค่า Service Mesh ของคุณสำหรับสิ่งนี้!) หรือตัวอย่างเช่น การระบายสีหน้าสถานะเป็นสีแดงและเปลี่ยนเส้นทางผู้ใช้ไปยังหน้าเวอร์ชันอื่นด้วย "วาฬตก" (“Twitter คือ ลง").
Service Meshes ไม่เพียงแต่ช่วยให้คุณกำหนดได้เท่านั้น เมื่อ การปิดระบบจะตามมาและ ที่ สิ่งนี้จะตามมา ในกรณีนี้ “เมื่อใด” สามารถรวมพารามิเตอร์ที่ระบุรวมกันได้: จำนวนคำขอทั้งหมดในช่วงเวลาหนึ่ง จำนวนการเชื่อมต่อแบบขนาน คำขอที่รอดำเนินการ การลองใหม่ที่ใช้งานอยู่ ฯลฯ
คุณอาจไม่ต้องการที่จะทำลายวงจรในทางที่ผิด แต่ดีใจที่รู้ว่าคุณมีแผนสำรองไว้ในกรณีฉุกเฉิน
6. การปรับขนาดอัตโนมัติ
TL; DR: เพิ่มหรือลดจำนวนอินสแตนซ์บริการขึ้นอยู่กับเกณฑ์ที่ระบุ
Service Mesh ไม่ใช่ตัวกำหนดเวลา ดังนั้นจึงไม่เป็นเช่นนั้น ดำเนินการ ปรับขนาดตัวเอง อย่างไรก็ตาม พวกเขาสามารถให้ข้อมูลว่านักวางแผนคนใดจะใช้เป็นฐานในการตัดสินใจของตนได้ เนื่องจาก Service Meshes สามารถเข้าถึงการรับส่งข้อมูลทั้งหมดระหว่างบริการต่างๆ ได้ พวกเขาจึงมีข้อมูลที่ครอบคลุมเกี่ยวกับสิ่งที่เกิดขึ้น เช่น บริการใดที่กำลังประสบปัญหา บริการใดที่มีการโหลดเพียงเล็กน้อย (ความจุที่จัดสรรให้กับบริการนั้นสูญเปล่า) เป็นต้น
ตัวอย่างเช่น Kubernetes ปรับขนาดบริการตามการใช้งาน CPU และหน่วยความจำของพ็อด (ดูรายงานของเรา "" - ประมาณ แปล)แต่ถ้าคุณตัดสินใจที่จะปรับขนาดตามตัวชี้วัดอื่นๆ (ในกรณีของเรา เกี่ยวข้องกับการเข้าชม) คุณจะต้องมีตัวชี้วัดพิเศษ การจัดการ แสดงวิธีการทำสิ่งนี้ด้วย , и แต่กระบวนการนั้นค่อนข้างซับซ้อน เราต้องการให้ Service Mesh ทำให้สิ่งนี้ง่ายขึ้นโดยอนุญาตให้เราตั้งค่าเงื่อนไขเช่น “เพิ่มจำนวนอินสแตนซ์บริการ” authหากจำนวนคำขอที่รอดำเนินการเกินเกณฑ์ภายในหนึ่งนาที"
7. การปรับใช้ Canary
TL; DR: ทดสอบฟีเจอร์หรือเวอร์ชันบริการใหม่กับผู้ใช้บางส่วน
สมมติว่าคุณกำลังพัฒนาผลิตภัณฑ์ SaaS และตั้งใจที่จะเปิดตัวเวอร์ชันใหม่สุดเจ๋ง คุณทดสอบมันในการจัดเตรียมและใช้งานได้ดี แต่ยังคงมีข้อกังวลบางประการเกี่ยวกับพฤติกรรมของเธอในสภาวะจริง กล่าวอีกนัยหนึ่ง คุณต้องทดสอบเวอร์ชันใหม่กับปัญหาจริงโดยไม่ต้องเสี่ยงต่อความไว้วางใจของผู้ใช้ การปรับใช้ Canary นั้นยอดเยี่ยมสำหรับสิ่งนี้ ช่วยให้คุณสามารถสาธิตคุณลักษณะใหม่แก่ผู้ใช้บางส่วนได้ ส่วนย่อยนี้อาจประกอบด้วยผู้ใช้ที่ภักดีที่สุดหรือผู้ที่ทำงานกับผลิตภัณฑ์เวอร์ชันฟรี หรือผู้ใช้ที่แสดงความปรารถนาที่จะเป็น "หนูตะเภา"
Service Meshes จะใช้สิ่งนี้โดยอนุญาตให้คุณระบุเกณฑ์ที่กำหนดว่าใครจะดูเวอร์ชันของแอปพลิเคชันได้ และกำหนดเส้นทางการรับส่งข้อมูลตามนั้น อย่างไรก็ตาม ไม่มีอะไรเปลี่ยนแปลงสำหรับบริการของตัวเอง บริการเวอร์ชัน 1.0 เชื่อว่าคำขอทั้งหมดมาจากผู้ใช้ที่ควรเห็น และเวอร์ชัน 1.1 เชื่อเช่นเดียวกันสำหรับผู้ใช้ ในขณะเดียวกัน คุณสามารถเปลี่ยนเปอร์เซ็นต์การรับส่งข้อมูลระหว่างเวอร์ชันเก่าและเวอร์ชันใหม่ โดยเปลี่ยนเส้นทางผู้ใช้จำนวนมากขึ้นไปยังเวอร์ชันใหม่หากทำงานได้เสถียรและ “หนูตะเภา” ของคุณก็เดินหน้าต่อไป
8. การปรับใช้สีน้ำเงิน-เขียว
TL; DR: เปิดตัวฟีเจอร์ใหม่สุดเจ๋ง แต่เตรียมพร้อมที่จะนำทุกอย่างกลับคืนมาทันที
ความหมาย คือการเปิดตัวบริการ “สีน้ำเงิน” ใหม่ โดยเปิดตัวควบคู่ไปกับบริการ “สีเขียว” แบบเก่า หากทุกอย่างดำเนินไปอย่างราบรื่นและบริการใหม่ทำงานได้ดี บริการเก่าก็สามารถค่อยๆ ปิดใช้งานได้ (อนิจจา สักวันหนึ่งบริการ "สีน้ำเงิน" ใหม่นี้จะทำซ้ำชะตากรรมของบริการ "สีเขียว" และหายไป...) การใช้งานสีน้ำเงินเขียวแตกต่างจากบริการคานารีตรงที่ฟังก์ชันใหม่ครอบคลุม ทุกคนพร้อมกัน ผู้ใช้ (ไม่ใช่ส่วนหนึ่ง); ประเด็นก็คือต้องมี "ท่าเรือที่ปลอดภัย" พร้อมในกรณีที่มีสิ่งผิดปกติเกิดขึ้น
Service Meshes นำเสนอวิธีที่สะดวกมากในการทดสอบบริการ "สีน้ำเงิน" และสลับไปใช้บริการ "สีเขียว" ที่ใช้งานได้ทันทีในกรณีที่เกิดปัญหา ไม่ต้องพูดถึงความจริงที่ว่าตลอดทางพวกเขาให้ข้อมูลมากมาย (ดู "Telemetry" ด้านล่าง) เกี่ยวกับงานของ "สีน้ำเงิน" ซึ่งช่วยให้เข้าใจว่าพร้อมสำหรับการทำงานเต็มรูปแบบหรือไม่
บันทึก. แปล: คุณสามารถอ่านเพิ่มเติมเกี่ยวกับกลยุทธ์การปรับใช้ต่างๆ ใน Kubernetes (รวมถึงนกขมิ้นที่กล่าวถึง สีน้ำเงิน/เขียว และอื่นๆ) ได้ใน .
9. ตรวจสุขภาพ
TL; DR: ติดตามว่าอินสแตนซ์บริการใดใช้งานได้และตอบสนองต่ออินสแตนซ์บริการที่ไม่สามารถใช้งานได้อีกต่อไป
ตรวจสุขภาพ (ตรวจสุขภาพ) ช่วยตัดสินใจว่าอินสแตนซ์บริการพร้อมที่จะยอมรับและประมวลผลการรับส่งข้อมูลหรือไม่ ตัวอย่างเช่น ในกรณีของบริการ HTTP การตรวจสอบสภาพอาจดูเหมือนคำขอ GET ไปยังตำแหน่งข้อมูล /health... ตอบ 200 OK จะหมายความว่าอินสแตนซ์นั้นแข็งแรงดีหรืออย่างอื่น - มันไม่พร้อมที่จะรับปริมาณข้อมูล Service Meshes ช่วยให้คุณสามารถระบุทั้งวิธีการตรวจสอบฟังก์ชันการทำงานและความถี่ที่จะดำเนินการตรวจสอบนี้ ข้อมูลนี้สามารถใช้เพื่อวัตถุประสงค์อื่นได้ - ตัวอย่างเช่น สำหรับการปรับสมดุลโหลดและการตัดวงจร
ดังนั้น การตรวจสุขภาพจึงไม่ใช่กรณีการใช้งานแบบสแตนด์อโลน แต่มักจะใช้เพื่อบรรลุเป้าหมายอื่นๆ นอกจากนี้ อาจจำเป็นต้องมีการดำเนินการภายนอกเป้าหมายตาข่ายบริการอื่นๆ ทั้งนี้ขึ้นอยู่กับผลลัพธ์ของการตรวจสอบสภาพ เช่น การอัปเดตหน้าสถานะ การสร้างปัญหาบน GitHub หรือการกรอกตั๋ว JIRA และเซอร์วิสเมชมีกลไกที่สะดวกสบายในการทำให้ทั้งหมดนี้เป็นแบบอัตโนมัติ
10. การปลดโหลด
TL; DR: เปลี่ยนเส้นทางการรับส่งข้อมูลเพื่อตอบสนองต่อการใช้งานที่เพิ่มขึ้นชั่วคราว
หากบริการบางอย่างมีการรับส่งข้อมูลมากเกินไป คุณสามารถเปลี่ยนเส้นทางการรับส่งข้อมูลบางส่วนไปยังตำแหน่งอื่นได้ชั่วคราว (นั่นคือ "ถ่ายโอนข้อมูล" "ถ่ายโอน" (หลั่งน้ำตา) เขาอยู่ที่นั่น) ตัวอย่างเช่น ไปยังบริการสำรองข้อมูลหรือศูนย์ข้อมูล หรือไปยังถาวร หัวข้อ. ด้วยเหตุนี้ บริการจะดำเนินการประมวลผลคำขอบางรายการต่อไป แทนที่จะหยุดทำงานและหยุดการประมวลผลทุกอย่างโดยสิ้นเชิง การกำจัดโหลดจะดีกว่าการทำลายวงจร แต่ก็ยังไม่แนะนำให้ใช้ในทางที่ผิด ช่วยป้องกันความล้มเหลวแบบเรียงซ้อนที่ทำให้บริการดาวน์สตรีมขัดข้อง
11. การขนาน/การมิเรอร์การรับส่งข้อมูล
TL; DR: ส่งคำขอเดียวไปยังหลาย ๆ แห่งพร้อมกัน
บางครั้งมีความจำเป็นต้องส่งคำขอ (หรือคำขอบางรายการ) ไปยังบริการต่างๆ ในคราวเดียว ตัวอย่างทั่วไปคือการส่งปริมาณการใช้งานจริงบางส่วนไปยังบริการชั่วคราว เว็บเซิร์ฟเวอร์ที่ใช้งานจริงหลักส่งคำขอไปยังบริการดาวน์สตรีม products.production และเพื่อเขาเท่านั้น และเซอร์วิสเมชจะคัดลอกคำขอนี้และส่งไปที่อย่างชาญฉลาด products.stagingซึ่งเว็บเซิร์ฟเวอร์ไม่ทราบด้วยซ้ำ
กรณีการใช้งาน Service Mesh ที่เกี่ยวข้องอีกกรณีหนึ่งที่สามารถนำไปใช้นอกเหนือจากการรับส่งข้อมูลแบบขนานก็คือ . โดยเกี่ยวข้องกับการส่งคำขอเดียวกันไปยังบริการเวอร์ชันต่างๆ และตรวจสอบว่าทุกเวอร์ชันทำงานเหมือนกันหรือไม่ ฉันยังไม่พบการใช้งานบริการแบบตาข่ายกับระบบการทดสอบการถดถอยแบบรวมเช่น แต่ความคิดเองก็ดูมีแนวโน้มดี
12. ฉนวนกันความร้อน
TL; DR: แบ่งบริการของคุณออกเป็นเครือข่ายขนาดเล็ก
หรือเรียกอีกอย่างว่า การแบ่งส่วนการแยกเป็นศิลปะของการแบ่งตาข่ายบริการออกเป็นส่วนที่แตกต่างกันตามตรรกะโดยไม่รู้อะไรเลยเกี่ยวกับกันและกัน การแยกออกก็เหมือนกับการสร้างเครือข่ายส่วนตัวเสมือน ความแตกต่างพื้นฐานคือคุณยังคงสามารถเพลิดเพลินกับสิทธิประโยชน์ทั้งหมดของ Service Mesh (เช่น การค้นพบบริการ) แต่มีการรักษาความปลอดภัยเพิ่มเติม ตัวอย่างเช่น หากผู้โจมตีสามารถเจาะบริการบนเครือข่ายย่อยหนึ่งได้ เขาจะไม่สามารถดูว่าบริการใดที่ทำงานบนเครือข่ายย่อยอื่นหรือขัดขวางการรับส่งข้อมูลของพวกเขา
นอกจากนี้ผลประโยชน์ยังอาจเป็นประโยชน์ต่อองค์กรอีกด้วย คุณอาจต้องการซับเน็ตบริการของคุณตามโครงสร้างบริษัทของคุณ และลดภาระของนักพัฒนาที่ต้องคำนึงถึงโครงข่ายบริการทั้งหมด
13. การจำกัดอัตราคำขอ การลองใหม่ และการหมดเวลา
TL; DR: คุณไม่จำเป็นต้องรวมงานการจัดการคำขอที่สำคัญในโค้ดเบสของคุณอีกต่อไป
สิ่งเหล่านี้ทั้งหมดถือได้ว่าเป็นกรณีการใช้งานที่แยกจากกัน แต่ฉันตัดสินใจรวมสิ่งเหล่านี้เข้าด้วยกันเนื่องจากมีคุณลักษณะทั่วไปประการหนึ่ง นั่นคือ สิ่งเหล่านี้เข้ามาแทนที่งานการจัดการวงจรการใช้งานของคำขอที่โดยทั่วไปจะจัดการโดยไลบรารีแอปพลิเคชัน หากคุณกำลังพัฒนาเว็บเซิร์ฟเวอร์ใน Ruby on Rails (ไม่รวมเข้ากับ service mesh) ที่สร้างคำขอไปยังบริการแบ็กเอนด์ผ่าน แอปพลิเคชันจะต้องตัดสินใจว่าจะทำอย่างไรหากคำขอ N ล้มเหลว คุณจะต้องค้นหาว่าบริการเหล่านี้จะสามารถประมวลผลปริมาณการรับส่งข้อมูลได้มากเพียงใดและฮาร์ดโค้ดพารามิเตอร์เหล่านี้โดยใช้ไลบรารีพิเศษ นอกจากนี้ แอปพลิเคชันจะต้องตัดสินใจว่าเมื่อใดถึงเวลาที่ต้องยอมแพ้และปล่อยให้คำขอหมดไป (ขึ้นอยู่กับการหมดเวลา) และเพื่อที่จะเปลี่ยนพารามิเตอร์ข้างต้น เว็บเซิร์ฟเวอร์จะต้องหยุด กำหนดค่าใหม่ และเริ่มต้นใหม่อีกครั้ง
การโอนงานเหล่านี้ไปยัง Service Mesh ไม่เพียงแต่หมายความว่านักพัฒนาบริการจะไม่ต้องคิดถึงงานเหล่านี้เท่านั้น แต่ยังทำให้สามารถดูงานเหล่านี้ได้ในระดับโลกมากขึ้นอีกด้วย หากมีการใช้ห่วงโซ่บริการที่ซับซ้อน เช่น A -> B -> C -> D -> E จะต้องคำนึงถึงวงจรชีวิตของคำขอทั้งหมดด้วย หากงานคือการขยายการหมดเวลาในบริการ C ก็มีเหตุผลที่จะทำทั้งหมดนี้ในครั้งเดียวและไม่ใช่บางส่วน: โดยการอัปเดตรหัสบริการและรอจนกว่าคำขอดึงจะได้รับการยอมรับ และระบบ CI ปรับใช้บริการที่อัปเดต
14. การวัดและส่งข้อมูลทางไกล
TL; DR: รวบรวมข้อมูลที่จำเป็นทั้งหมด (และไม่ใช่ทั้งหมด) จากบริการ
การวัดและส่งข้อมูลทางไกลเป็นคำทั่วไปที่รวมถึงหน่วยวัด การติดตามแบบกระจาย และบันทึก Service Meshes เสนอกลไกในการรวบรวมและประมวลผลข้อมูลทั้งสามประเภท นี่คือจุดที่สิ่งต่างๆ จะพร่ามัวเล็กน้อยเนื่องจากจำนวนตัวเลือกที่เป็นไปได้มีมากเกินไป ในการรวบรวมตัวชี้วัดก็มี และเครื่องมืออื่นๆ ที่สามารถใช้เพื่อรวบรวมบันทึก , , เป็นต้น (เช่น ClickHouse กับไฟล์ สำหรับ K8s - ประมาณ แปล)สำหรับการติดตามแบบกระจายก็มี และอื่น ๆ แต่ละ Service Mesh อาจรองรับเครื่องมือบางอย่าง ไม่ใช่อย่างอื่น น่าสนใจว่าโครงการนี้สามารถทำได้หรือไม่ ทำให้เกิดการบรรจบกัน
ในกรณีนี้ ข้อดีของเทคโนโลยีเซอร์วิสเมชก็คือ โดยหลักการแล้วคอนเทนเนอร์ไซด์คาร์สามารถรวบรวมข้อมูลข้างต้นทั้งหมดจากบริการของตนได้ กล่าวอีกนัยหนึ่ง คุณมีระบบรวบรวมการวัดและส่งข้อมูลทางไกลเพียงระบบเดียว และเซอร์วิสเมชสามารถประมวลผลข้อมูลทั้งหมดนี้ได้หลายวิธี ตัวอย่างเช่น:
- บันทึกส่วนท้ายจากบริการบางอย่างใน CLI
- ตรวจสอบปริมาณคำขอจากแดชบอร์ดตาข่ายบริการ
- รวบรวมร่องรอยแบบกระจายและส่งต่อไปยังระบบเช่นเยเกอร์
ความสนใจ การตัดสินเชิงอัตนัย: โดยทั่วไป การวัดและส่งข้อมูลทางไกลเป็นพื้นที่ที่การรบกวนอย่างรุนแรงจากเซอร์วิสเมชเป็นสิ่งที่ไม่พึงประสงค์ การรวบรวมข้อมูลพื้นฐานและการติดตามตัวชี้วัดทองบางอย่าง เช่น อัตราความสำเร็จของคำขอและเวลาแฝงก็เป็นเรื่องปกติ แต่หวังว่าเราจะไม่เห็นว่าสแต็กของ Frankenstein ปรากฏขึ้นซึ่งพยายามแทนที่ระบบพิเศษ ซึ่งบางส่วนได้พิสูจน์ตัวเองแล้วและศึกษามาอย่างดีแล้ว .
15. การตรวจสอบ
TL; DR: ผู้ที่ลืมบทเรียนประวัติศาสตร์จะต้องทำซ้ำ
การตรวจสอบเป็นศิลปะของการสังเกตเหตุการณ์สำคัญในระบบ ในกรณีของโครงข่ายบริการ อาจหมายถึงการติดตามว่าใครเป็นผู้ส่งคำขอไปยังจุดสิ้นสุดเฉพาะสำหรับบริการเฉพาะ หรือจำนวนครั้งที่เหตุการณ์ที่เกี่ยวข้องกับความปลอดภัยเกิดขึ้นในเดือนที่ผ่านมา
เห็นได้ชัดว่าการตรวจสอบมีความเกี่ยวข้องอย่างใกล้ชิดกับการวัดและส่งข้อมูลทางไกล ข้อแตกต่างก็คือการวัดและส่งข้อมูลทางไกลมักจะเกี่ยวข้องกับสิ่งต่างๆ เช่น ประสิทธิภาพการทำงานและความสมบูรณ์ทางเทคนิค ในขณะที่การตรวจสอบอาจเกี่ยวข้องกับปัญหาทางกฎหมายและปัญหาอื่นๆ ที่นอกเหนือไปจากขอบเขตทางเทคนิคที่เข้มงวด (เช่น การปฏิบัติตาม GDPR - กฎระเบียบทั่วไปของสหภาพยุโรปเกี่ยวกับการปกป้องข้อมูล)
16. การสร้างภาพ
TL; DR: React.js ที่มีอายุการใช้งานยาวนาน - แหล่งที่มาของอินเทอร์เฟซที่สวยงามไม่สิ้นสุด
อาจมีคำที่ดีกว่านี้ แต่ฉันไม่รู้ ฉันหมายถึงการแสดงแบบกราฟิกของ service mesh หรือส่วนประกอบบางส่วน การแสดงภาพเหล่านี้อาจรวมถึงตัวบ่งชี้ เช่น เวลาแฝงโดยเฉลี่ย ข้อมูลการกำหนดค่ารถเทียมข้างรถจักรยานยนต์ ผลการตรวจสุขภาพ และการแจ้งเตือน
การทำงานในสภาพแวดล้อมที่เน้นการบริการเกี่ยวข้องกับภาระการรับรู้ที่สูงกว่ามากเมื่อเทียบกับพระบาทสมเด็จพระเจ้าอยู่หัวมหาหินใหญ่ ดังนั้นควรลดความกดดันทางสติปัญญาลงทุกวิถีทาง อินเทอร์เฟซแบบกราฟิกที่เรียบง่ายสำหรับบริการแบบตาข่ายที่มีความสามารถในการคลิกปุ่มและรับผลลัพธ์ที่ต้องการอาจเป็นปัจจัยชี้ขาดในการเติบโตของความนิยมของเทคโนโลยีนี้
ไม่รวมอยู่ในรายการ
เดิมทีฉันตั้งใจที่จะรวมกรณีการใช้งานเพิ่มอีกสองสามรายการไว้ในรายการ แต่แล้วก็ตัดสินใจว่าจะไม่ทำ พร้อมด้วยเหตุผลในการตัดสินใจของฉัน:
- ศูนย์ข้อมูลหลายตัว. ในความคิดของฉัน นี่ไม่ใช่กรณีการใช้งานมากนักในฐานะพื้นที่แคบและเฉพาะเจาะจงของการประยุกต์ใช้บริการตาข่ายหรือชุดฟังก์ชันบางอย่าง เช่น การค้นพบบริการ
- ทางเข้าและทางออก. นี่เป็นพื้นที่ที่เกี่ยวข้อง แต่ฉันได้จำกัดตัวเอง (อาจจะปลอมแปลง) เฉพาะกรณีการใช้งาน "การจราจรตะวันออก - ตะวันตก" ทางเข้าและทางออกสมควรได้รับบทความแยกต่างหาก
ข้อสรุป
นั่นคือทั้งหมดที่สำหรับตอนนี้! ขอย้ำอีกครั้งว่ารายการนี้เป็นไปตามอำเภอใจและมีแนวโน้มว่าจะไม่สมบูรณ์ หากคุณคิดว่าฉันพลาดอะไรบางอย่างหรือมีสิ่งผิดปกติ โปรดติดต่อฉันทาง Twitter (). โปรดเคารพกฎแห่งความเหมาะสม
ปล.จากผู้แปล
ภาพประกอบชื่อบทความอิงตามภาพจากบทความ “"(โดย เกรกอรี แมคคินนอน) โดยจะแสดงให้เห็นว่าฟังก์ชันการทำงานบางอย่างจากแอปพลิเคชัน (สีเขียว) ได้ย้ายไปยัง Service Mesh ที่ให้การเชื่อมต่อระหว่างกันอย่างไร (สีน้ำเงิน)
อ่านเพิ่มเติมในบล็อกของเรา:
- «";
- «";
- «'
ที่มา: will.com
