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

◼ ตัวย่อของบทความ

◼ บทนำ

◼ ระบบนิเวศไมโครเซอร์วิส

◼ Monolith Architecture กับ Microservice Architecture

◼ ความท้าทายในไมโครเซอร์วิส

◼ เมื่อใดควรใช้ไมโครเซอร์วิส

ตัวย่อ

• API : อินเทอร์เฟซการเขียนโปรแกรมแอปพลิเคชัน
• MS : ไมโครเซอร์วิส
• NoSQL : ไม่ใช่แค่ SQL
• RTE : สภาพแวดล้อมรันไทม์

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

คุณสมบัติ/คุณลักษณะที่สำคัญบางประการของไมโครเซอร์วิสมีดังนี้

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

โดยทั่วไป ระบบ Microservices ประกอบด้วยรายการต่อไปนี้ เอนทิตีเหล่านี้บางส่วนเป็นขั้นตอนในการพัฒนาซอฟต์แวร์มาตรฐาน และบางส่วนเป็นกระบวนการเฉพาะของไมโครเซอร์วิส ซึ่งจะเป็นแกนหลักสำหรับระบบไมโครเซอร์วิสที่มีประสิทธิภาพ

โหลดบาลานเซอร์

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

เซิร์ฟเวอร์การค้นพบบริการ

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

API เกตเวย์

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

API Gateway จัดการคำขอด้วยวิธีใดวิธีหนึ่งจากสองวิธี:

• มันกำหนดเส้นทางหรือพร็อกซีคำขอไปยังบริการที่เหมาะสม
• กระจาย (กระจาย) คำขอไปยังบริการต่างๆ

ตอนนี้เราทราบแล้วว่ามีไมโครเซอร์วิสจำนวนมากที่ทำงานบนโหนดต่างๆ ในระบบนิเวศเดียวกัน ดังนั้น เราจำเป็นต้องตรวจสอบร่วมกันในระบบเดียวเป็นสิ่งสำคัญ แดชบอร์ดของ Hystrix และแดชบอร์ดผู้ดูแลระบบ Spring boot คือตัวอย่างบางส่วนของเครื่องมือตรวจสอบ หลักการตรวจสอบไมโครเซอร์วิสมี 5 ประการดังนี้

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

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

เบรกเกอร์

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

สถาปัตยกรรม Monolith กับสถาปัตยกรรม Microservice

ราคา

• เสาหิน : สูงขึ้นเมื่อโครงการปรับขนาด
• Microservce : สูงกว่าในขั้นตอนการพัฒนาแรก

• Monolithic : ฐานรหัสและฐานข้อมูลรวมสำหรับผลิตภัณฑ์ทั้งหมด
• Microservce : ไฟล์โค้ดหลายไฟล์ แต่ละบริการจัดการฐานและที่จัดเก็บข้อมูล

• เสาหิน : ต้องปรับใช้ฐานรหัสทั้งหมด
• Microservce : แต่ละไมโครเซอร์วิสจะถูกปรับใช้ทีละรายการ

• เสาหิน : กองรหัสเดียวกัน
• Microservce : สแต็คที่แตกต่างกัน (ภาษา, สภาพแวดล้อมรันไทม์และอื่น ๆ )

มีความท้าทายบางอย่างเมื่อเราจัดการกับไมโครเซอร์วิสดังต่อไปนี้

• การสื่อสารระหว่างกระบวนการ (ผ่านเครือข่าย)
• การทำธุรกรรมแบบกระจาย
• บริการจำนวนมาก
• ต้องการระบบอัตโนมัติมากขึ้น

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

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