การนำไมโครเซอร์วิสไปใช้ในสภาพแวดล้อมการผลิต

Informatec Digital » แหล่งข้อมูล » การนำไมโครเซอร์วิสไปใช้ในสภาพแวดล้อมการผลิต

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

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

เหตุใดจึงต้องนำไมโครเซอร์วิสไปใช้งานจริง (และเมื่อใดที่มันไม่คุ้มค่า)

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

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

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

จากมุมมองทางเทคโนโลยี ไมโครเซอร์วิสช่วยให้สามารถเลือกภาษา เฟรมเวิร์ก และฐานข้อมูลสำหรับแต่ละบริการได้อย่างอิสระ ไม่จำเป็นต้องใช้เทคโนโลยีเดียวกันทั้งหมด คุณอาจมีบริการทางธุรกิจใน .NET หรือ Java บริการประมวลผลข้อมูลใน Scala/Spark บริการเฉพาะทางใน Python หรือ F# หรือไมโครเซอร์วิส AI ใน R ความหลากหลายที่ควบคุมได้นี้ช่วยให้คุณสามารถใช้เครื่องมือที่เหมาะสมสำหรับแต่ละกรณี โดยไม่ต้องบังคับให้แอปพลิเคชันทั้งหมดเปลี่ยนไปใช้เทคโนโลยีใหม่ทั้งหมด

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

การออกแบบสถาปัตยกรรมและการออกแบบบริการ

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

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

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

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

ระบบที่ซับซ้อนหลายระบบมักผสมผสานบริการ CRUD ที่ค่อนข้างง่ายเข้ากับบริการที่ซับซ้อนกว่าซึ่งจัดการกับกฎทางธุรกิจที่เปลี่ยนแปลงไปไม่ใช่ว่าไมโครเซอร์วิสทุกตัวจะต้องมีสถาปัตยกรรมภายในที่ซับซ้อนเสมอไป บางตัวอาจเป็นเพียงตัวควบคุม HTTP ที่มีการเข้าถึงข้อมูลพื้นฐาน ในขณะที่บางตัว เช่น บริการสั่งซื้อหรือเรียกเก็บเงิน สามารถใช้รูปแบบขั้นสูงกว่าได้ (DDD, CQRS, เหตุการณ์โดเมน ฯลฯ)

โครงสร้างพื้นฐานสำหรับการผลิต: คลาวด์ คอนเทนเนอร์ และ Kubernetes/OpenShift

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

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

ใน Kubernetes/OpenShift หน่วยการใช้งานพื้นฐานคือPod ซึ่งบรรจุคอนเทนเนอร์ตั้งแต่หนึ่งตัวขึ้นไปโดยทั่วไป ไมโครเซอร์วิสจะสอดคล้องกับ Pod ประเภทหนึ่ง และถูกใช้งานโดยใช้ทรัพยากร เช่น Deployments (สำหรับบริการที่ไม่มีสถานะ) หรือ StatefulSets (เมื่อมีสถานะที่เกี่ยวข้อง) ตั้งแต่เริ่มต้น จะมีการกำหนดจำนวนสำเนาขั้นต่ำต่อสภาพแวดล้อม เพื่อให้สภาพแวดล้อมสำหรับการทดสอบ ก่อนการผลิต และการผลิต มีระดับความพร้อมใช้งานที่เหมาะสมกับความสำคัญของแต่ละสภาพแวดล้อม

การปรับขนาดอัตโนมัติถูกนำมาใช้โดยใช้HorizontalPodAutoscaler (HPA)ซึ่งจะปรับจำนวนสำเนาตามตัวชี้วัดต่างๆ เช่น CPU หน่วยความจำ หรือตัวชี้วัดแบบกำหนดเองอื่นๆ นอกจากนี้ แพลตฟอร์มยังต้องกำหนดค่ากฎ anti-affinity ของ pod เพื่อกระจายสำเนาของบริการเดียวกันไปยังโหนดต่างๆ ป้องกันไม่ให้ความล้มเหลวของโหนดเดียวทำให้ทุกอินสแตนซ์ล่ม

ในส่วนของการกำหนดขนาดในแนวตั้งนั้นresources.requests และ resources.limits ใช้ เพื่อกำหนดช่วงของ CPU และหน่วยความจำที่ Pod สามารถใช้งานได้ ตัวอย่างเช่น การสำรอง CPU ขั้นต่ำ 100MB และหน่วยความจำ 256MB และอนุญาตให้ใช้ได้สูงสุด 500MB และ 2GB ตามลำดับสำหรับบริการ Java โดยปรับ JVM (Xms, Xmx, Xss) เพื่อให้ใช้ทรัพยากรของคอนเทนเนอร์ได้อย่างมีประสิทธิภาพ

การจัดการสถานะ: ไมโครเซอร์วิสแบบไร้สถานะและแบบมีสถานะ

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

อย่างไรก็ตาม มีบางสถานการณ์ที่ไม่มีทางเลือกอื่นนอกจากต้องใช้ไมโครเซอร์วิสที่มีสถานะ (Stateful Microservices) ซึ่งได้รับการสนับสนุนโดยวอลุ่มถาวร (Persistent Volumes ) กรณีนี้เกิดขึ้นกับฐานข้อมูลบางประเภท ระบบไฟล์แบบกระจาย หรือส่วนประกอบที่ต้องการเก็บรักษาข้อมูลในพื้นที่ โดยทั่วไปแล้ว พอดเหล่านี้จะถูกปรับใช้ด้วย StatefulSets เชื่อมโยงกับ PersistentVolumes โดยใช้ PersistentVolumeClaims และปรับขนาดในแนวตั้งมากกว่าแนวนอน

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

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

การกระจายอำนาจข้อมูลและอธิปไตยด้านบริการ

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

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

นี่ไม่ได้หมายความว่าไม่มีการบูรณาการข้อมูล แต่หมายความว่าความสอดคล้องระหว่างบริการต่างๆ จะได้รับการจัดการด้วยเหตุการณ์และการส่งข้อความแบบอะซิงโครนัสโดยยอมรับความสอดคล้องในที่สุดเมื่อเหมาะสม โดยทั่วไปมักใช้ Event Bus (RabbitMQ, Azure Service Bus, Kafka เป็นต้น) เพื่อเผยแพร่การเปลี่ยนแปลงสถานะระหว่างไมโครเซอร์วิส ซึ่งช่วยลดการพึ่งพาฐานข้อมูลเดียวอย่างมาก

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

การกำกับดูแลแบบกระจายอำนาจ ทีมงาน และองค์กร

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

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

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

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

CI/CD, ระบบอัตโนมัติ และโมเดล GitOps

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

กระบวนการรวมและส่งมอบอย่างต่อเนื่อง (Continuous Integration and Delivery หรือ CD) ทั่วไปจะจัดการกับการคอมไพล์โค้ด การรันการทดสอบ การวิเคราะห์คุณภาพด้วยเครื่องมือต่างๆ เช่น SonarQubeการสร้างอิมเมจคอนเทนเนอร์จาก Dockerfile ขององค์กร และการอัปเดตไฟล์กำหนดค่าการปรับใช้ จากนั้น ระบบอย่าง ArgoCD หรือระบบที่คล้ายกันจะนำการเปลี่ยนแปลงไปใช้กับคลัสเตอร์โดยใช้แนวทาง GitOps

โดยทั่วไปแล้ว repository ของ microservice แต่ละแห่งจะประกอบด้วยDockerfile ที่ได้มาตรฐาน ไฟล์การกำหนดค่า pipeline (เช่น ci.json)คุณสมบัติสำหรับการวิเคราะห์คุณภาพ และไดเร็กทอรีการปรับใช้ที่มีคำจำกัดความของ Kubernetes (Kustomize หรือ Helm) แยกตามสภาพแวดล้อม Webhook ของ repository จะเรียกใช้ pipeline เมื่อเกิดเหตุการณ์ต่างๆ เช่น การเพิ่มแท็กหรือคำขอผสาน

รูปแบบ GitOps กำหนดให้ที่เก็บ Git เป็นแหล่งข้อมูลหลักสำหรับโครงสร้างพื้นฐานและการปรับใช้ ไฟล์ Manifest สำหรับการปรับใช้ บริการ ConfigMaps PVC SealedSecrets และทรัพยากรอื่นๆ จะถูกบันทึกเวอร์ชันไว้ที่นั่น และมีเครื่องมือเฉพาะที่จัดการการซิงโครไนซ์สถานะของคลัสเตอร์กับสิ่งที่กำหนดไว้ใน Git สิ่งนี้ช่วยให้สามารถตรวจสอบย้อนกลับ ตรวจสอบ Pull Request และย้อนกลับได้ง่าย

การตั้งค่า ความลับ และความปลอดภัย

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

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

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

ในแง่ของความปลอดภัยในการสื่อสาร รูปแบบที่โดดเด่นคือZero Trust : ไม่มีอะไรที่รับประกันได้เพียงเพราะการรับส่งข้อมูลเป็น "ภายใน" การเรียกใช้บริการทั้งหมด ทั้งภายในและภายนอก ต้องได้รับการตรวจสอบและอนุญาต โดยควรใช้ mTLS, โทเค็น JWT หรือกลไกอื่นที่เทียบเท่ากัน ไมโครเซอร์วิสไม่ได้มอบหมายความปลอดภัยให้กับ API Manager หรือเครือข่ายโดยไม่ตรวจสอบ แต่ยังมีการตรวจสอบของตนเองด้วย

การสื่อสารระหว่างไมโครเซอร์วิส, API และระบบส่งข้อความ

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

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

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

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

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

ความสามารถในการสังเกตการณ์, OTEL Collector และการใช้งาน

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

ส่วนประกอบสำคัญของระบบนี้คือOpenTelemetry Collector (OTEL Collector)ซึ่งจะถูกติดตั้งในเนมสเปซหรือส่วนกลางเพื่อรวบรวมเมตริก บันทึก และร่องรอยจากส่วนประกอบทั้งหมด ไมโครเซอร์วิสเพียงแค่ต้องรู้ว่าควรส่งข้อมูลเทเลเมทรีไปยัง Collector จากนั้น Collector จะส่งต่อไปยังระบบตรวจสอบ (Prometheus, Grafana, Jaeger, Elastic เป็นต้น) โดยที่เซอร์วิสไม่จำเป็นต้องรู้รายละเอียดใดๆ

สำหรับเลเยอร์โครงสร้างพื้นฐาน จะมีการใช้ ตัวเก็บรวบรวมและส่งออกข้อมูลระดับโหนดเพื่อรวบรวมข้อมูลเมตริก CPU หน่วยความจำ ดิสก์ เครือข่าย และบันทึกจากพอด แล้วส่งไปยัง Prometheus และ Elasticsearch ตามลำดับ เครื่องมืออย่าง Grafana และ Kibana ใช้สำหรับแสดงภาพข้อมูล สร้างแดชบอร์ด และกำหนดการแจ้งเตือนด้วยเกณฑ์อัจฉริยะและคู่มือการดำเนินการที่เกี่ยวข้อง

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

กลยุทธ์การทดสอบ สัญญา และประสบการณ์การพัฒนาในระดับท้องถิ่น

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

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

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

การทดสอบแบบครบวงจร (End-to-end testing) อาศัยสภาพแวดล้อมชั่วคราวหรือ "เวอร์ชันทดลอง" ที่สร้างขึ้นจากสาขาฟีเจอร์ (feature branches) มากขึ้นเรื่อยๆ ซึ่งจะสร้างสภาพแวดล้อมที่แยกต่างหากพร้อมบริการที่เกี่ยวข้องกับฟังก์ชันการทำงานนั้นๆ วิธีนี้ช่วยลดความขัดแย้งระหว่างทีม ลดผลกระทบจาก "มันใช้งานได้บนเครื่องของฉัน" และตรวจจับปัญหาการบูรณาการก่อนที่จะไปถึงสภาพแวดล้อมที่มีค่าใช้จ่ายสูงกว่า เช่น สภาพแวดล้อมก่อนการผลิต (pre-production)

รูปแบบการปรับใช้ไมโครเซอร์วิสในสภาพแวดล้อมการผลิต

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

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

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

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

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

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