ไมโครเซอร์วิสเป็นวิธีการแบ่งแอปพลิเคชันขนาดใหญ่ออกเป็นโมดูลที่เชื่อมต่อกันอย่างหลวมๆ ซึ่งสื่อสารระหว่างกันผ่าน API แบบง่ายๆ
ในช่วงนี้ มีเพียงคนใบ้เท่านั้นที่ไม่ได้พูดถึงไมโครเซอร์วิส สิ่งนี้กำลังได้รับความนิยมมากขึ้นเรื่อยๆ รูปแบบสถาปัตยกรรมแบบโมดูลาร์ดูเหมาะสมอย่างยิ่งกับสภาพแวดล้อมบนคลาวด์และกำลังได้รับความนิยมเพิ่มขึ้น ก่อนที่เราจะลงรายละเอียด เรามาดูทุกสิ่งกันก่อน ดังนั้น: ไมโครเซอร์วิสเป็นวิธีหนึ่งในการแบ่งโปรเจ็กต์ขนาดใหญ่ออกเป็นโมดูลขนาดเล็กที่เป็นอิสระและเชื่อมต่อกันอย่างหลวมๆ โมดูลอิสระมีหน้าที่รับผิดชอบงานที่กำหนดไว้อย่างชัดเจนและแยกจากกัน และสื่อสารระหว่างกันผ่าน API ที่เรียบง่ายและเข้าถึงได้ กล่าวอีกนัยหนึ่ง ไมโครเซอร์วิสเป็นเพียงรูปแบบสถาปัตยกรรมที่แตกต่างกันสำหรับการออกแบบที่ซับซ้อน ซึ่งส่วนใหญ่เป็นเว็บแอปพลิเคชัน แต่สิ่งที่ไม่ดีเกี่ยวกับโซลูชันทางสถาปัตยกรรมที่มีอยู่เช่น SOA (สถาปัตยกรรมเชิงบริการ)? โซลูชันระดับองค์กรสมัยใหม่ส่วนใหญ่ที่เขียนโดยใช้ SOA ดูเหมือนจะทำงานได้ค่อนข้างดี นี่อาจเป็นช่วงเวลาที่ดีในการพูดคุยเกี่ยวกับความท้าทายที่อุตสาหกรรมกำลังเผชิญอยู่ในปัจจุบัน... มาเริ่มด้วยตัวอย่างง่ายๆ กัน สมมติว่าฉันต้องเรียกใช้แอปพลิเคชันคลาสสิกที่เขียนด้วยภาษา Java ก่อนอื่น ฉันจะพัฒนา User Interface จากนั้นจึงพัฒนาเลเยอร์ตรรกะทางธุรกิจ โดยมีองค์ประกอบหลายอย่างที่จะโต้ตอบกับ UI และสุดท้ายคือเลเยอร์ฐานข้อมูล ซึ่งจะสามารถเข้าถึงได้โดยฐานข้อมูลถาวร ตอนนี้ตามความจริงที่ว่าฉันต้องการเรียกใช้แอปพลิเคชัน ฉันจะสร้าง WAR/EAR/JAR และเมานต์บนเซิร์ฟเวอร์ (เช่น JBoss, Tomcat หรือ WebLogic) เนื่องจากสิ่งนี้เสร็จสิ้นในที่เดียว ฉันจึงได้รับแอปพลิเคชันแบบเสาหิน ซึ่งหมายความว่าส่วนประกอบทั้งหมดรวมอยู่ในที่เดียว... ตัวอย่างในภาพ:
เป็นไปได้มากว่าคุณคุ้นเคยกับแนวทางนี้อยู่แล้วและเคยใช้แล้ว แต่แนวคิดก็คือการใช้ตัวอย่างนี้เพื่อแสดงให้เห็นว่านักพัฒนาซอฟต์แวร์จะต้องเผชิญความท้าทายใดในการใช้โซลูชันทางสถาปัตยกรรมนี้ การใช้งานเสาหิน: ความท้าทายที่ท้าทาย
God Microservices เข้ามาช่วยเหลือ หนึ่งในคุณลักษณะที่สำคัญที่สุดในโซลูชันทางสถาปัตยกรรมก็คือความสามารถในการปรับขนาดได้ ขณะที่ฉันเรียนรู้ไมโครเซอร์วิสเป็นครั้งแรก ฉันเห็นว่าทุกอย่างคล้ายกับคำพูดจากหนังสือ “The Art of Scalability” มาก นี่เป็นจุดเริ่มต้นที่ดีและเป็นสถานที่สำหรับการอภิปราย หนังสือเล่มนี้ให้คำจำกัดความของโมเดลที่เรียกว่า "Scalability Cube" ซึ่งอธิบายระบบความสามารถในการปรับขนาดสามมิติ:
ดังที่คุณเห็น แกน X อธิบาย "มาตราส่วนแนวนอน" (ซึ่งเราได้เห็นแล้วว่าใช้ได้กับสถาปัตยกรรมเสาหินด้วย) แกน Y แสดงถึงมาตราส่วนในแง่ของการแยกส่วนประกอบ บริการ ต่างๆ แนวคิดของแกน Z เป็นที่เข้าใจเมื่อมีการแบ่งข้อมูลและแอปพลิเคชันส่งคำขอไปยังตำแหน่งของข้อมูลอย่างแน่นอน นั่นคือพวกเขาไม่ได้ทั้งหมดในที่เดียว แนวคิดของแกน Y คือแนวคิดที่เราจะเน้นในรายละเอียดเพิ่มเติม แกนนี้แสดงถึงการสลายตัวเชิงฟังก์ชัน ในกลยุทธ์นี้ ฟังก์ชันต่างๆ ถือเป็นบริการที่เป็นอิสระ ดังนั้น ด้วยการติดตั้งแอปพลิเคชันทั้งหมดเฉพาะเมื่อทุกอย่างเสร็จสิ้นแล้ว นักพัฒนาจึงสามารถติดตั้งบริการแต่ละรายการแยกจากกัน และไม่รอให้ผู้อื่นทำงานในโมดูลของตนจนเสร็จสิ้น สิ่งนี้จะไม่เพียงปรับปรุงเวลาในการพัฒนา แต่ยังให้ความยืดหยุ่นในการเปลี่ยนแปลงและเดินสายใหม่โดยไม่ต้องกังวลกับส่วนประกอบที่เหลือของแอปพลิเคชัน ลองเปรียบเทียบแผนภาพนี้กับแผนภาพเสาหินก่อนหน้า:
ไมโครเซอร์วิส: ประโยชน์ ประโยชน์ ของไมโครเซอร์วิสดูเหมือนจะเพียงพอที่จะโน้มน้าวใจนักพัฒนาระดับองค์กร เช่น Amazon, Netflix, Ebay ให้เริ่มใช้วิธีการนี้ ไมโครเซอร์วิสต่างจากแอปพลิเคชันสถาปัตยกรรมแบบเสาหิน:

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


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