สถาปัตยกรรมระบบ microservice หลีกเลี่ยงปัญหาคอขวดของเครือข่ายได้อย่างไร

ฉันอ่านมากเกี่ยวกับสถาปัตยกรรม microservice สำหรับแอพพลิเคชันเซิร์ฟเวอร์และสงสัยว่าการใช้เครือข่ายภายในไม่ใช่คอขวดหรือข้อเสียที่สำคัญเมื่อเทียบกับสถาปัตยกรรมเสาหิน

เพื่อความแม่นยำนี่เป็นการตีความคำสองคำของฉัน:

1. สถาปัตยกรรม Monolith:แอปพลิเคชั่นหนึ่งเดียวในภาษาเดียวที่จัดการฟังก์ชันการทำงานข้อมูลและอื่น ๆ ตัวโหลดบาลานซ์จะกระจายการร้องขอจากผู้ใช้ทั่วทั้งเครื่องหลายเครื่อง

2. สถาปัตยกรรม Microservice:แอปพลิเคชั่นจำนวนมาก (ไมโครซอฟท์) จัดการส่วนเล็ก ๆ ของฟังก์ชั่นและข้อมูล microservice แต่ละอันจะเปิดเผย API ทั่วไปที่เข้าถึงได้ผ่านเครือข่าย (ตรงข้ามกับการสื่อสารระหว่างกระบวนการหรือหน่วยความจำที่ใช้ร่วมกันบนเครื่องเดียวกัน) การเรียกใช้ API ส่วนใหญ่จะติดอยู่บนเซิร์ฟเวอร์เพื่อสร้างหน้าเว็บแม้ว่าบางงานอาจดำเนินการโดยไคลเอนต์ที่สอบถามไมโครไซต์แต่ละรายการ

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

เครือข่ายภายในมักใช้การเชื่อมต่อ 1 Gbps หรือเร็วกว่า การเชื่อมต่อใยแก้วนำแสงหรือการเชื่อมต่อช่วยให้แบนด์วิดธ์ที่สูงขึ้นระหว่างเซิร์ฟเวอร์ ตอนนี้ลองนึกภาพขนาดเฉลี่ยของการตอบสนอง JSON จาก API วิธีการตอบสนองดังกล่าวสามารถส่งผ่านการเชื่อมต่อ 1 Gbps ในหนึ่งวินาที?

ลองทำคณิตศาสตร์กันดีกว่า 1 Gbps คือ 131 072 KB ต่อวินาที หากการตอบสนอง JSON โดยเฉลี่ยคือ 5 KB (ซึ่งค่อนข้างมาก!) คุณสามารถส่งการตอบสนอง 264 214 วินาทีต่อวินาทีผ่านทางสายสัญญาณด้วยเครื่องเพียงคู่เดียว ไม่เลวเลยใช่ไหม

นี่คือเหตุผลที่การเชื่อมต่อเครือข่ายมักจะไม่ใช่คอขวด

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

นี่คือเมื่อการตอบกลับ 264 ครั้งต่อ 26 ก่อนหน้าของเราต่อวินาทีนั้นเล็กเกินไปสำหรับขนาดของแอป คุณเพิ่มอีกเก้าคู่และตอนนี้คุณสามารถตอบสนอง 262 140 คำตอบได้แล้ว

แต่กลับมาที่เซิร์ฟเวอร์คู่ของเราแล้วเปรียบเทียบกัน

• หากการสืบค้นที่ไม่แคชเฉลี่ยไปยังฐานข้อมูลใช้เวลา 10 มิลลิวินาทีคุณจะถูก จำกัด 100 การค้นหาต่อวินาที 100 ข้อความค้นหา 26 214 คำตอบ การได้รับความเร็วของการตอบสนอง 26 214 ต่อวินาทีนั้นจำเป็นต้องใช้แคชจำนวนมากและการเพิ่มประสิทธิภาพ (ถ้าการตอบสนองต้องการทำสิ่งที่มีประโยชน์เช่นการสืบค้นฐานข้อมูลการตอบสนองสไตล์ "Hello World" นั้นไม่มีคุณสมบัติ)

• ในคอมพิวเตอร์ของฉันตอนนี้ DOMContentLoaded สำหรับหน้าแรกของ Google เกิดขึ้น 394 ms หลังจากที่ส่งคำขอ นั่นน้อยกว่า 3 คำขอต่อวินาที สำหรับหน้าแรกของ Programmers.SE มันเกิดขึ้น 603 ms หลังจากที่ส่งคำขอ นั่นไม่ใช่แม้แต่คำขอ 2 ครั้งต่อวินาที โดยวิธีการที่ฉันมีการเชื่อมต่ออินเทอร์เน็ต 100 Mbps และคอมพิวเตอร์ที่รวดเร็ว: ผู้ใช้หลายคนจะรออีกต่อไป

  หากคอขวดคือความเร็วเครือข่ายระหว่างเซิร์ฟเวอร์ทั้งสองไซต์นั้นสามารถทำการเรียกหลายพันครั้งไปยัง API ที่แตกต่างกันในขณะที่ให้บริการหน้าเว็บ

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

คิดเกี่ยวกับฐานข้อมูล

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

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

เมื่อความเร็วในการถ่ายโอนมีความสำคัญคือเมื่อ บริษัท กำลังโฮสต์ชุดข้อมูลขนาดใหญ่บน NAS และการเข้าถึง NAS โดยลูกค้าหลายรายในเวลาเดียวกัน นี่คือที่ SAN สามารถแก้ไขปัญหาได้ สิ่งนี้ถูกกล่าวว่านี่ไม่ใช่ทางออกเดียว สายเคเบิล Cat 6 สามารถรองรับความเร็วสูงถึง 10 Gbps พันธะสามารถใช้เพื่อเพิ่มความเร็วโดยไม่ต้องเปลี่ยนสายเคเบิลหรืออะแดปเตอร์เครือข่าย มีโซลูชันอื่น ๆ ที่เกี่ยวข้องกับการจำลองข้อมูลข้าม NAS หลายตัว

ลืมเรื่องความเร็ว คิดเกี่ยวกับความยืดหยุ่น

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

• หากคุณมีแอพที่ไม่เร็วโดยเฉพาะคุณจะเสียเงินเพราะคุณต้องใช้เซิร์ฟเวอร์ที่ทรงพลังกว่า

• หากคุณมีแอปที่รวดเร็วซึ่งไม่สามารถปรับขนาดได้คุณจะสูญเสียลูกค้าเพราะคุณจะไม่สามารถตอบสนองความต้องการที่เพิ่มขึ้นได้

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

แม้จะมีการสูญเสียประสิทธิภาพ แต่สภาพแวดล้อมเสมือนจริงก็ได้รับความนิยมอย่างมากเนื่องจากความยืดหยุ่นที่ได้รับ

เช่นเดียวกับความเร็วของเครือข่ายคุณอาจพบว่า VM เป็นคอขวดจริงและด้วยขนาดที่แท้จริงของคุณคุณจะประหยัดเงินได้หลายพันล้านดอลลาร์ด้วยการโฮสต์แอปของคุณโดยตรงโดยไม่ต้องใช้ VM แต่นี่ไม่ใช่สิ่งที่เกิดขึ้นกับ 99.9% ของแอป: คอขวดของพวกเขาอยู่ที่อื่นและข้อเสียของการสูญเสียสักสองสามไมโครวินาทีเนื่องจาก VM ได้รับการชดเชยอย่างง่ายดายโดยประโยชน์ของฮาร์ดแวร์ที่เป็นนามธรรมและความยืดหยุ่น

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

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

ฉันต้องการเพิ่มมุมมองที่แตกต่างจากอุตสาหกรรมที่แตกต่างกันด้วยสมมติฐานที่แตกต่างกันมาก - การจำลองแบบกระจาย (ระดับนิติบุคคล) แนวคิดนี้เป็นเหมือนเกมวิดีโอ FPS แบบกระจาย ความแตกต่างที่สำคัญ: ผู้เล่นทุกคนแบ่งปันบางสถานะ: ตอนนี้มังกรอยู่ที่ไหน ไม่มีการเรียกฐานข้อมูล ทุกอย่างถูกจัดเก็บไว้ใน RAM เพื่อความเร็วและเวลาแฝงต่ำปริมาณงานมีความเกี่ยวข้องน้อยกว่า (แต่ฉันคิดว่าคุณไม่สามารถเพิกเฉยได้)

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

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

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

คิดอย่างรอบคอบเกี่ยวกับวิธีการทำงานของบริการเมื่อมีการโทรและมีการแลกเปลี่ยนข้อมูลใด แอปพลิเคชันของเราไม่ได้แลกเปลี่ยนเพียงแค่ข้อมูลตำแหน่งพวกเขาแลกเปลี่ยนข้อมูลการคำนวณที่ตายแล้ว - ฉันอยู่ที่ตำแหน่ง x มุ่งหน้าไปในทิศทาง y ที่ความเร็ว q และฉันไม่ต้องอัปเดตข้อมูลของฉันจนกว่าสมมติฐานเหล่านั้นจะเปลี่ยน การอัปเดตจำนวนน้อยลงและเวลาในการตอบสนอง (ในขณะที่ยังมีปัญหา) เกิดขึ้นน้อยลงตามสัดส่วน

ดังนั้นแทนที่จะขอบริการที่เกรนละเอียดที่ความถี่สูงกว่าลองลดความถี่ลงโดย:

1. การเปลี่ยนแปลงข้อมูลที่ถูกร้องขอและใช้การคำนวณแบบโลคัล
2. การส่งเคียวรีหรือพารามิเตอร์ทริกเกอร์สำหรับการตอบสนองแบบอะซิงโครนัส
3. คำขอแบ็ตช์
4. การคาดการณ์คำขอและเตรียมการตอบกลับล่วงหน้าเกี่ยวกับการเก็งกำไร (ตรงข้ามกับการประเมินที่ขี้เกียจ)
5. หลีกเลี่ยงการเรียกไมโครไซต์อื่น ๆ ; สารประกอบนี้เป็นปัญหาอย่างชัดเจน ฉันเข้าใจว่านี่เป็นสิ่งจูงใจที่ทำให้ microservices มีขนาดใหญ่ขึ้นและเอาชนะจุดนั้นได้ แต่ microservices นั้นไม่ได้เป็นเพื่อนกับความล่าช้า บางทีแค่ยอมรับมันและเอาชนะมัน

ตอนนี้อย่าลืมตรวจสอบสมมติฐานของคุณเกี่ยวกับระบบของคุณ หากคุณมีความกังวลเกี่ยวกับปริมาณงานมากกว่าเวลาแฝงหรือไม่มีสถานะที่ใช้ร่วมกัน ฯลฯ จากนั้นให้ใช้ microservices ที่เหมาะสม ฉันแค่บอกว่าอาจจะไม่ใช้สิ่งที่พวกเขาไม่สมเหตุสมผล

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

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

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

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

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

โปรดทราบว่าบริการทางธุรกิจประกอบด้วยบุคคลแอปพลิเคชันกระบวนการทางธุรกิจ โดยปกติจะมีเพียงบางส่วนเท่านั้นที่แสดงว่าเป็นหน่วยงานด้านเทคนิค

สิ่งนี้อาจฟังดูเป็นนามธรรมเล็กน้อยดังนั้นตัวอย่างของการระบุขอบเขตบริการอาจเป็นที่สนใจ

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

และจำไว้ว่า microservices นั้นไม่เล็กอย่างที่คนคิด