เฮ้ ฮับ! ฉันขอเสนอการแปลบทความให้คุณทราบ นักบิน แมตต์ไคลน์.
คราวนี้ ฉัน “ต้องการและแปล” คำอธิบายเกี่ยวกับส่วนประกอบ Service Mesh, Data Plane และ Control Plane คำอธิบายนี้ดูเหมือนเป็นสิ่งที่เข้าใจได้และน่าสนใจที่สุดสำหรับฉัน และที่สำคัญที่สุดคือนำไปสู่ความเข้าใจที่ว่า “จำเป็นเลยเหรอ?”
เนื่องจากแนวคิดเรื่อง "Service mesh" ได้รับความนิยมมากขึ้นในช่วงสองปีที่ผ่านมา (บทความต้นฉบับเมื่อวันที่ 10 ตุลาคม 2017) และจำนวนผู้เข้าร่วมในพื้นที่เพิ่มขึ้น ฉันจึงเห็นความสับสนที่เพิ่มขึ้นพอสมควรในหมู่คนทั้งหมด ชุมชนเทคโนโลยีเกี่ยวกับวิธีเปรียบเทียบและเปรียบเทียบโซลูชันต่างๆ
สถานการณ์สามารถสรุปได้ดีที่สุดโดยทวีตชุดต่อไปนี้ที่ฉันเขียนในเดือนกรกฎาคม:
ความสับสนในการให้บริการ #1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy ไม่มีใครเทียบได้กับ Istio Istio เป็นสิ่งที่แตกต่างอย่างสิ้นเชิง 1 /
อย่างแรกคือระนาบข้อมูล ตนเองไม่ได้ทำอะไรเลย พวกเขาคงมีอารมณ์อยากทำอะไรมากกว่านี้ 2/
Istio เป็นตัวอย่างของระนาบควบคุมที่เชื่อมโยงส่วนต่างๆ เข้าด้วยกัน นี่เป็นอีกชั้นหนึ่ง /จบ
ทวีตก่อนหน้านี้กล่าวถึงโปรเจ็กต์ต่างๆ มากมาย (Linkerd, NGINX, HAProxy, Envoy และ Istio) แต่ที่สำคัญกว่านั้นคือแนะนำแนวคิดทั่วไปของ Data Plane, Service Mesh และ Control Plane ในโพสต์นี้ ฉันจะย้อนกลับไปและพูดถึงสิ่งที่ฉันหมายถึงโดยคำว่า "ระนาบข้อมูล" และ "ระนาบควบคุม" ในระดับที่สูงมาก จากนั้นพูดคุยเกี่ยวกับวิธีที่ข้อกำหนดนี้นำไปใช้กับโครงการที่กล่าวถึงในทวีต
Service Mesh คืออะไร จริงๆ แล้วคืออะไร?
รูปที่ 1: ภาพรวมของ Service Mesh
1 รูป แสดงให้เห็นแนวคิดของโครงข่ายบริการในระดับพื้นฐานที่สุด มีคลัสเตอร์บริการ (AD) อยู่สี่กลุ่ม แต่ละอินสแตนซ์บริการเชื่อมโยงกับพร็อกซีเซิร์ฟเวอร์ในเครื่อง การรับส่งข้อมูลเครือข่ายทั้งหมด (HTTP, REST, gRPC, Redis ฯลฯ) จากอินสแตนซ์แอปพลิเคชันเดียวจะถูกส่งผ่านพร็อกซีในเครื่องไปยังคลัสเตอร์บริการภายนอกที่เหมาะสม ด้วยวิธีนี้ อินสแตนซ์ของแอปพลิเคชันจะไม่ทราบถึงเครือข่ายโดยรวมและทราบเฉพาะพร็อกซีในเครื่องเท่านั้น ส่งผลให้เครือข่ายระบบแบบกระจายถูกลบออกจากบริการ
เครื่องบินข้อมูล
ในบริการตาข่าย พร็อกซีเซิร์ฟเวอร์ที่อยู่ในเครื่องสำหรับแอปพลิเคชันจะดำเนินการต่อไปนี้:
- การค้นพบบริการ. มีบริการ/แอปพลิเคชันใดบ้างสำหรับการสมัครของคุณ?
- ตรวจสุขภาพ. อินสแตนซ์บริการที่ส่งคืนโดยการค้นพบบริการมีประสิทธิภาพดีและพร้อมที่จะยอมรับการรับส่งข้อมูลเครือข่ายหรือไม่ ซึ่งอาจรวมถึงการตรวจสุขภาพทั้งแบบแอ็คทีฟ (เช่น การตอบสนอง/การตรวจสภาพ) และแบบพาสซีฟ (เช่น การใช้ข้อผิดพลาด 3xx 5 ครั้งติดต่อกันเพื่อบ่งชี้ถึงสถานะบริการที่ไม่แข็งแรง)
- การกำหนดเส้นทาง. เมื่อได้รับคำขอ "/foo" จากบริการ REST คลัสเตอร์บริการใดควรส่งคำขอไปที่
- โหลดบาลานซ์. เมื่อเลือกคลัสเตอร์บริการระหว่างการกำหนดเส้นทางแล้ว ควรส่งคำขอไปยังอินสแตนซ์บริการใด หมดเวลาเท่าไร? ด้วยการตั้งค่าการตัดวงจรแบบใด? หากคำขอล้มเหลว ควรจะลองอีกครั้งหรือไม่
- การรับรองความถูกต้องและการอนุญาต. สำหรับคำขอที่เข้ามา สามารถระบุ/อนุญาตบริการการโทรด้วยการเข้ารหัสโดยใช้ mTLS หรือกลไกอื่นได้หรือไม่ หากได้รับการยอมรับ/ได้รับอนุญาต จะอนุญาตให้เรียกใช้การดำเนินการที่ร้องขอ (จุดสิ้นสุด) บนบริการได้หรือไม่ หรือควรส่งคืนการตอบสนองที่ไม่ผ่านการตรวจสอบสิทธิ์หรือไม่
- ความสามารถในการสังเกต. ควรสร้างสถิติโดยละเอียด บันทึก/บันทึก และข้อมูลการติดตามแบบกระจายสำหรับแต่ละคำขอ เพื่อให้ผู้ปฏิบัติงานเข้าใจกระแสการรับส่งข้อมูลแบบกระจายและปัญหาการแก้ไขจุดบกพร่องที่เกิดขึ้น
ส่วนข้อมูลมีหน้าที่รับผิดชอบจุดก่อนหน้าทั้งหมดในโครงข่ายบริการ อันที่จริงแล้ว พร็อกซีในเครื่องของบริการ (รถเทียมข้างรถจักรยานยนต์) คือระนาบข้อมูล กล่าวอีกนัยหนึ่ง Data Plane มีหน้าที่รับผิดชอบในการออกอากาศ การส่งต่อ และการตรวจสอบทุกแพ็คเก็ตเครือข่ายที่ส่งไปยังหรือจากบริการตามเงื่อนไข
เครื่องบินควบคุม
นามธรรมเครือข่ายที่พร็อกซีในเครื่องมีให้ในชั้นข้อมูลนั้นช่างมหัศจรรย์(?) อย่างไรก็ตาม พร็อกซีทราบเกี่ยวกับเส้นทาง "/foo" ไปยังบริการ B ได้อย่างไร ข้อมูลการค้นพบบริการที่เติมโดยคำขอพร็อกซีสามารถนำมาใช้ได้อย่างไร พารามิเตอร์ได้รับการกำหนดค่าสำหรับการทำโหลดบาลานซ์ การหมดเวลา การตัดวงจร ฯลฯ อย่างไร คุณจะปรับใช้แอปพลิเคชันโดยใช้วิธีสีน้ำเงิน/เขียวหรือวิธีเปลี่ยนการรับส่งข้อมูลอย่างสง่างามได้อย่างไร ใครเป็นผู้กำหนดการตั้งค่าการรับรองความถูกต้องและการอนุญาตทั่วทั้งระบบ
รายการทั้งหมดที่กล่าวมาข้างต้นอยู่ภายใต้การควบคุมของระนาบควบคุมของเซอร์วิสเมช ระนาบควบคุมใช้ชุดพร็อกซีไร้สัญชาติที่แยกเดี่ยวและเปลี่ยนให้เป็นระบบแบบกระจาย.
ฉันคิดว่าเหตุผลที่นักเทคโนโลยีหลายคนพบว่าแนวคิดที่แยกจากกันของ Data Plane และ Control Plane ทำให้เกิดความสับสน เนื่องจากสำหรับคนส่วนใหญ่ Data Plane นั้นคุ้นเคย ในขณะที่ Control Plane นั้นแตกต่าง/ไม่เข้าใจ เราทำงานร่วมกับเราเตอร์และสวิตช์เครือข่ายทางกายภาพมาเป็นเวลานาน เราเข้าใจว่าแพ็กเก็ต/คำขอจำเป็นต้องไปจากจุด A ไปยังจุด B และเราสามารถใช้ฮาร์ดแวร์และซอฟต์แวร์เพื่อทำสิ่งนี้ได้ พร็อกซีซอฟต์แวร์รุ่นใหม่เป็นเพียงเครื่องมือเวอร์ชันแฟนซีที่เราใช้มาเป็นเวลานาน
รูปที่ 2: ระนาบควบคุมของมนุษย์
อย่างไรก็ตาม เราใช้ Control Plane มาเป็นเวลานาน แม้ว่าผู้ให้บริการเครือข่ายส่วนใหญ่อาจไม่เชื่อมโยงส่วนนี้ของระบบกับส่วนประกอบทางเทคโนโลยีใดๆ ก็ตาม เหตุผลง่ายๆ:
เครื่องบินควบคุมส่วนใหญ่ที่ใช้อยู่ในปัจจุบันคือ... เรา.
На รูปที่ 2 แสดงสิ่งที่ฉันเรียกว่า "เครื่องบินควบคุมของมนุษย์" ในการปรับใช้ประเภทนี้ ซึ่งยังคงพบเห็นได้ทั่วไป ผู้ปฏิบัติงานที่เป็นมนุษย์อาจไม่พอใจจะสร้างการกำหนดค่าแบบคงที่ - อาจใช้สคริปต์ - และปรับใช้ผ่านกระบวนการพิเศษบางอย่างกับพร็อกซีทั้งหมด พร็อกซีจะเริ่มใช้การกำหนดค่านี้ และเริ่มประมวลผลส่วนข้อมูลโดยใช้การตั้งค่าที่อัปเดต
รูปที่ 3: ระนาบควบคุมตาข่ายบริการขั้นสูง
На รูปที่ 3 แสดงระนาบควบคุม "ขยาย" ของเซอร์วิสเมช ประกอบด้วยส่วนต่าง ๆ ดังต่อไปนี้:
- มนุษย์: ยังมีคน (หวังว่าจะโกรธน้อยลง) ที่ทำการตัดสินใจระดับสูงเกี่ยวกับระบบทั้งหมดโดยรวม
- UI ระนาบควบคุม: บุคคลโต้ตอบกับอินเทอร์เฟซผู้ใช้บางประเภทเพื่อควบคุมระบบ นี่อาจเป็นเว็บพอร์ทัล แอปพลิเคชันบรรทัดคำสั่ง (CLI) หรืออินเทอร์เฟซอื่นๆ เมื่อใช้อินเทอร์เฟซผู้ใช้ ผู้ปฏิบัติงานสามารถเข้าถึงพารามิเตอร์การกำหนดค่าระบบส่วนกลาง เช่น:
- การควบคุมการปรับใช้ การเปลี่ยนการรับส่งข้อมูลสีน้ำเงิน/เขียว และ/หรือแบบค่อยเป็นค่อยไป
- ตัวเลือกการรับรองความถูกต้องและการอนุญาต
- ข้อกำหนดตารางเส้นทาง เช่น เมื่อแอปพลิเคชัน A ขอข้อมูลเกี่ยวกับ "/foo" จะเกิดอะไรขึ้น
- การตั้งค่าโหลดบาลานเซอร์ เช่น การหมดเวลา การลองใหม่ การตั้งค่าการตัดวงจร ฯลฯ
- ตัวกำหนดเวลาภาระงาน: บริการทำงานบนโครงสร้างพื้นฐานผ่านระบบการจัดกำหนดการ/การจัดกำหนดการบางประเภท เช่น Kubernetes หรือ Nomad ตัวกำหนดเวลามีหน้าที่รับผิดชอบในการโหลดบริการพร้อมกับพรอกซีในเครื่อง
- การค้นพบบริการ. เมื่อตัวกำหนดเวลาเริ่มและหยุดอินสแตนซ์ของบริการ จะรายงานสถานะความสมบูรณ์ไปยังระบบการค้นหาบริการ
- API การกำหนดค่าพร็อกซี Sidecar : พร็อกซีในเครื่องจะดึงสถานะจากส่วนประกอบต่างๆ ของระบบแบบไดนามิกโดยใช้โมเดลที่สอดคล้องกันในที่สุดโดยไม่มีการแทรกแซงจากผู้ปฏิบัติงาน ระบบทั้งหมด ซึ่งประกอบด้วยอินสแตนซ์บริการและพร็อกซีเซิร์ฟเวอร์ที่ทำงานอยู่ในปัจจุบัน ทั้งหมดมารวมกันเป็นระบบนิเวศเดียว Universal Data Plane API ของ Envoy เป็นตัวอย่างหนึ่งของวิธีการทำงานในทางปฏิบัติ
โดยพื้นฐานแล้ว จุดประสงค์ของ Control Plane คือการกำหนดนโยบายที่จะได้รับการยอมรับจาก Data Plane ในท้ายที่สุด ระนาบควบคุมขั้นสูงจะกำจัดบางส่วนของระบบบางส่วนออกจากผู้ปฏิบัติงาน และต้องใช้การทำงานแบบแมนนวลน้อยลง หากทำงานได้อย่างถูกต้อง!...
ระนาบข้อมูลและระนาบควบคุม สรุประนาบข้อมูลเทียบกับระนาบควบคุม
- ระนาบข้อมูลตาข่ายบริการ: ส่งผลต่อทุกแพ็คเก็ต/คำขอในระบบ รับผิดชอบในการค้นหาแอปพลิเคชัน/บริการ การตรวจสอบสภาพ การกำหนดเส้นทาง โหลดบาลานซ์ การรับรองความถูกต้อง/การอนุญาต และความสามารถในการสังเกต
- ระนาบควบคุมตาข่ายบริการ: จัดเตรียมนโยบายและการกำหนดค่าสำหรับส่วนข้อมูลที่ทำงานอยู่ทั้งหมดภายในเครือข่ายบริการ ไม่แตะต้องแพ็คเกจ/คำขอใดๆ ในระบบ Control Plane จะเปลี่ยน Data Plane ทั้งหมดเป็นระบบแบบกระจาย
ภาพรวมโครงการปัจจุบัน
เมื่อเข้าใจคำอธิบายข้างต้นแล้ว เรามาดูสถานะปัจจุบันของโปรเจ็กต์ Service Mesh กันดีกว่า
- ระนาบข้อมูล: Linkerd, NGINX, HAProxy, ทูต, Traefik
- เครื่องบินควบคุม: อิสติโอ, เนลสัน, สมาร์ทสแตค
แทนที่จะวิเคราะห์เชิงลึกของแต่ละโซลูชันข้างต้น ฉันจะพูดถึงประเด็นบางประเด็นที่ฉันเชื่อว่าก่อให้เกิดความสับสนอย่างมากในระบบนิเวศในขณะนี้
Linkerd เป็นหนึ่งในพร็อกซีเซิร์ฟเวอร์ Data Plane แรกๆ สำหรับ Service Mesh ในต้นปี 2016 และทำงานได้อย่างยอดเยี่ยมในการสร้างความตระหนักรู้และความใส่ใจต่อโมเดลการออกแบบ Service Mesh ประมาณ 6 เดือนหลังจากนั้น Envoy เข้าร่วม Linkerd (แม้ว่าเขาจะอยู่กับ Lyft มาตั้งแต่ปลายปี 2015 ก็ตาม) Linkerd และ Envoy เป็นสองโครงการที่ถูกกล่าวถึงบ่อยที่สุดเมื่อพูดถึง Service Mesh
Istio ได้รับการประกาศในเดือนพฤษภาคม 2017 เป้าหมายของโครงการ Istio นั้นคล้ายคลึงกับระนาบควบคุมแบบขยายที่แสดงไว้มาก รูปที่ 3. Envoy for Istio เป็นพร็อกซีเริ่มต้น ดังนั้น Istio จึงเป็นระนาบควบคุม และ Envoy จึงเป็นระนาบข้อมูล ในช่วงเวลาสั้นๆ Istio สร้างความตื่นตาตื่นใจอย่างมาก และ Data Plane อื่นๆ ก็เริ่มบูรณาการเพื่อทดแทน Envoy (ทั้ง Linkerd และ NGINX สาธิตการผสานรวมกับ Istio) ความจริงที่ว่าระนาบข้อมูลที่ต่างกันสามารถใช้ภายในระนาบควบคุมเดียวกันได้ หมายความว่าระนาบควบคุมและระนาบข้อมูลไม่จำเป็นต้องเชื่อมต่อกันอย่างแน่นหนา API เช่น API เครื่องบินข้อมูลทั่วไปของ Envoy สามารถสร้างสะพานเชื่อมระหว่างสองส่วนของระบบได้
Nelson และ SmartStack ช่วยอธิบายเพิ่มเติมเกี่ยวกับการแยกระนาบควบคุมและระนาบข้อมูล Nelson ใช้ Envoy เป็นพร็อกซีและสร้างระนาบควบคุมที่เชื่อถือได้สำหรับ Service Mesh โดยอิงตามสแต็ก HashiCorp เช่น เร่ร่อน เป็นต้น SmartStack อาจเป็นคลื่นลูกใหม่ของบริการ meshes SmartStack สร้าง Control Plane รอบ HAProxy หรือ NGINX ซึ่งแสดงให้เห็นถึงความสามารถในการแยก Control Plane จาก Service Mesh จาก Data Plane
สถาปัตยกรรมไมโครเซอร์วิสที่มีโครงข่ายบริการกำลังได้รับความสนใจมากขึ้นเรื่อยๆ (ถูกต้อง!) และมีโครงการและผู้จำหน่ายจำนวนมากขึ้นเรื่อยๆ ที่เริ่มทำงานในทิศทางนี้ ในอีกไม่กี่ปีข้างหน้า เราจะเห็นนวัตกรรมมากมายทั้งใน Data Plane และ Control Plane รวมถึงการผสมผสานส่วนประกอบต่างๆ เพิ่มเติม ท้ายที่สุดแล้ว สถาปัตยกรรมไมโครเซอร์วิสควรมีความโปร่งใสและมหัศจรรย์ (?) มากขึ้นสำหรับผู้ปฏิบัติงาน
หวังว่าจะหงุดหงิดน้อยลงเรื่อยๆ
ประเด็นที่สำคัญ
- Service Mesh ประกอบด้วยสองส่วนที่แตกต่างกัน: ส่วนข้อมูลและส่วนควบคุม จำเป็นต้องมีส่วนประกอบทั้งสองชิ้น และหากไม่มีส่วนประกอบดังกล่าว ระบบจะไม่ทำงาน
- ทุกคนคุ้นเคยกับระนาบควบคุม และ ณ จุดนี้ ระนาบควบคุมอาจเป็นคุณ!
- ส่วนข้อมูลทั้งหมดแข่งขันกันในเรื่องคุณสมบัติ ประสิทธิภาพ ความสามารถในการกำหนดค่า และความสามารถในการขยาย
- เครื่องบินควบคุมทั้งหมดแข่งขันกันในด้านคุณสมบัติ ความสามารถในการกำหนดค่า ความสามารถในการขยาย และความสะดวกในการใช้งาน
- Control Plane หนึ่งสามารถมี Abstractions และ API ที่ถูกต้อง เพื่อให้สามารถใช้ Data Plane หลายอันได้
ที่มา: will.com