Production Concerns

จาก “ทำงานได้” ไปสู่ “ขึ้น production ได้”

คุณนิยาม service, generate stub, implement handler แล้วเรียกใช้ได้ — บนเครื่องคุณทุกอย่างทำงานได้ แต่ production ถามคำถามที่ยากกว่านั้น: จะ log และ authenticate ทุก call โดยไม่ต้องแก้ทุก handler ยังไง? จะเข้ารหัส traffic และพิสูจน์ว่าใครเป็นคนเรียกยังไง? จะกระจาย load ไปยัง backend หลายตัวยังไง ในเมื่อ gRPC ตั้งใจถือ connection เดียวที่อยู่ยาว? โมดูลนี้ตอบคำถามพวกนี้

โมดูลนี้ครอบคลุมอะไรบ้าง

บทเรียน	สิ่งที่คุณจะได้เรียน
Interceptors	middleware model — ห่อทุก call เพื่อทำ logging, auth, metrics, retry
Security & Auth	TLS และ mTLS สำหรับ channel, token auth ต่อ call และทำไมสองอย่างนี้ต้องแยกกัน
Metadata	header และ trailer แบบ key/value — auth token, trace id, request id
Load balancing & health	ทำไม L4 balancer ทำ gRPC พัง, client-side LB และ health checking

ธีมของโมดูล: cross-cutting concern

ทุกอย่างในนี้คือ cross-cutting concern — สิ่งที่ทุก RPC ต้องการ แต่ไม่ควรเป็นของ handler ตัวใดตัวหนึ่ง

flowchart LR
  call["incoming call"] --> tls["TLS / auth"]
  tls --> intc["interceptors
(log, metrics)"]
  intc --> md["metadata
(trace id, token)"]
  md --> handler["handler ของคุณ
(business logic)"]
  handler --> lb["load balancing
กระจาย call ไปหลาย backend"]

cross-cutting concern ห่อ business logic ไว้ ไม่ได้อยู่ข้างใน

gRPC มี hook ระดับ first-class ให้แต่ละอย่าง เพื่อให้ handler ของคุณโฟกัสแค่ business logic เรียนรู้พวกนี้แล้ว service ของคุณจะ observable, secure และ scale ได้ โดยไม่ต้องเขียน code ที่ทำงานจริงใหม่