ในการออกแบบ service ของระบบงานนั้น
มีรูปแบบหนึ่งที่เจอบ่อยมาก ๆ คือเรามักจะแยกเป็น service ย่อย ๆ
โดยแต่ละ service ทำงานอย่างใดอย่างหนึ่งไปเลย (Single Responsibility)
เป็นสิ่งที่ดีมาก ๆ เพราะว่าแต่ละ service มีขอบเขตการทำงานชัดเจน
แต่เมื่อนำ service ต่าง ๆ มาทำงานร่วมกัน
จะเกิดรูปแบบต่าง ๆ มากมาย
หนึ่งในรูปแบบคือ Chain of Responsibility หรือ Chain of Services
แสดงดังรูป
คำอธิบาย
การทำงานจะเริ่มจาก Main API หรือ product หรือระบบงานหลักนั่นเอง
จากนั้นจะเรียกใช้งาน service 1
จากนั้น service 1 ก็ไปเรียกใช้งาน service อื่น ๆ ต่อไปเรื่อย ๆ
ในรูปแบบของ chain of service นั่นเอง
ผลที่ตามมาคือ
ความซับซ้อนซ่อนเงื่อนของการทำงานที่สูงขึ้น
จำนวน service ที่เรียกใช้งานกันเยอะมาก ๆ
ผลกระทบต่อการทำงานและเปลี่ยนแปลง
ที่ต้องพูดคุยและวางแผนมากขึ้น
ผลกระทบของ response time ที่มีแนวโน้มว่าสูงขึ้น
จุดของการพังมากขึ้น
พังตรงไหน หาเจอง่ายหรือไม่
หรือมีระบบแจ้งและระบุจุดเกิดปัญหาให้เลย
ยิ่งติดต่อสื่อสารกับแบบ synchronous ยิ่งอาจจะทำให้เกิดปัญหาได้อีกมาก
แต่ก็พอทุเลาได้ด้วย Circuit Breaker pattern
ดังนั้นต้องเลือกรูปแบบการติดต่อสื่อสารให้ดี
รวมทั้งลดจำนวนของ service หรือความลึกของ service ลงไปอีกด้วย
ถามว่าลึกเท่าไรดี บอกได้เลยแค่เกิน 2-3 ชั้น ก็บรรลัยแล้วนะ !!
ใครเจอปัญหานี้อยู่บ้าง ?
คำถามต่อมาคือ ถ้าเจอปัญหาแบบนี้ แล้วจะแยกไปทำไม ?
