Microservice Architecture - บทนำ

Microservice เป็นวิธีการพัฒนาแอปพลิเคชันที่ใช้บริการ ในวิธีการนี้แอปพลิเคชันขนาดใหญ่จะถูกแบ่งออกเป็นหน่วยบริการอิสระที่เล็กที่สุด Microservice เป็นกระบวนการของการนำ Service-oriented Architecture (SOA) มาใช้โดยแบ่งแอปพลิเคชันทั้งหมดเป็นชุดของบริการที่เชื่อมต่อกันโดยแต่ละบริการจะตอบสนองความต้องการทางธุรกิจเพียงอย่างเดียว

แนวคิดของ Going Micro

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

ต่อไปนี้เป็นกฎบางประการที่เราต้องคำนึงถึงในขณะที่พัฒนาแอปพลิเคชันที่มุ่งเน้น Microservice

  • Independent - ไมโครเซอร์วิสแต่ละตัวควรใช้งานได้อย่างอิสระ

  • Coupling - ไมโครเซอร์วิสทั้งหมดควรอยู่คู่กันอย่างหลวม ๆ เพื่อที่การเปลี่ยนแปลงในหนึ่งจะไม่ส่งผลกระทบต่ออีก

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

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

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

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

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

พิจารณาสถานการณ์ต่อไปนี้ที่คุณต้องเปลี่ยนใบสมัครตามความต้องการของธุรกิจ

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

อีกครั้งหน่วยธุรกิจของคุณต้องการการเปลี่ยนแปลงบางอย่างในโมดูล "ชำระเงิน" เพื่อรวมตัวเลือก "กระเป๋าเงิน" ตอนนี้คุณต้องเปลี่ยนโมดูล“ ชำระเงิน” ของคุณและทำให้ใช้งานได้อีกครั้งในเซิร์ฟเวอร์ หมายเหตุคุณกำลังปรับใช้โมดูลต่างๆของแพ็คเกจซอฟต์แวร์ของคุณอีกครั้งในขณะที่เราไม่ได้ทำการเปลี่ยนแปลงใด ๆ ต่อไปนี้คือแนวคิดของสถาปัตยกรรมที่มุ่งเน้นการบริการที่เฉพาะเจาะจงมากขึ้นสำหรับสถาปัตยกรรม Microservice เราสามารถพัฒนาแอปพลิเคชันเสาหินของเราในลักษณะที่แต่ละโมดูลของซอฟต์แวร์จะทำงานเป็นหน่วยงานอิสระสามารถจัดการงานทางธุรกิจเดียวได้อย่างอิสระ

ลองพิจารณาตัวอย่างต่อไปนี้

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

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

ข้อดีข้อเสีย

ต่อไปนี้เป็นข้อดีของการใช้ไมโครเซอร์วิสแทนการใช้แอปพลิเคชันเสาหิน

ข้อดี

  • Small in size- Microservices คือการนำรูปแบบการออกแบบ SOA มาใช้ ขอแนะนำให้ใช้บริการของคุณให้มากที่สุดเท่าที่จะทำได้ โดยพื้นฐานแล้วบริการไม่ควรทำงานทางธุรกิจมากกว่าหนึ่งอย่างดังนั้นจึงเห็นได้ชัดว่ามีขนาดเล็กและดูแลรักษาง่ายกว่าแอปพลิเคชันเสาหินอื่น ๆ

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

  • Autonomous- บริการไมโครแต่ละรายการควรเป็นหน่วยธุรกิจอิสระของแอปพลิเคชันทั้งหมด ดังนั้นแอปพลิเคชันจึงทำงานร่วมกันอย่างหลวม ๆ ซึ่งช่วยลดต้นทุนการบำรุงรักษา

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

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

  • Ease of deployment- เนื่องจากแอปพลิเคชันทั้งหมดถูกแบ่งย่อยออกเป็นชิ้นส่วนเล็ก ๆ ส่วนประกอบทุกชิ้นจึงควรมีลักษณะเป็นสแต็กเต็ม ทั้งหมดนี้สามารถปรับใช้ในทุกสภาพแวดล้อมได้อย่างง่ายดายโดยมีเวลาที่ซับซ้อนน้อยกว่าซึ่งแตกต่างจากแอปพลิเคชันเสาหินอื่น ๆ ในประเภทเดียวกัน

ต่อไปนี้เป็นประเด็นบางประการเกี่ยวกับข้อเสียของสถาปัตยกรรมไมโครเซอร์วิส

ข้อเสีย

  • Distributed system- เนื่องจากความแตกต่างทางเทคนิคจึงมีการใช้เทคโนโลยีที่แตกต่างกันเพื่อพัฒนาส่วนต่างๆของไมโครเซอร์วิส จำเป็นต้องมีผู้เชี่ยวชาญที่มีทักษะจำนวนมากเพื่อสนับสนุนซอฟต์แวร์แบบกระจายที่แตกต่างกันขนาดใหญ่นี้ ดังนั้นการกระจายและความแตกต่างกันจึงเป็นข้อเสียอันดับหนึ่งของการใช้ไมโครเซอร์วิส

  • Cost - Microservice มีค่าใช้จ่ายสูงเนื่องจากคุณต้องรักษาพื้นที่เซิร์ฟเวอร์ที่แตกต่างกันสำหรับงานธุรกิจที่แตกต่างกัน

  • Enterprise readiness- สถาปัตยกรรม Microservice ถือได้ว่าเป็นกลุ่มของเทคโนโลยีที่แตกต่างกันเนื่องจากเทคโนโลยีมีการพัฒนาขึ้นทุกวัน ดังนั้นจึงเป็นเรื่องยากที่จะทำให้องค์กรแอปพลิเคชันไมโครเซอร์วิสพร้อมที่จะเปรียบเทียบกับรูปแบบการพัฒนาซอฟต์แวร์ทั่วไป

Microservice ผ่าน SOA

ตารางต่อไปนี้แสดงคุณสมบัติบางประการของ SOA และ Microservice โดยให้ความสำคัญของการใช้ microservice ผ่าน SOA

ส่วนประกอบ SOA ไมโครเซอร์วิส
รูปแบบการออกแบบ SOA เป็นกระบวนทัศน์การออกแบบสำหรับซอฟต์แวร์คอมพิวเตอร์โดยที่ส่วนประกอบของซอฟต์แวร์จะสัมผัสกับโลกภายนอกเพื่อใช้งานในรูปแบบของบริการ Micro Service เป็นส่วนหนึ่งของ SOA เป็นการใช้งาน SOA โดยเฉพาะ
การพึ่งพา หน่วยธุรกิจต่างพึ่งพาซึ่งกันและกัน หน่วยธุรกิจทั้งหมดเป็นอิสระจากกัน
ขนาด ขนาดซอฟต์แวร์ใหญ่กว่าซอฟต์แวร์ทั่วไป ขนาดซอฟต์แวร์มีขนาดเล็ก
เทคโนโลยี กองเทคโนโลยีน้อยกว่า Microservice Microservice มีลักษณะที่แตกต่างกันเนื่องจากเทคโนโลยีที่แน่นอนถูกนำมาใช้เพื่อทำงานเฉพาะอย่าง Microservices ถือได้ว่าเป็นกลุ่มของเทคโนโลยีมากมาย
อิสระและโฟกัส แอปพลิเคชัน SOA สร้างขึ้นเพื่อทำงานทางธุรกิจหลายอย่าง แอปพลิเคชัน Microservice สร้างขึ้นเพื่อทำงานทางธุรกิจเดียว
ธรรมชาติ เสาหินในธรรมชาติ กองเต็มในธรรมชาติ
การปรับใช้ การทำให้ใช้งานได้ใช้เวลานาน การปรับใช้ทำได้ง่ายมาก ดังนั้นจะใช้เวลาน้อยลง
ลดค่าใช้จ่าย คุ้มค่ากว่า ประหยัดค่าใช้จ่ายน้อยลง
ความสามารถในการปรับขนาด น้อยกว่าเมื่อเทียบกับ Microservices ปรับขนาดเต็มที่
ตัวอย่าง ให้เราพิจารณาแอปพลิเคชันการจอง CAB ออนไลน์หนึ่งรายการ หากเราต้องการสร้างแอปพลิเคชันนั้นโดยใช้ SOA หน่วยซอฟต์แวร์จะเป็น -
  • GetPayments และ DriverInformation และ MappingDataAPI
  • AuthenticateUsersAnd DriversAPI
หากแอปพลิเคชันเดียวกันสร้างขึ้นโดยใช้สถาปัตยกรรมไมโครเซอร์วิส API จะเป็น -
  • SubmitPaymentsService
  • GetDriverInfoService
  • GetMappingDataService
  • AuthenticateUserService
  • AuthenticateDriverService