เหตุใดเราจึงสร้าง Enterprise Service Mesh

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

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

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

ที่ระดับพร็อกซี (ระนาบข้อมูล):

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

ที่ระดับระนาบควบคุม:

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

ผู้ใช้ที่สนใจในการพัฒนาเทคโนโลยีนี้มีหลากหลายมาก ตั้งแต่บริษัทสตาร์ทอัพขนาดเล็กไปจนถึงบริษัทอินเทอร์เน็ตขนาดใหญ่ เช่น PayPal

เหตุใด Service Mesh จึงจำเป็นในภาคองค์กร

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

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

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

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

ต้องสังเกตว่า การอัปเดตแอปพลิเคชันแบบกระจายในสภาพแวดล้อมแบบตาข่ายบริการจะง่ายขึ้น ตัวอย่างเช่น การใช้งานสีน้ำเงิน/เขียวซึ่งมีสภาพแวดล้อมแอปพลิเคชันสองแบบสำหรับการติดตั้ง ซึ่งหนึ่งในนั้นไม่ได้รับการอัพเดตและอยู่ในโหมดสแตนด์บาย การย้อนกลับเป็นเวอร์ชันก่อนหน้าในกรณีที่การเปิดตัวไม่สำเร็จจะดำเนินการโดยเราเตอร์พิเศษซึ่งบทบาทของ Service Mesh จะจัดการได้ดี. หากต้องการทดสอบเวอร์ชันใหม่คุณสามารถใช้ ปล่อยนกขมิ้น — เปลี่ยนเป็นเวอร์ชันใหม่เพียง 10% ของการรับส่งข้อมูลหรือคำขอจากกลุ่มนำร่องของลูกค้า การรับส่งข้อมูลหลักไปที่เวอร์ชันเก่าไม่มีอะไรเสียหาย

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

หากบริษัทต้องการลดต้นทุนสำหรับการพัฒนาโซลูชันบูรณาการ Service Mesh ยังช่วย: คุณสามารถเปลี่ยนไปใช้เวอร์ชันโอเพ่นซอร์สได้จากผลิตภัณฑ์เชิงพาณิชย์. Enterprise Service Mesh ของเราใช้ Service Mesh เวอร์ชันโอเพ่นซอร์ส

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

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

เหตุใดคุณจึงต้องปรับแต่ง Service Mesh

ในบริษัทของเรา มีระบบและโมดูลหลายร้อยระบบอยู่ร่วมกัน และรันไทม์มีภาระงานมาก ดังนั้นรูปแบบง่ายๆ ของระบบหนึ่งที่เรียกอีกระบบหนึ่งแล้วได้รับการตอบกลับนั้นไม่เพียงพอ เพราะในการผลิตจริงเราต้องการมากกว่านี้ คุณต้องการอะไรอีกจากตาข่ายบริการระดับองค์กร?

บริการประมวลผลเหตุการณ์

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

ค่อนข้างแปลกที่ Service Mesh ทุกเวอร์ชันรองรับ Remote Procedure Call (RPC) แต่ไม่เป็นมิตรกับ EDA เนื่องจาก Service Mesh เป็นการบูรณาการแบบกระจายที่ทันสมัย ​​และ EDA เป็นรูปแบบสถาปัตยกรรมที่เกี่ยวข้องมาก ซึ่งช่วยให้คุณทำสิ่งที่ไม่เหมือนใครในแง่ของประสบการณ์ของลูกค้า

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

บริการถ่ายโอนไฟล์

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

บริการจัดออร์เคสตรา

องค์กรขนาดใหญ่มักจะมีทีมที่แตกต่างกันที่สร้างผลิตภัณฑ์ที่แตกต่างกัน ตัวอย่างเช่น ในธนาคาร บางทีมทำงานเกี่ยวกับเงินฝาก ในขณะที่ทีมอื่นๆ ทำงานเกี่ยวกับผลิตภัณฑ์สินเชื่อ และมีกรณีดังกล่าวค่อนข้างมาก คนเหล่านี้คือผู้คนที่แตกต่างกัน และทีมที่แตกต่างกันที่สร้างผลิตภัณฑ์ พัฒนา API และส่งมอบให้กับผู้อื่น และบ่อยครั้งที่มีความจำเป็นต้องเขียนบริการเหล่านี้ รวมถึงการใช้ตรรกะที่ซับซ้อนสำหรับการเรียกชุด API ตามลำดับ ในการแก้ปัญหานี้ คุณต้องมีวิธีแก้ปัญหาในเลเยอร์การรวมที่จะลดความซับซ้อนของตรรกะเชิงประกอบทั้งหมดนี้ (การเรียกใช้ API หลายตัว อธิบายเส้นทางคำขอ ฯลฯ) นี่คือบริการประสานใน Enterprise Service Mesh

เอไอ และ เอ็มแอล

เมื่อไมโครเซอร์วิสสื่อสารผ่านชั้นการบูรณาการเพียงชั้นเดียว Service Mesh จะรู้ทุกอย่างเกี่ยวกับการโทรของแต่ละบริการโดยธรรมชาติ เรารวบรวมการวัดและส่งข้อมูลทางไกล: ใครโทรหาใคร เมื่อใด นานแค่ไหน กี่ครั้ง และอื่นๆ เมื่อมีบริการเหล่านี้นับแสนรายการ และการโทรหลายพันล้านครั้ง ทั้งหมดนี้ก็จะสะสมและก่อตัวเป็น Big Data ข้อมูลนี้สามารถวิเคราะห์ได้โดยใช้ AI, การเรียนรู้ของเครื่อง ฯลฯ จากนั้นสิ่งที่มีประโยชน์บางอย่างก็สามารถทำได้ตามผลการวิเคราะห์ อย่างน้อยที่สุดก็ควรส่งมอบการควบคุมการรับส่งข้อมูลเครือข่ายและการเรียกแอปพลิเคชันทั้งหมดที่รวมอยู่ใน Service Mesh ให้กับปัญญาประดิษฐ์

บริการเกตเวย์ API

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

• ความปลอดภัย. ปัญหาที่เกี่ยวข้องกับ ddos, ช่องโหว่ของโปรโตคอล, แอปพลิเคชัน, ระบบปฏิบัติการ และอื่นๆ
• มาตราส่วน. เมื่อจำนวน API ที่ต้องให้บริการแก่ลูกค้าถึงหลักพันหรือหลายแสนชุด ก็จำเป็นต้องมีเครื่องมือการจัดการบางประเภทสำหรับ API ชุดนี้ คุณต้องตรวจสอบ API อย่างต่อเนื่อง: ไม่ว่าพวกมันจะทำงานหรือไม่ก็ตาม สถานะคืออะไร ทราฟฟิกที่ไหลลื่น สถิติใด ฯลฯ เกตเวย์ API ควรจัดการงานนี้ในขณะที่ทำให้กระบวนการทั้งหมดสามารถจัดการได้และปลอดภัย ด้วยองค์ประกอบนี้ Enterprise Service Mesh จึงเรียนรู้ที่จะเผยแพร่ API ทั้งภายในและภายนอกได้อย่างง่ายดาย

บริการสนับสนุนโปรโตคอลและรูปแบบข้อมูลเฉพาะ (AS Gateway)

ปัจจุบัน โซลูชัน Service Mesh ส่วนใหญ่สามารถทำงานได้เฉพาะกับการรับส่งข้อมูล HTTP และ HTTP2 หรือในโหมดลดลงที่ระดับ TCP/IP Enterprise Service Mesh กำลังเกิดขึ้นพร้อมกับโปรโตคอลการถ่ายโอนข้อมูลที่เฉพาะเจาะจงอื่นๆ อีกมากมาย บางระบบอาจใช้ตัวกลางรับข้อความ ส่วนบางระบบจะบูรณาการในระดับฐานข้อมูล หากบริษัทมี SAP ก็สามารถใช้ระบบบูรณาการของตนเองได้เช่นกัน ยิ่งไปกว่านั้น ทั้งหมดนี้ได้ผลและเป็นส่วนสำคัญของธุรกิจ

คุณไม่สามารถพูดเพียงว่า: “มาละทิ้งสิ่งเดิมๆ และสร้างระบบใหม่ที่สามารถใช้ Service Mesh ได้” ในการเชื่อมต่อระบบเก่าทั้งหมดกับระบบใหม่ (บนสถาปัตยกรรมไมโครเซอร์วิส) ระบบที่สามารถใช้ Service Mesh ได้จะต้องมีอะแดปเตอร์ ตัวกลาง เกตเวย์บางประเภท เห็นด้วยคงจะดีถ้ามาในกล่องพร้อมกับการบริการ เกตเวย์ AC สามารถรองรับตัวเลือกการรวมระบบใดก็ได้ ลองจินตนาการว่าคุณเพิ่งติดตั้ง Enterprise Service Mesh และพร้อมที่จะโต้ตอบกับโปรโตคอลทั้งหมดที่คุณต้องการ แนวทางนี้สำคัญมากสำหรับเรา

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

ที่มา: will.com