Image may be NSFW.
Clik here to view.
Clik here to view.

เหตุผลสำหรับการนำ Microservices มาใช้
1. เรื่องของการพูดคุยที่เยอะเกินไป ในการพัฒนาระบบนั้น พบว่า เมื่อต้องเริ่มต้นพัฒนา เมื่อต้องเพิ่ม feature เข้าไปยังระบบ เมื่อต้องแก้ไขระบบ สิ่งที่เกิดขึ้นคือ ต้องพูดคุย ประชุมกับหลายทีมมากมาย ดังนั้นกว่าจะได้เริ่มพัฒนา ต้องใช้เวลาสูงมาก ยิ่งเมื่อพัฒนาปัญหาก็เยอะมาก ปรับเปลี่ยนสิ่งใด จะยากมาก ๆ 2. การ deploy ระบบงานทุกครั้ง ใช้เวลา และ มีความเสี่ยงสูงทุกครั้ง เมื่อเกิดความกลัวแล้ว สิ่งที่ตามมาคือ ความระมัดระวัง ทั้งการเพิ่มขั้นตอนที่มากมาย ทั้งเวลาที่ใช้เยอะมาก ๆ ผลที่ตามมาคือ ระบบไม่สามารถใช้งานได้ นั่นคือผลกระทบต่อผู้ใช้และธุรกิจอีกด้วย 3. เจอข้อจำกัดของ infrastructure และภาษาโปรแกรม ยิ่งระบบมีขนาดใหญ่ขึ้น ปัญหาที่ตามมาคือ infrastructure ที่มีอยู่ไม่สามารถรองรับได้หรือถึงขีดจำกัด สิ่งที่ต้องทำคือ ขยายนั่นเอง ทำให้ต้องใช้ค่าใช้จ่ายที่สูงมาก ๆ รวมไปถึงภาษาโปรแกรมหรือเทคโนโลยีที่ใช้งานอีกด้วย เช่น ถ้าระบบเดิมคือภาษา Ruby นั้น เริ่มรองรับจำนวนผู้ใช้งานได้ช้าลง การจะเปลี่ยนไปใช้ภาษา Go หรือ NodeJS น่าจะดีกว่า แต่ก็ทำไม่ได้ หรือ ยากมาก ๆจากปัญหาต่าง ๆ เหล่านี้ จึงทำให้ทางทีมพัฒนานั้น เริ่มคิดและหาวิธีแก้ไข หนึ่งในนั้นคือ การแบ่งระบบงานใหญ่ ๆ ออกมาเป็นระบบหรือ service ย่อย ๆ ที่เราเรียกกันว่า Microservice นั่นเองปล. ถ้ายังไม่มีปัญหาเหล่านี้ ก็ให้พิจารณากันหน่อยนะ
มาดูวิธีการแก้ไขปัญหากันดูว่าเป็นอย่างไรบ้าง ?
แน่นอนว่า เริ่มด้วยการแยก service บางตัวออกมาก่อน แต่การแยกเป็น service ย่อย ๆ ทั้งระบบเลยก็ไม่ได้ เพราะว่า จะมีปัญหาต่าง ๆ มากมายให้แก้ไข ซึ่งนรกมาก ๆ ยังไม่พอนะ ปัญหาที่ตามมาคือ เมื่อแยก service ออกมาแล้ว การติดต่อสื่อสารระหว่างระบบเดิมกับ service เล็ก ๆ ต้องทำอย่างไร ? ในระบบนี้มีความต้องการดังนี้ ทำงานแบบ real time ดังนั้นถ้ามีข้อมูลเปลี่ยนแปลง ส่วนต่าง ๆ ที่เกี่ยวข้องต้องทำงานด้วย แต่ไม่ต้องการให้แต่ละส่วนงานต่าง ๆ ยึดติดกันเกินไป (Decouple หรือ Loose coupling) จึงเลือกใช้งานการติดต่อกันแบบ Asynchronous แน่นอนว่าต้องมีคนกลางสำหรับการติดต่อกัน (Messaging) คำถามคือ ต้องใช้อะไรเป็นตัวกลางในการติดต่อกัน เช่น ActiveMQ, RabbitMQ และ Apache Kafka ทางทีมพัฒนานั้นเลือกใช้ Apache Kafka (ในบทความเป็น service บน Heruku นะ เพื่อลดปัญหาในการดูแลรักษาระบบเอง)มาดูขั้นตอนการย้ายระบบกันบ้าง
ทำการย้ายแบบค่อยเป็นค่อยไป ไม่ทำแบบ big bang เนื่องจากมีความเสี่ยงสูงมาก ๆ โดยประกอบไปด้วย 8 ขั้นตอนดังนี้ ขั้นตอนที่ 1 สร้าง Producer logic ในฝั่งของระบบเดิม เริ่มด้วยการเพิ่ม code ในระบบเดิม ทำหน้าที่ส่ง event หรือการเปลี่ยนแปลงต่าง ๆ ไปยังตัวกลางคือ Apache Kafka Image may be NSFW.Clik here to view.

Clik here to view.

Clik here to view.

Clik here to view.

Clik here to view.

เมื่อทำงานครบทั้ง 8 ขั้นตอน ก็จะทำให้เราสามารถแยก service ออกมาจากระบบเดิมได้แบบปลอดภัยแล้วนะโดยสิ่งที่ทางทีมพัฒนาได้รับจากการเปลี่ยนแปลงประกอบไปด้วย
- Deploy และ Release ได้บ่อยขึ้น
- ลดปัญหาเรื่อง I/O Latency จากการเรียกผ่าน API
- ความพึงพอใจของผู้ใช้งานเพิ่มขึ้น
คำถามที่น่าสนใจ ทำไมเราถึงนำแนวคิดของ Microservices มาใช้งาน ?