Enterprise Service Bus คืออะไร
Enterprise Service Bus (ESB) เป็นรูปแบบสถาปัตยกรรมซอฟต์แวร์ที่รองรับการแลกเปลี่ยนข้อมูลแบบเรียลไทม์ระหว่างแอปพลิเคชันต่างๆ องค์กรขนาดใหญ่มีแอปพลิเคชันหลายมากมายทำหน้าที่ต่างกันออกไปโดยใช้โมเดลข้อมูล โปรโตคอล และข้อจำกัดด้านความปลอดภัยอย่างหลากหลาย ESB ทำให้การผสานรวมโปรแกรมง่ายขึ้น โดยการดำเนินการเช่น การแปลงข้อมูล การแปลงโปรโตคอล การกำหนดเส้นทางข้อความ แอปพลิเคชันจะส่งผ่านข้อมูลที่เกี่ยวข้องให้กับ ESB และจะแปลงและส่งต่อข้อมูลไปยังโปรแกรมอื่นๆ ที่ต้องการ
ประโยชน์ของ Enterprise Service Bus คืออะไร
แนวคิด Enterprise Service Bus (ESB) สามารถสร้างมาตรฐานและลดความซับซ้อนของการสื่อสาร การส่งข้อความ และการผสานระหว่างบริการทั่วทั้งองค์กร ต่อไป เราจะให้ประโยชน์บางประการสำหรับการใช้งานสถาปัตยกรรม ESB ขนาดเล็ก
ปรับปรุงการผสานแอปพลิเคชัน
ESB เสนอแพลตฟอร์มกลางสำหรับการผสานแอปพลิเคชันขององค์กร องค์กรสามารถผสานระบบและแอปพลิเคชันทุกประเภทได้อย่างราบรื่น ไม่ว่าจะเป็นเทคโนโลยีพื้นฐานหรือโปรโตคอลใดก็ตาม สิ่งนี้ทำให้องค์กรสามารถบำรุงรักษา จัดการ และปรับขนาดแอปพลิเคชันของตนได้ง่ายขึ้น
ประสิทธิภาพของนักพัฒนาเพิ่มขึ้น
นักพัฒนาสร้างแอปพลิเคชันได้เร็วขึ้นโดยใช้บริการสื่อสารที่สร้างไว้ล่วงหน้าซึ่งจัดทำโดย ESB ทีมแชร์ค่าใช้จ่ายด้านโครงสร้างพื้นฐานและจัดเตรียมเซิร์ฟเวอร์สำหรับการใช้งานร่วมกัน ลดค่าใช้จ่ายในการดำเนินงานในขณะที่ปรับปรุงประสิทธิภาพโดยรวม ESB ยังสามารถนำไปสู่เวลาในการออกสู่ตลาดได้เร็วขึ้นและลดต้นทุนการพัฒนา
ปรับปรุงการมองเห็นและการควบคุม
ด้วย ESB องค์กรต่างๆ สามารถตรวจสอบการไหลของข้อมูลและบริการในแอปพลิเคชันต่างๆ และระบุและแก้ไขปัญหาใดๆ ที่อาจเกิดขึ้นได้อย่างรวดเร็ว สิ่งนี้ช่วยให้องค์กรมั่นใจได้ว่าแอปพลิเคชันของพวกเขาพร้อมใช้งาน เชื่อถือได้ และปลอดภัย
Enterprise Service Bus ทำงานอย่างไร
Enterprise Service Bus (ESB) ทำงานบนหลักการของสถาปัตยกรรมที่เน้นการบริการ (SOA)
SOA เป็นวิธีการพัฒนาซอฟต์แวร์ที่ใช้ส่วนประกอบซอฟต์แวร์ที่เรียกว่าการบริการเพื่อสร้างแอปพลิเคชันสำหรับธุรกิจ บริการแต่ละอย่างเพิ่มขีดความสามารถทางธุรกิจ และหลายบริการยังสามารถสื่อสารระหว่างกันทั่วทั้งแพลตฟอร์มในภาษาต่างๆ
แพลตฟอร์ม ESB ให้บริการด้านการสื่อสารที่แอปพลิเคชันใช้ในการโต้ตอบระหว่างกัน ตัวอย่างบางส่วน ได้แก่ การแปลงข้อความ การแปลงโปรโตคอล การกำหนดเส้นทาง และการยืนยันตัวตน
(การนำซอฟต์แวร์ ESB มาใช้กับ AWS)
ต่อไป เราจะหารือเกี่ยวกับส่วนประกอบที่สำคัญของสถาปัตยกรรม ESB
ตำแหน่งข้อมูล
ในสถาปัตยกรรม ESB ตำแหน่งข้อมูลสามารถถูกมองว่าเป็นจุดเข้าหรือออกจาก ESB
โดยทั่วไปตำแหน่งข้อมูลแต่ละรายการจะมีที่อยู่หรือตัวระบุที่ไม่ซ้ำกัน คุณสามารถใช้อุปกรณ์ตำแหน่งข้อมูลโดยใช้เทคโนโลยีต่างๆ เช่น อินเทอร์เฟซบริการเว็บ คิวข้อความ หรือเซิร์ฟเวอร์ FTP ตำแหน่งข้อมูลยังสามารถประมวลผลข้อความประเภทต่างๆ เช่น XML JSON หรือข้อมูลไบนารี
ความยืดหยุ่นของสถาปัตยกรรมตำแหน่งข้อมูลช่วยให้ ESB สามารถผสานกับระบบและแอปพลิเคชันที่หลากหลาย
อแดปเตอร์
ส่วนประกอบของอะแดปเตอร์ในเครื่องมือ ESB จะแปลข้อความระหว่างรูปแบบและโปรโตคอลต่างๆ ซึ่งหมายความว่าแอปพลิเคชันซอฟต์แวร์ของผู้รับสามารถใช้งานได้อย่างเหมาะสม นอกจากนี้ยังอาจมีคุณสมบัติต่างๆ เช่น การบันทึกข้อความ การตรวจสอบ การยืนยันตัวตน และการรองรับข้อผิดพลาด
บัส
บัสเป็นส่วนประกอบ ESB หลักสำหรับการแลกเปลี่ยนข้อความระหว่างตำแหน่งข้อมูล ใช้ชุดของกฎหรือนโยบายตามเกณฑ์ต่างๆ เช่น ประเภทข้อความ เนื้อหา หรือปลายทางเพื่อกำหนดเส้นทางข้อความ
คุณสามารถกำหนดนโยบายในการกำหนดค่า ESB เพื่อให้เป็นไปตามข้อกำหนดของกระบวนการทางธุรกิจที่ซับซ้อน ใช้โปรโตคอลการสื่อสารที่หลากหลาย เช่น HTTP JMS และ FTP เพื่อสื่อสารกับตำแหน่งข้อมูล
บัสทำงานดังนี้
- บัสได้รับข้อความที่ตำแหน่งข้อมูลหนึ่งจุด
- กำหนดที่อยู่ตำแหน่งข้อมูลปลายทางโดยตรวจสอบกฎนโยบายธุรกิจ
- ประมวลผลข้อความและส่งไปยังตำแหน่งข้อมูลปลายทาง
ตัวอย่างเช่น สมมติว่าบัสได้รับไฟล์ XML จากแอปพลิเคชันที่เชื่อมต่อกับตำแหน่งข้อมูล A โดยกำหนดว่าควรส่งไฟล์ XML ไปยังตำแหน่งข้อมูล B และ C ตำแหน่งข้อมูล B ต้องการข้อมูล JSON ในขณะที่ตำแหน่งข้อมูล C ต้องการฟังก์ชัน HTTP Put อะแดปเตอร์แปลงไฟล์ XML เป็น JSON และบัสส่งไปยังตำแหน่งข้อมูล B บัสดำเนินการร้องขอ HTTP ด้วย XML บนตำแหน่งข้อมูล C
ข้อจำกัดของ Enterprise Service Bu คืออะไร
สถาปัตยกรรมองค์กรได้ย้ายออกจาก Enterprise Service Bus (ESB) เนื่องจากข้อจำกัดต่อไปนี้
ความซับซ้อน
ต้องใช้ความรู้ทางเทคนิคเฉพาะทางในการปรับใช้และบำรุงรักษา ESB ซึ่งทำให้ซับซ้อนและมีราคาแพง การล็อกผู้ขายทำให้การเปลี่ยนไปใช้โซลูชัน ESB อื่นทำได้ยาก และจำกัดตัวเลือกสำหรับการรวมข้อมูล ทีมประสบปัญหาเวลารอนานเนื่องจากมีเพียงทีมผู้บริหารส่วนกลางของ ESB เท่านั้นที่สามารถรวมแอปพลิเคชันองค์กรใหม่ได้
ความสามารถในการปรับขนาด
ซอฟต์แวร์ ESB แนะนำเวลาแฝงเพิ่มเติมในการสื่อสารเนื่องจากการเพิ่มเลเยอร์ของสิ่งที่เป็นนามธรรมและการประมวลผล เมื่อจำนวนตำแหน่งข้อมูลและการวางผังบริการการสื่อสารเพิ่มขึ้น ESB จะกลายเป็นคอขวดและส่งผลกระทบต่อประสิทธิภาพการทำงาน ค่าใช้จ่ายในการปรับใช้ความพร้อมใช้งานสูงและกระบวนการกู้คืนจากความเสียหายสำหรับเซิร์ฟเวอร์ ESB ก็เพิ่มขึ้นเช่นกัน
ความยากในการอัพเกรด
การปรับปรุงการรวม ESB อาจทำให้เกิดความไม่เสถียรในส่วนประกอบที่เชื่อมต่ออื่นๆ และต้องมีการทดสอบที่สำคัญก่อนการอัปเดต การระดมทุนเพื่ออัปเกรดโครงการ ESB ต้องอาศัยการทำงานร่วมกันระหว่างทีม ซึ่งอาจเป็นเรื่องที่ท้าทาย
เทคโนโลยีใดมาแทนที่ Enterprise Service Bus ขององค์กร
ทุกวันนี้ การใช้ Enterprise Service Bus (ESB) ถูกจำกัดไว้เฉพาะระบบที่ล้าสมัยที่ต้องมีการผสานที่ซับซ้อนเป็นหลัก รูปแบบสถาปัตยกรรม ESB ถูกแทนที่ด้วยสถาปัตยกรรมไมโครเซอร์วิสท่ามกลางเทคโนโลยีอื่นๆ
สถาปัตยกรรมไมโครเซอร์วิสประกอบด้วยส่วนประกอบซอฟต์แวร์ที่มีขนาดเล็กมากและเป็นอิสระจากกันโดยสิ้นเชิง โดยมีโปรโตคอลการสื่อสารของตัวเองที่เปิดเผยผ่าน API ที่มีน้ำหนักเบา โดยพื้นฐานแล้วเป็นหน้าที่ของผู้บริโภคในการใช้ไมโครเซอร์วิสผ่าน API ทำให้ไม่จำเป็นต้องใช้ ESB แบบรวมศูนย์
สำหรับข้อมูลเพิ่มเติม คุณสามารถอ่านเกี่ยวกับไมโครเซอร์วิส และอ่านเกี่ยวกับ API
การเพิ่มขึ้นของการประมวลผลบนคลาวด์และสถาปัตยกรรมไมโครเซอร์วิสได้นำไปสู่การเกิดขึ้นของเทคโนโลยีใหม่ที่มักถูกมองว่าเป็นทางเลือกแทน ESB เราจะหารือบางส่วนของพวกเขาต่อไป
เกตเวย์ API
เกตเวย์ API เป็นส่วนประกอบขนาดเล็กที่ให้จุดเข้าใช้งานเดียวสำหรับลูกค้าในการเข้าถึงบริการต่างๆ มักใช้สำหรับจัดการ API บังคับใช้ความปลอดภัย และรองรับทราฟฟิก
โครงข่ายการบริการ
ตาข่ายบริการเป็นเลเยอร์โครงสร้างพื้นฐานเฉพาะสำหรับจัดการการสื่อสารระหว่างบริการกับบริการภายในสถาปัตยกรรมไมโครเซอร์วิส โดยจะมีคุณสมบัติต่างๆ เช่น การสำรวจบริการ การจัดสรรภาระงาน และการจัดการทราฟฟิก
สถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์
ในสถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ บริการจะสื่อสารผ่านการรองรับรเหตุการณ์แบบอะซิงโครนัสแทนคำขอแบบซิงโครนัส เหตุการณ์คือการเปลี่ยนแปลงในสภาวะ หรือมีการอัปเดต เช่น มีการใส่สินค้าหนึ่งรายการในรถเข็นบนเว็บไซต์อีคอมเมิร์ซ เหตุการณ์สามารถมีสถานะ (สินค้าที่ซื้อ ราคา และที่อยู่ในการจัดส่ง) หรือเป็นตัวระบุ (การแจ้งเตือนว่ามีการจัดส่งคำสั่งซื้อ)
Event Bus คืออะไร
หลายองค์กรได้เปลี่ยนจาก Enterprise Service Bus (ESB) เป็น Event Bus Event Bus เป็นไปป์ไลน์ที่รับเหตุการณ์ โดยจะเชื่อมต่อส่วนประกอบของแอปพลิเคชันเข้าด้วยกันตามเหตุการณ์ ซึ่งช่วยให้คุณสร้างแอปพลิเคชันที่ขับเคลื่อนด้วยเหตุการณ์ที่ปรับขนาดได้ได้ง่ายขึ้น
กฎที่เกี่ยวข้องกับ Event Bus จะประเมินเหตุการณ์เมื่อมาถึง กฎแต่ละข้อจะตรวจสอบว่าเหตุการณ์ตรงกับเกณฑ์ของกฎหรือไม่ คุณเชื่อมโยงกฎกับ Event Bus เฉพาะ ดังนั้นกฎจะใช้กับเหตุการณ์ที่ได้รับจาก Event Bus นั้นเท่านั้น
ผู้ผลิตเผยแพร่เหตุการณ์ Event Bus Event Bus จะกรองและประเมินเหตุการณ์เมื่อมาถึงตามกฎที่กำหนดค่าไว้ล่วงหน้า จากนั้นส่งเหตุการณ์ไปยังผู้บริโภค บริการของผู้ผลิตและบริการผู้บริโภคถูกแยกออกจากกัน ซึ่งทำให้สามารถปรับขนาด อัปเดต และปรับใช้ได้อย่างอิสระ
AWS จะรองรับข้อกำหนดการรวมแอปพลิเคชันของคุณได้อย่างไร
Amazon Web Services (AWS) มอบชุดบริการรวมแอปพลิเคชัน ช่วยให้สามารถสื่อสารระหว่างส่วนประกอบที่แยกส่วนภายในไมโครเซอร์วิส ระบบกระจาย และแอปพลิเคชันแบบไม่ต้องใช้เซิร์ฟเวอร์ หากคุณสงสัย โปรดอ่านเพิ่มเติมได้ที่ Application Integration บน AWS
ตัวอย่างเช่น คุณสามารถใช้บริการเหล่านี้เพื่อตอบสนองความต้องการของคุณ
- เกตเวย์ของ Amazon API เพื่อสร้าง เผยแพร่ ดูแล ตรวจสอบ และรักษาความปลอดภัยของ API ได้ทุกขนาดสำหรับเวิร์กโหลดแบบไม่ต้องใช้เซิร์ฟเวอร์และเว็บแอปพลิเคชัน
- Amazon EventBridge เพื่อสร้าง Event Bus ที่เชื่อมต่อข้อมูลแอปพลิเคชันจากแอปพลิเคชัน Software as a Service (SaaS) และบริการของ AWS ของคุณเอง
- Amazon Simple Queue Service (Amazon SQS) ที่จะสร้างคิวข้อความที่ส่ง เก็บ และรับข้อความระหว่างส่วนประกอบของแอปพลิเคชันในทุกปริมาณ
เริ่มต้นด้วยการรวมแอปพลิเคชันบน AWS โดยสร้างบัญชีวันนี้
ขั้นตอนถัดไปบน AWS
