ในยุค 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 ฯลฯ) ซึ่งช่วยให้เห็นภาพโฟลว์คำขอในบริการต่างๆ และอาจเป็นประโยชน์อย่างมากต่อการวินิจฉัยปัญหา
สุดท้ายนี้ เนื่องจากความล้มเหลวสามารถต่อเนื่องกันในบริการได้เนื่องจากการออกแบบไมโครเซอร์วิสแบบกระจาย การรวมบันทึกจึงเป็นแนวทางปฏิบัติที่สำคัญในการตรวจสอบไมโครเซอร์วิส ด้วยการรวมบันทึกเข้ากับแพลตฟอร์มแบบรวมศูนย์และการตั้งค่าการแจ้งเตือนแบบเรียลไทม์ คุณจะก้าวนำหน้าปัญหาสองก้าวอยู่เสมอ และสามารถตอบสนองเชิงรุกก่อนที่จะส่งผลกระทบต่อผู้ใช้
บทสรุป
แม้ว่าโลกของไมโครเซอร์วิสจะเป็นเรื่องยากอย่างแน่นอน แต่การทำความเข้าใจพื้นฐานและขั้นตอนสำคัญของการใช้งานไมโครเซอร์วิสสามารถทำให้กระบวนการทั้งหมดง่ายขึ้นมาก นอกจากนี้ เมื่อเวลาผ่านไป ก็มีเครื่องมือมากมายพร้อมฟีเจอร์มากมายให้เลือกใช้ ทำให้การใช้งานไมโครเซอร์วิสง่ายกว่าที่เคย
คำถามที่พบบ่อย
กลยุทธ์การ deploy ที่ใช้กันทั่วไปสำหรับ microservices มีอะไรบ้าง
แม้ว่าจะมีกลยุทธ์ต่างๆ มากมายสำหรับการปรับใช้ไมโครเซอร์วิส แต่กลยุทธ์การปรับใช้ที่ใช้บ่อยที่สุด ได้แก่ อินสแตนซ์บริการต่อคอนเทนเนอร์ การเผยแพร่แบบเป็นขั้นตอน การปรับใช้สีน้ำเงินเขียว และการปรับใช้แบบไร้เซิร์ฟเวอร์ ซึ่งแต่ละกลยุทธ์มีระดับการแยก ความยืดหยุ่น และความสามารถในการปรับขนาดที่แตกต่างกัน
Kubernetes มีบทบาทอย่างไรในการจัดการ microservices
ไมโครเซอร์วิสอาศัยเครื่องมือประสานไมโครเซอร์วิส เช่น Kubernetes เพื่อทำให้การปรับใช้ ปรับขนาด และจัดการบริการแบบคอนเทนเนอร์เป็นไปโดยอัตโนมัติ โดยให้ความสามารถในการจัดสรรภาระงาน การปรับขนาดอัตโนมัติ และการรักษาตัวเอง เพื่อให้มั่นใจว่าไมโครเซอร์วิสจะมีความยืดหยุ่นและมีประสิทธิภาพ
ฉันจะมั่นใจในความปลอดภัยในสภาพแวดล้อมไมโครเซอร์วิสได้อย่างไร
เนื่องจากลักษณะการกระจายของไมโครเซอร์วิสจึงมีความซับซ้อนในเรื่องความปลอดภัยมากกว่าสถาปัตยกรรมขนาดใหญ่ การรักษาความปลอดภัยในไมโครเซอร์วิสเกี่ยวข้องกับการตรวจสอบสิทธิ์และการอนุญาตคำขอ การเข้ารหัสการสื่อสารระหว่างบริการ และการใช้เกตเวย์ API และโครงข่ายบริการ เช่น Istio สำหรับการจัดการความปลอดภัยแบบรวมศูนย์
