Go และ gRPC ในปี 2026: Microservices ประสิทธิภาพสูงและคำถามสัมภาษณ์

gRPC กลายเป็นเลเยอร์การสื่อสารเริ่มต้นสำหรับ microservices ของ Go ที่ต้องการเวลาแฝงต่ำและสัญญา API ที่เคร่งครัด ด้วย grpc-go v1.81, Go 1.26 และความสมบูรณ์ของระบบนิเวศ go-grpc-middleware การสร้างบริการ gRPC ระดับโปรดักชันใน Go ทำได้ง่ายกว่าที่เคยเป็นมา และยังคงเป็นหนึ่งในหัวข้อที่ถูกถามมากที่สุดในการสัมภาษณ์งานสาย backend

ทำไม gRPC จึงครองการสื่อสาร backend ของ Go

สามคุณสมบัติทำให้ gRPC เป็นตัวเลือกที่เป็นธรรมชาติสำหรับ microservices ของ Go ประการแรก Protocol Buffers สร้างโค้ด Go ที่มีชนิดข้อมูลเข้มงวดตั้งแต่ตอนคอมไพล์ จับความไม่ตรงกันของสัญญาก่อนการดีพลอย ประการที่สอง การ multiplexing ของ HTTP/2 ขจัด head-of-line blocking และรองรับ streaming แบบ full-duplex บนการเชื่อมต่อ TCP เดียว ประการที่สาม โมเดล interceptor สอดคล้องกับปรัชญา composition-over-inheritance ของ Go ทำให้เรื่องที่ตัดขวางอย่างการยืนยันตัวตนและ tracing ประกอบเข้าด้วยกันได้

ระบบนิเวศ gRPC ใน Go ได้รวมตัวกันรอบไลบรารีที่ผ่านการพิสูจน์มาแล้วไม่กี่ตัว grpc-go จัดการแกนหลักของ transport และ codegen แพ็กเกจ go-grpc-middleware v2 มอบ interceptor ระดับโปรดักชันสำหรับ logging, metrics, การยืนยันตัวตน และ recovery stats handler ของ gRPC จาก OpenTelemetry ครอบคลุม distributed tracing โดยไม่ต้องเขียนโค้ด interceptor เอง

การนิยามบริการด้วย Protocol Buffers

บริการ gRPC ทุกตัวเริ่มต้นจากไฟล์ .proto สคีมานิยามสัญญาของบริการ ชนิดของ message และเมธอด RPC ตัวอย่างต่อไปนี้จำลองบริการผู้ใช้ด้วยการค้นหาแบบ unary และเมธอด server-streaming สำหรับฟีดกิจกรรม

syntax = "proto3";

package user.v1;

option go_package = "gen/user/v1;userv1";

service UserService {
  // Unary RPC: single request, single response
  rpc GetUser(GetUserRequest) returns (GetUserResponse);
  // Server streaming: single request, stream of responses
  rpc StreamActivity(StreamActivityRequest) returns (stream ActivityEvent);
}

message GetUserRequest {
  string user_id = 1;
}

message GetUserResponse {
  string user_id = 1;
  string email = 2;
  string display_name = 3;
  int64 created_at_unix = 4;
}

message StreamActivityRequest {
  string user_id = 1;
  int32 limit = 2;
}

message ActivityEvent {
  string event_id = 1;
  string action = 2;
  string resource = 3;
  int64 timestamp_unix = 4;
}

การรัน protoc --go_out=. --go-grpc_out=. user_service.proto จะสร้างไฟล์สองไฟล์ ไฟล์หนึ่งมีชนิดของ message และอีกไฟล์มีอินเทอร์เฟซ client/server ของ gRPC อินเทอร์เฟซ server ที่ถูกสร้างขึ้นคือสิ่งที่การ implement ฝั่ง Go ต้องทำให้สำเร็จ

การ implement server gRPC ใน Go

การ implement server ฝัง struct UnimplementedUserServiceServer ที่ถูกสร้างขึ้น ซึ่งให้ความเข้ากันได้ไปข้างหน้า การเพิ่ม RPC ใหม่ลงในไฟล์ proto จะไม่ทำให้โค้ด server เดิมพังจนกว่าจะ implement เมธอดนั้นอย่างชัดเจน

package server

import (
	"context"
	"fmt"
	"time"

	userv1 "myapp/gen/user/v1"
	"google.golang.org/grpc/codes"
	"google.golang.org/grpc/status"
)

type UserServer struct {
	userv1.UnimplementedUserServiceServer
	store UserStore // interface for DB access
}

func NewUserServer(store UserStore) *UserServer {
	return &UserServer{store: store}
}

// GetUser handles the unary RPC
func (s *UserServer) GetUser(ctx context.Context, req *userv1.GetUserRequest) (*userv1.GetUserResponse, error) {
	if req.GetUserId() == "" {
		return nil, status.Error(codes.InvalidArgument, "user_id is required")
	}

	user, err := s.store.FindByID(ctx, req.GetUserId())
	if err != nil {
		return nil, status.Errorf(codes.Internal, "lookup failed: %v", err)
	}
	if user == nil {
		return nil, status.Error(codes.NotFound, "user not found")
	}

	return &userv1.GetUserResponse{
		UserId:       user.ID,
		Email:        user.Email,
		DisplayName:  user.DisplayName,
		CreatedAtUnix: user.CreatedAt.Unix(),
	}, nil
}

// StreamActivity sends activity events as a server stream
func (s *UserServer) StreamActivity(req *userv1.StreamActivityRequest, stream userv1.UserService_StreamActivityServer) error {
	events, err := s.store.GetActivity(stream.Context(), req.GetUserId(), int(req.GetLimit()))
	if err != nil {
		return status.Errorf(codes.Internal, "activity fetch failed: %v", err)
	}

	for _, evt := range events {
		if err := stream.Send(&userv1.ActivityEvent{
			EventId:       evt.ID,
			Action:        evt.Action,
			Resource:      evt.Resource,
			TimestampUnix: evt.Timestamp.Unix(),
		}); err != nil {
			return fmt.Errorf("stream send: %w", err)
		}
	}

	return nil
}

มีสองรูปแบบที่ควรสังเกต status.Error และ status.Errorf สร้าง error แบบ gRPC-native พร้อมรหัสสถานะที่ถูกต้อง ซึ่ง client สามารถตรวจสอบได้ในเชิงโปรแกรม การฝัง UnimplementedUserServiceServer รับประกันความปลอดภัยตอนคอมไพล์เมื่อ proto มีการเปลี่ยนแปลง

การ bootstrap server โปรดักชันด้วย interceptor

server gRPC เปล่า ๆ จัดการคำขอได้แต่ขาดความสามารถในการสังเกตการณ์ การยืนยันตัวตน และการกู้คืนจาก panic บริการระดับโปรดักชันต้องการห่วงโซ่ interceptor ไลบรารี go-grpc-middleware v2 มอบ interceptor ที่ประกอบเข้าด้วยกันได้ และเชื่อมต่อกันด้วย grpc.ChainUnaryInterceptor

package main

import (
	"log"
	"net"
	"os"
	"os/signal"
	"syscall"

	"google.golang.org/grpc"
	"google.golang.org/grpc/reflection"
	"go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc"

	"github.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors/logging"
	"github.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors/recovery"
	"github.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors/ratelimit"

	userv1 "myapp/gen/user/v1"
	"myapp/server"
)

func main() {
	// Interceptor order matters: recovery first, then metrics, then auth
	srv := grpc.NewServer(
		// OpenTelemetry tracing via stats handler (not interceptor)
		grpc.StatsHandler(otelgrpc.NewServerHandler()),

		grpc.ChainUnaryInterceptor(
			recovery.UnaryServerInterceptor(),          // catch panics
			ratelimit.UnaryServerInterceptor(limiter),   // rate limiting
			logging.UnaryServerInterceptor(logger),      // structured logging
			authInterceptor,                              // token validation
		),
		grpc.ChainStreamInterceptor(
			recovery.StreamServerInterceptor(),
			ratelimit.StreamServerInterceptor(limiter),
			logging.StreamServerInterceptor(logger),
		),
	)

	// Register service implementation
	userv1.RegisterUserServiceServer(srv, server.NewUserServer(store))

	// Enable reflection for grpcurl and debugging
	reflection.Register(srv)

	lis, err := net.Listen("tcp", ":50051")
	if err != nil {
		log.Fatalf("listen: %v", err)
	}

	// Graceful shutdown on SIGTERM
	go func() {
		sig := make(chan os.Signal, 1)
		signal.Notify(sig, syscall.SIGTERM, syscall.SIGINT)
		<-sig
		log.Println("shutting down gRPC server")
		srv.GracefulStop()
	}()

	log.Printf("gRPC server listening on :50051")
	if err := srv.Serve(lis); err != nil {
		log.Fatalf("serve: %v", err)
	}
}

ลำดับของ interceptor กำหนดความสำคัญในการประมวลผล recovery ทำงานก่อนเพื่อจับ panic จาก interceptor ใด ๆ ที่อยู่ถัดลงไป rate limiting ทำงานก่อนการยืนยันตัวตนเพื่อปกป้องชั้นยืนยันตัวตนเองจากการถูกใช้งานในทางที่ผิด tracing ของ OpenTelemetry ใช้ StatsHandler แทน interceptor ซึ่งเป็นแนวทางที่แนะนำตั้งแต่ grpc-go v1.81 เพราะ stats handler เข้าถึงเหตุการณ์ transport ระดับล่างได้

รูปแบบการจัดการ error ของ gRPC ใน Go

การจัดการ error ที่เหมาะสมแยกบริการ gRPC ระดับโปรดักชันออกจากต้นแบบ gRPC นิยามชุดรหัสสถานะมาตรฐานที่ client ทุกตัวเข้าใจ แพ็กเกจ status ของ Go แมปรหัสเหล่านี้เป็น error

รูปแบบสำคัญ ได้แก่

• คืนค่า codes.InvalidArgument สำหรับคำขอที่มีรูปแบบผิด (บั๊กของ client)
• คืนค่า codes.NotFound เมื่อทรัพยากรไม่มีอยู่
• คืนค่า codes.Internal สำหรับความล้มเหลวของ server ที่ไม่คาดคิด
• คืนค่า codes.Unauthenticated เมื่อข้อมูลรับรองตัวตนหายไปหรือไม่ถูกต้อง
• คืนค่า codes.PermissionDenied เมื่อข้อมูลรับรองตัวตนถูกต้องแต่ไม่เพียงพอ

package rpcerr

import (
	"google.golang.org/grpc/codes"
	"google.golang.org/grpc/status"
)

// NotFound wraps a resource-not-found error with a consistent message
func NotFound(resource, id string) error {
	return status.Errorf(codes.NotFound, "%s %q not found", resource, id)
}

// InvalidArg wraps a validation error
func InvalidArg(field, reason string) error {
	return status.Errorf(codes.InvalidArgument, "%s: %s", field, reason)
}

// Internal wraps an unexpected error, hiding internals from the client
func Internal(err error) error {
	// Log the real error server-side; return generic message to client
	return status.Error(codes.Internal, "internal server error")
}

การห่อ error ในตัวสร้างที่เฉพาะเจาะจงต่อโดเมนช่วยให้รหัสสถานะคงเส้นคงวาตลอดทุก RPC client สามารถใช้ switch บน status.Code(err) เพื่อจัดการแต่ละกรณีได้โดยไม่ต้องแยกวิเคราะห์สตริงของ error

การทดสอบบริการ gRPC ด้วย bufconn

การทดสอบแบบ integration ของบริการ gRPC โดยปกติต้องเริ่ม server TCP จริง แพ็กเกจ bufconn มอบ listener แบบ in-memory ที่ขจัดการจัดสรรพอร์ตและ overhead ของเครือข่ายไปอย่างสิ้นเชิง

package server_test

import (
	"context"
	"net"
	"testing"

	"google.golang.org/grpc"
	"google.golang.org/grpc/credentials/insecure"
	"google.golang.org/grpc/test/bufconn"

	userv1 "myapp/gen/user/v1"
	"myapp/server"
)

const bufSize = 1024 * 1024

func setupServer(t *testing.T) userv1.UserServiceClient {
	t.Helper()

	lis := bufconn.Listen(bufSize) // in-memory listener
	srv := grpc.NewServer()
	userv1.RegisterUserServiceServer(srv, server.NewUserServer(mockStore{}))

	go func() {
		if err := srv.Serve(lis); err != nil {
			t.Errorf("server exited: %v", err)
		}
	}()
	t.Cleanup(srv.GracefulStop)

	// Dial the in-memory listener
	conn, err := grpc.NewClient(
		"passthrough:///bufconn",
		grpc.WithContextDialer(func(ctx context.Context, _ string) (net.Conn, error) {
			return lis.DialContext(ctx)
		}),
		grpc.WithTransportCredentials(insecure.NewCredentials()),
	)
	if err != nil {
		t.Fatalf("dial bufconn: %v", err)
	}
	t.Cleanup(func() { conn.Close() })

	return userv1.NewUserServiceClient(conn)
}

func TestGetUser_NotFound(t *testing.T) {
	client := setupServer(t)

	_, err := client.GetUser(context.Background(), &userv1.GetUserRequest{
		UserId: "nonexistent",
	})

	// Verify gRPC status code
	st, ok := status.FromError(err)
	if !ok || st.Code() != codes.NotFound {
		t.Errorf("expected NotFound, got %v", err)
	}
}

bufconn สร้างการเชื่อมต่อ gRPC จริงพร้อมการ serialization เต็มรูปแบบและการรัน interceptor เพียงแต่ไม่ผ่าน TCP การทดสอบรันเร็วขึ้นและสามารถรันแบบขนานได้โดยไม่ชนกันที่พอร์ต นี่คือรูปแบบมาตรฐานที่ใช้ในตัวรีโพ grpc-go เอง

การรักษาความปลอดภัย gRPC ด้วย mTLS และการยืนยันตัวตนด้วยโทเคน

บริการ gRPC ระดับโปรดักชันต้องการความปลอดภัยของ transport มีสองแนวทางที่โดดเด่น ได้แก่ mTLS สำหรับการยืนยันตัวตนระหว่างบริการที่ทั้งสองฝั่งแสดงใบรับรอง และการยืนยันตัวตนด้วยโทเคน (JWT หรือ API key) สำหรับตัวตนของ client ภายในช่องทางที่ปลอดภัยอยู่แล้ว

การตั้งค่า mTLS โหลดใบรับรองตอน server เริ่มทำงาน

package main

import (
	"crypto/tls"
	"crypto/x509"
	"os"

	"google.golang.org/grpc/credentials"
)

func loadTLSCredentials(certFile, keyFile, caFile string) (credentials.TransportCredentials, error) {
	cert, err := tls.LoadX509KeyPair(certFile, keyFile)
	if err != nil {
		return nil, err
	}

	caPool := x509.NewCertPool()
	caPEM, err := os.ReadFile(caFile)
	if err != nil {
		return nil, err
	}
	caPool.AppendCertsFromPEM(caPEM)

	tlsCfg := &tls.Config{
		Certificates: []tls.Certificate{cert},
		ClientAuth:   tls.RequireAndVerifyClientCert, // enforce mTLS
		ClientCAs:    caPool,
		MinVersion:   tls.VersionTLS13, // TLS 1.3 minimum in 2026
	}

	return credentials.NewTLS(tlsCfg), nil
}

TLS 1.3 เป็นเส้นฐานสำหรับบริการ gRPC ในปี 2026 ให้ handshake ที่เร็วขึ้น (1-RTT) และชุด cipher ที่แข็งแกร่งกว่า TLS 1.2 สำหรับการยืนยันตัวตนด้วยโทเคนที่วางซ้อนบน TLS interceptor แบบ unary จะดึงโทเคนออกจาก metadata ของ gRPC และตรวจสอบความถูกต้องก่อนที่ handler จะทำงาน

คำถามสัมภาษณ์: gRPC และ microservices ของ Go

คำถามต่อไปนี้ปรากฏบ่อยในการสัมภาษณ์งาน backend engineering ที่เน้น Go และระบบกระจาย แต่ละคำตอบมุ่งไปที่ระดับความลึกที่คาดหวังในระดับ senior

RPC ทั้งสี่ชนิดใน gRPC มีอะไรบ้าง และแต่ละชนิดเหมาะกับเมื่อใด

Unary (หนึ่งคำขอ หนึ่งคำตอบ) ครอบคลุมการทำงาน CRUD ส่วนใหญ่ Server streaming เหมาะกับสถานการณ์ที่ server ผลักผลลัพธ์หลายรายการ เช่น ฟีดกิจกรรม ผลการค้นหา การอัปเดตแบบเรียลไทม์ Client streaming ใช้กับสถานการณ์อัปโหลดหรือการเขียนแบบกลุ่ม ที่ client ส่งหลาย message ก่อน server จะตอบกลับ Bidirectional streaming ตอบโจทย์แชต การแก้ไขร่วมกัน หรือโปรโตคอลใด ๆ ที่ทั้งสองฝั่งส่งอย่างเป็นอิสระ

gRPC จัดการความเข้ากันได้ย้อนหลังอย่างไรเมื่อ field ของ proto ถูกลบ

Proto3 ไม่เคยใช้หมายเลข field ซ้ำ การลบ field หมายความว่า server จะเพิกเฉยต่อค่านั้นหาก client เก่ายังส่งมาอยู่ และ client เก่าที่อ่านคำตอบจะเห็นเพียงค่า zero สำหรับ field ที่ถูกลบ คีย์เวิร์ด reserved ป้องกันการนำหมายเลขหรือชื่อ field กลับมาใช้ซ้ำโดยไม่ตั้งใจ สิ่งนี้แตกต่างโดยพื้นฐานจาก API แบบ JSON ที่การลบ field อาจทำให้ deserialization ล้มเหลว

อธิบายบทบาทของ interceptor ในบริการ gRPC ระดับโปรดักชัน

interceptor คือเลเยอร์ middleware ของ gRPC พวกมันทำงานก่อนและหลัง handler ตามลำดับที่ลงทะเบียน ห่วงโซ่โปรดักชันทั่วไป ได้แก่ recovery (จับ panic) > rate limiting > logging > การยืนยันตัวตน > validation ไลบรารี go-grpc-middleware v2 มอบ interceptor ที่ประกอบกันได้ตามรูปแบบนี้ interceptor ไม่สามารถแก้ไขเลเยอร์ transport (TLS, พอร์ต) ได้ มันทำงานในระดับ RPC เท่านั้น

ความแตกต่างระหว่าง grpc.StatsHandler กับ interceptor คืออะไร

interceptor ห่อ handler ของ RPC และทำงานในระดับแอปพลิเคชัน stats handler รับเหตุการณ์ระดับ transport เช่น การเริ่มเชื่อมต่อ การส่ง/รับ message การเสร็จสิ้นของ RPC OpenTelemetry ใช้ stats handler เพราะมันจับ metric ที่ interceptor มองไม่เห็น เช่น จำนวนไบต์และเหตุการณ์วงจรชีวิตของการเชื่อมต่อ ตั้งแต่ grpc-go v1.66+ คำแนะนำอย่างเป็นทางการคือใช้ stats handler สำหรับการสังเกตการณ์ และ interceptor สำหรับตรรกะทางธุรกิจ

คุณจะ implement graceful shutdown สำหรับ server gRPC อย่างไร

GracefulStop() หยุดรับการเชื่อมต่อใหม่และรอให้ RPC ที่กำลังทำงานเสร็จสิ้น รูปแบบคือ ฟัง SIGTERM ใน goroutine เรียก GracefulStop() จากนั้นการเรียก Serve() จะคืนค่ากลับ สำหรับ RPC แบบ streaming ที่อาจทำงานไม่จำกัดเวลา ให้กำหนด deadline ด้วยการยกเลิก context หรือใช้ health check ที่หยุดคืนค่า SERVING ก่อนเริ่ม shutdown เพื่อให้ load balancer มีเวลาระบายทราฟฟิก

ทีมควรเลือก gRPC แทน REST สำหรับบริการภายในเมื่อใด

gRPC เป็นตัวเลือกที่แข็งแกร่งกว่าเมื่อ บริการต้องการสัญญา API ที่เคร่งครัดและบังคับใช้ตอนคอมไพล์ ระบบต้องการ streaming (server push, สองทิศทาง) เวลาแฝงสำคัญและการ serialization แบบไบนารีช่วยลดขนาด payload ทีมดูแลทั้งโค้ด client และ server REST เหมาะกว่าสำหรับ API สาธารณะที่บริโภคโดยเบราว์เซอร์ (JSON โดยกำเนิด ไม่ต้องใช้ proxy) API ที่มีการ caching หนักผ่านความหมายของ HTTP หรือทีมที่ต้องการความเข้ากันได้ของ tooling สูงสุด สถาปัตยกรรมจำนวนมากใช้ทั้งสองอย่าง gRPC ภายในพร้อมเกตเวย์ RESTสำหรับผู้บริโภคภายนอก

บทสรุป

• Protocol Buffers บังคับใช้สัญญา API ตอนคอมไพล์ การเปลี่ยนแปลงที่ทำให้พังจะปรากฏตอนสร้างโค้ด ไม่ใช่ตอน runtime
• รูปแบบ UnimplementedServer ให้ความเข้ากันได้ไปข้างหน้าเมื่อเพิ่ม RPC ใหม่ลงในบริการที่กำลังพัฒนา
• ลำดับ interceptor สำคัญ recovery ก่อน แล้วจึง rate limiting แล้วจึงการยืนยันตัวตน ไลบรารี go-grpc-middleware v2 จัดการการเชื่อมต่อให้
• ใช้ grpc.StatsHandler กับ OpenTelemetry สำหรับ tracing สงวน interceptor ไว้สำหรับตรรกะทางธุรกิจอย่างการยืนยันตัวตนและ validation
• bufconn ช่วยให้การทดสอบ integration เร็วและไม่ต้องใช้พอร์ต โดยรันทั้งสแตก gRPC รวมถึงการ serialization และ interceptor
• mTLS กับ TLS 1.3 เป็นเส้นฐานปี 2026 สำหรับความปลอดภัยระหว่างบริการ วางการยืนยันตัวตนด้วยโทเคนซ้อนทับเพื่อระบุตัวตนภายใน mesh
• เตรียมตัวสำหรับคำถามสัมภาษณ์ gRPCด้วยการเข้าใจ RPC ทั้งสี่ชนิด กฎความเข้ากันได้ย้อนหลังของ proto และความแตกต่างระหว่าง interceptor กับ stats handler