เห็นเอกสารเรื่อง Top 6 Microservices patterns จาก MuleSoft ออกมา
เป็นการแนะนำ 6 แบบของ Microservices ที่มักถูกนำมาใช้งาน
และดูเหมือนจะเป็นรูปแบบที่เกิดขึ้นในองค์กร IT ที่เป็น enterprise เสียด้วย
จึงทำการสรุปไว้นิดหน่อย
ในแต่ละองค์กรมี culture มีเป้าหมาย มีความวุ่นวายที่แตกต่างกัน
การจะนำรูปแบบความสำเร็จจากที่หนึ่งไปอีกที่หนึ่ง มันไม่จริงเลย
ดังนั้นด้วยแนวคิดของ Microservices คือ
ค่อย ๆ สร้าง เรียนรู้และปรับปรุงอย่างต่อเนื่อง
โดยมักจะมีรูปแบบหรือแนวทางที่คล้าย ๆ กัน
ทาง MuleSoft จึงทำการสรุปออกแบบได้ 6 รูปแบบ
แน่นอนว่าแต่ละรูปแบบมีทั้งข้อดีและข้อเสีย
มีอะไรบ้างมาดูกัน
แบ่งเป็น 2 กลุ่มใหญ่ ๆ คือ
กลุ่มที่หนึ่ง เรื่องของการแยกออกเป็น service เล็ก ๆ
รูปแบบที่ 1 Fine-grained SOA
เป็นรูปแบบในการแบ่งแยก service ตามแนวคิดของ SOA
ซึ่งเป็นแนวทางที่ช่วยทำให้คนที่มีประสบการณ์กับ SOA มาแล้วเข้าใจได้ง่ายขึ้น
เพราะว่า มันคือการแยกเป็น service ย่อย ๆ
บางคนคิดว่าการแยกเป็น service ย่อย ๆ ต้องเป็น Microservices สิ
แนวคิดนี้ไม่ใช่นะ
การแยกเป็น service ย่อย ๆ ก็ทำให้เกิดปัญหาใหม่ ๆ ขึ้นมา
เช่นการติดต่อสื่อสารการระหว่าง service และการ monitoring ระบบ
ที่มาของรูปแบบนี้คือ
แต่ละ service มีขนาดใหญ่หรือหน้าที่รับผิดชอบเยอะเกินไป
ยากต่อการเปลี่ยนแปลง และเลี่ยงไม่ได้ที่จะเกิดผลกระทบ
บางครั้งเรียกระบบนี้ว่า Big bang microservices
แสดงดังรูป
รูปแบบที่ 2 Layered APIs overfine-grained SOA
จากรูปแบบที่ 1 จะแบ่งกลุ่มการทำงานในรูปแบบ Layer คือ
- System Layer
- Process/Domain Layer
- Experience Layer
แต่ละ layer จะทำการ expose API ออกมา เพื่อให้ส่วนอื่น ๆ เข้าใช้งาน
รูปแบบนี้เป็นที่มาของ MuleSoft เลยก็ว่าได้
ทำให้สามารถจัดกลุ่มและจัดการ service ได้ง่ายขึ้น
แต่ก็ทำให้แต่ละ layer ต้องมีเรื่องของการทำงานร่วมกัน integration
ซึ่งจะลดเรื่องของ speed of change ลงไปอีก
แสดงดังรูป
กลุ่มที่สอง เรื่องของการจัดการ state
รูปแบบที่ 3 Message-oriented state management over layered APIs
จากในรูปแบบที่สองนั้น แต่ละ Layer จะมีการติดต่อผ่าน API ที่กำหนดไว้
ซึ่งมักจะมีปัญหาเรื่อง side-effect หรือผลกระทบที่เกิดขึ้นจากการเปลี่ยนแปลงใน layer ต่าง ๆ
เนื่องจากต้องติดต่อสื่อสารกัน
ดังนั้นวิธีการนี้จึงใช้การติดต่อสื่อสารแบบ asynchronous
โดยทุก ๆ การทำงานทั้ง event และ command ต่าง ๆ จะถูกส่งมายังตัวกลาง
ซึ่งมักจะใช้ queue เป็นตัวพื้นฐาน
จากนั้น service ต่าง ๆ ก็ต้องทำงานตาม event หรือ command นั้น ๆ
ถ้าในสายของ SOA จะเข้าใจดีในชื่อ ESB (Enterprise Service Bus)
แต่ปัญหาที่ตามมาคือ ระบบมีความซับซ้อนมากขึ้น ก็แน่ละ
ถ้าเกิดข้อขัดแย้งต่าง ๆ หรือการทำงานผิดพลาด
สามารถที่จะทำงานซ้ำใหม่หรือ rebuild/replay หรือ rollback ได้อย่างไร ?
รูปแบบที่ 4 Event-driven state management over layered APIs
ในรูปแบบนี้เริ่มต้นก็เหมือนกับรูปแบบที่ 3 แต่เพิ่มเติมคือ
การกำหนดมาตรฐานของ event ที่สร้างขึ้นมา
โดยแต่ละ event จะมีข้อมูลที่เกี่ยวข้องกับ state การทำงานนั้น
มี timestamp เพื่อระบุเวลาที่เกิดขึ้น
ทำให้แต่ละ event มีลำดับการทำงานที่ชัดเจน
ช่วยทำให้เมื่อเกิดปัญหาขึ้นมา
เราสามารถ replay หรือ rollback ได้ง่ายขึ้น
แต่แนวคิดนี้ยังทำให้เกิดความสับสนระหว่าง event กับ command
โดยที่
event คือสิ่งที่เกิดขึ้นแล้ว
ส่วน command คือคำสั่งที่ทำให้เกิดบางอย่างขึ้นมา
อีกทั้งยังมีปัญหาเรื่องของ data consistency หรือความถูกต้องของข้อมูล
รูปแบบที่ 5 Isolating state in layered APIs
เนื่องจากการติดต่อแบบ asynchronous และการใช้ messaging queue
ทำให้เกิดปัญหาเรื่อง data consistency
ดังนั้นเราแก้ไขปัญหาง่าย ๆ ด้วยการแยกเก็บ state หรือข้อมูลตามแต่ละ layer ไปเลยสิ ไม่ต้องมา share หรือส่ง event/command ไปมา ให้เสียเวลา
แต่ต้องทำให้มั่นใจว่า ข้อมูลไม่ถูก copy ไปที่ส่วนอื่นนะ
มิเช่นนั้น เรื่องการ sync ข้อมูลจะหนักเอาการแน่ ๆ
รูปแบบที่ 6 Replicating state in layered APIs (Event sourcing)
เนื่องจากปัญหาของ data consistency ที่เกิดจากข้อมูลชุดเดียวกันอยู่หลาย ๆ ที่
จึงพยายามจะทำที่จัดเก็บความข้อมูลหรือการเปลี่ยนแปลงไว้ที่เดียว
ในส่วนแต่ละ layer/service ก็ทำการเก็บ caching data เท่าที่จะใช้งาน
เมื่อมีการเปลี่ยนแปลงก็มาจัดเก็บในรูปแบบ event ที่มีมาตรฐานไว้ตรงกลาง
โดย event จะมีคุณสมบัติตามที่กล่าวมาข้างต้น
ไม่สามารถเปลี่ยนแปลงได้
เรียงตามเวลา หรือ timestamp
ซึ่งจะเรียก event เหล่านี้ว่า event sourcing
ส่วนที่จัดเก็บเรียกว่า event store
แสดงดังรูป
ก่อนนำไปใช้งานต้องเข้าใจก่อนว่าในแต่ละ pattern เป็นอย่างไร
เหมาะกับงานประเภทไหน
ในงานที่เราพัฒนาสามารถนำหลาย ๆ pattern มาใช้งานได้เสมอ
ที่สำคัญ Microservices ไม่ได้เหมาะสมกับงานทุก ๆ อย่าง
ยกตัวอย่างเช่น
ระบบงานมีการใช้งาน ERP ทั้งหมดแล้ว
ถ้าต้องการนำแนวคิด Microservices มาใช้
คำถามคือ คุณต้องลบ ERP ทิ้งไปเลยนะ คุณจะทำมันจริง ๆ ไหม ?
คำตอบคือ คิดเอาเองนะ นั่นมันทางที่คุณฯเลือกและต้องเผชิญต่อไป
ลองไป download มาอ่านกันได้ครับ มีเพียง 46 หน้าเท่านั้นเอง
