การปรับใช้ไมโครเซอร์วิส: ทุกอย่างตั้งแต่แนวทางปฏิบัติและกลยุทธ์ที่ดีที่สุดไปจนถึงการตรวจสอบและความปลอดภัย

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

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

สิ่งนี้นำไปสู่การพัฒนาแนวทางแบบโมดูลาร์มากขึ้น เช่น สถาปัตยกรรมเชิงบริการ (SOA) และต่อมา สถาปัตยกรรมไมโครเซอร์วิส (MSA)ซึ่งในที่สุดก็มีความโดดเด่นในช่วงต้นปี 2010

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

ไมโครเซอร์วิสคืออะไร? พวกเขาทำงานอย่างไร?

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

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

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

ไมโครเซอร์วิสทำงานอย่างไร?

โดยแก่นของสถาปัตยกรรมไมโครเซอร์วิสจะแบ่งแอปพลิเคชันขนาดใหญ่ออกเป็นบริการขนาดเล็กและแตกต่าง โดยแต่ละบริการจะรับผิดชอบความสามารถทางธุรกิจที่เฉพาะเจาะจง บริการเหล่านี้สื่อสารกันผ่านเครือข่าย โดยมักจะผ่าน REST API, gRPC หรือตัวรับส่งข้อความ เช่น RabbitMQ หรือ Apache Kafka

ตามคำจำกัดความของ Martin Fowler และ James Lewis ไมโครเซอร์วิสล้วนมีคุณลักษณะสำคัญสี่ประการดังต่อไปนี้:

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

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

ขั้นตอนสำคัญของการปรับใช้ไมโครเซอร์วิส

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

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

การวางแผนและการเตรียมพร้อมสำหรับการใช้งานไมโครเซอร์วิส

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

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

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

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

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

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

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

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

กลยุทธ์การปรับใช้ไมโครเซอร์วิส

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

• อินสแตนซ์บริการต่อคอนเทนเนอร์: ในแนวทางนี้ ไมโครเซอร์วิสแต่ละรายการจะทำงานในคอนเทนเนอร์ของตัวเอง ซึ่งให้การแยกได้ดีกว่าอินสแตนซ์หลายรายการต่อโมเดลโฮสต์ คอนเทนเนอร์ช่วยให้ปรับขนาดได้ง่ายและปรับปรุงการจัดสรรทรัพยากร
• อินสแตนซ์บริการต่อเครื่องเสมือน: แต่ละบริการทำงานในเครื่องเสมือน (VM) ที่แยกจากกัน ซึ่งให้การแยกตัวที่ดีกว่าคอนเทนเนอร์ แม้ว่าสิ่งนี้จะปรับปรุงความปลอดภัยและความเสถียร แต่โดยทั่วไปแล้วจะต้องมีค่าใช้จ่ายมากกว่า
• การเผยแพร่แบบค่อยเป็นค่อยไป: ขั้นแรก ให้ปรับใช้เวอร์ชันไมโครเซอร์วิสกับผู้ใช้กลุ่มเล็กๆ ทดสอบความเสถียรก่อนที่จะเปิดตัวเต็มรูปแบบ วิธีการนี้ช่วยลดผลกระทบหากเกิดปัญหา และช่วยให้สามารถย้อนกลับได้อย่างรวดเร็วเพื่อรักษาความสมบูรณ์ของระบบ
• การปรับใช้สีน้ำเงิน-เขียว: วิธีการนี้ใช้สภาพแวดล้อมการผลิตที่เหมือนกันสองสภาพแวดล้อม โดยสภาพแวดล้อมหนึ่งรองรับการรับส่งข้อมูลสด ในขณะที่อีกสภาพแวดล้อมหนึ่งใช้สำหรับการทดสอบรุ่นถัดไป การใช้งานสีน้ำเงิน-เขียวช่วยให้สามารถย้อนกลับได้ง่ายและอัปเดตเป็นศูนย์ เนื่องจากสามารถสลับการรับส่งข้อมูลระหว่างสองสภาพแวดล้อมได้อย่างราบรื่น
• การเผยแพร่แบบเป็นฉาก: กลยุทธ์นี้เกี่ยวข้องกับการค่อยๆ เปิดตัวการอัปเดตไปยังกลุ่มผู้ใช้หรือสภาพแวดล้อมที่แตกต่างกัน โดยมักจะเริ่มต้นด้วยสภาพแวดล้อมภายในก่อนถึงการผลิต การจำกัดรัศมีการระเบิดของปัญหาที่อาจเกิดขึ้น และอนุญาตให้ทีมแก้ไขปัญหาเป็นขั้นตอน
• การปรับใช้แบบไร้เซิร์ฟเวอร์: แนวทางนี้ใช้ประโยชน์จากแพลตฟอร์มแบบไร้เซิร์ฟเวอร์ เช่น AWS Fargate และ Google Cloud Run ซึ่งทำให้การจัดการโครงสร้างพื้นฐานเป็นอัตโนมัติโดยจัดการการปรับขนาดและการจัดสรรทรัพยากรให้กับคุณ ด้วยการปรับใช้แบบไร้เซิร์ฟเวอร์ คุณไม่จำเป็นต้องจัดการเซิร์ฟเวอร์พื้นฐาน ช่วยให้คุณสามารถมุ่งเน้นไปที่ไมโครเซอร์วิสของคุณได้ด้วยตนเอง

เมื่อคุณเลือกไมโครเซอร์วิสข้อใดข้อหนึ่งข้างต้นเพื่อใช้งานไมโครเซอร์วิส คุณจะต้องมีเครื่องมือประสานไมโครเซอร์วิส

การจัดไมโครเซอร์วิส

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

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

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

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

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

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

เมื่อคุณตั้งค่าเครื่องมือประสานไมโครเซอร์วิสแล้ว คุณจะต้องสร้างและทำให้เป็นอัตโนมัติ ไปป์ไลน์ CI/CD สำหรับการปรับใช้ไมโครเซอร์วิส

ไปป์ไลน์ CI/CD สำหรับการปรับใช้ไมโครเซอร์วิส

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

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

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

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

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

บริษัทหลายแห่ง เช่น Spotify, Expedia, iRobot, Lufthansa, Pandora ฯลฯ ใช้ไปป์ไลน์ CI/CD สำหรับไมโครเซอร์วิสผ่านเครื่องมือ CI/CD เช่น CircleCI, AWS CodePipeline และ GitLab เพื่อทำให้กระบวนการปรับใช้เป็นอัตโนมัติ รับประกันคุณภาพของโค้ดที่สม่ำเสมอ และส่งมอบคุณสมบัติใหม่อย่างรวดเร็วในขณะที่ยังคงความเสถียรของระบบ

รูปแบบการสื่อสารไมโครเซอร์วิส

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

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

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

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

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

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

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

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

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

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

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

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

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

สำหรับตัวรับส่งข้อความ Publish-Subscribe (Pub/Sub) เช่น Google Cloud Pub/Sub และ Redis Streams ตัวรับส่งข้อความเหล่านี้มักจะใช้สำหรับการส่งข้อความที่ปรับขนาดได้ทั่วทั้งระบบแบบกระจายสำหรับการวิเคราะห์แบบเรียลไทม์และการนำเข้าเหตุการณ์ รวมถึงการแจ้งเตือนแบบเรียลไทม์และแอปพลิเคชันแชท

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

การค้นพบบริการไมโครเซอร์วิส

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

ซึ่งทำได้ผ่านการค้นพบบริการในตัวที่ Kubernetes DNS มอบให้ ซึ่งจะอัปเดตที่อยู่ IP และบันทึก DNS แบบไดนามิกตามขนาดบริการหรือเปลี่ยนตำแหน่งภายในคลัสเตอร์

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

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

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

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

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

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

โซลูชันการค้นพบบริการไมโครเซอร์วิสฝั่งเซิร์ฟเวอร์ เช่น Kubernetes, AWS Elastic Load Balancing และ API Gateways (Kong, NGINX ฯลฯ) ช่วยกำหนดเส้นทางการรับส่งข้อมูลอย่างมีประสิทธิภาพและรักษาความพร้อมใช้งานในระดับสูง และมีการใช้งานโดยบริษัทต่างๆ เช่น Airbnb, Pinterest, Expedia, Lyft เป็นต้น

ความปลอดภัยของไมโครเซอร์วิส

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

เนื่องจากแต่ละบริการจะต้องมีการรักษาความปลอดภัยแยกจากกัน จึงจำเป็นต้องมีการป้องกันเพิ่มเติม เนื่องจากพื้นผิวการโจมตีมีขนาดใหญ่กว่ามากในไมโครเซอร์วิส ด้วยเหตุนี้ มาตรฐาน เช่น OAuth2 และ JSON Web Tokens (JWT) จึงมักใช้เพื่อการตรวจสอบสิทธิ์และการอนุญาตตามที่คุณอาจเดาได้

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

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

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

การปรับขนาดไมโครเซอร์วิส

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

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

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

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

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

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

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

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

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

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

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

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

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

การตรวจสอบไมโครเซอร์วิส

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

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

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

ความคิดสุดท้าย

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

คำถามที่พบบ่อย

กลยุทธ์การปรับใช้ใดบ้างที่มักใช้สำหรับไมโครเซอร์วิส

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

Kubernetes มีบทบาทอย่างไรในการเตรียมไมโครเซอร์วิส

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

ฉันจะมั่นใจในความปลอดภัยในสภาพแวดล้อมไมโครเซอร์วิสได้อย่างไร

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