มีคำถามบ่อยๆที่เจอมา ว่า Microservices คืออะไร บางทีก็กางแบบมาให้ดูว่า สิ่งที่ทำ เรียกว่า Microservies หรือเปล่า เลยขอสรุปบล็อกไว้นิดนึง
Microservices คืออะไร
ถ้าเราจะต้องออกแบบระบบ หรือไปสังเกตว่าระบบไหนเป็น Microservices สามารถสังเกตจากคุณลักษณะ 6 ข้อ ของมันได้ดังต่อไปนี้
A microservice is responsible for a single piece of functionality
มีหน้าที่ในทำงานเพียงแค่อย่างเดียว ซึ่งการจะเขียน Services เพื่อแบ่งหน้าที่การทำงานได้ จะต้องศึกษาถึงขอบเขตของ Services (Type of Capability) ว่าจะแบ่งด้วยหลักเกณฑ์ใด โดย หลักๆ มีสองประเภท คือ
- A Business Capabilitiy : แบ่งตามจุดมุ่งหมายของ Business เช่น ทำมาเพื่อคำนวณราคาสินค้า, ทำเพื่อเก็บข้อมูลลูกค้าที่ใช้งาน Shopping Cart เป็นต้น โดยการแบ่งตามนี้ มักใช้แนวทางของ DDD (Domain-Driven Development) เข้ามาช่วย
- A Technical Capability : แบ่งตาม Technology ที่ถูกกำหนดขึ้น เช่น มี Services อื่นต้องการใช้งานกับ Services ของเรา และมีข้อจำกัดบางอย่าง ดังน้ัน ต้องออกแบบ Services ให้ทำงานร่วมกันได้
A microservice is individually deployable
มีอิสระต่อกัน ไม่ผูกพันกับส่วนอื่นๆ สามารถอยู่ได้ด้วยตัวเอง ถ้า Service ตัวหนึ่งพัง หรือปิดลง ตัวอื่นจะต้องไม่พังตามไปด้วย ดังนั้นการ Deploy จะเป็นอิสระจากระบบอื่นๆ ด้วย
ยิ่งการ Deploy เป็นก้อนใหญ่มาก ความเสี่ยงที่เกิดกับระบบก็จะมีมากขึ้น ดังนั้น ถ้าจะให้เป็นตามหลักการนี้ จะต้องคำนึงถึงการออกแบบให้เล็กพอที่จะไม่กระทบกับส่วนอื่นๆ และสามารถเปลี่ยนแปลงได้เรื่อยๆ
A microservice consists of one or more processes
ใน Microservices สามารถมีได้หลาย Process แต่ว่า จะต้องไม่ไปเกี่ยวกับ Process ของ Services ตัวอื่นๆ เช่น ระบบ Shopping Cart กับ Product Category จะต้องไม่มี Process การทำงานที่ไปเกี่ยวข้อง ดังนั้น ถ้ามันผูกกันอยู่ และเราต้องการ Deploy Shopping Cart ใหม่ เราจำเป็นต้อง Deploy Product Category ด้วย ทั้งๆที่มันไม่ได้ถูกแก้ไข
A microservice owns its own data store.
มีจัดเก็บข้อมูล (Data) เป็นของตนเอง ดังนั้น ถ้า Services แต่ละตัวต้องการใช้ข้อมูลของ Services อื่นๆ จะต้องเรียกผ่าน API ของ Services นั้น จะไม่เรียกตรงไปที่ Database เพราะ ถ้าในแต่ละ Microservices สามารถใช้เทคโนโลยี Database ต่างกันได้ และก็มีโอกาสที่จะเกิดเปลี่ยนแปลงภายหลังได้ ดังนั้น ถ้า Database มีการแก้ไขเกิดขึ้น ตัว API Service ที่เรียกใช้ จะต้องแก้ตามไปด้วย และอีกเหตุผลหนึ่งคือ ส่วนของ Database มักต้องควบคุมเรื่อง Performance และ Scalability ที่จะเกิดขึ้นได้ตลอดเวลา ดังนั้น ถ้ามีส่วนอื่นๆมาเกี่ยวข้องด้วย จะทำให้ควบคุมการใช้งานได้ยาก
A small team can maintain a handful of microservices.
ทีมเล็กๆ ก็สามารถดูแลรักษา Microservices ตัวหนึ่งๆได้ สามารถใช้ภาษาเขียนหรือเทคโนโลยีตามที่ทีมถนัดได้ เพราะแต่ละ Services แยกออกจากกัน
ถามว่าทีมเล็กๆที่ว่าควรเป็นเท่าไร คือ ประมาณ 5 คน
A microservice is replaceable.
จะต้องถูกออกแบบมาให้ทดแทนได้ เพราะบางที Requirement เปลี่ยน หรือมีเทคโนโลยีที่เหมาะสมใหม่เข้ามา เช่น ภาษาที่ใช้เขียน, Database ทีมที่พัฒนาจะใช้เวลาเท่าเดิมหรือเวลาที่เหมาะสม ในการพัฒนาใหม่ เพื่อนำไปใช้ทดแทนของเดิมได้ทันที
หน้าตาของโครงสร้าง Microservices
ถ้าอธิบายด้วยรูป เทียบกับการออกแบบแบบเดิม กับ Microservices
(ภาพจาก https://www.packtpub.com/)
(ภาพจาก https://www.packtpub.com/)
ดังนั้น ถ้าสมมติว่าเราได้แตก Services ออกมา และมีหลาย Services เชื่อมโยงกัน ภาพจะได้ประมาณนี้
(ภาพจาก https://www.nginx.com/)
ทำไมเราต้องใช้ Microservices
พอเข้าใจและเห็นภาพของ Microservices กันบ้างแล้ว คำถามต่อมาคือ แล้วทำไมต้องใช้ หรือทำแล้วจะได้อะไร?
จาก คุณลักษณะ Microservices 6 ข้อ ข้างต้นที่ว่ามา จะทำให้เกิดผล 3 ข้อ ดังนี้
- Malleable: พลิกแพลงระบบได้ง่าย (ระบบมี Flexible ยืดหยุ่น)
- Scalable : สามารถขยายออกได้ (หรือมีความ Elastic หดเข้าขยายออกได้ง่าย )
- Resilient : ตายไม่เป็น หรือเรียกกลับคืนได้ไว
ถ้ามองให้เห็นภาพว่า 3 ข้อดังกล่าว จะให้ประโยชน์อะไรกับเราได้บ้าง คือ
Enable continuous delivery
ไม่ใช่ว่าทำ CI/CD แล้วจะต้องทำ Microservices นะครับ แต่หมายถึง มันสอดคล้องกัน ทำให้เราสามารถใช้กระบวนการ CI/CD (Continuouse Integration/Continuouse Delivery) ได้ง่ายขึ้น เพราะ
- พัฒนาระบบและแก้ไขได้ไว (ก็มันเล็กนี่นะ)
- ทดสอบได้ด้วยการทำ automated tests (เพราะเล็ก ทดสอบการทำงานแค่อย่างเดียว ไม่ซับซ้อน)
- Deploy ได้อย่างอิสระ
- Operate ได้อย่างมีประสิทธิภาพ
ดังนั้นถ้าสอดคล้องกับการทำ CI/CD แล้ว สิ่งที่เป็นประโยชน์ตามมาในระดับ Business คือ
- เพิ่มความเป็น Agility ให้เกิดขึ้น เพราะยืดหยุ่นและส่งมอบ product ได้ไวขึ้น
- ทำให้ระบบน่าเชื่อถือขึ้น
- ลดความเสี่ยง
- และทำให้ product มีประสิทธิภาพมาขึ้น
High level of maintainability
มีสองมุมมองคือ
มุมมองของ Developer
- ทำงานเพียงหนึ่งเดียว ง่ายต่อการพัฒนาและดูแล
- เก็บข้อมูล (Data) ไว้ที่ตัวเอง และมีการกระทำจากแค่ภายใน Service ตนเอง ทำให้ง่ายต่อการเข้าใจระบบ
- สามารถทำ Automated Test ได้ง่าย เพราะมี Process ทำงานเพียงเรื่องเดียว
อีกมุมคือ มุมมองของ Operatios
- สามารถดูแลได้ด้วยทีมขนาดเล็ก
- ง่ายต่อการ Monitor การทำงานของแต่ละ Service
- มีการ Deploy ที่เป็นอิสระจากกัน
Robust and scalable
Microservices ง่ายต่อการขยาย เพราะเป็นอิสระต่อกัน ดังนั้น ถ้า Services ตัวใดต้องการขยายให้มีขนาดใหญ่ขึ้น(หรือเล็กลง) สามารถทำได้เฉพาะ Services นั้น ไม่จำเป็นต้องทำทั้งระบบ ประหยัดทรัพยากรได้ทางอ้อมด้วย
—
หลังจากได้รู้จัก Microservices ไปแล้ว ยังอยากทำอยู่หรือเปล่าครับ?
อ้างอิง
ขอบคุณครับ … เห็นภาพชัดเจนเลย