สถาปัตยกรรมไมโครเซอร์วิส: จุดเด่นของความสามารถ

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

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

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

เป็นแนวทางการพัฒนาซอฟต์แวร์ที่แบ่งระบบออกเป็นส่วนย่อยๆ ที่เป็นอิสระและเชื่อมโยงเข้าด้วยกัน บริการอิสระถูกรวบรวมเข้าด้วยกันเพื่อตอบสนองความต้องการเฉพาะของภาคส่วนใดภาคหนึ่ง Spotify, Amazon, PayPal, Netflix และ Twitter ต่างก็รับทราบการค้นพบใหม่นี้และกำลังโฆษณาอย่างกว้างขวาง

สถาปัตยกรรมไมโครเซอร์วิสคืออะไร?

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

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

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

ความจำเป็นในการพัฒนาสถาปัตยกรรมไมโครเซอร์วิสและ ข้อจำกัดของสถาปัตยกรรมเสาหิน

1. การปรับขนาดแอปพลิเคชัน

เนื่องจากธุรกิจขนาดเว็บที่ประสบความสำเร็จประสบกับการขยายตัวแบบทวีคูณ ซอฟต์แวร์ของพวกเขาจึงต้องยอมให้มีการปรับขนาดในแนวนอนที่ยอดเยี่ยมด้วย ในบางครั้ง เฉพาะส่วนของซอฟต์แวร์ที่เป็น CPU หรือ I/O หนักเท่านั้นที่ต้องได้รับการปรับขนาดและจัดการแยกกัน (ใช้กับการเขียนโปรแกรมหลายภาษา) ซอฟต์แวร์ที่มีฟังก์ชันแบบเสาหินเป็นเอนทิตีเดียวและสร้างขึ้นโดยใช้ภาษาการเขียนโปรแกรมเดียวและ Tech Stack ในการปรับขนาดแนวนอนให้สำเร็จ จำเป็นต้องปรับขนาดแอปพลิเคชันทั้งหมด เนื่องจากซอฟต์แวร์แบบเสาหินรองรับเฉพาะภาษาการเขียนโปรแกรมเดียวเท่านั้น จึงเป็นไปไม่ได้ที่จะพัฒนาแม้แต่โมดูลเดียวในภาษาการเขียนโปรแกรมอื่นหรือ Tech Stack

2. ความเร็วในการพัฒนา

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

3. การปรับขนาดการพัฒนา

เพื่อให้ได้มาซึ่งความได้เปรียบทางการแข่งขันหรือเพื่อคว้าผลไม้ที่แขวนอยู่ต่ำ ธุรกิจมักพยายามสร้างการพัฒนาขนานกันโดยการจ้างนักพัฒนามากขึ้น นักพัฒนาไม่สามารถทำงานอย่างอิสระบนฐานโค้ดขนาดใหญ่ที่มีเสาหินและเชื่อมต่ออย่างใกล้ชิด และมักต้องการการซิงโครไนซ์และความระมัดระวังเพิ่มเติมเพื่อหลีกเลี่ยงการรบกวนการทำงานของกันและกัน การเพิ่มนักพัฒนาเพิ่มเติมไม่ได้ส่งผลให้มีคุณลักษณะเพิ่มขึ้น และอาจส่งผลให้มีคุณลักษณะน้อยลงในบางครั้ง ในทำนองเดียวกัน เนื่องจากต้องใช้ความรู้ความเข้าใจสูงในการทำความเข้าใจฐานรหัสเสาหินทั้งหมด โดยปกติแล้วการรับสมัครพนักงานใหม่หรือผู้ที่จบใหม่จะใช้เวลาพอสมควรในการสร้างบรรทัดแรกของโค้ดที่มีประสิทธิภาพ ในปี 2008 ฉันได้สัมภาษณ์กับธุรกิจโทรคมนาคมในเบอร์ลิน ซึ่งผู้จัดการด้านเทคนิคบอกฉันด้วยรอยยิ้มที่พอใจว่าฐานรหัส C++ ของบริษัทมีสายงานหลายล้านสาย และวิศวกรใหม่สามารถผลิตรหัสที่มีประสิทธิภาพได้หลังจากสี่ถึงหกเดือนเท่านั้น

4. รอบการเปิดตัว

วัฏจักรการวางจำหน่ายของโครงการเสาหินขนาดใหญ่มักใช้เวลานานเกินไป ตั้งแต่หกถึงสองปีครึ่ง โดยมีความล่าช้าเพิ่มเติมสองสามเดือนถึงหลายปีตามขนาดของโครงการ วงจรการปล่อยขนาดใหญ่มักทำให้บริษัทเสียเปรียบในการแข่งขันในยุคปัจจุบัน เนื่องจากคู่แข่งรายใหม่สามารถเข้าสู่ตลาดได้ในช่วงช่องว่างการปล่อย

5. การทำให้เป็นโมดูล

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

6. ความทันสมัย

แอพที่ประสบความสำเร็จที่มีอยู่จำเป็นต้องมีการปรับปรุงให้ทันสมัยด้วยเหตุผลหลายประการ (เช่น การใช้ประโยชน์จากฮาร์ดแวร์ที่ทันสมัย ​​เบราว์เซอร์ แบนด์วิดท์เครือข่าย Tech Stack หรือ Attract นักพัฒนาที่ดี) การปรับโปรแกรมแบบเสาหินให้ทันสมัยอาจมีราคาแพงและใช้เวลานาน เนื่องจากต้องมีการปรับปรุงแอปพลิเคชันทั้งหมดให้ทันสมัยของ Big Bang โดยไม่กระทบต่อบริการ

ประเภทของไมโครเซอร์วิส

ไมโครเซอร์วิสแบบดิฟเฟอเรนเชียลและอินทิกรัลเป็นไมโครเซอร์วิสสองประเภทที่แตกต่างกัน

ก. ดิฟเฟอเรนเชียล

ในรูปแบบสถาปัตยกรรมนี้ สถาปัตยกรรมจะแยกออกเป็นบริการอิสระที่สามารถแยกออกเป็นธุรกรรมได้ ส่งผลให้มีการกระจายธุรกรรมเดียวไปยังหลายบริการ

ข. ปริพันธ์

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

ลักษณะของไมโครเซอร์วิส

1. ปกครองตนเอง

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

2. เฉพาะทาง

แต่ละบริการขึ้นอยู่กับชุดทักษะและปัญหาที่แตกต่างกัน เมื่อเวลาผ่านไป หากนักพัฒนาเพิ่มรหัสเพิ่มเติมในบริการ บริการอาจถูกแบ่งออกเป็นบริการที่เล็กลง

3. การจัดองค์ประกอบผ่านบริการ

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

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

4. ผลิตภัณฑ์ไม่ใช่โครงการ

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

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

5. การกระจายอำนาจการปกครอง

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

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

สำหรับชุมชนไมโครเซอร์วิส ค่าใช้จ่ายเป็นสิ่งที่ไม่พึงปรารถนาอย่างยิ่ง

6. มาตรฐานการทดสอบการรบและมาตรฐานที่บังคับใช้

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

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

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

7. ระบบอัตโนมัติโครงสร้างพื้นฐาน

ผลข้างเคียงหนึ่งที่เราได้เห็นจากระบบอัตโนมัติมากขึ้นอันเป็นผลมาจากการส่งมอบและการใช้งานอย่างต่อเนื่องคือการแนะนำเครื่องมือที่มีประโยชน์เพื่อช่วยเหลือนักพัฒนาและกลุ่มปฏิบัติการ เครื่องมือสำหรับการผลิตสิ่งประดิษฐ์ การบำรุงรักษา codebase การเริ่มบริการพื้นฐานหรือสำหรับการเพิ่มการตรวจสอบและการบันทึกที่เป็นมาตรฐานนั้นค่อนข้างแพร่หลายในปัจจุบัน ตัวอย่างที่ดีที่สุดบนเว็บคือคอลเล็กชันเครื่องมือโอเพนซอร์ซของ Netflix อย่างไม่ต้องสงสัย แม้ว่าจะมีเครื่องมืออื่นๆ ที่โดดเด่นคือ Dropwizard ที่เราใช้กันอย่างแพร่หลาย

ภาพรวมของกลไกการสื่อสารในสถาปัตยกรรมไมโครเซอร์วิส

บริการที่ประกอบเป็นสถาปัตยกรรมไมโครเซอร์วิสจะดำเนินการบนเซิร์ฟเวอร์ที่แตกต่างกันจำนวนหนึ่ง มีการใช้โปรโตคอลเช่น HTTP, AMQP และ TCP เพื่ออำนวยความสะดวกในการสื่อสารระหว่างบริการจำนวนมากเหล่านี้ สองโปรโตคอลที่มีการนำไปใช้อย่างแพร่หลายมากที่สุดคือ HTTP/REST และการส่งข้อความแบบอะซิงโครนัส โปรโตคอล HTTP มักถูกใช้โดย REST Application Programming Interface (API) สำหรับบริการออนไลน์ ลูกค้าสามารถเข้าถึงและแก้ไขทรัพยากรของแอปพลิเคชันโดยใช้ตัวระบุตำแหน่งทรัพยากรที่เหมือนกันร่วมกับวิธี HTTP เช่น GET, POST, PUT และ DELETE (URL) อินเทอร์เฟซการเขียนโปรแกรมแอปพลิเคชัน REST (API) ทำหน้าที่เป็นจุดเริ่มต้นของฟังก์ชันการทำงานของแอปพลิเคชัน ลูกค้าแจ้งความต้องการของตนต่อบริการโดยส่งคำขอไปยัง API ลูกค้ามีตัวเลือกในการสื่อสารกับไมโครเซอร์วิสโดยตรงหรือผ่านทางเกตเวย์ API

มีการระบุจุดเข้าใช้งานเพียงจุดเดียวสำหรับคำขอใดๆ และทั้งหมดที่ส่งไปยังบริการโดยใช้รูปแบบเกตเวย์ API เกตเวย์ Application Programming Interface (API) เมื่อได้รับคำขอจากลูกค้า จะส่งคำขอไปยังบริการที่เหมาะสม

รูปแบบเกตเวย์ API มีหลายแบบ หนึ่งในนั้นคือแบ็กเอนด์สำหรับรูปแบบส่วนหน้า การออกแบบนี้สร้างเกตเวย์ API ที่แตกต่างกันสำหรับไคลเอ็นต์แต่ละประเภท (เช่น เกตเวย์หนึ่งสำหรับไคลเอ็นต์มือถือ และอีกเกตเวย์สำหรับแอปพลิเคชันเว็บ)

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

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

สถาปัตยกรรม Microservices ใช้สำหรับอะไร?

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

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

• CPU เฉพาะของมัน
• ระบบปฏิบัติการและสภาพแวดล้อมรันไทม์ของตัวเอง
• ในหลายกรณี ทีมผู้เชี่ยวชาญจะทำงานเพื่อให้แน่ใจว่าแต่ละบริการจะแตกต่างจากบริการอื่นๆ

ด้วยการออกแบบนี้ แต่ละบริการจึงสามารถ:

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

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

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

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

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

ก. การย้ายเว็บไซต์

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

ข. เนื้อหาสื่อ

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

ค. การเจรจาทางการเงินและการเรียกเก็บเงิน

เป็นไปได้ที่จะถือว่าการประมวลผลการชำระเงินและคำสั่งซื้อเป็นบริการที่แตกต่างกันสองส่วน ทำให้สามารถรับชำระเงินได้แม้ว่าจะมีปัญหากับระบบการเรียกเก็บเงินก็ตาม

ง. การประมวลผลข้อมูล

บริการประมวลผลข้อมูลแบบแยกส่วนสามารถปรับปรุงการรองรับระบบคลาวด์ได้ด้วยการใช้แพลตฟอร์มไมโครเซอร์วิส ซึ่งสามารถนำไปใช้ในการประมวลผลข้อมูลได้เช่นกัน

รูปแบบการออกแบบสำหรับไมโครเซอร์วิส

ภาษารูปแบบเป็นแนวทางของคุณ!

ก) รูปแบบการสลายตัว

• บล็อกเฮ ดแยกทรัพยากรที่สำคัญ เช่น พูลการเชื่อมต่อ หน่วยความจำ และ CPU สำหรับแต่ละเวิร์กโหลดหรือบริการ ด้วยการติดตั้งระบบกั้น ปริมาณงานเดียว (หรือบริการ) จะไม่สามารถใช้ทรัพยากรทั้งหมดได้ ทำให้ผู้อื่นอดอยาก แนวทางนี้ช่วยเพิ่มความทนทานของระบบโดยขจัดความล้มเหลวของคาสเคดที่เกิดจากบริการเดียว รูปแบบนี้ถูกขนานนามว่า Bulkhead เพราะมันคล้ายกับพาร์ทิชันแบบแบ่งส่วนของตัวเรือ แบ่งอินสแตนซ์บริการออกเป็นกลุ่มต่างๆ ตามความต้องการของลูกค้าและความพร้อมใช้งาน สถาปัตยกรรมนี้ช่วยแยกข้อผิดพลาด และช่วยให้คุณสามารถรักษาความสามารถในการให้บริการสำหรับผู้ใช้บางคน แม้จะอยู่ระหว่างการแยกย่อย
• Sidecar ติดตั้งส่วนประกอบที่เป็นประโยชน์ของแอปพลิเคชันเป็นคอนเทนเนอร์หรือกระบวนการที่แตกต่างกันเพื่อเปิดใช้งานการแยกและการห่อหุ้ม รูปแบบนี้ยังช่วยให้แอปพลิเคชันประกอบด้วยส่วนประกอบและเทคโนโลยีที่แตกต่างกัน รูปแบบนี้ถูกขนานนามว่า Sidecar เพราะมันคล้ายกับรถมอเตอร์ไซค์พ่วงข้างที่ผูกติดอยู่กับมอเตอร์ไซค์ ในการออกแบบ sidecar นั้นเชื่อมต่อกับแอพพลิเคชั่นหลักและเสนอฟังก์ชันที่รองรับสำหรับแอพพลิเคชั่น รถเทียมข้างเคียงมีอายุการใช้งานเท่ากับแอปพลิเคชันหลัก ซึ่งสร้างและยุติร่วมกับผู้ปกครอง รูปแบบไซด์คาร์มักเรียกว่ารูปแบบไซด์คิก และเป็นรูปแบบการสลายตัวสุดท้ายที่เราแสดงในโพสต์
• Strangler Fig รองรับการปรับโครงสร้างใหม่ของแอปพลิเคชัน โดยค่อยๆ แทนที่ฟังก์ชันการทำงานเฉพาะด้วยบริการใหม่

b) รูปแบบการบูรณาการ

1. รูปแบบไมโครเซอร์วิสที่ถูกล่ามโซ่

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

2. รูปแบบผู้รวบรวม

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

รูปแบบ Aggregator ช่วยในการแก้ไขปัญหานี้ อธิบายวิธีที่เราอาจรวมข้อมูลจากหลายแหล่งแล้วให้ผลลัพธ์สุดท้ายแก่ผู้ใช้ สามารถทำได้สองวิธี:

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

3. รูปแบบหนังสือมอบฉันทะ

เราเพียงแค่เสนอ Microservices ผ่านเกตเวย์ API ฉันอนุญาตให้ GW รับคุณลักษณะ API เช่น ความปลอดภัยและการจัดประเภท API ในตัวอย่างนี้ เกตเวย์ API ประกอบด้วยโมดูล API สามโมดูล:

• Mobile API ซึ่งใช้ API สำหรับไคลเอ็นต์มือถือ FTGO
• เบราว์เซอร์ API ซึ่งใช้ API กับแอปพลิเคชัน JavaScript ที่ทำงานในเบราว์เซอร์
• Public API ซึ่งใช้ API สำหรับนักพัฒนาบุคคลที่สาม

4. รูปแบบสาขา

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

ประโยชน์ของสถาปัตยกรรมไมโครเซอร์วิส

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

ก. ผลผลิตที่เหนือกว่า

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

ข. ความยืดหยุ่นที่ดีขึ้น

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

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

ค. ขยายขนาดได้

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

ในความเป็นจริง การปรับขนาดแนวนอนสูงที่บังคับให้องค์กรเช่น Netflix, Spotify, Uber และ Google เปลี่ยนจาก Monolithic เป็น Microservice Architecture ประการที่สอง หากไมโครเซอร์วิสตัวใดตัวหนึ่งมี CPU จำนวนมาก ไมโครเซอร์วิสนั้นอาจถูกเขียนด้วยภาษาโปรแกรมที่ปรับให้เหมาะสมกับ CPU (C/C++, Rust) ในขณะที่ไมโครเซอร์วิสอื่นๆ อาจเขียนด้วยภาษาที่แปลแล้ว (Java, PHP)

ง. การบูรณาการอย่างต่อเนื่อง / การส่งมอบอย่างต่อเนื่อง (CI/CD)

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

อี การทำให้เป็นโมดูล

ในสถาปัตยกรรมไมโครเซอร์วิส อุปสรรคระหว่างไมโครเซอร์วิสประกอบด้วยอินเทอร์เฟซทางกายภาพ (เครือข่าย) ที่ยากต่อข้าม ด้วยเหตุนี้ Microservices ที่ออกแบบมาอย่างดีจึงทำให้ Modularization หากการเปรียบเทียบการพัฒนาซอฟต์แวร์กับสังคม การมอดูเลต Microservice ก็เปรียบได้กับกฎหมายระดับชาติและระดับนานาชาติที่มีตำรวจ/บทลงโทษ อย่างที่เราทราบกันดีอยู่แล้ว กฎเกณฑ์ระดับชาติและระดับนานาชาติที่เข้มงวดมักจะสามารถรักษาความสงบเรียบร้อยของสังคมได้

ฉ. กำหนดการวางจำหน่าย

แง่มุมที่ดีที่สุดเกี่ยวกับสถาปัตยกรรม Microservice คือแต่ละ Microservice อาจถูกปรับใช้แยกกัน ด้วยเหตุนี้ รอบการเผยแพร่ซอฟต์แวร์สำหรับแอปพลิเคชันไมโครเซอร์วิสจึงสั้นลงอย่างมาก และด้วย CI/CD อาจมีการเผยแพร่จำนวนมากในแต่ละวัน

ข้อเสียของสถาปัตยกรรมไมโครเซอร์วิส

ก. Increased Complexity of Communication Between the Services

When an application is broken up into smaller parts, it takes more time to send and receive messages. When handling requests between the different modules, developers have to be extra careful. Different systems might talk to each other in different ways, so there might be a need for an interpreter. This can make it harder to set up the whole system all at once. One of the biggest problems with microservices is that it might be hard to switch from a monolith to microservices because it's hard to manage.

This basically means that a lot of services made by a lot of different teams are deployed in a lot of different places, making it very hard to manage them. For example, Monolithic Architecture gives the same answer whether a Web app has a few thousand lines of code or several million lines of code (Enterprise Java or Ruby on Rails or PHP). But in Microservice Architecture, there are many possible solutions depending on the applications and use cases.

So, Microservice Architecture is doomed to fail if the wrong solution is used for the wrong application size or type (like putting a child's clothes on an adult man or the other way around). Also, it's hard to design Microservices because they have a lot more moving parts than Monoliths. Most of the time, a Microservice with bad design is worse than a Monolith.

ข. Complex Configuration

Despite being isolated and self-contained, a microservice must be regularly configured, especially when it is moved from development to test to staging to production. This arrangement may be rather intricate. Moreover, if a microservice must utilize other microservices, these bindings must be defined before deployment or even during runtime.

ค. Context Boundary Translation

Despite the fact that it would be ideal if all microservices within a MOA used the same data structures and communication protocols to interact with one another, this is typically not the case.

ง. More Assets in Return for More Autonomy

MOAs demand a great deal of horsepower. Remember that each MOA microservice has its own runtime environment and data storage. In some instances, even the most streamlined microservice might consume the same amount of resources as a single monolithic program.

อี Unfeasible for Small Applications

Larger applications can benefit from microservices design. However, implementation will likely be more time-consuming and difficult for smaller applications.

ฉ. Relatively Complex Deployment

The deployment might be a difficult and complicated process. During deployment, coordination between numerous services would be required. Deploying a WAR file in a container would not be as straightforward as it sounds.

กรัม Distributed Debugging

The difficulty of troubleshooting a MOA including hundreds of microservices communicating in concert is one of the downsides of microservices. Tracing the course of a request into and out of a MOA is challenging due to the independence of each container. The MOA is opaque if there is no effective monitoring mechanism in place. Logging the internals of a MOA offers a limited perspective, but MOA monitoring requires a comprehensive view.

ชม. Contributes to Enhanced Fault Tolerance

Large applications with several services deployed have more fault tolerance in the event that any one module fails. Microservices allow applications to continue functioning even if one service fails. This is because the services are not tightly coupled.

ผม. Costly

An improper service partition might be expensive. For instance, if an application is improperly partitioned, the services are connected to a certain degree, and they will create numerous inter-service interactions via the network, which can degrade performance.

เจ Greater Security Risks

Lastly, because microservices will reside across several environments, computers, and API requests, they provide a greater number of entry points for an attacker to compromise the system.

เค Communication Complexities

Microservices accomplish rigorous modularity and development independence via process/network barriers, as previously mentioned. The disadvantage is that services may only communicate over the physical network, resulting in increased network latency. Microservices may connect with one another in a variety of methods, including synchronous communication using REST, gRPC, and asynchronous communication using Message Queue and Message Broker, each of which has advantages and disadvantages.

Synchronous communication is simpler to build, but it might result in a Distributed Monolith. Asynchronous Communication via Messaging provides greater flexibility at the expense of increased implementation complexity. In Microservice Architecture, choosing the appropriate Communication channel based on the application is equally tough.

ล. การกำหนดค่าที่ซับซ้อน

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

เครื่องมือไมโครเซอร์วิส

1. ระบบปฏิบัติการ

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

2. ภาษาโปรแกรม

ด้วย Emizentech คุณสามารถขยายรายการเพลงของคุณได้อย่างราบรื่น เครื่องมือนี้ใช้งานได้จริงและเป็นปัจจุบัน โดยทั่วไปแล้ว มันถูกออกแบบมาสำหรับใช้กับภาษาโปรแกรมทั้งหมด นอกจากนี้ยังเข้ากันได้กับ bytecode ที่แสดงบน BEAM ซึ่งเรียกอีกอย่างว่า Erlang Virtual Machine

3. เครื่องมือจัดการและทดสอบ API (เกตเวย์ API)

การดำเนินการสร้างและเผยแพร่ API การบังคับใช้มาตรฐานการใช้งาน การจำกัดการเข้าถึง การปลูกฝังชุมชนนักพัฒนา การรวบรวมและวิเคราะห์สถิติการใช้งาน และการรายงานประสิทธิภาพเป็นองค์ประกอบทั้งหมดของการดูแลระบบ API

ในความเป็นจริง แพลตฟอร์มการจัดการ API ประกอบด้วยองค์ประกอบต่อไปนี้:

• เครื่องมือสำหรับผู้พัฒนา
• ประตู
• การรายงานและการวิเคราะห์

4. เครื่องมือส่งข้อความ (การส่งข้อความและการสตรีมเหตุการณ์)

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

LinkedIn รับผิดชอบในการสร้างเทคโนโลยีที่เรียกว่า Apache Kafka ซึ่งต่อมาได้มีส่วนร่วมในชุมชน Apache

รูปแบบถูกใช้โดยเครื่องมือ RabbitMQ เพื่ออำนวยความสะดวกในการสื่อสารข้ามไมโครเซอร์วิสต่างๆ นอกจากนั้นยังช่วยในกระบวนการปรับขนาดแอปพลิเคชันพร้อมกัน

5. ชุดเครื่องมือ

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

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

6. กรอบโครงสร้างทางสถาปัตยกรรมและ Js Toolkit

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

7. เครื่องมือประสาน

เนื่องจากคอนเทนเนอร์และไมโครเซอร์วิสทำงานร่วมกันโดยทั่วไป การประสานคอนเทนเนอร์จึงเป็นหัวข้อที่สำคัญมากที่ต้องคำนึงถึง Conductor, Kubernetes และ Istio เป็นโซลูชันประสาน microservices สามตัวที่ใช้บ่อยที่สุดสำหรับการจัดเรียงคอนเทนเนอร์ อย่างไรก็ตาม ยังมีเครื่องมืออื่นๆ อีกมากมาย ในฐานะที่เป็นส่วนหนึ่งของระบบนิเวศซอฟต์แวร์โอเพ่นซอร์ส (OSS) ที่ Netflix ดูแล ตัวนำทำหน้าที่เป็นกลไกจัดการไมโครเซอร์วิส ตัวนำคือโปรแกรมที่ทำงานบนคลาวด์และใช้การนำไปใช้ที่เรียกว่าโฟลว์ออร์เคสตราเพื่อดำเนินกิจกรรมต่างๆ โดยใช้ไมโครเซอร์วิส นอกจากนี้ ยังช่วยให้ควบคุมและดูการโต้ตอบทั้งหมดที่เกิดขึ้นในไมโครเซอร์วิสได้ง่ายขึ้น

8. เครื่องมือตรวจสอบ

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

9. เครื่องมือไร้เซิร์ฟเวอร์

ส่วนประกอบที่สำคัญของ SA ของไมโครเซอร์วิสคือเทคโนโลยีแบบไร้เซิร์ฟเวอร์ ซึ่งมักเรียกกันว่า ปรับปรุงประสิทธิภาพของกระบวนการรื้อวัตถุให้เป็นส่วนประกอบพื้นฐานที่สุด ทั้ง Claudia และ AWS Lambda เป็นตัวอย่างของเครื่องมือไร้เซิร์ฟเวอร์ที่ใช้กันอย่างแพร่หลายในการพัฒนาไมโครเซอร์วิส การติดตั้ง AWS Lambda และ API Gateway เป็นส่วนหนึ่งของความรับผิดชอบของ Claudia ด้วย นอกจากนี้ คลอเดียยังสามารถทำให้กิจกรรมการปรับใช้และการตั้งค่าที่มีแนวโน้มเกิดข้อผิดพลาดเป็นไปโดยอัตโนมัติ ขณะเดียวกันก็รักษาฟังก์ชันการทำงาน "นอกกรอบ" ไว้ได้

10. ตู้คอนเทนเนอร์ Docker และ Kubernetes

• คอนเทนเนอร์: คอนเทนเนอร์จะทำการจำลองระบบปฏิบัติการของโฮสต์ (หรือเคอร์เนล) เป็นหลัก โดยแยกความต้องการของแอปพลิเคชันออกจากคอนเทนเนอร์อื่นๆ ที่กำลังดำเนินการบนคอมพิวเตอร์เครื่องเดียวกัน
• นักเทียบท่า: นักเทียบท่าประกอบด้วยส่วนต่าง ๆ มากมาย รวมถึงรันไทม์คอนเทนเนอร์ที่เรียกว่า dockerd ตัวสร้างอิมเมจคอนเทนเนอร์ที่เรียกว่า BuildKit และอินเทอร์เฟซบรรทัดคำสั่งที่ใช้โต้ตอบกับตัวสร้าง คอนเทนเนอร์ และเอ็นจิ้น (เรียกว่านักเทียบท่า)
• Kubernetes เป็นเทคโนโลยีการจัดการคอนเทนเนอร์แบบโอเพ่นซอร์สฟรีที่รวมกลุ่มคอมพิวเตอร์ไว้ในแหล่งทรัพยากรการประมวลผลเพียงแหล่งเดียว Kubernetes ได้รับการพัฒนาโดย Google Kubernetes ช่วยให้คุณสามารถจัดโครงสร้างแอปพลิเคชันของคุณในรูปแบบของกลุ่มคอนเทนเนอร์ ซึ่งจะถูกดำเนินการโดยเอ็นจิน Docker Kubernetes จะดูแลให้แอปพลิเคชันของคุณทำงานต่อไปในลักษณะที่คุณระบุ

รูปแบบทั่วไปในสถาปัตยกรรมไมโครเซอร์วิส

ก. รูปแบบแบ็กเอนด์สำหรับส่วนหน้า (BFF)

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

ข. รูปแบบเอนทิตีและการรวม

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

ค. รูปแบบการค้นพบบริการ

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

ง. รูปแบบไมโครเซอร์วิสอแดปเตอร์

การออกแบบ Adapter Microservices จะปรับเปลี่ยนหากจำเป็น ระหว่าง API เชิงธุรกิจที่สร้างโดยใช้เทคนิคการส่งข้อความแบบ RESTful หรือน้ำหนักเบา โดยใช้วิธีการที่ขับเคลื่อนด้วยโดเมนเดียวกันกับไมโครเซอร์วิสทั่วไป และ API ดั้งเดิมหรือบริการ SOAP แบบ WS-* แบบคลาสสิก จำเป็นต้องมีการปรับเปลี่ยน เช่น เมื่อทีมพัฒนาขาดการควบคุมแบบกระจายศูนย์สำหรับแหล่งข้อมูลของแอปพลิเคชัน

อี รูปแบบการสมัครคนแปลกหน้า

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

รูปแบบการต่อต้านในสถาปัตยกรรมไมโครเซอร์วิส

ก. ความโกลาหลในการทำงานร่วมกัน

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

ข. สถาปัตยกรรมบริการแบบเลเยอร์

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

ค. ความซับซ้อน

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

ง. กลยุทธ์การกำหนดเวอร์ชันที่ไม่ดี

กลยุทธ์การกำหนดเวอร์ชันที่ไม่มีประสิทธิภาพส่งผลให้เกิดโค้ดและการพึ่งพาที่ไม่สามารถจัดการได้ ด้วยเหตุนี้ จึงควรวางแนวทางการกำหนดเวอร์ชันที่มีประสิทธิภาพสำหรับสถาปัตยกรรม Microservices วิธีพื้นฐานที่สุดวิธีหนึ่งคือการสร้างเวอร์ชัน API และรวมเวอร์ชันไว้ใน URL เส้นทาง

อี การออกแบบรูปแบบการเข้าถึงข้อมูลปริมาณงานของ Microservices ที่ไม่เหมาะสม

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

ฉ. ความผิดปกติของการพึ่งพา

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

วิธีที่ดีในการหลีกเลี่ยงรูปแบบการต่อต้านนี้คือการแนะนำ API Gateway

ความแตกต่างระหว่างสถาปัตยกรรมแบบเสาหิน ไมโครเซอร์วิส และสถาปัตยกรรมเชิงบริการ

ตลาดแนวดิ่งที่สำคัญต้องการไมโครเซอร์วิส

การดูแลสุขภาพ: ตลาดไมโครบริการด้านการดูแลสุขภาพคาดว่าจะเติบโตจาก 130 ล้านดอลลาร์ในปี 2558 เป็น 519 ล้านดอลลาร์ในปี 2568 ความต้องการสำหรับการเปิดตัวบริการที่รวดเร็วยิ่งขึ้น การยอมรับเทคโนโลยีใหม่ที่รวดเร็วยิ่งขึ้น และประสิทธิภาพที่ดีขึ้นกำลังขับเคลื่อนการพัฒนาในอุตสาหกรรมการดูแลสุขภาพ อุตสาหกรรมการดูแลสุขภาพแสวงหาคำตอบสำหรับความต้องการด้านความปลอดภัยของข้อมูลและการปฏิบัติตามกฎระเบียบ ตลอดจนวิธีเอาชนะความยากลำบากในการใช้งาน

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

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

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

สื่อและความบันเทิง: ในปี 2552 Netflix ได้ย้ายไปยังไมโครเซอร์วิส และขณะนี้บริการประมวลผลคำขอขอบ 2 พันล้านรายการทุกวันโดยใช้ไมโครเซอร์วิสมากกว่า 500 รายการ การเปลี่ยนแปลงนี้มอบความเร็ว ความสามารถในการปรับขนาด และการเข้าถึงได้

ตัวอย่างของบริษัทที่นำสถาปัตยกรรมไมโครเซอร์วิสมาใช้

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

#1. Uber

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

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

#2. Netflix

จากนั้น Netflix ก็ย้ายไปยังโครงสร้างพื้นฐานข้อมูลแบบกระจายบนคลาวด์ AWS ถูกใช้เพื่อส่งมอบระบบที่ปรับขนาดได้ในแนวนอนและบริการ/คุณสมบัติเพิ่มเติม ในปี 2552 Netflix เริ่มโอนกิจการซึ่งเสร็จสิ้นหลังจากผ่านไปเกือบสามปี จากนั้น Netflix ได้แปลงแอปพลิเคชันที่ต้องเผชิญกับผู้ใช้ทั้งหมดเป็นไมโครเซอร์วิสแบบอัตโนมัติ ในปี 2555 การปรับปรุงโฉมเสร็จสิ้นลง ภายในปี 2015 Netflix ได้ขจัดการหยุดชะงักของบริการทั้งหมด และสามารถประมวลผลการสืบค้น API ได้ประมาณ 2 พันล้านคำต่อวัน ปัจจุบัน Netflix มีผู้ใช้มากกว่า 139 ล้านคนใน 190 ประเทศ วันนี้ Netflix ดำเนินการประมาณ 700 ระบบไมโครเซอร์วิสแยกจากกัน

#3. อเมซอน

Amazon มีเสาหินขนาดใหญ่ในปี 2544 ในปี 2564 เกือบทุกคนคุ้นเคยกับ Amazon Web Services (AWS) ซึ่งเป็นโซลูชันภายในที่กลายมาเป็นบริการคลาวด์คอมพิวติ้งเชิงพาณิชย์เนื่องจากมีความเหนือกว่า Microservices นั้นยอดเยี่ยมสำหรับอีคอมเมิร์ซเพราะสามารถติดตามกิจกรรมของผู้ใช้ การซื้อ และช่องทางการขายเต็มรูปแบบ ตามที่ผู้จัดการผลิตภัณฑ์อาวุโสของ Amazon

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

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

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

#4. อีเบย์

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

#5. SoundCloud

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

#6. Spotify

เพื่อป้องกันการซิงโครไนซ์ภายในบริษัท Spotify ได้รับการออกแบบบนสถาปัตยกรรมไมโครเซอร์วิสโดยมีทีมงานฟูลสแตกอิสระที่รับผิดชอบ Spotify ใช้สถาปัตยกรรม Microservice ซึ่งนักพัฒนาซอฟต์แวร์ทุกคนเขียนใน "อาณาเขต" แบบปิดที่มีความสามารถเฉพาะตัวของตนเอง Microservice แต่ละรายการมีความรับผิดชอบเดียวที่ตรงไปตรงมา และในกรณีส่วนใหญ่ ฐานข้อมูลและตรรกะที่ไม่สามารถเข้าถึงได้โดยกระบวนการอื่น

Microservices สามารถช่วยให้คุณเอาชนะความท้าทายประเภทใดได้บ้าง

นี่คือคำตอบสำหรับคำถาม "ไมโครเซอร์วิสแก้ปัญหาอะไรได้บ้าง"; มาตรวจสอบอุปสรรคที่สถาปัตยกรรมไมโครเซอร์วิสช่วยเอาชนะกัน

กรณีที่ 1 ยอดคงเหลือของ eBay คืนมา

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

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

กรณีที่ 2 Uber และการขยายตัวอย่างรวดเร็ว

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

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

การขาดรูปแบบความเป็นเจ้าของนั้นเกิดจากการพึ่งพาอาศัยกันของเสาหินจำนวนมาก ดังนั้นการโยกย้ายถิ่นฐานจึงเป็นเรื่องยาก นอกจากนี้ยังเกิดขึ้นที่นักพัฒนาที่ได้รับการว่าจ้างใหม่ไม่สามารถมีส่วนร่วมในเสาหินได้ แม้จะเกิดข้อผิดพลาดเล็กน้อย แต่ผลที่ตามมาก็รุนแรง นี่คือตอนที่พวกเขาตัดสินใจใช้ไมโครเซอร์วิส การเคลื่อนไหวของพวกเขาใช้เวลาพอสมควร พวกเขาแยกส่วนบริการทั้งหมดและย้ายแอปพลิเคชันแบบเสาหินไปยังสถาปัตยกรรมที่เน้นบริการขนาดเล็กซึ่งสร้างขึ้นโดยใช้ Python, Node.js และ Apache Thrift

กรณีที่ 3 เวลาทำงานที่ดีขึ้นของ Twitter

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

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

กรณีที่ 4 KarmaWifi และรหัสสปาเก็ตตี้

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

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

กรณีที่ 5 ประสิทธิภาพที่ดีขึ้นของ Walmart

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

พวกเขาเริ่มใช้เทคโนโลยีเช่น Node.js และฐานข้อมูล Cassandra เพื่อสร้างไมโครเซอร์วิสต่างๆ ที่สามารถเรียกใช้แบบไดนามิกผ่าน API วัตถุประสงค์คือการทำให้นักพัฒนาที่ทำงานในแผนกธุรกิจหลายแห่งของ Walmart เป็นเจ้าของแอพได้ง่ายขึ้นและช่วยให้พวกเขาทำเช่นนั้นได้ง่ายขึ้น พวกเขาค้นพบว่าสิ่งนี้ลดการพึ่งพากลุ่มไอทีแบบรวมศูนย์

ในที่สุด ความสามารถของนักพัฒนาในการขยายความสามารถส่วนหลังของข้อเสนออีคอมเมิร์ซขององค์กรมีส่วนทำให้ธุรกิจมีความคล่องตัวเพิ่มขึ้น

จะนำสถาปัตยกรรม Microservices ไปใช้งานบน Android และ iOS ได้อย่างไร

1. ขั้นตอนที่ 1: ตัดสินใจว่าธุรกิจของคุณต้องการจริงๆ หรือไม่
2. ขั้นตอนที่ 2: ถ้าใช่ ให้ดูโครงสร้างพื้นฐานที่มีอยู่แล้ว
3. ขั้นตอนที่ 3: เตรียมทีมของคุณให้พร้อมใช้วิธีการ
4. ขั้นตอนที่ 4: หากคุณกำลังเปลี่ยนจากระบบเสาหินเป็นระบบไมโครเซอร์วิส ให้ตรวจสอบกับผู้ดูแลระบบข้อมูลของคุณเพื่อดูว่าพวกเขาได้รับแจ้งและเข้าใจงานเป็นอย่างดีหรือไม่
5. ขั้นตอนที่ 5: เลือกภาษาและกรอบงานสำหรับการเข้ารหัส
6. ขั้นตอนที่ 6: ตั้งค่าสถาปัตยกรรมพื้นฐานด้วยบริการ คอนเทนเนอร์ และเทมเพลตเครื่องเสมือน
7. ขั้นตอนที่ 7: แยกฐานข้อมูลออกเป็นฐานข้อมูลขนาดเล็กจำนวนมากหากสถาปัตยกรรมของคุณเป็น “เสาหิน”
8. ขั้นตอนที่ 8: ใส่เกตเวย์ API เข้าที่
9. ขั้นตอนที่ 9: ติดตามการติดตามและทำแผนที่
10. ขั้นตอนที่ 10: ทดสอบโดยใช้ระบบอัตโนมัติ

Microservices เป็นอนาคตหรือไม่?

วัตถุประสงค์หลักของบทความนี้คือการอธิบายแนวคิดพื้นฐานและหลักการของไมโครเซอร์วิส จากการพยายามทำให้สำเร็จ เห็นได้ชัดว่าเราถือว่ารูปแบบสถาปัตยกรรมไมโครเซอร์วิสเป็นแนวคิดที่จำเป็น ซึ่งเป็นแนวคิดที่แอปพลิเคชันขององค์กรควรพิจารณาอย่างรอบคอบ เมื่อเร็วๆ นี้ เราได้พัฒนาระบบจำนวนหนึ่งที่ใช้ลักษณะนี้ และเราทราบดีว่ามีผู้อื่นที่ชื่นชอบวิธีการนี้ Amazon, Netflix, The Guardian, UK Government Digital Service, realestate.com.au, Forward และ comparisonthemarket.com เป็นกลุ่มที่เราทราบดีว่าใครเป็นผู้บุกเบิกรูปแบบสถาปัตยกรรมในรูปแบบใดรูปแบบหนึ่ง

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

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

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

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

 ดังนั้นเราจึงเขียนสิ่งนี้ด้วยการมองในแง่ดีอย่างระมัดระวัง เราเชื่อว่า Microservices จะยังคงอยู่!

ทำไมต้องเลือก EmizenTech?

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

ลักษณะเด่นของบริการของเราคือ:

• สถาปัตยกรรมที่ขับเคลื่อนด้วยโดเมนเพื่อป้องกันความล้มเหลวของแอปพลิเคชัน
• มั่นใจได้ถึงความสามารถในการปรับขยายในระดับสูง
• การออกแบบฐานข้อมูลแบบกระจายอำนาจ
• เปิดใช้งานการแยกความล้มเหลวอย่างง่ายและ
• เปิดใช้งานการจัดส่งอย่างต่อเนื่องโดยใช้วัฒนธรรม DevOps

ปิดความคิด

ก้าวต่อไป!

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

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

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

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

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

microservices ช่วยให้ธุรกิจของคุณก้าวไปข้างหน้าได้หรือไม่? อย่าลังเลที่จะติดต่อเราเพื่อขอคำปรึกษาที่ไม่มีข้อผูกมัด!

ขอบคุณที่อ่าน!

คำถามที่พบบ่อยเกี่ยวกับสถาปัตยกรรมไมโครเซอร์วิส