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

บล็อกก่อนหน้าบางส่วนใน 101 Series มีดังนี้:

API 101
Async Communication 101 ฐานข้อมูล 101 การออกแบบฐานข้อมูล 101 กลยุทธ์การปรับใช้ 101

รูปแบบเอกอัครราชทูตคืออะไร?

Ambassador เป็นกรณีพิเศษของรูปแบบ ide-car ซึ่งจะถ่ายฟังก์ชันการเชื่อมต่อไคลเอ็นต์ทั่วไป เช่นการตรวจสอบ การบันทึก การกำหนดเส้นทาง ความปลอดภัย ความยืดหยุ่นโดยใช้บริการ/คอนเทนเนอร์ที่อยู่ร่วมกัน (ในกรณีของการปรับใช้บน Kubernetes/Docker) บริการ Ambassador ทำหน้าที่เป็นโซลูชันพร็อกซีที่ใช้ซ้ำได้สำหรับบริการดั้งเดิมที่เขียนในหลายภาษาและเฟรมเวิร์กโดยนำเสนอคุณลักษณะ L7 เช่น การลองใหม่ HTTP รูปแบบเบรกเกอร์ การแก้ไขส่วนหัวของคำขอ ฯลฯ การเผยแพร่ Ambassador และโครงสร้างพื้นฐานสามารถเผยแพร่และปรับขนาดได้โดยไม่ขึ้นอยู่กับธุรกิจ แอปพลิเคชัน/คอนเทนเนอร์ ทำให้เป็นตัวเลือกที่เหมาะสมสำหรับการปิดความต้องการที่ไม่อยู่ในหน้าที่ของโดเมนธุรกิจ

เอกอัครราชทูตในฐานะ SideCar

ลำดับการไหล

1. Application Container ส่งคำขอไปยังService B/Service C ระยะไกล ผ่านAmbassador Proxy
2. Proxy SideCar เพิ่มข้อมูลการติดตามไปยังส่วนหัวของคำขอ ยังเข้ารหัสคำขอด้วยการเพิ่มใบรับรองสำหรับTLS ร่วมกัน นอกจากนี้ยังเริ่มวัดเวลาแฝงของคำขอ
3. Remote Service B/Service Cได้รับคำขอและตรวจสอบส่วนหัวของคำขอก่อนที่จะส่งข้อความตอบกลับ
4. รถฝั่ง Ambassador ได้รับการตอบกลับและบันทึกเวลาแฝงของคำขอ
5. Application Container ได้รับการตอบกลับครั้งสุดท้าย

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

ข้อจำกัด

1. คำขอแอปพลิเคชันที่มีความต้องการเวลาแฝงที่สำคัญและการเดินทางไปกลับปลายทาง 2 จุดอาจได้รับผลกระทบจากพร็อกซีรถด้านข้างเพิ่มเติม
2. แอปพลิเคชันที่มีความต้องการด้านการเชื่อมต่อถูกรวมเข้ากับรหัส/ภาษาของไคลเอ็นต์อย่างลึกซึ้ง และการแยกคำขอผ่านพร็อกซีนั้นไม่สามารถปรับขนาดได้

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

สำหรับข้อเสนอแนะ โปรดส่งข้อความไปที่amit[dot]894[at]gmail[dot]comหรือติดต่อลิงก์ใดก็ได้ที่https://about.me/amit_raj