คืออะไร?

Microservice หรือ Microservice Architecture คือสถาปัตยกรรมการออกแบบ Service หรือก็คือออกแบบซอฟต์แวร์ โดยการที่ในชื่อมีคำว่า Micro นำหน้าอยู่ก็เพราะว่าเป็นการออกแบบที่ทำให้ Service มีขนาดเล็กเพื่อแก้ไขจุดด้อยของสถาปัตยกรรมการออกแบบอื่นๆ ซึ่งตัวอื่นที่ว่าคืออะไร ที่บอกว่าทำให้มีขนาดเล็กเป็นยังไง เราไปดูกันต่อได้เลย

Monolithic VS Microservice

ถ้าจะบอกว่า Microservice เป็นการออกแบบ Service ให้มีขนาดเล็ก การจะเทียบให้เห็นภาพชัดเจนที่สุดก็ต้องเทียบกับ Monolithic 

รูปจาก nsights.daffodilsw.com

• Monolithic เป็นชื่อของสถาปัตยกรรมการออกแบบซอฟต์แวร์หรือ Service ที่มีคนใช้งานเป็นจำนวนมากและมีมาอย่างยาวนาน โดยเป็นลักษณะของระบบที่การทำงานทุกอย่างจะรวมอยู่ในกลุ่มก้อนเดียวกัน และใช้งาน Database เดียวกัน (อย่างในภาพจะเห็นว่าเป็นเว็บไซต์ขายสินค้าที่มีฟังก์ชันจัดการผู้ใช้, ตะกร้าสินค้า และการส่งสินค้า รวมอยู่ด้วยกัน และใช้ฐานข้อมูลเดียวกัน)
• Microservice จะออกแบบโดยแยกการทำงานที่รวมกันเป็นก้อนใหญ่ๆของแบบ Monolithic ออกมาให้เล็กลงโดยอาจจะแยกตามบริการหรือตามฟังก์ชันการทำงานเลยก็ได้ (จากในภาพฟังก์ชันทั้งสามอย่างจะแยกออกจากกัน และไม่ได้ใช้ฐานข้อมูลเดียวกันในการเก็บข้อมูลอีกต่อไป เพราะแต่ละฟังก์ชันหรือบริการที่แยกออกมามีฐานข้อมูลเป็นของตัวเอง และสามารถติดต่อกันได้ผ่าน API )

สรุปแล้ว Monolithic กับ Microservice ต่างกันยังไง ?

• Monolithic นั้นจากการที่ทุกอย่างอยู่รวมกันใช้ฐานข้อมูลเดียวกัน การพัฒนาระบบขึ้นมาจึงเป็นเรื่องง่าย นำไปติดตั้งใช้งานก็ง่ายเพราะระบบทั้งหมดมีอยู่เพียงตัวเดียว แต่ถ้ามีแต่ข้อดีก็คงจะไม่การออกแบบอื่นๆเกิดขึ้นมา Monolithic นั้นเมื่อพัฒนาไประยะหนึ่งจนระบบเริ่มซับซ้อน ฟังก์ชันมีจำนวนมากขึ้น ก็จะทำให้การจะพัฒนาต่อไปเป็นเรื่องยาก เพราะต้องคำนึงนึงฟังก์ชันอื่นๆที่ทำงานร่วมกันอยู่ หรือไม่ก็เป็นเรื่องของฐานข้อมูลที่อาจจะมีฟังก์ชันอื่นๆใช้งานอยู่ ถ้าไปแก้ไขเปลี่ยนแปลงอะไรก็อาจจะกระทบกับส่วนอื่นๆได้ และเรื่องการเปลี่ยนแปลงเทคโนโลยีหรือเครื่องมือที่ใช้ในการพัฒนาก็เป็นเรื่องยาก เพราะถ้าจะเปลี่ยนก็หมายความว่าต้องเปลี่ยนหมดทั้งระบบนั่นเอง
• Microservice สามารถแก้ปัญหาความยุ่งยากและซับซ้อนในระบบขนาดใหญ่ได้ เพราะแบ่งส่วนออกเป็นบริการ (Service) ย่อยๆหลายๆตัว การพัฒนาก็สามารถทำได้ง่ายด้วยการแยกทำทีละส่วนและค่อยทำให้เชื่อมต่อกันได้ผ่าน API ส่วนเรื่องฐานข้อมูลก็ไม่ต้องคอยห่วงว่าจะกระทบกับส่วนอื่นเพราะแต่ละบริการจะมีฐานข้อมูลเป็นของตัวเอง การแยกเป็นบริการย่อยๆแบบนี้ยังทำให้สามารถพัฒนาซอฟแวร์ได้ง่ายและเร็วขึ้นด้วยการแบ่งทีมในการพัฒนาแต่ละส่วน โดยแต่ละทีมก็สามารถเลือกภาษาหรือเครื่องมือในการพัฒนาที่ถนัดได้อย่างอิสระ 

คุณสมบัติที่ดี

คุณสมบัติของ microservice นั้นไม่มีหลักการตายตัว ถ้าดูจากที่อื่นๆ อาจเจอแตกต่างกันออกไปในที่นี้จะสรุปออกเป็น 3 อย่าง

1. เล็กสมชื่อ
   การทำงานหลักแต่ละส่วนของระบบ ถ้าเป็นไปได้ควรแยกออกเป็น service แต่ละอัน เช่นจัดการสินค้า กับจัดการการซื้อสินค้าก็แยกกันไปเลย
2. stand alone
   แต่ละ service สามารถติดตั้งหรือ deploy ได้ด้วยตัวเองไม่ต้องรอ service ตัวอื่นๆ และการทำงานก็ควรที่จะพึ่งพาคนอื่นให้น้อยที่สุด ทำให้เวลาทดสอบ service แต่ละตัวทำได้ง่าย การพัฒนาหรือปรับเปลี่ยนก็ทำง่ายด้วย
3. มีที่เก็บข้อมูลของตัวเอง
   ตอนนี้ service แต่ละอันก็ทำงานแยกกันแล้วแต่ละ service ยังใช้ database รวมอยู่ละก็บอกเลยว่าเสียของสุดๆ เพราะมันจะทำให้ service ไม่อยู่แยกกันอย่างแท้จริง

หลักการวางผังระบบ microservice

อย่างที่เคยอธิบายว่าการทำงานของแต่ละ service นั้นทำงานแยกกันและอยู่ได้ด้วยตัวมันเอง แต่ก็มีปัญหาใหญ่อีกอย่างหนึ่งก็คือข้อมูลที่แต่ละ service ต้องใช้นั้นมักจะเหมือนๆกัน ทำให้ระบบของเราออกมา service นี้ไปเรียกข้อมูลจากตัวนั้น service นี้ไปเรียกจากตัวนู้น ผลก็คือ service จะทำอะไรแต่ละอย่างได้ก็ต้องไปพึ่ง service ตัวอื่นๆ สุดท้ายก็เหมือนไม่ต่างอะไรจากเดิม พอเกิดปัญหาแบบนี้ขึ้นจึงต้องมาแก้ตั้งแต่การวางผังระบบใหม่เพื่อลดปัญหาดังกล่าว แต่ปัญหาต่อมาคือ แล้วควรออกแบบผังระบบยังไงดี?

หลักการออกแบบเพื่อจัดการกับปัญหาลักษณะนี้อยู่ 2 ประการนั่นคือ

• Low Coupling
  ทำให้ service แต่ละตัวทำงานร่วมกับ service อื่นหรือรู้จักกันให้น้อยที่สุด เวลาที่แก้ service ใด service หนึ่งจะได้ไม่กระทบกับ service ที่โยงอยู่
• High Cohesion
  จัดกลุ่มการทำงานที่ใกล้เคียงกันใช้ข้อมูลเหมือนกัน ให้เป็น service เดียวกัน เพื่อให้ service นั้นมีข้อมูลที่จำเป็นให้มากที่สุดในตัวมันเอง เพื่อที่จะได้ติดต่อกับ service อื่นน้อยๆ

Microservice ในการใช้งานจริง

พอเราได้รู้จักกับ Microservice กันมาสักเล็กน้อยแล้ว ก็จะเห็นว่าสิ่งที่สำคัญมากๆเลยก็คือการวางแผนออกแบบ Service ของเราให้มีคุณสมบัติต่างๆครบถ้วนตามที่ควรจะมี เพื่อให้ได้รับประโยชน์จากการใช้งาน service มากที่สุด ส่วนในเรื่องของการเลือกภาษาหรือเครื่องมือมาใช้ในการพัฒนาก็มีความยืดหยุ่น สามารถเลือกใช้ได้ตามความถนัดหรือความเหมาะสมในแต่ละ Service ดังนั้นจึงขอแนะนำให้รู้จักกับสองสิ่งที่จะเป็นประโยชน์ในการพัฒนาจริง ได้แก่

API
ชื่อเต็มๆก็คือ Application Program Interface เป็นช่องทางที่ทำไว้เพื่อให้สามารถเชื่อมต่อกับโปรแกรมหรือระบบได้ ใน service ที่ระบบหรือบริการแต่ละตัวแยกจากกันและทำงานด้วยตัวเอง และมีการติดต่อแลกเปลี่ยนข้อมูลกัน ซึ่งวิธีที่จะติดต่อกันก็ทำได้ผ่าน API โดยแต่ละ service จะต้องสร้าง API เพื่อให้ service อื่นๆสามารถติดต่อได้ ยิ่งระบบมีขนาดใหญ่หรือมี service มากๆจำนวน API ที่มีไว้ใช้งานก็ยิ่งมากตาม ดังนั้นจึงต้องวางแผนในการใช้งาน API ทั้งหมดให้ดี เพื่อลดโอกาสที่จะเกิดความซ้ำซ้อนของ API ภายในระบบ ซึ่งเทคโนโลยีหรือเครื่องมือที่จะใช้ก็ควรจะไม่ผูกขาดกับภาษาใดภาษาหนึ่งอย่างเช่น REST เป็นต้น

Container
เป็นเทคโนโลยีที่ทำให้เราสามาถนำ service ของเราไปใช้งานได้ง่ายยิ่งขึ้น โดยสามาถสร้างสภาพแวดล้อมการทำงานที่แยกออกมาเฉพาะของแต่ละ service โดยสามารถติดตั้งใช้งาน แก้ไข หรือจัดการ service จำนวนมากๆได้ง่าย ตัวอย่างเครื่องมือจัดการเช่น Docker

สรุปแล้วต้องเปลี่ยนไปใช้ Microserviceใช่มั้ย ?

ถ้าอ่านบทความนี้จนจบก็อาจมีบางคนคิดว่าจะต้องเปลี่ยนไปใช้ถึงจะดีใช่มั้ย แต่ทุกๆอย่างมันมีข้อดีก็ต้องมีข้อเสียเช่นกัน การที่เราลดความใหญ่ของระบบโดยรวม แล้วไปย่อยเป็นหลายๆ service เล็กๆ มันทำให้เกิดภาระงานที่ตามมาก็คือ ในการจัดการให้ service ทั้งหมดทำงานร่วมกันได้สมบูรณ์ ในการที่แต่ละตัวจะต้องมีสภาพแวดล้อมในการทำงานของตัวเองแยกต่างหาก การที่ต้องออกแบบและวางแผนการติดต่อกันผ่าน API หรือกระทั่งการจะติดตั้ง service ให้ครบทุกตัว ทั้งหมดนี้คือภาระงานที่เพิ่มขึ้นจากการที่เราจะเลือกใช้ ดังนั้นก่อนจะตัดสินใจใช้งาน ก็ลองคิดทบทวนกันให้ดีๆว่าการเปลี่ยนมาใช้นั้นเราจะได้ประโยชน์หรือได้งานมาเพิ่มมากกว่ากัน สุดท้ายแล้วก็ขอให้ทุกคนมีความสุขกับการใช้ service ขนาดจิ๋วนี้ นะครับ