Nest.js Microservices.pdfNest.js Microservices.pdfNest.js Microservices.pdfNest.js Microservices.pdfNest.js Microservices.pdfNest.js Microservices.pdfNest.js Microservices.pdfNest.js Microservices.pdf

NEST.JS
MICROSERVICES
Babel Coder
https://www.babelcoder.com

MICROSERVICES
Babel Coder
Babel Coder

MICROSERVICES คืออะไร
การออกแบบแอปพลิเคชันแบบ Monolithic นันจะรวมศูนย์ทุกฟเจอร์เข้าเปนโปรแกรมเดียว
โดยทังแอปพลิเคชันจะมีการใช้งานฐานข้อมูลร่วมกันเพือจัดเก็บข้อมูลสําหรับฟเจอร์ต่าง ๆ
Order
Stock
Payment
Monolithic
Babel Coder
Babel Coder

สถาปตยกรรมแบบ Monolithic นีประกอบด้วยข้อดีต่าง ๆ ได้แก่
ง่ายต่อการพัฒนา
ง่ายต่อการแก้ไขหรือเปลียนแปลง
สามารถทําการทดสอบฟงก์ชันต่าง ๆ ได้อย่างตรงไปตรงมา
ง่ายต่อการ Deploy แอปพลิเคชันสู่ Production
ไม่ยุ่งยากในการ Scale ระบบ
Babel Coder
Babel Coder

อย่างไรก็ตาม Monolithic นันก็มีข้อเสียด้วยเช่นกัน คือ
การผูกติดกับภาษาโปรแกรม
ความยุ่งยากในการพัฒนาระดับทีม
ความช้าในการ Deploy
การ Scale ระบบทีไร้ประสิทธิภาพ
Babel Coder
Babel Coder

Order
Stock
Payment
Order
Stock
Payment
Order
Stock
Payment
LOAD
BALANCER
Babel Coder
Babel Coder

เพือแก้ปญหาของ Monolithic ดังกล่าว จึงเปนทีมาของสถาปตยกรรมแบบ Microservices
สถาปตยกรรมแบบ Microservices เปนสถาปตยกรรมทีออกแบบตามหลักการของ Cloud
Native โดยระบบหนึง ๆ จะประกอบไปด้วยหลายหน่วยย่อยหรือเซอร์วิส ทีมีการเชือมต่อกัน
อย่างหลวม ๆ กับเซอร์วิสอืน แต่ละเซอร์วิสจะมีขนาดเล็กและแยก Deploy ได้อย่างอิสระ
Babel Coder
Babel Coder

Order
microservices
Stock Payment
Babel Coder
Babel Coder

ลักษณะพืนฐานของ MICROSERVICES
สถาปตยกรรมแบบ Microservices ประกอบด้วยลักษณะต่าง ๆ ดังต่อไปนี
Autonomy แต่ละเซอร์วิสในสถาปตยกรรมแบบ Microservices สามารถแยกพัฒนาได้
เช่น มีทีมสําหรับการพัฒนาเซอร์วิสของ User, Article, Order และ Payment แยกแตก
ต่างกันออกไป พร้อมทังสามารถแยก Deploy หรือ scale แยกแต่ละเซอร์วิสได้โดยไม่
กระทบกับเซอร์วิสอืน
Specialization แต่ละเซอร์วิสได้รับการออกแบบโดยอาศัยการแบ่งแยกตาม
Business Capability เพือให้สามารถแก้ปญหาทางธุรกิจนัน ๆ ได้อย่างเฉพาะเจาะจง
Agility ความคล่องตัวนันเกิดจากการที Microservices ส่งเสริมให้องค์กรมีการ
ออกแบบทีมขนาดเล็กเพือเปนเจ้าของแต่ละเซอร์วิส
Flexible Scaling Microservices ทําให้เกิดการ scale แต่ละเซอร์วิสได้อย่างอิสระโดย
ไม่กระทบกับเซอร์วิสอืน ๆ
Babel Coder
Babel Coder

Order
ลักษณะพืนฐานของ MICROSERVICES
Stock Payment
Order Order
Babel Coder
Babel Coder

SCALE CUBE
--- Wikimedia
Babel Coder
Babel Coder

Babel Coder
Babel Coder
CLOUD NATIVE คืออะไร
Cloud Native คือแนวทางทีซอฟต์แวร์ใช้ในการสร้าง ปรับใช้ และจัดการแอปพลิเคชันทีทันสมัยในสภาพแวดล้อมการ
ประมวลผลบนคลาวด์ หากแอปพลิเคชันนันถูกออกแบบมาเพือใช้งานบนคลาวด์จะเรียกว่า Cloud Native Applications
โดยทัวไปแล้วแอปพลิเคชันบน Microservices จะได้รับการพัฒนาในรูปแบบของ Cloud Native
คุณสมบัติหลักของ Cloud Native ได้แก่:
ความยืดหยุ่น
01
การประมวลผลบนคลาวด์
02
ไมโครเซอร์วิส
03
การใช้งาน Container
04
DevOps และ Automation
05
การประหยัดค่าใช้จ่าย
การอัปเดตฟเจอร์
07
06

DOMAIN
DRIVEN DISIGN
Babel Coder
Babel Coder

Babel Coder
Babel Coder
DOMAIN DRIVEN DESIGN
Domain Driven Design คือแนวทางและกรอบความคิดในการออกแบบระบบให้สอดคล้องกับแนวทางทางธุรกิจ โดยอาศัย
มุมมองจากผู้เชียวชาญหลายแขนงทังผู้เชียวชาญภาคธุรกิจและนักพัฒนา บนพืนฐานของการออกแบบบนภาษาเดียวกัน
ผลลัพธ์สุดท้ายคือการวางระบบทีอิงอยู่กับ Domain ทางธุรกิจ

Babel Coder
Babel Coder
DOMAIN
Domain หมายถึงปญหาหรือจุดสนใจทางธุรกิจทีระบบต้องการพัฒนาเพือแก้ไขปญหา เช่น ระบบวิดีโอออนไลน์อาจประกอบ
ไปด้วย Domain ต่าง ๆ ได้แก่ Recommendation Search Payment และ Ads เปนต้น
Domain สามารถมี Subdomain ซึงถือเปนส่วนย่อยของ Domain นัน ๆ ได้ เช่น Order Management อาจมี
Subdomain เปน Shopping Cart Management, Payment Processing และ Order Fullfillment เปนต้น

Babel Coder
Babel Coder
UBIQUITOUS LANGUAGE
เพือให้การนิยามศัพท์ต่าง ๆ ใน Domain เปนไปในทิศทางเดียวกัน เราจึงต้องการภาษากลางทีทัง Domain Experts นัก
พัฒนาและผู้มีส่วนเกียวข้องเข้าใจร่วมกัน เรียกว่า Ubiquitous Language ภาษากลางนีภาคธุรกิจต้องแจกแจงให้นัก
พัฒนาเข้าใจถึงความหมายเพือให้รูปแบบของการสือสารทังโปรเจคและศัพท์ทีใช้ในการตังชือตัวแปร ฟงก์ชัน คลาส เปนไปใน
แนวทางเดียวกันกับความหมายทางธุรกิจ นอกจากนีศัพท์บางอย่างทีจําเปนต้องให้ภาคธุรกิจทราบนักพัฒนาต้องแจกแจง
เพือให้ผู้มีส่วนเกียวข้องทราบเช่นกัน

Babel Coder
Babel Coder
BOUNDED CONTEXT
Subdomain ใด ๆ ควรมีขอบเขตความรับผิดชอบทีชัดเจนและมีเพียงสิงเดียวทีเปนงานควรค่าแก่การดําเนินการ ขอบเขต
ชัดเจนนีถูกเรียกว่า Bounded Context ของ Subdomain นัน ๆ Bounded Context ใช้เพือนิยามสิงต่อไปนี
มี Domain Models ใดบ้างทีจําเปนสําหรับ subdomain นัน ๆ
แต่ละ Models มี Properties ใดบ้าง
มีหน้าทีการทํางานใดบ้างที subdomain ต้องกระทํา
ตัวอย่างเช่น Shopping Cart Subdomain สามารถมี Models ได้แก่ Cart, Product, Customer โดยมีหน้าทีการทํางาน
คือการ CRUD บน Cart อย่างไรก็ตาม Models ต่าง Subdomain อาจมีการนิยามทีแตกต่างกัน เช่น Product และ
Customer ใน Shopping Cart ไม่จําเปนต้องเหมือนกับใน Subdomain ของ Product Catalogs
Bounded Context ทีแตกต่างกันอาจมีการนิยาม ubiquitous language ทีแตกต่างกัน เช่น Promotion ใน
Shopping Cart อาจหมายถึงราคาโปรโมชัน ในขณะที Promotion ใน HR อาจหมายถึงการเลือนตําแหน่ง เปนต้น

Babel Coder
Babel Coder
VALUE OBJECTS VS ENTITIES
Value Objects หมายถึงออบเจ็กต์ทีไม่สามารถแก้ไขค่าได้ Value Objects จะถือว่ามีค่าเท่ากันเมือมีค่าข้อมูลเหมือนกัน
เช่น Color จะมีค่าเท่ากันเมือ RGB เท่ากัน เปนต้น
Entities หมายถึงออบเจ็กต์ทีสามารถเปลียนแปลงค่าได้และไม่สามารถวัดความเท่ากันได้โดยดูแต่เพียง Property
อย่างเดียว หากแต่อาศัยการเท่ากันจากค่า Identity เช่น ID
การออกแบบระบบจึงควรพิจารณาว่าสิงใดเปน Value Objects และสิงใดควรเปน Entities เนืองจาก Entities นันมีการ
ทํางานทีซับซ้อนกว่าทังการนิยาม methods เพือเปลียนแปลง Properties เปนต้น

Babel Coder
Babel Coder
Order Item
AGGREGATE ROOT
Aggregate หมายถึงกลุ่มของออบเจ็กต์ทีมีความสัมพันธ์กันโดยถูกจัดการในฐานะทีเปนหน่วยออบเจ็กต์เดียวกัน ในมุมมอง
ของ DDD นันกลุ่มก้อนของออบเจ็กต์ใน DDD นันสัมพันธ์กันจนไม่ควรแยกจัดการทีละส่วนหากแต่ต้องจัดการโดยใช้มุม
มองว่าเปนชินส่วนเดียวกัน
Order
Order Item
Order Item

COMMUNICATION
Babel Coder
Babel Coder

การสือสารระหว่างเซอร์วิส
Order Stock Payment
Babel Coder
Babel Coder

Order Stock Payment
1
SYNCHRONOUS MESSAGES
Request an order
check stock
Calculate total price
2
3
Babel Coder
Babel Coder

Order Stock Payment
SYNCHRONOUS MESSAGES
check stock
Calculate total price
2
3
POST <STOCK_IP>/products/<ID>
POST <PAYMENT_IP>/checkout
Babel Coder
Babel Coder

HTTP / REST API
Babel Coder
Babel Coder
Order Stock Payment
HTTP / REST API เปนหนึงในวิธีการสือสารแบบ Synchronous ระหว่างเซอร์วิสทีเปนทีนิยม เซอร์วิสต่าง ๆ สามารถสือสารกัน
ด้วย REST API ได้ อย่างไรก็ตามหากเซอร์วิสมีการร้องขอข้อมูบต่อเนืองไปหลาย ๆ เซอร์วิสย่อมทําให้ Client ปลายทางใช้ระยะ
เวลารอคอยการตอบกลับทีนานตาม นอกจากนีหากมีข้อผิดพลาดเกิดขึนในเซอร์วิสชันใน Client จะรับทราบถึงข้อผิดพลาดนันได้
ช้าเนืองจากต้องรอเวลาก่อนเซอร์วิสแรก ๆ จะประมวลผลเสร็จและส่งการทํางานไปยังเซอร์วิสชันในก่อน จึงจะทราบว่ามีข้อผิด
พลาดเกิดขึน

Babel Coder
Babel Coder
GRPC
gRPC เปนรูปแบบหนึงของ Remote Procedure Call
(RPC) ทีมีความสามารถในการนําส่งข้อมูลได้ในขนาดที
เล็กกว่าและรวดเร็วกว่าจึงนิยมใช้ในการจัดการการสือสาร
ระหว่างเซอร์วิสแบบ Synchronous Messaging

Babel Coder
Babel Coder
article
user
comment
GRAPHQL FEDERATION
GraphQL Federation เปนหนึงในความสามารถของ Apollo Server ในการรวมหลาย GraphQL API ให้เปนหนึงเดียว เรียกว่า
Supergraph โดยเราสามารถแจกแจงเซอร์วิสต่าง ๆ เปน GraphQL API ย่อย ๆ เรียกว่า Subgraph ได้ เมือมีการร้องขอข้อมูลไปยัง
Supergraph การร้องขอนันจะมีการส่ง Query ย่อย แบบ Synchronous ไปยัง Subgraph ซึงเปนเซอร์วิสต่าง ๆ แล้วจึงรวมผลลัพธ์
กลับสู่ Client ต่อไป

Order Stock Payment
1
ASYNCHRONOUS MESSAGES
ORDER_REQUESTED Event
Message Channel
Message Broker
Babel Coder
Babel Coder

เมือไหร่ควรใช้การสือสารแบบใด
ทังการสือสารแบบ Synchronous และ Asynchronous ต่างมีข้อดีข้อเสียแตกต่างกัน การเลือกใช้การสือสารประเภทต่าง ๆ ตามความ
เหมาะสมจึงเปนเรืองสําคัญ
เราควรเลือกใช้การสือสารแบบ Synchronous ในกรณีต่อไปนี
หากไม่สามารถดําเนินการอย่างอืนได้ถ้าไม่ได้รับผลลัพธ์จากเซอร์วิสอืน เช่น กรณีสอบถามข้อมูลสินค้าจาก Product ทีเซอร์วิส Product
มีการร้องขอข้อมูลผู้ขายต่อไปยัง User กรณีนีต้องใช้ Synchronous เพือให้ข้อความตอบกลับไปยังส่วนของ UI นันสมบูรณ์
เมือต้องการข้อมูลแบบ Real-time
เมือแต่ละเซอร์วิสมีระยะเวลาการประมวลผลทีสัน
เราควรเลือกใช้การสือสารแบบ Asynchronous ในกรณีต่อไปนี
เมือฟเจอร์นันยอมรับการทํางานทีเสร็จสินในภายหลังได้ เช่น การออกรายงานทีสามารถส่งผลลัพธ์ภายหลังผ่านอีเมล์ได้
เมือการทํางานของเซอร์วิสระหว่างกลางมีความล่าช้าหรือใช้ระยะเวลานานในการประมวลผล
เมือยอมรับให้บางเซอร์วิสเกิดข้อผิดพลาดในการทํางานได้และต้องการความสามารถในการทําซํา (Retry)
Babel Coder
Babel Coder

API GATEWAY คืออะไร
Order Stock Payment
POST <ORDER_IP>
Babel Coder
Babel Coder

Order Stock Payment
API GATEWAY คืออะไร
POST <GATEWAY_IP>/orders
POST /orders
A
P
I
G
a
t
e
w
a
y
Babel Coder
Babel Coder

Babel Coder
Babel Coder
Users UI
MICRO FRONTEND
Articles UI Articles
Users

QUERIES
Babel Coder
Babel Coder

Babel Coder
Babel Coder
CQRS
การสร้างแอปพลิเคชันอย่างง่ายในรูปแบบของการ CRUD ทีการอ่านและการเขียนข้อมูลกระทําบน Data Models ชุดเดียวกัน แม้จะสามารถ
กระทําได้โดยง่ายแต่ในระบบทีซับซ้อนย่อมมีความท้าทายต่าง ๆ เกิดขึน
ปญหาการปรับปรุงประสิทธิภาพของ Data Schemas การบันทึกข้อมูลทีดีโครงสร้างของตารางควรทํา Normalize เพือแบ่งแยกข้อมูล
ตามตารางต่าง ๆ อย่างเหมาะสม อย่างไรก็ตามการอ่านข้อมูลนันยิงมีการทํา Normalize มากเท่าใดยิงต้องอาศัยการ Join ตารางเพือ
สืบค้นข้อมูลให้ได้ผลลัพธ์ตามต้องการมากเท่านัน
การเลือกใช้ฐานข้อมูลทีเหมาะสม การรวมการอ่านและการเขียนข้อมูลบนฐานข้อมูลเดียวกันทําให้เสียประโยชน์บางอย่าง เช่น
แอปพลิเคชันทีต้องการการจัดการ Transaction และ ACID ทีเหมาะสมจึงเลือกใช้ฐานข้อมูลประเภท DBMS อย่างไรก็ตามการสืบค้น
ข้อมูลกลับต้องการความสามารถเชิงลึก หากแบ่งแยกการอ่านข้อมูลออกมาต่างหากได้จะสามารถเลือกใช้ฐานข้อมูลทีเหมาะสม เช่น
ElasticSearch ได้
ปญหาด้านการขยายการรองรับผู้ใช้งาน การอ่านข้อมูลโดยทัวไปแล้วมักจะมีปริมาณการเรียกใช้งานทีมากกว่าการเขียนข้อมูล หากการ
อ่านและการเขียนได้รับการแบ่งแยกออกจากกัน นันจะทําให้เราเลือกสเกลระบบในการอ่านให้มากขึนได้
Separation of Concerns การแบ่งแยกงานด้านการอ่านออกจากการเขียนข้อมูลออกจากกันจะทําให้ระบบมีความยืดหยุ่นในการเพิม
คุณสมบัติให้แต่ละงานได้มากขึน

Babel Coder
Babel Coder
CQRS
Command and Query Responsibility Segregation (CQRS) เปนหลักการทีว่าด้วยการแบ่งแยก Command ออกจาก Queries โดย
งานด้านการจัดการ Command จะมี Data Models ทีแตกต่างกับ Data Models ของงานฝง Queries
Command เปนด้านของการรับ Event จากระบบหรือเซอร์วิสอืน เพือดําเนินการ Create Update หรือ Delete ข้อมูล โดยอาจ
ประกอบด้วยกระบวนการอืน เช่น Data Validation การจัดการด้าน Business Logic การจัดการความปลอดภัย เปนต้น เมืองานฝง
Command เสร็จสินจะทําการส่งต่อ Event ใหม่ออกไปเพือให้ฝง Query ดําเนินการต่อไป
Query ทําการรับ Event จากด้าน Command เพือนําไปจัดทําข้อมูลทีมีความเหมาะสมต่อการเรียกใช้งาน ข้อมูลส่วนนีจะมีการจัดเก็บใน
Read Models ด้วยรูปแบบทีง่ายต่อการ Query ไปใช้งานต่อได้อย่างรวดเร็วบนประสิทธิภาพสูงสุด

Babel Coder
Babel Coder
Queries
Event Handlers
Commands
CQRS
Query Store
Command Store
Read
Create
Update
Delete
Event
Updates
Reads
Updates

Babel Coder
Babel Coder
CQRS
ORDER
Updates
Command Store
Queries
Event Handlers
ORDER_PLACED ORDER_CREATED
Query Store
Updates
Reads
Get
Order Query Service

Babel Coder
Babel Coder
CQRS
Order
Query
Order
Order
Query
Order
Query
Query Store Replicas
CQRS ช่วยให้เราสามารถสเกลเซอร์วิสทีมี
การเข้าถึงการใช้งานสูง เช่น Query
Service ได้มากขึน

Babel Coder
Babel Coder
MATERIALIZED VIEW
Query Store Materialized View Presentation Layer
CQRS ช่วยให้เราสามารถแบ่งแยกฐานข้อมูลระหว่าง Command และ Query ได้อย่างเหมาะสม เราสามารถใช้ Elastic Search ฝง
Query เพือการค้นหาเชิงลึก หรือใช้ฐานข้อมูลประเภท NoSQL อืนในการจัดเก็บข้อมูล โดยข้อมูลฝง Query จะถูกจัดเก็บในรูปแบบที
พร้อมสําหรับการนําไปใช้งานได้ทันทีโดยไม่ต้องอาศัยการประมวลผลอืนเพิมเติมหรือประมวลผลน้อยทีสุด
Get

Babel Coder
Babel Coder
EVENTUAL CONSISTENCY
CQRS อาจมี delay เกิดขึนระหว่างการอัพเดทและการอ่านข้อมูล เช่น คําสังซือได้รับการยืนยันแล้ว (ORDER_PLACED) แต่รับการ
อัพเดทในฐานข้อมูลฝง Command แล้ว อย่างไรก็ตามข้อมูลนียังไม่ได้รับการอัพเดทฝง Query เนืองจากเหตุการณ์
ORDER_CREATED ยังมาไม่ถึง หากในระหว่างนีมีการร้องขอข้อมูลเข้ามาเราจะยังไม่ได้รับข้อมูลล่าสุดจนกว่าเหตุการณ์
ORDER_CREATED จะได้รับการจัดการในฝง Query
Eventual Consistency เปนหลักการทีกล่าวเหตุการณ์เช่นทีว่า ระบบอาจมี delay เกิดขึนได้บ้างแต่ท้ายทีสุดแล้วข้อมูลทังระบบจะต้อง
ได้รับการอัพเดทสอดคล้องและเหมือนกัน
ORDER
Queries
Event Handlers
ORDER_PLACED ORDER_CREATED
Get
Order Query Service

Babel Coder
Babel Coder
OPTIMISTIC UPDATE
เพือให้ UI มีการแสดงผลลัพธ์ทีสอดคล้องกับการทํางานจริง เมือมีการอัพเดทข้อมูลให้ทําการส่ง Command ไปยังเซอร์วิสก่อน ในขณะ
เดียวกันก็ทําการอัพเดทข้อมูลบน UI เสมือนข้อมูลนันได้รับการอัพเดทแล้ว หากการทํางานล้มเหลวจึงยกเลิกการแสดงผลลัพธ์บน UI
เรียกลักษณะการทํางานเช่นนีว่า Optimistic Update
Create
Failed

Babel Coder
Babel Coder
POLLING
วิธีการ Polling จะทําการส่ง Request ไปยัง Command Service จากนันจึงทําการ Polling ข้อมูลจาก Query Service จนกว่าจะได้
รับการอัพเดทจึงจะหยุดกระบวนการ Polling
Query
Command
UI
Request
1. 2. Poll until updated

Babel Coder
Babel Coder
PUBLISH - SUCSCRIBE
นอกเหนือจากการ Polling เรายังสามารถกระทํา Publish - Subscribe ด้วยการให้ UI ทําการ Subscribe บน Query ภายหลังการส่ง
Request ไปยัง Command Service เมือ Query มีการอัพเดทจะทําการ Publish การเปลียนแปลงมายังส่วนของ UI โดยอัตโนมัติ
เนืองจากเราได้ทําการ Subscribe ไว้แล้ว
Query
Command
UI
2. Request Subscribe
1. 3. Publish

EVENT SOURCING
Babel Coder
Babel Coder

Babel Coder
Babel Coder
TRADITIONAL DATA STORAGE
Service
Database
Records
Update
Old Data
ในการบันทึกข้อมูลบนฐานข้อมูลเปนการแทนทีทับข้อมูลเดิมด้วยข้อมูลใหม่ กรณีเช่นนีเราไม่สามารถทราบได้เลยว่าข้อมูลก่อน
หน้านันคือข้อมูลใด มีค่าเปนเช่นไร เกิดการเปลียนแปลงค่าเพราะเหตุใด รวมถึงใครเปนผู้ดําเนินการขันตอนดังกล่าว

Babel Coder
Babel Coder
Service
AUDIT LOGS
Database
เพือให้เราสามารถจัดเก็บประวัติของการดําเนินการต่าง ๆ ว่าใคร ดําเนินการใด เพือให้เกิดการเปลียนแปลงสิงใด เราจึงต้องมี
Audit Logs ทีอาจเปนไฟล์ ตารางหรือฐานข้อมูล เพือจัดเก็บบันทึกการเปลียนแปลงนัน เมือเราต้องการให้ข้อมูลทีถูกบันทึก
ใน State สอดคล้องกับข้อมูลใน Audit Logs เราสามารถกระทําได้ผ่าน Transaction
State
Audit Logs

Babel Coder
Babel Coder
Service
DUPLICATED DATA
Database
ข้อมูลใน Audit Logs นันเปนข้อมูลทีมีความถูกต้องแม่นยําทีสุดแต่อยู่ในรูปแบบของบันทึกของช่วงเวลาว่าเกิดการกระทําใด
ๆ ก่อนหลังบ้าง ถ้าการดําเนินงานทุกอย่างถูกต้อง ข้อมูลใน State ก็จะเปนข้อมูลทีบันทึกเปนผลลัพธ์สุดท้ายของการทําตาม
ขันตอนใน Audit Logs จึงกล่าวได้ว่า State คือข้อมูลทีซําซ้อนกับ Audit Logs
State
Audit Logs
Duplicated
Single Source of Truth

Babel Coder
Babel Coder
Service
EVENT SOURCING
Database
เราจึงไม่จัดเก็บข้อมูล State หรือสถานะสุดท้ายในฐานข้อมูลอีกต่อไป หากแต่จัดเก็บบันทึกของเหตุการณ์ต่าง ๆ ทีเกิดขึน
แทนใน Event Logs (ต่อไปนีจะเรียกว่า Event Store) เมือใดก็ตามทีเราต้องการสถานะหรือค่าสุดท้ายของการทํางานเรา
สามารถทําซําเหตุการณ์ต่าง ๆ เหล่านันจนได้ผลลัพธ์สุดท้ายออกมาได้
Event Logs / Event Store
Replay
State / Object
แต่ละ Record ใน Event Store จะเปน
Immutable Data คือไม่สามารถเปลียนแปลง
ข้อมูลได้

Babel Coder
Babel Coder
Event_ID Event_Type Data
1 ACC_DEPOSITED { uid: 1, amount: 100 }
3 ACC_WITHDRAWED { uid: 1, amount: 10 }
EVENT SOURCING
Account Balance: 190

Babel Coder
Babel Coder
Event_ID Event_Type Data
3 ACC_WITHDRAWED { uid: 1, amount: 10 }
5 ACC_DEPOSITED { uid: 1, amount: 20, note: ‘...’ }
EVENT SOURCING
กรณีทีเกิดความผิดพลาด เช่น ID 3 ทีความ
ตังใจเดิมเปนการฝากเงิน 10 บาท หากแต่
ระบบบันทึกผิดพลาดเปนถอนเงิน 10 บาทแทน
ตามหลักการของ Event Sourcing เราจะไม่
สามารถแก้ไข Record ทีบันทึกแล้วได้ แต่เรา
สามารถสร้าง Record จาก Event ใหม่ตาม
ID 5 เพือหักล้างการกระทําดังกล่าวได้

Babel Coder
Babel Coder
DateTime Event_ID Event_Type Data
xxx1 1 ACC_DEPOSITED { uid: 1, amount: 100 }
xxx3 3 ACC_WITHDRAWED { uid: 1, amount: 10 }
EVENT SOURCING
การใช้ Event Sourcing นันทําให้เราสามารถ
คํานวณค่าผลลัพธ์ในช่วงเวลาทีกําหนด โดย
อาศัยการ Replay บันทึกจากเหตุการณ์ใน
ช่วงเวลาทีสนใจ เช่น สนใจ Account
Balance ของ User ID เปน 1 ในช่วงเวลา
xxx1 ถึง xxx3 ซึงจะได้ผลลัพธ์เปน 90 บาท

Babel Coder
Babel Coder
Service
Command
THE DUAL WRITE PROBLEM
Event Queue
ในสถานการณ์ทีเซอร์วิสต้องมีการอัพเดทข้อมูลลงฐานข้อมูลพร้อมกันกับทีต้องส่งข้อมูลอัพเดทนันไปยังเซอร์วิสอืน เช่น ผ่าน
Event Queue เนืองจากทังฐานข้อมูลและ Queue เปนคนละระบบกันจึงการันตีไม่ได้ว่าข้อมูลจะ Sync กัน หากการอัพเดท
ข้อมูลฝงหนึงสําเร็จแต่อีกด้านไม่สําเร็จจะทําให้เกิดปญหาด้านความสอดคล้องกันของข้อมูลได้
Database

Babel Coder
Babel Coder
Service
Command
THE DUAL WRITE PROBLEM
Event Queue
เนืองการ Event Store เปนศูนย์รวมของข้อมูลทีแท้จริงเราจึงสามารถแก้ไขปญหาดังกล่าวได้ โดยทําการบันทึกเหตุการณ์ไป
ยัง Event Store ก่อน เมือการกระทําดังกล่าวสําเร็จจึงส่งต่อผลลัพธ์นันไปยังระบบภายนอก เช่น Event Queue ต่อไป
Event Store

Babel Coder
Babel Coder
Total Item
10
10
OPTIMISTIC CONCURRENCY
สมมติให้จํานวนสินค้าคงเหลือมี 10 ชิน เมือผู้ใช้งาน A และ B ต่างเข้ามาใช้งานพร้อมกัน หน้าจอ UI จะแสดงผลของเขาทังคู่จะ
แสดงผลลัพธ์สินค้าคงเหลือเปน 10 ชิน ทังสองจึงสามารถเลือกซือสินค้าได้ในจํานวนไม่เกิน 10 ชินทังคู่ เมือ A และ B ทําการ
สังซือระบบจะบันทึกการสังซือและตัดยอดคงเหลือของสินค้า ทว่าในความเปนจริงแล้วเหตุการณ์นีต้องไม่เกิดขึนเนืองจาก
สินค้าคงเหลือจะไม่เพียงพอ
10
ITEM_REMOVED (6) ITEM_REMOVED (9)
Event Store

Babel Coder
Babel Coder
Total Item
10
10
10
ITEM_REMOVED (6) ITEM_REMOVED (9)
V2 V2
OPTIMISTIC CONCURRENCY
เราสามารถเพิมเลขเวอร์ชันของแต่ละเหตุการณ์ได้ หากเหตุการณ์ใดมีเลขเวอร์ชันตรงกันจะถือว่าเปนเหตุการณ์ทีเกิดขึนพร้อม
กัน Record ตัวหลังทีมีเวอร์ชันเดียวกันจะไม่ถูกนํามาประมวลผลหรืออาจไม่ถูกบันทึกลงใน Event Store
Event
Store

Babel Coder
Babel Coder
SNAPSHOTS
Snapshot Version N
การคํานวณผลลัพธ์สุดท้ายของ Entity จากเหตุการณ์ทังหมดใน Event Store นันเปนเรืองเสียเวลา เราจึงทําการสร้าง
Snapshot ทีคํานวณผลลัพธ์จากเหตุการณ์ไว้ล่วงหน้าแล้วโดยมีการกํากับด้วยเลขเวอร์ชัน การร้องขอข้อมูลล่าสุดสามารถ
เริมจาก Snapshots เวอร์ชันล่าสุดก่อนแล้วคํานวณเพิมเติมในส่วนของเหตุการณ์ถัดไปทีเกิดขึนหลัง Snapshot เวอร์ชัน
นัน ทังนี Snapshots เก็บข้อมูลแบบ Immutable Data และสามารถลบ Snapshots ทิงได้
Event 1 Event 2 Event 3 Event N
Event N + 1 Event N + 2

Babel Coder
Babel Coder
SNAPSHOTS
DateTime Entity Entity_ID Event_ID Event_Type Data
xxx1 Account 1 1 ACC_DEPOSITED { uid: 1, amount: 100 }
xxx2 Account 1 2 ACC_WITHDRAWED { uid: 1, amount: 10 }
Version Entity Entity_ID Data
1 Account 1 { uid: 1, amount: 100 }
Snapshots
Event
Store

Babel Coder
Babel Coder
MATERIALIZED VIEW
Event Store นันจัดเก็บข้อมูลในลักษณะทีเปนความสัมพันธ์ของเหตุการณ์ใน Domain Event โดยอาจมีข้อมูลทีมากเกิน
กว่านําไปใช้แสดงผลหรือข้อมูลบางส่วนต้องถูกคํานวณด้วยลักษณะพิเศษก่อนแสดงผล หากทุกครังทีต้องการนําข้อมูลไป
แสดงต้องผ่านการประมวลใหม่ทังหมดย่อมเสียเวลา Materialized View สามารถเข้ามาเพิมประสิทธิภาพด้วยการจัดเก็บ
ข้อมูลสุดท้ายเฉพาะส่วนทีต้องการแสดงผลจริงเท่านัน
Event Store Materialized View Presentation Layer

Babel Coder
Babel Coder
MATERIALIZED VIEW
ภายหลังการบันทึกเหตุการณ์ใน Event Store เราจะทําการสร้างอัพเดทเพือเน้นเก็บข้อมูลเฉพาะส่วนแสดงผลใน
Materialized View
Command
Materialized View Presentation Layer
Event Store
Query
Event

TRANSACTION
Babel Coder
Babel Coder

SAGA PATTERN
Saga Pattern คือรูปแบบของการออกแบบระบบในสถาปตยกรรม Microservices เพือจัดการให้เกิด Data
Consistency จากการสือสารกันของเซอร์วิสต่าง ๆ ในระบบ รูปแบบของ Saga นันจะมองว่าธุรกรรม
(Transaction) ใด ๆ จะเกิดจากการดําเนินการผ่านธุรกรรมย่อย ๆ ในแต่ละเซอร์วิส (Local Transactions)
แต่ละธุรกรรมย่อย ๆ ของเซอร์วิสนันจะมีการอัพเดทลงฐานข้อมูลของเซอร์วิสตนเอง จากนันเซอร์วิสจึงส่งต่อ
การทํางานด้วยการส่งเหตุการณ์ (Event) เพือให้เกิดการทํางานของเซอร์วิสถัดไป หากธุรกรรมย่อยนันล้มเหลว
ในการดําเนินงาน Saga จะทําการเรียก Compensating Transaction อันเปนธุรกรรมย้อนกลับเพือให้ระบบ
สามารถย้อนการเปลียนแปลงกลับไปได้
รูปแบบการทํางานของ Saga แบ่งออกเปนสองประเภท คือ Choreography-based Saga และ
Orchestration-based Saga
Babel Coder
Babel Coder

CHOREOGRAPHY-BASED SAGA
Order
Stock
Payment
ORDER_REQUESTED
1.
2. ORDER_CREATED
3. STOCK_RESERVED
4
.
O
R
D
E
R
_
P
L
A
C
E
D
Babel Coder
Babel Coder

Babel Coder
Babel Coder
ORDER_CREATED
CHOREOGRAPHY-BASED SAGA

ORCHESTRATION-BASED SAGA
Orchestrator
Order
Stock
Payment
T1: Order requested
Saga
Log
ORDER_REQUESTED
1.
T3: Check status requested
3. CHECK_STOCK_REQUESTED
2. ORDER_CREATED
4. STOCK_RESERVED
6. PAYMENT_APPROVED
T5: Payment requested
5. PAYMENT_REQUESTED
T6: Payment approved
7. O
RD
ER_
RESERV
ED
T2: Order created
T4: Stock reserved
T7: Order reserved
Babel Coder
Babel Coder

COMPENSATING TRANSACTIONS
Orchestrator
Order
Stock
Payment
T1: Order requested
Saga
Log
ORDER_REQUESTED
1.
T3: Check status requested
3. CHECK_STOCK_REQUESTED
2. ORDER_CREATED
4. STOCK_REJECTED
C3: -
C2: -
T2: Order created
T4: Stock rejected
C1: Order cancelled
5
.
O
R
D
E
R
_
C
A
N
C
E
L
L
E
D
Babel Coder
Babel Coder
C4: -

RELIABLE SERVICES
Babel Coder
Babel Coder

Babel Coder
Babel Coder
RELIABILITY
ธรรมชาติของ Microservices มักไม่จบการทํางานอยู่เพียงเซอร์วิสเดียว เซอร์วิสหนึงมักเรียกการทํางานต่อไปยัง
downstream services อืน ๆ โดยมากแล้วปญหามักเกิดกับการสือสารแบบ Synchronous Messaging หากมี
downstream services ใดตายไปย่อมทําให้เกิดการล้มเหลวทังสายการร้องขอนัน นอกจากนีการเชือมต่อทีล้มเหลวของ
ระบบเน็ตเวิร์กก็อาจเปนหนึงในปญหาทีทําให้การร้องขอผิดพลาด

Babel Coder
Babel Coder
AVAILABILITY
A
B C
D
E F
HA = 95%
HA = 99.9%
HA = 99.9%
HA = 99.9%
HA = 99.9% x 95% x 99.9% = 94.8%
HA = 99.9% x 94.8% x 99.9% = 94.5%

Babel Coder
Babel Coder
A
B C
D
E F
CASCADING FAILURES

Babel Coder
Babel Coder
DESIGNING RELIABLE COMMUNICATION
เมือความผิดพลาดเปนสิงทีหลีกเลียงไม่ได้ เราจึงต้องออกแบบให้เซอร์วิสและการสือสารระหว่างเซอร์วิสสามารถเข้าถึงได้ดี
ทีสุด และสามารถฟนคืนจากข้อผิดพลาดได้อย่างรวดเร็ว โดยอาศัยเทคนิคต่าง ๆ ดังนี
Retries
Fallbacks
Timeouts
Circuit Breakers
Rate Limits

Babel Coder
Babel Coder
RETRIES
การสือสารไปยังเซอร์วิสอืน เซอร์วิสนัน ๆ อาจมีความผิดพลาดชัวคราว (transient faults ) เกิดขึนได้ เหตุนีเราจึงควร
Retry Request เพือทดสอบการร้องขอใหม่อีกครัง กลยุทธิของการประยุกต์ใช้ Retry มีดังนี
Cancel ถ้าสืบทราบได้ว่าความผิดพลาดของเซอร์วิสนันไม่ใช่ความผิดพลาดชัวคราว Request นันควรยกเลิก
Retry immediately หากความผิดพลาดนันเกิดขึนไม่บ่อย เช่น packet ของเน็ตเวิร์กผิดพลาด ให้ทําการ Retry ทันที
Retry after delay กรณีทีการเชือมต่อนันหนาแน่น (busy failures) ให้เว้นช่วงไว้ระยะหนึงก่อนเริมทําการ Retry
ใหม่อีกครัง
เมือเกิด Request Failed เราสามารถทําการ Retry ได้โดยอาจจะทําการ Retry ซํา ๆ ได้จนกว่าจะถึงจํานวนครังสูงสุดทีตัง
ค่าไว้ นอกจากนีในแต่ละรอบของการ Retry เราอาจจะมีการตังค่า delay ทีเหมาะสมโดยพิจารณาจากประเภทของข้อผิด
พลาดทีเกิดขึน delay ในแต่ละรอบนันอาจเพิมค่าขึนเรือย ๆ แบบ exponential ได้

Babel Coder
Babel Coder
FALLBACKS
การทํางานของเซอร์วิส A ทีต้องเรียกต่อไปยังเซอร์วิสอืนเช่นเซอร์วิส B กรณีเช่นนีเราถือว่าเซอร์วิส B เปน dependency
ของเซอร์วิส A
กรณีที dependency ของเซอร์วิสล้มเหลวในการทํางาน เราสามารถดําเนินการตามทางเลือกได้ต่อไปนี
Graceful Degradation
Caching
Functional Redundancy
Stubbed Data

Babel Coder
Babel Coder
Order Payment
GRACEFUL DEGRADATION
สมมติให้ Order Service จําเปนต้องอาศัยข้อมูลจาก Payment Service เพือเติมเต็มข้อมูลทีเกียวข้องกับการจ่ายเงิน
เมือ Payment Service ไม่สามารถทํางานได้จึงไม่มีข้อมูลส่วนนีในการแสดงผล กรณีเช่นนีเราสามารถลดขันของการแสดง
ผลให้เหมาะสมและเปนประโยชน์สูงสุดต่อผู้ใช้งาน เช่น งดแสดงส่วนของวิธีการชําระเงินแต่แสดงรายละเอียดยอดเงินทีมี
ข้อมูลอยู่แล้วแทน
Order Summary
Product A:
Qty: 1
Price: 200
Payment
Total Price: 200 THB

Babel Coder
Babel Coder
CACHING
กรณีทีข้อมูลจากเซอร์วิสเปนสิงทีไม่จําเปนต้องถูกต้อง 100% หากเซอร์วิสผู้เปนเจ้าของข้อมูลไม่สามารถทํางานได้ เรา
สามารถนําข้อมูลจากแคชมาแสดงผลแทนได้ เช่น กรณีของข้อมูลความคิดเห็นเปนข้อมูลทีไม่จําเปนต้องแม่นยําสูงสุดจึง
สามารถนําข้อมูลแคชมาใช้แสดงผลชัวคราวก่อนได้ เมือเซอร์วิสกลับมาทํางานอีกครังจึงนําข้อมูลจากเซอร์วิสมาแสดงผลทับ
Comments
Babel Coder
Comment#1
Babel Coder
Comment#2
Order
Cache

Babel Coder
Babel Coder
Exchange
FUNCTIONAL REDUNDANCY
กรณีทีเซอร์วิสทีต้องการข้อมูลไม่สามารถตอบสนองการทํางานได้ หากเรามีทางเลือกอืน เช่น มีเซอร์วิสอืนทีสามารถร้องขอ
ข้อมูลแบบเดียวกันได้ ให้ทําการเรียกใช้เซอร์วิสนันเปนการชัวคราว เช่น กรณีทีเซอร์วิส Exchange ไม่ทํางาน เราสามารถ
ร้องขอข้อมูลหุ้นจาก SET โดยตรงได้
Stock Exchange
SET

Babel Coder
Babel Coder
STUBBED DATA
กรณีทีข้อมูลนันไม่จําเปนต้องแม่นยํามากนัก และเราไม่มีข้อมูลแคชทีเคยจัดเก็บมาก่อน เราสามารถอาศัยข้อมูลใกล้เคียงมา
แสดงผลเปนการชัวคราวก่อนได้ เช่น ระบบแนะนําหนังสือ กรณีทีเซอร์วิส Recommendation ไม่สามารถทํางานได้อย่าง
ถูกต้องเฉพาะสําหรับบางผู้ใช้งาน เราอาจนํารายการแนะนําแบบทัวไปมาใช้เปนการชัวคราวกับกลุ่มของผู้ใช้งานทีมีปญหาก่อน
ได้ เมือเซอร์วิสกลับมาทํางานอย่างถูกต้องจึงทําการอัพเดทผลลัพธ์อีกครัง

Babel Coder
Babel Coder
TIMEOUTS
ข้อผิดพลาดบางประการเปนข้อผิดพลาดทีรับรู้ได้ช้า เช่น เมือเซอร์วิสหนึงทีการใช้งานมากทําให้ร้องรับการร้องขอได้ช้า เมือมี
การร้องขอข้อมูลจากเซอร์วิสดังกล่าวเราจึงต้องทําการกําหนด Timeout เพือไม่ให้ต้องรอคอยผลลัพธ์ทีนานเกินไป

Babel Coder
Babel Coder
CIRCUIT BREAKERS
สถานการณ์ทีเซอร์วิสมีข้อผิดพลาดชัวคราวหรือเข้าถึงไม่ได้ชัวคราว เราสามารถใช้รูปแบบของ Retry เพือร้องขอซําโดยคาด
หวังไว้ว่าสุดท้ายการทํางานจะกลับมาเปนปกติ
อย่างไรก็ตามความผิดพลาดบางประเภทเปนแบบระยะยาวหรือถาวร การพยายาม Retry ซําในหลาย ๆ ครังจึงไม่เกิดประโยชน์
เราจึงต้องอาศัยรูปแบบการจัดการใหม่ทีเรียกว่า Circuit Breakers

Babel Coder
Babel Coder
Request
Circuit
Open?
CIRCUIT BREAKERS
Make Request to
Service
Success?
Response Fallback
Threshold
Exceeded?
Open Circuit
Yes
Report Metrics
Closed
Open
No Yes

Babel Coder
Babel Coder
CIRCUIT BREAKERS
เมือ Circuit อยู่ในสถานะ Open เราคงไม่ต้องการให้มันอยู่ในสถานะแบบนีตลอดไป เพราะเมือใดทีเซอร์วิสกลับมาใช้งานได้
ตามปกติสถานะของ Circuit ทีถูกต้องควรจะเปนสถานะ Close ด้วยเหตุนีเมือ Circuit อยู่ในสถานะ Open เราจึงควร
ทดลองส่ง Request เพือไปตรวจสอบการทํางานของเซอร์วิสปลายทาง ในจังหวะนีเรากล่าวได้ว่า Circuit อยู่ในสถานะ Half
Open เมือผลลัพธ์ของการทดสอบผ่าน Circuit จะกลับสู่สถานะ Close และจะยังคงอยู่ในสถานะ Open เมือการทดสอบ
นันล้มเหลว

Babel Coder
Babel Coder
RATE LIMITS
เซอร์วิสหนึง ๆ สามารถรองรับจํานวน Request ได้แตกต่างกัน เพือให้การทํางานของเซอร์วิสยังคงดํารงอยู่ได้อย่างเปนสุข
เราจึงควรกําหนดจํานวนการเข้าถึงผ่านการตังค่า Rate Limits การกระทําเช่นนีจะช่วยปองกันไม่ให้เซอร์วิสล้มเหลวในการ
ทํางานอันจะนําไปสู่ Cascading Failure ได้ในอนาคต

Nest.js Microservices.pdfNest.js Microservices.pdfNest.js Microservices.pdfNest.js Microservices.pdfNest.js Microservices.pdfNest.js Microservices.pdfNest.js Microservices.pdfNest.js Microservices.pdf

More Related Content

Similar to Nest.js Microservices.pdfNest.js Microservices.pdfNest.js Microservices.pdfNest.js Microservices.pdfNest.js Microservices.pdfNest.js Microservices.pdfNest.js Microservices.pdfNest.js Microservices.pdf

More from NuttavutThongjor1

Nest.js Microservices.pdfNest.js Microservices.pdfNest.js Microservices.pdfNest.js Microservices.pdfNest.js Microservices.pdfNest.js Microservices.pdfNest.js Microservices.pdfNest.js Microservices.pdf