API Gateway: ประตูหน้าบ้านเดียว สำหรับทุกบริการหลังบ้าน

18 พฤษภาคม 2569อ่าน 6 นาที
API Gateway: ประตูหน้าบ้านเดียว สำหรับทุกบริการหลังบ้าน

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

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

รวมงานซ้ำไว้ที่ประตู

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

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

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

API GatewayArchitectureMicroservicesAPI

บริการที่เกี่ยวข้อง

รับพัฒนาเว็บแอปพลิเคชัน

สร้างเว็บแอปที่รองรับการเติบโตและเชื่อมกับระบบอื่นได้

WhaleScope

ดูโครงสร้างตลาดของทุกหมวดธุรกิจไทย บน WhaleScope

รายชื่อบริษัท ผู้เล่นรายใหญ่ และอัตราคงอยู่ของแต่ละหมวด — จากข้อมูลจดทะเบียน 2 ล้านนิติบุคคล

อ่านต่อ

Microservices หรือ Monolith: แยกระบบเป็นชิ้นเล็กดีจริงไหม

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

GraphQL หรือ REST: เลือก API แบบไหนให้เหมาะกับงาน

REST เป็นมาตรฐานที่เรียบง่ายและใช้กันทั่วไป ส่วน GraphQL ให้ผู้เรียกขอข้อมูลได้ตรงตามต้องการ ลดการดึงเกินหรือขาด เข้าใจข้อดีข้อเสียเพื่อเลือกให้เหมาะ ไม่ใช่เลือกตามกระแส

Distributed Tracing: ตามรอยคำขอเดียว ข้ามสิบระบบ เพื่อหาว่าช้าที่ใคร

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

Idempotency และ Retry: ออกแบบระบบที่ทำงานซ้ำได้โดยไม่พัง

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