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 หน่วยซอฟต์แวร์จะเป็น -
|
หากแอปพลิเคชันเดียวกันสร้างขึ้นโดยใช้สถาปัตยกรรมไมโครเซอร์วิส API จะเป็น -
|