ภาพรวม

สิ่งที่จะสร้าง

ShopMicro คือ backend สำหรับ e-commerce ที่ขับเคลื่อนด้วย event สร้างเป็นชุดของ microservices ด้วยภาษา Go ลองนึกภาพเครื่องยนต์เบื้องหลังการ checkout ของร้านค้าออนไลน์ แยกออกเป็นเซอร์วิสเล็ก ๆ แต่ละตัวรับผิดชอบงานเดียวและคุยกันผ่านเครือข่าย

ลองนึกภาพ flow นี้ ลูกค้า browse แคตตาล็อกและเลือกสินค้า จากนั้น สั่งซื้อ (place an order) คลิกครั้งเดียวจุดชนวนปฏิกิริยาลูกโซ่เบื้องหลัง — บันทึก order เป็น PENDING แล้วพยายามชำระเงิน ถ้าชำระเงินสำเร็จ order กลายเป็น CONFIRMED ถ้าล้มเหลวก็เป็น CANCELLED และไม่ว่าทางไหน ลูกค้าจะได้รับ notification ที่บอกว่าเกิดอะไรขึ้น

ไม่มีโปรแกรมยักษ์ตัวเดียวที่ทำทั้งหมดนี้ แต่เป็นเซอร์วิสอิสระห้าตัวที่ส่งงานต่อกันผ่านการเรียกแบบ synchronous และกระแสของ event หัวใจของ ShopMicro คือเส้นทาง browse → order → pay → notify ที่ประสานงานข้ามเซอร์วิสที่ไม่เคยแชร์ฐานข้อมูลกัน และนั่นคือเหตุผลที่คุ้มค่าจะสร้างตั้งแต่ต้นจนจบ

พอจบแล้วคุณจะได้ระบบจริง: เซอร์วิส Go ห้าตัว, ฐานข้อมูล PostgreSQL สองตัว, event log ของ Kafka, work queue ของ RabbitMQ, gateway ที่แปลง REST เป็น gRPC และ Helm chart ที่ deploy ทั้งหมดขึ้น Kubernetes

ทำไม

ทิวทอเรียลส่วนใหญ่สอนเครื่องมือทีละตัวแบบโดด ๆ — “นี่ gRPC,” “นี่ Kafka,” “นี่ saga” — แล้วปล่อยให้คุณเดาเองว่าประกอบกันยังไง ShopMicro ทำตรงกันข้าม ทุกชิ้นอยู่ในระบบเพราะโปรดักต์ต้องการ:

• order และ product ต้อง จัดเก็บ อยู่กับเซอร์วิสที่เป็นเจ้าของข้อมูลนั้นเอง แต่ละเซอร์วิสจึงมี PostgreSQL ของตัวเอง
• เซอร์วิสต้อง เรียกกันและกัน อย่างรวดเร็วด้วย contract ที่มี type ชัดเจน เราจึงใช้ gRPC
• โลกภายนอกพูดภาษา REST เราจึงวาง grpc-gateway ไว้ด้านหน้าเพื่อแปลง
• order flow กินหลายเซอร์วิสและใช้ database transaction ก้อนใหญ่ก้อนเดียวไม่ได้ เราจึงประสานงานด้วย event log (Kafka) และ saga
• side effect อย่างการส่งอีเมลต้อง เชื่อถือได้และ retry ได้ เราจึงยกงานนี้ให้ RabbitMQ work queue ที่มี ack, retry และ dead-letter queue

การสร้างโปรดักต์ที่ประกอบกันเป็นหนึ่งเดียวบังคับให้คุณตัดสินใจแบบเดียวกับทีมจริง และรู้สึกได้ว่า ทำไม microservices, gRPC, Kafka, RabbitMQ และ Kubernetes แต่ละตัวถึงมีที่ทางของตัวเอง

ข้อดีข้อเสีย

ข้อดี

• คุณจบด้วยระบบ distributed ระดับพอร์ตโฟลิโอ ไม่ใช่โฟลเดอร์ของ snippet ที่ไม่เชื่อมกัน
• ทุกแนวคิด — gRPC, event streaming, saga, outbox — ยึดโยงกับฟีเจอร์ที่จับต้องได้และคุณเห็นทำงานจริง
• สแตก (Go, gRPC, Kafka, RabbitMQ, Kubernetes) สะท้อนแพลตฟอร์ม microservice บน production จริง

ข้อเสีย

• กว้างและยากกว่าทิวทอเรียลเซอร์วิสเดียว: คุณรันเซอร์วิสห้าตัว, ฐานข้อมูลสองตัว และ broker สองตัวพร้อมกัน
• ระบบ distributed มีรูปแบบความล้มเหลวที่ monolith ไม่เคยเจอ — การเรียกผ่านเครือข่ายล้มเหลว, message มาถึงซ้ำสองครั้ง, เซอร์วิสรีสตาร์ทกลางคัน — และเราจงใจเผชิญหน้ากับทุกกรณี
• โมดูลช่วงแรกสร้างรากฐาน (protobuf, gRPC scaffolding) ก่อนที่ checkout flow จะมีชีวิตให้เห็น

ลงมือสร้าง

นี่คือชุดฟีเจอร์ทั้งหมดที่คุณจะส่งมอบ ทีละเซอร์วิส:

• API Gateway — จุดเข้า REST จุดเดียวที่แปลง HTTP/JSON เป็น gRPC call (ผ่าน grpc-gateway) และ route ไปยังเซอร์วิสที่ถูกต้อง
• Catalog Service — product และรายละเอียดสินค้า เก็บใน PostgreSQL เสิร์ฟผ่าน gRPC
• Order Service — สร้าง order (PENDING), เป็นเจ้าของ order saga และ publish event อย่างเชื่อถือได้ผ่าน outbox pattern; มี PostgreSQL ของตัวเอง
• Payment Service — ขับเคลื่อนด้วย event; consume order.created, พยายามชำระเงิน และ publish payment.succeeded หรือ payment.failed
• Notification Service — ขับเคลื่อนด้วย event; consume ผลลัพธ์การชำระเงินและ enqueue send-job บน RabbitMQ work queue ให้ worker ส่งต่อ
• Idempotent consumers ทุกที่ เพื่อไม่ให้ message ที่ส่งมาซ้ำสองครั้งไปตัดบัตรซ้ำหรือส่งอีเมลสองฉบับ
• Helm chart หนึ่งตัว ที่ deploy เซอร์วิสทั้งห้าพร้อม infrastructure ขึ้น Kubernetes

และนี่คือ course map แต่ละโมดูลของการสร้างต่อยอดจากคอร์สใน Learn Hub มายังชิ้นส่วนหนึ่งของโปรเจกต์

โมดูล	สิ่งที่คุณสร้าง	คอร์สใน Learn Hub ที่อ้างอิง
1 · Setup & Tooling	Go monorepo, shared tooling และ Docker Compose ไฟล์แรก	Go / Docker
2 · Protobuf & gRPC	สัญญา .proto และ Go stub ที่ generate ด้วย buf	gRPC
3 · Catalog Service	เซอร์วิส Catalog แบบ gRPC ที่มี PostgreSQL รองรับ	Go / gRPC
4 · Order Service	เซอร์วิส Order แบบ gRPC, schema ของ order และการสร้าง order	Go / gRPC
5 · API Gateway	grpc-gateway REST façade ด้านหน้าเซอร์วิสต่าง ๆ	gRPC / Microservices
6 · Kafka (Event Stream)	topic orders และ payments เป็น event log ที่ replay ได้	Kafka
7 · RabbitMQ (Work Queues)	work queue พร้อม ack, retry และ dead-letter queue	RabbitMQ
8 · Payment Service	เซอร์วิส Payment ที่ขับเคลื่อนด้วย event ทั้ง consume และ publish	Kafka / Go
9 · Order Saga	order saga พร้อม outbox pattern สำหรับ publish อย่างเชื่อถือได้	Microservices
10 · Notification Service	เซอร์วิส Notification: Kafka เข้า, RabbitMQ send-job ออก	Kafka / RabbitMQ
11 · Resilience	retry, timeout, idempotency และการล้มเหลวอย่างนุ่มนวล	Go
12 · Testing	unit test และ integration test ข้ามเซอร์วิส	Go
13 · Docker & Compose	Dockerfile และ Compose stack เต็มรูปแบบสำหรับ dev บนเครื่อง	Docker
14 · Kubernetes (Helm)	Helm chart ที่ deploy ทั้งระบบขึ้น Kubernetes	Kubernetes

ตรวจสอบผล

คุณพร้อมไปต่อเมื่อคุณตอบคำถามเหล่านี้ด้วยคำพูดของคุณเองได้:

• ShopMicro ทำอะไร และอะไรทำให้ระบบนี้เป็น “event-driven”?
• คุณเรียกชื่อเซอร์วิสทั้งห้าตัวและงานเดียวที่แต่ละตัวรับผิดชอบได้ไหม?
• คุณไล่เส้นทาง browse → order → pay → notify และชี้ได้ไหมว่าโมดูลไหนสร้างขั้นตอนไหน?

สรุป

ShopMicro คือระบบ e-commerce แบบ microservices ที่ขับเคลื่อนด้วย event ซึ่งคุณจะสร้างตั้งแต่ต้นจนจบด้วย Go — เซอร์วิสห้าตัว (API Gateway, Catalog, Order, Payment, Notification), gRPC สำหรับการเรียกแบบ synchronous, Kafka และ RabbitMQ สำหรับแบบ asynchronous และ Helm chart สำหรับ Kubernetes ตอนนี้คุณรู้รายการฟีเจอร์ทั้งหมดแล้ว และรู้ว่าโมดูลการสร้างทั้งสิบสี่ตัวจับคู่กับคอร์สใน Learn Hub ที่ต่อยอดมายังไง ต่อไปเราจะไปดู architecture ของระบบ