การแปลบทความ: โมเดลการร้อยด้ายทูต - https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310

ฉันพบว่าบทความนี้ค่อนข้างน่าสนใจ และเนื่องจากส่วนใหญ่มักใช้ Envoy เป็นส่วนหนึ่งของ "istio" หรือเรียกง่ายๆ ว่า "ตัวควบคุมทางเข้า" ของ kubernetes คนส่วนใหญ่จึงไม่มีปฏิสัมพันธ์โดยตรงกับมันเหมือนกับ ตัวอย่างเช่น กับทั่วไป การติดตั้ง Nginx หรือ Haproxy อย่างไรก็ตาม หากมีสิ่งใดเสียหาย เป็นการดีที่จะเข้าใจว่ามันทำงานจากภายในอย่างไร ฉันพยายามแปลข้อความเป็นภาษารัสเซียให้มากที่สุดเท่าที่จะเป็นไปได้ รวมถึงคำพิเศษด้วย สำหรับผู้ที่พบว่ามันเจ็บปวดเมื่อมองดูสิ่งนี้ ฉันทิ้งต้นฉบับไว้ในวงเล็บ ยินดีต้อนรับสู่แมว

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

คำถามทางเทคนิคที่พบบ่อยที่สุดข้อหนึ่งที่ฉันได้รับเกี่ยวกับ Envoy คือการขอคำอธิบายระดับต่ำของโมเดลเธรดที่ใช้ ในโพสต์นี้ ฉันจะอธิบายว่า Envoy จับคู่การเชื่อมต่อกับเธรดอย่างไร รวมถึงระบบ Thread Local Storage ที่ใช้ภายในเพื่อทำให้โค้ดขนานกันและมีประสิทธิภาพสูงยิ่งขึ้น

ภาพรวมการทำเกลียว

Envoy ใช้สตรีมที่แตกต่างกันสามประเภท:

หลัก: เธรดนี้ควบคุมการเริ่มต้นและการสิ้นสุดกระบวนการ การประมวลผลทั้งหมดของ XDS (xDiscovery Service) API รวมถึง DNS การตรวจสอบสภาพ การจัดการคลัสเตอร์และรันไทม์ทั่วไป การรีเซ็ตสถิติ การดูแลระบบ และการจัดการกระบวนการทั่วไป - สัญญาณ Linux การรีสตาร์ทแบบด่วน ฯลฯ ทุกสิ่งที่ เกิดขึ้นในเธรดนี้เป็นแบบอะซิงโครนัสและ "ไม่บล็อก" โดยทั่วไป เธรดหลักจะประสานกระบวนการทำงานที่สำคัญทั้งหมดที่ไม่ต้องใช้ CPU จำนวนมากในการทำงาน ซึ่งช่วยให้โค้ดควบคุมส่วนใหญ่สามารถเขียนได้เหมือนกับว่าเป็นเธรดเดี่ยว
คนงาน: ตามค่าเริ่มต้น Envoy จะสร้างเธรดผู้ปฏิบัติงานสำหรับแต่ละเธรดฮาร์ดแวร์ในระบบ ซึ่งสามารถควบคุมได้โดยใช้ตัวเลือก --concurrency. เธรดของผู้ปฏิบัติงานแต่ละเธรดจะรันลูปเหตุการณ์ "ไม่บล็อก" ซึ่งมีหน้าที่รับผิดชอบในการฟังผู้ฟังแต่ละคน ในขณะที่เขียน (29 กรกฎาคม 2017) จะไม่มีการแบ่งส่วนของผู้ฟัง ยอมรับการเชื่อมต่อใหม่ การสร้างอินสแตนซ์ตัวกรองสแต็กสำหรับ การเชื่อมต่อ และการประมวลผลการดำเนินการอินพุต/เอาท์พุต (IO) ทั้งหมดตลอดอายุการใช้งานของการเชื่อมต่อ อีกครั้ง สิ่งนี้อนุญาตให้เขียนโค้ดการจัดการการเชื่อมต่อส่วนใหญ่ราวกับว่าเป็นเธรดเดี่ยว
ตัวล้างไฟล์: แต่ละไฟล์ที่ Envoy เขียน ซึ่งส่วนใหญ่เป็นบันทึกการเข้าถึง ปัจจุบันมีเธรดการบล็อกที่เป็นอิสระ นี่เป็นเพราะความจริงที่ว่าการเขียนไปยังไฟล์ที่แคชโดยระบบไฟล์แม้ในขณะที่ใช้งาน O_NONBLOCK บางทีก็โดนบล็อกได้นะ (ถอนหายใจ) เมื่อเธรดผู้ปฏิบัติงานจำเป็นต้องเขียนลงไฟล์ ข้อมูลจะถูกย้ายไปยังบัฟเฟอร์ในหน่วยความจำ ซึ่งในที่สุดข้อมูลจะถูกล้างผ่านเธรด ไฟล์ฟลัช. นี่คือพื้นที่หนึ่งของโค้ดที่ในทางเทคนิคแล้วเธรดของผู้ปฏิบัติงานทั้งหมดสามารถบล็อกการล็อกเดียวกันในขณะที่พยายามเติมบัฟเฟอร์หน่วยความจำ

การจัดการการเชื่อมต่อ

ตามที่กล่าวไว้สั้นๆ ข้างต้น เธรดของผู้ปฏิบัติงานทั้งหมดจะรับฟัง Listener ทั้งหมดโดยไม่มีการแบ่งส่วนใดๆ ดังนั้นเคอร์เนลจึงถูกใช้เพื่อส่งซ็อกเก็ตที่ได้รับการยอมรับไปยังเธรดของผู้ปฏิบัติงานอย่างสวยงาม โดยทั่วไปแล้วเคอร์เนลสมัยใหม่จะทำได้ดีมากในเรื่องนี้ พวกเขาใช้คุณสมบัติเช่นการเพิ่มลำดับความสำคัญของอินพุต/เอาท์พุต (IO) เพื่อพยายามเติมเธรดด้วยงานก่อนที่จะเริ่มใช้เธรดอื่น ๆ ที่กำลังฟังบนซ็อกเก็ตเดียวกันและไม่ได้ใช้แบบโรบิน การล็อค (Spinlock) เพื่อดำเนินการแต่ละคำขอ
เมื่อการเชื่อมต่อได้รับการยอมรับบนเธรดของผู้ปฏิบัติงานแล้ว จะไม่ออกจากเธรดนั้น การประมวลผลการเชื่อมต่อเพิ่มเติมทั้งหมดได้รับการจัดการทั้งหมดในเธรดของผู้ปฏิบัติงาน รวมถึงพฤติกรรมการส่งต่อด้วย

สิ่งนี้มีผลกระทบที่สำคัญหลายประการ:

พูลการเชื่อมต่อทั้งหมดใน Envoy ถูกกำหนดให้กับเธรดของผู้ปฏิบัติงาน ดังนั้น แม้ว่าพูลการเชื่อมต่อ HTTP/2 จะสร้างการเชื่อมต่อเพียงครั้งเดียวไปยังแต่ละโฮสต์อัปสตรีมในแต่ละครั้ง หากมีเธรดของผู้ปฏิบัติงานสี่เธรด ก็จะมีการเชื่อมต่อ HTTP/2 สี่รายการต่อโฮสต์อัปสตรีมในสถานะคงที่
เหตุผลที่ Envoy ทำงานในลักษณะนี้ก็คือ ด้วยการเก็บทุกอย่างไว้ในเธรดของผู้ปฏิบัติงานเพียงเธรดเดียว โค้ดเกือบทั้งหมดจึงสามารถเขียนได้โดยไม่ต้องปิดกั้น และเหมือนกับว่าเป็นเธรดเดี่ยว การออกแบบนี้ทำให้ง่ายต่อการเขียนโค้ดจำนวนมาก และปรับขนาดได้อย่างเหลือเชื่อจนรองรับเธรดของผู้ปฏิบัติงานได้ไม่จำกัดจำนวน
อย่างไรก็ตาม ประเด็นหลักประการหนึ่งคือจากพูลหน่วยความจำและจุดยืนด้านประสิทธิภาพการเชื่อมต่อ จริงๆ แล้วการกำหนดค่า --concurrency. การมีเธรดของผู้ปฏิบัติงานมากกว่าที่จำเป็นจะทำให้สิ้นเปลืองหน่วยความจำ สร้างการเชื่อมต่อที่ไม่ได้ใช้งานมากขึ้น และลดอัตราการรวมการเชื่อมต่อ ที่ Lyft ตู้คอนเทนเนอร์สำหรับตัวแทนของเราทำงานพร้อมกันต่ำมาก ดังนั้นประสิทธิภาพจึงใกล้เคียงกับบริการที่พวกเขานั่งข้างๆ โดยประมาณ เราเรียกใช้ Envoy เป็น Edge Proxy เมื่อมีการทำงานพร้อมกันสูงสุดเท่านั้น

การไม่ปิดกั้นหมายถึงอะไร?

คำว่า "ไม่บล็อก" ถูกใช้หลายครั้งแล้วเมื่อพูดถึงวิธีการทำงานของเธรดหลักและเธรดผู้ปฏิบัติงาน รหัสทั้งหมดเขียนบนสมมติฐานว่าไม่มีอะไรถูกบล็อก อย่างไรก็ตาม สิ่งนี้ไม่เป็นความจริงทั้งหมด (สิ่งที่ไม่เป็นความจริงทั้งหมด?)

ทูตใช้การล็อคกระบวนการที่ยาวหลายอย่าง:

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

เธรดที่จัดเก็บในตัวเครื่อง

เนื่องจากวิธีที่ Envoy แยกความรับผิดชอบของเธรดหลักจากความรับผิดชอบของเธรดของผู้ปฏิบัติงาน มีข้อกำหนดว่าการประมวลผลที่ซับซ้อนสามารถทำได้บนเธรดหลัก จากนั้นมอบให้กับเธรดของผู้ปฏิบัติงานแต่ละรายในลักษณะที่เกิดขึ้นพร้อมกันอย่างมาก ส่วนนี้จะอธิบาย Envoy Thread Local Storage (TLS) ในระดับสูง ในส่วนถัดไป ผมจะอธิบายวิธีการใช้ในการจัดการคลัสเตอร์

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

ระบบ TLS (Thread local storage) ของ Envoy ทำงานดังนี้:

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

แม้ว่าจะเป็นกระบวนทัศน์ที่เรียบง่ายและมีประสิทธิภาพอย่างเหลือเชื่อ แต่ก็คล้ายกับแนวคิดของการบล็อก RCU (Read-Copy-Update) มาก โดยพื้นฐานแล้ว เธรดของผู้ปฏิบัติงานจะไม่เห็นการเปลี่ยนแปลงข้อมูลใดๆ ในช่อง TLS ในขณะที่งานกำลังทำงานอยู่ การเปลี่ยนแปลงเกิดขึ้นเฉพาะในช่วงเวลาที่เหลือระหว่างกิจกรรมการทำงานเท่านั้น

ทูตใช้สิ่งนี้ในสองวิธี:

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

เธรดการอัปเดตคลัสเตอร์

ในส่วนนี้ ผมจะอธิบายวิธีใช้ TLS (Thread local storage) ในการจัดการคลัสเตอร์ การจัดการคลัสเตอร์ประกอบด้วย xDS API และ/หรือการประมวลผล DNS ตลอดจนการตรวจสอบสภาพ

การจัดการโฟลว์คลัสเตอร์ประกอบด้วยส่วนประกอบและขั้นตอนต่อไปนี้:

Cluster Manager เป็นส่วนประกอบภายใน Envoy ที่จัดการอัพสตรีมคลัสเตอร์ที่รู้จักทั้งหมด, Cluster Discovery Service (CDS) API, Secret Discovery Service (SDS) และ Endpoint Discovery Service (EDS) API, DNS และการตรวจสอบภายนอกที่ใช้งานอยู่ การตรวจสุขภาพ มีหน้าที่รับผิดชอบในการสร้างมุมมอง "ที่สอดคล้องกันในที่สุด" ของแต่ละคลัสเตอร์ต้นทาง ซึ่งรวมถึงโฮสต์ที่ค้นพบและสถานะความสมบูรณ์
ตัวตรวจสอบสภาพทำการตรวจสอบสภาพที่ใช้งานอยู่และรายงานการเปลี่ยนแปลงสถานะความสมบูรณ์ไปยังผู้จัดการคลัสเตอร์
CDS (Cluster Discovery Service) / SDS (Secret Discovery Service) / EDS (Endpoint Discovery Service) / DNS ดำเนินการเพื่อกำหนดความเป็นสมาชิกคลัสเตอร์ การเปลี่ยนแปลงสถานะจะถูกส่งกลับไปยังตัวจัดการคลัสเตอร์
แต่ละเธรดของผู้ปฏิบัติงานดำเนินการวนรอบเหตุการณ์อย่างต่อเนื่อง
เมื่อตัวจัดการคลัสเตอร์พิจารณาว่าสถานะของคลัสเตอร์มีการเปลี่ยนแปลง ระบบจะสร้างสแน็ปช็อตแบบอ่านอย่างเดียวใหม่ของสถานะของคลัสเตอร์ และส่งไปยังแต่ละเธรดของผู้ปฏิบัติงาน
ในช่วงระยะเวลาที่เงียบสงบครั้งถัดไป เธรดของผู้ปฏิบัติงานจะอัปเดตสแนปช็อตในช่อง TLS ที่จัดสรร
ในระหว่างเหตุการณ์ I/O ที่ควรกำหนดโฮสต์เพื่อโหลดบาลานซ์ โหลดบาลานเซอร์จะขอสล็อต TLS (Thread local storage) เพื่อรับข้อมูลเกี่ยวกับโฮสต์ สิ่งนี้ไม่จำเป็นต้องล็อค โปรดทราบว่า TLS ยังสามารถทริกเกอร์เหตุการณ์การอัปเดตเพื่อให้โหลดบาลานเซอร์และส่วนประกอบอื่นๆ สามารถคำนวณแคช โครงสร้างข้อมูล ฯลฯ อีกครั้ง สิ่งนี้อยู่นอกเหนือขอบเขตของโพสต์นี้ แต่มีการใช้ในตำแหน่งต่างๆ ในโค้ด

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

ระบบย่อยอื่นๆ ที่ใช้ TLS

TLS (ที่จัดเก็บในเครื่องเธรด) และ RCU (อัปเดตการอ่านสำเนา) ถูกนำมาใช้กันอย่างแพร่หลายใน Envoy

ตัวอย่างของการใช้:

กลไกในการเปลี่ยนฟังก์ชันการทำงานระหว่างการดำเนินการ: รายการฟังก์ชันที่เปิดใช้งานในปัจจุบันได้รับการคำนวณในเธรดหลัก จากนั้นเธรดผู้ปฏิบัติงานแต่ละเธรดจะได้รับสแน็ปช็อตแบบอ่านอย่างเดียวโดยใช้ซีแมนทิกส์ RCU
การเปลี่ยนตารางเส้นทาง: สำหรับตารางเส้นทางที่จัดทำโดย RDS (Route Discovery Service) ตารางเส้นทางจะถูกสร้างขึ้นบนเธรดหลัก สแน็ปช็อตแบบอ่านอย่างเดียวจะถูกจัดเตรียมให้กับแต่ละเธรดของผู้ปฏิบัติงานในภายหลังโดยใช้ซีแมนทิกส์ RCU (การอัปเดตสำเนาการอ่าน) ทำให้การเปลี่ยนตารางเส้นทางมีประสิทธิภาพแบบอะตอมมิก
การแคชส่วนหัว HTTP: ปรากฎว่าการคำนวณส่วนหัว HTTP สำหรับแต่ละคำขอ (ในขณะที่ใช้งาน ~25K+ RPS ต่อคอร์) มีราคาค่อนข้างแพง Envoy คำนวณส่วนหัวจากส่วนกลางทุกๆ ครึ่งวินาทีโดยประมาณ และมอบให้กับผู้ปฏิบัติงานแต่ละคนผ่าน TLS และ RCU

ยังมีกรณีอื่นๆ อีก แต่ตัวอย่างก่อนหน้านี้ควรให้ความเข้าใจที่ดีว่า TLS ใช้เพื่ออะไร

ข้อผิดพลาดด้านประสิทธิภาพที่ทราบ

แม้ว่า Envoy จะทำงานได้ค่อนข้างดีโดยรวม แต่ก็มีประเด็นสำคัญบางประการที่ต้องให้ความสนใจเมื่อใช้กับการทำงานพร้อมกันและปริมาณงานที่สูงมาก:

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

บทสรุป

โมเดลเธรดของ Envoy ได้รับการออกแบบมาเพื่อให้ง่ายต่อการเขียนโปรแกรมและการขนานกันอย่างมาก โดยสูญเสียหน่วยความจำและการเชื่อมต่อที่อาจสิ้นเปลืองหากกำหนดค่าไม่ถูกต้อง รุ่นนี้ช่วยให้สามารถทำงานได้ดีมากที่จำนวนเธรดและปริมาณงานที่สูงมาก
ดังที่ฉันได้กล่าวไว้สั้น ๆ บน Twitter การออกแบบยังสามารถทำงานบนสแต็กเครือข่ายโหมดผู้ใช้เต็มรูปแบบ เช่น DPDK (Data Plane Development Kit) ซึ่งอาจส่งผลให้เซิร์ฟเวอร์ทั่วไปจัดการคำขอนับล้านต่อวินาทีด้วยการประมวลผล L7 เต็มรูปแบบ มันจะน่าสนใจมากที่จะได้เห็นสิ่งที่สร้างขึ้นในอีกไม่กี่ปีข้างหน้า
ความคิดเห็นสั้นๆ สุดท้ายนี้: มีคนถามหลายครั้งว่าทำไมเราถึงเลือก C++ สำหรับ Envoy เหตุผลยังคงอยู่ที่ยังคงเป็นภาษาเกรดอุตสาหกรรมเพียงภาษาเดียวที่ใช้กันอย่างแพร่หลายซึ่งสถาปัตยกรรมที่อธิบายไว้ในโพสต์นี้สามารถสร้างได้ C++ ไม่เหมาะกับทุกโปรเจ็กต์หรือหลายโปรเจ็กต์อย่างแน่นอน แต่สำหรับกรณีการใช้งานบางกรณี ยังคงเป็นเพียงเครื่องมือเดียวในการทำงานให้สำเร็จ

ลิงค์ไปยังรหัส

ลิงก์ไปยังไฟล์ที่มีอินเทอร์เฟซและการใช้งานส่วนหัวที่กล่าวถึงในโพสต์นี้:

ที่มา: will.com

[แปล] แบบจำลองการร้อยด้ายทูต