- บทความเกี่ยวกับต้นทุนและประโยชน์ของการเปลี่ยนจากแบ็กเอนด์แบบเดี่ยวไปเป็นสถาปัตยกรรมไมโครเซอร์วิส
- เมื่อจำนวนทีมที่ร่วมพัฒนาในโค้ดเบสเดียวเพิ่มขึ้น คอมโพเนนต์ต่าง ๆ จะเชื่อมโยงกันมากขึ้นเรื่อย ๆ ทำให้ประสิทธิภาพการทำงานลดลงและความซับซ้อนเพิ่มขึ้น
- วิธีแก้ปัญหาหนึ่งเพื่อลดผลกระทบนี้คือการแยกแบ็กเอนด์แบบเดี่ยวออกเป็นชุดของบริการที่ดีพลอยได้อย่างอิสระและสื่อสารกันผ่าน API หรือก็คือไมโครเซอร์วิส
- คำว่า 'ไมโคร' ชวนให้เข้าใจผิด เพราะบริการไม่ได้จำเป็นต้องเล็กระดับ 'ไมโคร' เสมอไป คำที่เหมาะสมกว่าอาจเป็นสถาปัตยกรรมเชิงบริการ
- การแยกแบ็กเอนด์ออกเป็นชุดของบริการที่มีขอบเขตชัดเจน ช่วยให้ทีมขนาดเล็กเพียงทีมเดียวก็เพียงพอสำหรับการพัฒนาและดูแลแต่ละบริการ ส่งผลให้ความเร็วในการพัฒนาแอปพลิเคชันเพิ่มขึ้น
- ไมโครเซอร์วิสแต่ละตัวสามารถสเกลได้อย่างอิสระ และเลือกใช้เทคโนโลยีสแตกที่ต่างกันตามความต้องการของตนเอง ทำให้ทดลองและประเมินเทคโนโลยีใหม่ ๆ ได้ง่าย
- อย่างไรก็ตาม สถาปัตยกรรมไมโครเซอร์วิสเพิ่มชิ้นส่วนที่ต้องดูแลในทั้งระบบ ทำให้ความซับซ้อนสูงขึ้นและต้องมีมาตรฐานบางอย่างอย่างสม่ำเสมอ
- หากไมโครเซอร์วิสแต่ละตัวใช้ภาษา ไลบรารี และดาต้าสโตร์คนละแบบ อาจกลายเป็นความยุ่งเหยิงที่ทำให้แอปพลิเคชันดูแลรักษาได้ยาก และทำให้นักพัฒนาย้ายข้ามทีมได้ลำบาก
- เพื่อรองรับบริการอิสระจำนวนมาก จำเป็นต้องสามารถสร้างเซิร์ฟเวอร์ ดาต้าสโตร์ และทรัพยากรอื่น ๆ ใหม่ได้อย่างง่ายดาย ซึ่งต้องอาศัยระบบอัตโนมัติในระดับสูง
- การเรียกใช้งานระยะไกลมีต้นทุนสูงและเปิดทางให้ระบบล้มเหลวได้ในรูปแบบใหม่ ๆ จึงต้องมีกลไกป้องกัน เช่น timeout, retry และ circuit breaker
- การทำ continuous integration ช่วยให้มั่นใจว่าการเปลี่ยนแปลงโค้ดจะผ่านกระบวนการ build และ test แบบอัตโนมัติก่อนถูกรวมเข้ากับเมนบรานช์
- การทดสอบแบบบูรณาการของไมโครเซอร์วิสทั้งหมดทำได้ยากกว่าการทดสอบระบบโมโนลิธมาก เพราะเมื่อบริการแต่ละตัวโต้ตอบกัน อาจเกิดพฤติกรรมที่ละเอียดอ่อนและไม่คาดคิดได้
- โดยทั่วไปทีมที่พัฒนาบริการก็มักต้องรับผิดชอบต่อการดูแลการเรียกใช้บริการนั้นด้วย ซึ่งก่อให้เกิดแรงเสียดทานระหว่างงานพัฒนากับต้นทุนด้านปฏิบัติการ
- การดีบักความล้มเหลวของระบบในแบบไมโครเซอร์วิสทำได้ยากขึ้น การทำ logging และ monitoring ที่ดีในทุกระดับจึงมีความสำคัญ
- เมื่อแยกแอปพลิเคชันออกเป็นหลายบริการ โมเดลข้อมูลจะไม่ได้อยู่ในดาต้าสโตร์เดียวอีกต่อไป ซึ่งโดยมากต้องยอมรับแนวคิด eventual consistency
- โดยทั่วไป ทางเลือกที่ดีที่สุดคือเริ่มต้นด้วยโมโนลิธ และค่อยแยกออกเป็นบริการเฉพาะเมื่อการกำหนดขอบเขตระหว่างบริการทำได้ชัดเจนยากจริง ๆ
- การเริ่มต้นด้วยแนวทาง microservices-first ควรทำก็ต่อเมื่อมีประสบการณ์กับมันอยู่แล้วและมีแพลตฟอร์มรองรับ หรือได้คำนึงถึงเวลาที่ต้องใช้ในการสร้างแพลตฟอร์มนั้นไว้แล้ว
ยังไม่มีความคิดเห็น