สถาปัตยกรรมไมโครเซอร์วิส: ข้อดีและข้อเสีย

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

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

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

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

ไมโครเซอร์วิส: คุณลักษณะของการติดตั้งและการจำลองเสมือน ตอนนี้เราเข้าใจแล้วว่าไมโครเซอร์วิสคืออะไร และข้อได้เปรียบที่ยิ่งใหญ่ที่สุดคือ มันถูกเมาท์โดยไฟล์เก็บถาวร WAR/EAR/JAR มากกว่าหนึ่งไฟล์ แต่มันติดตั้งยังไงล่ะ? วิธีที่ดีที่สุดในการติดตั้งไมโครเซอร์วิสภายในคอนเทนเนอร์ คอนเทนเนอร์คือระบบปฏิบัติการเสมือนที่ได้รับการกำหนดค่าอย่างสมบูรณ์พร้อมกับกำหนดค่าสภาพแวดล้อมที่จำเป็น ซึ่งช่วยแยกการเข้าถึงทรัพยากรของระบบฮาร์ดแวร์ที่ติดตั้งคอนเทนเนอร์นั้น แน่นอนว่าโซลูชันที่มีชื่อเสียงที่สุดในตลาดคือDocker เครื่องเสมือนจาก IaaS (โครงสร้างพื้นฐานเป็นบริการ) เช่น AWS ยังทำงานได้ดีสำหรับการติดตั้งไมโครเซอร์วิส แต่ไมโครเซอร์วิสที่ค่อนข้างเบาอาจไม่ได้ใช้ทรัพยากรทั้งหมดที่อยู่ในเครื่องเสมือน ซึ่งสามารถลดผลกำไรจากการใช้งานได้ คุณยังสามารถติดตั้งไมโครเซอร์วิสของคุณโดยใช้ แพ็คเกจ OSGI (Open Service Gateway Initiative) ในกรณีนี้ ไมโครเซอร์วิสทั้งหมดจะทำงานใน JVM เดียว แต่สิ่งนี้เกี่ยวข้องกับปัญหาการแลกเปลี่ยนระหว่างการควบคุมและการแยกกัน ไมโครเซอร์วิส: ข้อเสีย เพียงเพราะ “ทั้งหมดนี้เจ๋ง” และ “เราไม่เคยเห็นสิ่งนี้มาก่อน” ไม่ได้หมายความว่าไม่มีข้อเสีย ด้านล่างนี้คือรายการพื้นที่ที่อาจเกิดความเจ็บปวดซึ่งสถาปัตยกรรมไมโครเซอร์วิสนำมาด้วย:

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

.... แน่นอนว่าด้วยเครื่องมือที่เหมาะสมและแนวทางปฏิบัติ ก็สามารถหลีกเลี่ยงข้อเสียเหล่านี้ได้ แต่พวกเขาต้องการการสนับสนุนและไม่สามารถแก้ไขปัญหาทั้งหมดได้ทั้งหมด บทความนี้แปลจาก เว็บไซต์ CloudAcademy แปลฟรี ทุกคนมีอิสระในการแสดงความคิดเห็นในความคิดเห็น พวกเขาจะอ่านอย่างแน่นอน บทความต้นฉบับ บัญชี Github ของฉัน