[บันทึก] การเข้าร่วมในคลาส Microservice ของพี่ปุ๋ย วันที่ 3/3
สวัสดีครับผม วันนี้เป็นวันสุดท้ายแล้วของคลาส Microservice ของพี่ปุ๋ยครับผม
เนื้อหาตอนเช้า พี่ปุ๋ยพามาดูวิวัฒนาการของ Microservice ตั้งแต่ยุคแรกเริ่ม
พี่ปุ๋ยพานับเป็น Microservice 1.0 ไปจนถึง 4.0
โดยใน Microservice ในยุคหลัง ๆ นี่มีเทคโนโลยีมากมายที่เกิดมาเพื่อสนับสนุนแนวคิดของ Microservice โดยหัวใจหลักที่ส่งผลอย่างมากในยุคนี้เลยคือเทคโนโลยี Container ซึ่งจะส่งผลให้ Service
เกิด ขึ้นมาเพิ่มเริ่มต้นทำงานได้เร็ว
สามารถ ตาย จากไปและ เกิดขึ้นมาใหม่ ได้ง่ายด้วย
ซึ่งในประโยคนี้จะเป็นหัวข้อเกี่ยวกับพวก
Graceful Shutdown และ Service Recovery ครับ
Service ที่พังแล้วฟื้นตัวเองได้ดูเผิน ๆ อาจจะคิดว่าดีแต่จริง ๆ
แล้วควรจะทำให้มันไม่พังจะดีกว่า
นอกจากนี้ยังรวมถึง Service สามารถทำการ Scale ได้ง่ายขึ้นมาก ๆ ในโลกของ Container
Microservice Testing
ตรงนี้พี่ปุ่ยอิงตามรูปแบบการทดสอบ Microservice ของ Matin Fowler เลยครับ
โดยเริ่มตั้งแต่
Unit Test — ระบุจุดของการทดสอบว่าอยู่ในชั้นไหนใน Service เราโดยแบ่งประเภทของ Unit Test เป็น 2 ประเภทก็คือแบบ
Solitary และแบบ Sociable
Integration Test — อันนี้พี่คุยแซวไว้ว่า ให้คุยกันดี ๆ นะว่าคำว่า Integration Test ของแต่ละคนเหมือนกันไหม (เพราะอย่างเช่นในการพัฒนาตามรูปแบบของ Monolith จะใช้คำว่า Integration สำหรับการการทำงานร่วมกันของหลายส่วนภายในระบบเดียวกัน) พี่ปุ๋ยให้คำนิยามว่าเป็นการทดสอบตะเข็บชายแดนของระบบเรา มันคือการทดสอบส่วนที่ต้องเชื่อมต่อไปยังระบบอื่นนั่นเองครับ
Component Test — คำนิยามของการทดสอบนี้คือ การทดสอบภายในประเทศ ที่มีจังหวัด อำเภอ ตำบลมาทำงานร่วมกันทั้งหมด แต่ก็ยังเป็นแค่ภายในประเทศอยู่นะ ยังไม่มีการเชื่อมต่อไปยังระบบภายนอก แต่จะจำลองเอาไว้ก่อนเพื่อให้ทดสอบภายในได้
Contract Test — ตามชื่อของการทดสอบเลยครับ มันคือการเช็คสัญญาของระบบเราและระบบภายนอก
อธิบายเพิ่มเติมคือ ใน Service ที่ให้บริการแล้วมีผู้รับบริการเป็น Service ภายนอก ต้องมีการทดสอบว่าตั้งสอง Service ยังสามารถทำงานร่วมกันได้อยู่ เกิดเป็น Contract ระหว่างฝ่าย Consumer และ Provider นั่นเอง
End-to-End Test — การทดสอบในมุมมองการใช้งานจริง โดยทดสอบกับระบบที่ทำงานเหมือนกับ Production เลยเพื่อทดสอบว่าระบบทำงานได้ตามที่ต้องการจริง ๆ
ไม่ว่าจะเป็นการทดสอบแบบไหน การทดสอบนั้นต้องสามารถทดสอบซ้ำได้
การทดสอบต้องได้ผลลัพธ์ที่เหมือนเดิมตลอด
จึงทำให้การจัดการข้อมูล ที่เกี่ยวข้องกับการทดสอบนั้นสำคัญมากเช่นกัน
การทดสอบในจุดนี้จะใช้เครื่องมือที่แตกต่างกันไป และต้องทำให้เป็น Automate และสามารถทดสอบซ้ำได้ เพื่อที่ว่าลดงานของเหล่า Tester แล้วให้ไปโฟกัสกับงาน Test ในจุดอื่นที่มีประโยชน์กว่าแทน
Continuous Delivery / Continuous Integration
พี่ปุ๋ยยกภาพมาอธิบายไว้ก็คือ ใน Pipeline(Build-Test-Deploy) ของการส่งมอบของเรานั้นจะต้องเกิดอะไรขึ้นบ้าง โดยไล่ตั้งแต่จากฝั่ง Source Code บนเครื่องของ Developer จะต้องผ่านขั้นตอนต่าง ๆ ตามภาพครับ
ซึ่งตรงนี้พี่ปุ๋ยได้เอาเครื่องมือต่าง ๆ มาทำให้ดูว่า
กระบวนการใน Pipeline นี้เกิดขึ้นได้อย่างไร เป็นตัวอย่างการสร้างและใช้งาน
ไม่ว่าจะเป็นการเริ่มต้นสร้าง Project บน Jenkins เพื่อให้ทำการบางอย่างเมื่อมีการเปลี่ยนแปลงบน Version Control และค่อย ๆ เพิ่มรายละเอียดเข้าไป โดยเริ่มจากง่าย ๆ ก่อน , มีตัวอย่างการทำ Source Code Analysis โดยใช้เครื่องมืออย่าง Sonarqube
ซึ่งข้อควรระวังตรงนี้คือพอระบบ Pipeline ที่เราสร้างขึ้นมามีความซับซ้อนมากขึ้น การดูแลก็ทำได้ยาก เครื่องมือที่ถูกนำมาช่วยเพื่อให้พัฒนาได้เร็วขึ้น กลับกลายเป็นทำให้ช้าลง ข้อแนะนำของพี่ปุ๋ยคือ
อย่านำเครื่องมือเป็นตัวตั้ง ทดลองสร้างจากพื้นฐานง่าย ๆ ดูก่อนจากนั้นก็ค่อย ๆ ปรับปรุง ทำให้มันดีขึ้น ทำให้มันเร็วขึ้นตามลำดับวิธี
CI is about what people do not about what tools they use
สรุปสำหรับตัวเอง : ผ่านมาแล้ว 3 วันกับการเรียนรู้เรื่อง Microservice สำหรับตัวเองในตอนนี้ รู้สึกอยากทดลองทำโปรเจคของตัวเองดูสักอย่าง โดยเอาความรู้ที่ได้มา ลองมาใช้กับสิ่งที่จะทำดู ในทฤษฎีอาจดูสวยงาม แต่ในชีวิตจริงนั้นอาจจะเป็นหนังอีกเรื่องเลยก็ได้ อาจจะได้เจอปัญหาเพื่อที่จะต้องนำมาศึกษาหาวิธีแก้เพิ่มเติมอีก เพื่อที่จะได้เข้าใจลึกซึ้งขึ้น แล้วก็สำหรับตัวเองในเรื่องของการที่วันหนึ่งต้องขึ้นมาสอน ได้สังเกตุเห็นวิธีการสอนเนื้อหาที่การสอนแต่ละครั้งไม่ได้มีรูปแบบตายตัว แต่เป็นการปรับเนื้อหา ปรับบริบทให้เข้ากับคนที่มาเรียน ส่วนมากจะเน้นเกี่ยวกับการกระบวนการการทำงานที่เป็นพื้นฐาน การพูดคุยทำงานร่วมกันในทีมมากกว่าเน้นใช้เครื่องมือสำเร็จรูป สิ่งที่เน้นคือต้องเข้าใจพื้นฐานให้ดีก่อนที่จะไปในขั้นต่อไป
