สวัสดีอีกครั้ง!..เนื่องในวันเปิดภาคเรียน เราได้เตรียมการแปลที่เป็นประโยชน์อีกฉบับหนึ่ง
Service Mesh คือเลเยอร์โครงสร้างพื้นฐานที่มีความหน่วงต่ำที่กำหนดค่าได้ ซึ่งจำเป็นต่อการจัดการการสื่อสารระหว่างกระบวนการบนเครือข่ายปริมาณมากระหว่าง Application Programming Interfaces (API) Service Mesh ช่วยให้สามารถสื่อสารได้อย่างรวดเร็ว เชื่อถือได้ และปลอดภัยระหว่างบริการโครงสร้างพื้นฐานแอปพลิเคชันแบบคอนเทนเนอร์และบ่อยครั้ง Service Mesh มอบความสามารถต่างๆ เช่น การค้นพบบริการ การปรับสมดุลโหลด การเข้ารหัส ความโปร่งใส การตรวจสอบย้อนกลับ การรับรองความถูกต้องและการอนุญาต และการสนับสนุนรูปแบบการปิดเครื่องอัตโนมัติ (เบรกเกอร์).
โดยทั่วไปแล้ว service mesh จะถูกนำไปใช้โดยจัดเตรียมอินสแตนซ์บริการแต่ละรายการด้วยอินสแตนซ์พร็อกซีที่เรียกว่า รถเทียมข้างรถจักรยานยนต์ รถเทียมข้างรถจักรยานยนต์ จัดการการสื่อสารระหว่างบริการ ติดตามและแก้ไขปัญหาด้านความปลอดภัย นั่นคือทุกสิ่งที่สามารถสรุปได้จากแต่ละบริการ ด้วยวิธีนี้ นักพัฒนาสามารถเขียน ดูแลรักษา และให้บริการโค้ดแอปพลิเคชันในบริการได้ และผู้ดูแลระบบสามารถทำงานร่วมกับ Service Mesh และรันแอปพลิเคชันได้
ปัจจุบัน Istio จาก Google, IBM และ Lyft เป็นสถาปัตยกรรม Service Mesh ที่มีชื่อเสียงที่สุด และ Kubernetes ซึ่งเดิมพัฒนาขึ้นที่ Google ปัจจุบันเป็นเพียงเฟรมเวิร์กการประสานคอนเทนเนอร์เดียวที่ Istio รองรับ ผู้ขายกำลังพยายามสร้าง Istio เวอร์ชันที่รองรับเชิงพาณิชย์ เป็นเรื่องน่าสนใจที่จะเห็นว่าพวกเขาสามารถนำเสนอสิ่งใหม่ ๆ ให้กับโครงการโอเพ่นซอร์สได้อย่างไร
อย่างไรก็ตาม Istio ไม่ใช่ตัวเลือกเดียวเนื่องจากการใช้งาน Service Mesh อื่นๆ กำลังได้รับการพัฒนา ลวดลาย sidecar proxy เป็นการใช้งานที่ได้รับความนิยมมากที่สุด ซึ่งสามารถตัดสินได้จากโครงการ Buoyant, HashiCorp, Solo.io และอื่นๆ นอกจากนี้ยังมีสถาปัตยกรรมทางเลือกอีกด้วย: ชุดเครื่องมือเทคโนโลยีของ Netflix เป็นหนึ่งในแนวทางที่ใช้ฟังก์ชัน Service Mesh ผ่านไลบรารี Ribbon, Hysterix, Eureka, Archaius รวมถึงแพลตฟอร์มต่างๆ เช่น Azure Service Fabric
Service Mesh ยังมีคำศัพท์เฉพาะสำหรับส่วนประกอบและฟังก์ชันของบริการ:
- กรอบการประสานคอนเทนเนอร์. เนื่องจากมีการเพิ่มคอนเทนเนอร์ลงในโครงสร้างพื้นฐานของแอปพลิเคชันมากขึ้นเรื่อยๆ จึงจำเป็นต้องมีเครื่องมือแยกต่างหากสำหรับการตรวจสอบและจัดการคอนเทนเนอร์ ซึ่งก็คือเฟรมเวิร์กการประสานคอนเทนเนอร์ Kubernetes ยึดครองกลุ่มเฉพาะนี้อย่างมั่นคง มากเสียจนแม้แต่คู่แข่งหลักอย่าง Docker Swarm และ Mesosphere DC/OS ก็เสนอการผสานรวมกับ Kubernetes เป็นทางเลือกแทน
- บริการและอินสแตนซ์ (Kubernetes Pods). อินสแตนซ์คือสำเนาไมโครเซอร์วิสที่ทำงานอยู่ชุดเดียว บางครั้งอินสแตนซ์หนึ่งก็คือคอนเทนเนอร์เดียว ใน Kubernetes อินสแตนซ์ประกอบด้วยคอนเทนเนอร์อิสระกลุ่มเล็กๆ ที่เรียกว่าพ็อด ลูกค้าไม่ค่อยเข้าถึงอินสแตนซ์หรือพ็อดโดยตรง บ่อยครั้งที่เข้าถึงบริการซึ่งเป็นชุดของอินสแตนซ์หรือพ็อดที่เหมือนกัน ปรับขนาดได้ และทนทานต่อข้อผิดพลาด (แบบจำลอง)
- พร็อกซีรถไซด์คาร์. Sidecar Proxy ใช้งานได้กับอินสแตนซ์หรือพ็อดเดียว จุดประสงค์ของ Sidecar Proxy คือการกำหนดเส้นทางหรือการรับส่งข้อมูลพร็อกซีที่มาจากคอนเทนเนอร์ที่ใช้งานได้และส่งกลับการรับส่งข้อมูล Sidecar โต้ตอบกับ Sidecar Proxies อื่นๆ และได้รับการจัดการโดยกรอบงานการจัดการ การใช้งาน Service Mesh หลายอย่างใช้ Sidecar Proxy เพื่อสกัดกั้นและจัดการการรับส่งข้อมูลทั้งหมดเข้าและออกจากอินสแตนซ์หรือพ็อด
- การค้นพบบริการ. เมื่ออินสแตนซ์จำเป็นต้องสื่อสารกับบริการอื่น อินสแตนซ์จะต้องค้นหา (ค้นพบ) อินสแตนซ์ที่มีประสิทธิภาพและพร้อมใช้งานของบริการอื่น ๆ โดยทั่วไปแล้ว อินสแตนซ์จะทำการค้นหา DNS กรอบงานการจัดการคอนเทนเนอร์จะรักษารายการอินสแตนซ์ที่พร้อมรับคำขอและจัดเตรียมอินเทอร์เฟซสำหรับการสืบค้น DNS
- โหลดบาลานซ์. กรอบงานการประสานคอนเทนเนอร์ส่วนใหญ่จัดให้มีการปรับสมดุลโหลดที่เลเยอร์ 4 (การขนส่ง) Service Mesh ใช้การปรับสมดุลโหลดที่ซับซ้อนมากขึ้นที่เลเยอร์ 7 (ระดับแอปพลิเคชัน) ซึ่งมีอัลกอริธึมมากมาย และมีประสิทธิภาพมากขึ้นในการจัดการการรับส่งข้อมูล การตั้งค่าการปรับสมดุลโหลดสามารถเปลี่ยนแปลงได้โดยใช้ API ซึ่งช่วยให้คุณสามารถประสานการปรับใช้สีน้ำเงิน-เขียวหรือแบบ Canary ได้
- การเข้ารหัส. Service Mesh สามารถเข้ารหัสและถอดรหัสคำขอและการตอบกลับ ซึ่งช่วยขจัดภาระนี้ออกจากบริการ Service Mesh ยังสามารถปรับปรุงประสิทธิภาพโดยการจัดลำดับความสำคัญหรือนำการเชื่อมต่อถาวรที่มีอยู่กลับมาใช้ใหม่ ซึ่งช่วยลดความจำเป็นในการคำนวณราคาแพงเพื่อสร้างการเชื่อมต่อใหม่ การใช้งานการเข้ารหัสการรับส่งข้อมูลที่พบบ่อยที่สุดคือ TLS ร่วมกัน (mTLS)โดยที่โครงสร้างพื้นฐานคีย์สาธารณะ (PKI) สร้างและแจกจ่ายใบรับรองและคีย์สำหรับใช้งานโดย Sidecar Proxy
- การรับรองความถูกต้องและการอนุญาต. Service Mesh สามารถอนุญาตและรับรองความถูกต้องของคำขอที่สร้างจากภายนอกหรือภายในแอปพลิเคชัน โดยส่งเฉพาะคำขอที่ได้รับการตรวจสอบแล้วไปยังอินสแตนซ์เท่านั้น
- รองรับรูปแบบการปิดเครื่องอัตโนมัติ. รองรับบริการตาข่าย ซึ่งแยกอินสแตนซ์ที่ไม่ดีต่อสุขภาพออก จากนั้นค่อยๆ ส่งกลับไปยังกลุ่มอินสแตนซ์ที่ดีต่อสุขภาพเมื่อจำเป็น
เรียกว่าส่วนหนึ่งของแอปพลิเคชัน Service Mesh ที่จัดการการรับส่งข้อมูลเครือข่ายระหว่างอินสแตนซ์ ระนาบข้อมูล. สร้างและปรับใช้การกำหนดค่าที่ควบคุมพฤติกรรม ระนาบข้อมูลจะดำเนินการโดยใช้แยกต่างหาก เครื่องบินควบคุม. เครื่องบินควบคุม โดยทั่วไปจะรวมหรือออกแบบมาเพื่อเชื่อมต่อกับ API, CLI หรือ GUI เพื่อควบคุมแอปพลิเคชัน
Control Plane ใน Service Mesh กระจายการกำหนดค่าระหว่าง Sidecar Proxy และ Data Plane
สถาปัตยกรรม Service Mesh มักใช้เพื่อแก้ไขปัญหาการดำเนินงานที่ซับซ้อนโดยใช้คอนเทนเนอร์และไมโครเซอร์วิส ผู้บุกเบิกในสนาม เป็นบริษัทเช่น Lyft, Netflix และ Twitter ซึ่งให้บริการที่มีเสถียรภาพแก่ผู้ใช้หลายล้านคนทั่วโลก (). สำหรับแอปพลิเคชันที่มีความต้องการน้อยกว่า สถาปัตยกรรมที่เรียบง่ายก็น่าจะเพียงพอแล้ว
สถาปัตยกรรม Service Mesh ไม่น่าจะตอบโจทย์การทำงานของแอปพลิเคชันและปัญหาการส่งมอบทั้งหมดได้ สถาปนิกและนักพัฒนามีเครื่องมือมากมายและมีเพียงหนึ่งในนั้นเท่านั้นที่เป็นค้อนซึ่งในหลาย ๆ งานจะต้องแก้ไขเพียงเล็บตอกเท่านั้น ตัวอย่างเช่น มีโมเดลที่แตกต่างกันหลายแบบที่ให้แนวทางการแก้ปัญหาอย่างต่อเนื่องโดยใช้ไมโครเซอร์วิส
องค์ประกอบที่มารวมกันในสถาปัตยกรรม Service Mesh เช่น NGINX, คอนเทนเนอร์, Kubernetes และไมโครเซอร์วิสเป็นแนวทางทางสถาปัตยกรรม สามารถให้ประสิทธิผลเท่าเทียมกันในการใช้งานที่ไม่ใช่ Service Mesh ตัวอย่างเช่น Istio ได้รับการออกแบบให้เป็นสถาปัตยกรรม Service Mesh ที่สมบูรณ์ แต่ความเป็นโมดูลทำให้นักพัฒนาสามารถเลือกและใช้งานเฉพาะส่วนประกอบทางเทคโนโลยีที่ต้องการเท่านั้น ด้วยเหตุนี้ การพัฒนาความเข้าใจที่ชัดเจนเกี่ยวกับแนวคิด Service Mesh จึงเป็นสิ่งสำคัญ แม้ว่าคุณจะไม่แน่ใจว่าจะสามารถนำไปใช้งานในแอปพลิเคชันของคุณได้อย่างเต็มที่ก็ตาม
ที่มา: will.com