ช่วงนี้พูดถึง Istio กันเยอะ
แต่คำถามที่น่าสนใจคือ
มันอ่านว่าอะไร ? มีทั้ง ไอ เอส ที ไอ โอ และ อิท ทิ โอ อ่านอย่างไรก็ช่างมันนะ
มันคืออะไร ?
มันมาจัดการ service mesh ไง แล้ว service mesh คืออะไร ?
ทำไมต้องใช้งานมันละ ?
สถาปัตยกรรมมันเป็นอย่างไร ?
ทำงานอย่างไร ?
บ้างก็บอกว่า ปกติก็พัฒนาด้วย Stack ของ Spring Cloud Netflix ทำไมต้องมาใช้ ?
ชีวิตดูยากมากมาย
ดังนั้นลองมาเริ่มเรียนรู้กันนิดหน่อย (ไม่น่าจะนิดนะ)
ก่อนอื่นเริ่มจากที่มาที่ไปก่อน
นั่นคือ architecture ของระบบงานสมัยใหม่
เริ่มเปลี่ยนจาก monolith มาเป็น microservices
นั่นหมายความว่า จะเกิด service จำนวนมากให้พัฒนา ดูแลและจัดการ
ส่งผลให้การพัฒนาง่ายขึ้น
ส่งผลให้ระบบตายยากขึ้น
ส่งผลให้ระบบ scale ง่ายขึ้น
แต่การจัดการ รวมทั้ง infrastructure ไม่ง่ายเลย !!
ถ้าพูดถึงการพัฒนาระบบ Microservices
stack ของการพัฒนาที่ได้รับความนิยมคือ Spring Cloud Netflix
ที่พัฒนาด้วยภาษา Java
ซึ่งมีเครื่องมือต่าง ๆ ดังนี้
- Eureka สำหรับจัดการเรื่อง Service Registry และ Discovery
- Ribbon สำหรับ Load Balancing ในฝั่ง client เพื่อเลือกว่าจะส่ง request ไปยัง server ใด
- Feign เป็น REST client สำหรับเรียกใช้งาน service อื่น ๆ ซึ่งการทำงานภายในใช้งาน Ribbon นั่นเอง
- Zuul เป็น API Gateway ทำให้ทุก APIs ถูกเรียกจากที่เดียว รวมทั้งช่วยจัดการเรื่อง rounting ต่าง ๆ อีกด้วย
- Hystrix เป็น Circuit Breaker สำหรับจัดการเรื่อง fault tolerance ช่วยปิดการติดต่อสื่อสารไปยังส่วนที่ทำงานไม่ปกติ ซึ่งส่งผลดีต่อผู้ใช้งาน service
- Turbine เป็น dashboard สำหรับแสดง trafic การใช้งาน และ circuit breaker
ชีวิตการพัฒนา Microservices ทำไมมันแยะเยี่ยงนี้ !!!
แต่มันก็มีปัญหาต่อมาอีกคือ การ deploy ทำอย่างไรดี ?
ทั้งการดูแล container ต่าง ๆ ให้มีตามจำนวนที่กำหนด (desired container)
ทั้งการ scale แบบอัตโนมัติ
การแก้ไขปัญหามีทั้ง Docker Swarm และ Kubernetes
ยังไม่พอนะ ก็มีปัญหาอีกคือ
ถ้าต้องการความสามารถต่าง ๆ เหมือนกับ Spring Cloud Netflix stack ละ
จะต้องทำอย่างไร ?
เนื่องจากสิ่งต่าง ๆ เหล่านั้นตาม stack พัฒนาด้วยภาษา Java
นั่นหมายความว่า มันผูกมัดกับภาษาโปรแกรมมากจนเกินไป
ดังนั้นสิ่งที่ต้องการคือแยกออกมาเป็น platform
ที่สามารถดูแลและจัดการระบบที่พัฒนาด้วยภาษาโปรแกรมต่าง ๆ
หนึ่งในเครื่องมือคือ Istio นั่นเอง
ปล.
เรื่องของ Service Model, Service Mesh และ Istio นั้น
สามารถอ่านเพิ่มเติมได้ที่ Site ของอาจารย์ชาญวิทย์ ได้เลย ชัดเจนมาก ๆ
หรืออ่านเพิ่มเติมได้จาก What is Istio ?
จาก official website นั้นอธิบาย architecture ของ Istio ไว้ดังรูป
จะพบว่ามีส่วนการทำงานเพียบเลย
แต่สิ่งแรกที่อยู่ใกล้แต่ละ service มากที่สุดคือ Proxy หรือ Envoy proxy หรือ Sidecar proxy
ทำให้ Istio สามารถจัดการสิ่งต่าง ๆ ตามด้านบนได้ง่าย
ที่สำคัญสามารถกำหนด rule และ policy ต่าง ๆ ได้อีกด้วย
โดยไม่ต้องไปทำการแก้ไข code
เช่น
- การติดต่อระหว่าง service
- การ tracing การทำงานของ service
- การจัดการเรื่อง Circuit Breaker
- การจัดการเรื่อง Retry
- มีระบบ monitoring และ dashboard สำหรับระบบงาน
- การจัดการเรื่อง traffic routing เช่น 70% ของ traffic ให้ไปทำงานที่ service version 1 และ 30% ของ traffic ให้ไปทำงานที่ service version 2
- Canary deployment
มาดูรายละเอียดของแต่ละ component กันบ้าง
Envoy
เป็นสิ่งที่พัฒนาต่อยอดมาจาก Envoy proxy ที่พัฒนาจากบริษัท Lyft
Envoy พัฒนาด้วยภาษา C++
ทำหน้าที่เป็น proxy ของการเข้าถึงหรือเรียก service ต่าง ๆ
โดยที่ Envoy มีความสามารถที่ build-in เข้ามาด้วยดังนี้
- Dynamic service discovery
- Load balancing
- Circuit Breaker
- HTTP/2 และ gRPC proxy
- Health check
- Fault injection
- Metric
Envoy นั้นจะถูก deploy คู่กับ container ใน Pods เสมอ จะเรียกว่า sidecar
นั่นหมายความว่าใน 1 Pod นั้นจะมี 2 container เสมอ
Mixer
ทำหน้าที่จัดการ access control policy ของการสื่อสารระหว่าง service ต่าง ๆ ใน cluster
และทำหน้าที่รวมข้อมูลการทำงานที่ส่งมาจาก Envoy proxy
Pilot
ทำการเตรียม Service discovery สำหรับ Envoy proxy
ทำการจัดการเรื่องของ traffic routing เช่น A/B testing และ canary deployment เป็นต้น
Citadel
ทำหน้าที่ authentication ระหว่าง service และจากผู้ใช้งาน
อีกทั้งยังสามารถใช้งาน Authorization ได้อีกด้วย
เพื่อให้เห็นภาพชัดขึ้นลองมาสร้าง service และ deploy ด้วย Istio กันต่อไป
