การเดินทางสู่ไมโครเซอร์วิสของ Shoprocket: ตอนที่ 1

หลายเดือนหลังจากที่ฉันเริ่มงานที่ Shoprocket ฉันเริ่มรู้สึกหงุดหงิด ทีมพัฒนาของเรามีแอปพลิเคชัน PHP ที่กำลังอยู่ในระหว่างการพัฒนา โดยทีมเล็กๆ ของเราเป็นนักพัฒนาที่ฉลาดกระจายอยู่ทั่วโลก ทำไมฉันถึงรู้สึกหงุดหงิด? สำหรับฉัน ดูเหมือนว่าการแก้ไขบั๊กจะทำให้เกิดบั๊กใหม่มากขึ้น การรวมฟีเจอร์ใหม่ไม่ง่ายอย่างที่ควรจะเป็น และการปรับใช้แอปพลิเคชันก็ไม่บ่อยและเครียด สาเหตุของปัญหาเหล่านี้: โค้ดที่เชื่อมโยงกันมากเกินไป

เรามีแอปพลิเคชันโมโนลิธ และเกือบทั้งหมดของโค้ดเบสของเรานั่งอยู่ในที่เก็บ Github เดียว การอัปเดตหรือการแก้ไขฟีเจอร์เดียวมักจะเกิดขึ้นในหลายๆ ที่ สำหรับการทดสอบ เรามีกระบวนการรีวิวจากเพื่อนร่วมงาน ซึ่งนักพัฒนาคนอื่นๆ ต้องเซ็นรับรองสาขาก่อนที่จะถูกผสานเข้ากับ master และปรับใช้ทั้งหมด นั่นหมายความว่าเมื่อเกิดบั๊กขึ้นมาใต้เรดาร์ มันมักจะยากที่จะระบุการเปลี่ยนแปลงที่ทำให้เกิดปัญหา และเมื่อเราค้นพบแล้ว การแก้ไขก็จะต้องผ่านกระบวนการเดียวกันและแอปพลิเคชันทั้งหมดต้องถูกปรับใช้อีกครั้ง

ในฐานะที่เป็นนักพัฒนาหนุ่มที่กระตือรือร้นเสมอในการมองหาอย่างใหม่ เมื่อฉันมาค้นพบไมโครเซอร์วิส ฉันคิดว่าแนวทางสถาปัตยกรรมนี้จะสามารถแก้ปัญหาทั้งหมดของเราได้ ไม่มีคำจำกัดความอย่างเป็นทางการสำหรับไมโครเซอร์วิส แต่จากการศึกษาของฉัน ฉันได้เรียนรู้ว่าสถาปัตยกรรมไมโครเซอร์วิสคือวิธีการออกแบบแอปพลิเคชันซอฟต์แวร์เป็นระบบกระจายของบริการที่เป็นอิสระแต่ละบริการมีความเฉพาะทางสูงและมีอายุการใช้งานของตัวเอง สำหรับผู้อ่านที่ต้องการการแนะนำที่ละเอียดยิ่งขึ้นเกี่ยวกับแนวคิดนี้ ฉันขอแนะนำบทความที่ยอดเยี่ยมของ Martin Fowler บทความ.

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

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

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

เมื่อมองย้อนกลับไป นี่อาจเป็นการเลือกส่วนประกอบที่ไม่ดีสำหรับบริการแรก ผลิตภัณฑ์ของเรามีปลั๊กอิน Javascript ที่ ทำให้สามารถขายออนไลน์บนเว็บไซต์ใดก็ได้. เราจัดการเซสชันเป็นทรัพยากร โดยการเก็บข้อมูลเซสชันในฐานข้อมูลสำหรับการวิเคราะห์ KPIs ที่ละเอียดเช่นอัตราการละทิ้งรถเข็น อย่างไรก็ตาม ทรัพยากรนี้ไม่สามารถจับต้องได้เหมือนกับคำสั่งซื้อหรือรายการสินค้า นอกจากนี้เรายังใช้ทรัพยากรเซสชันเกือบทุกครั้งที่มีการเปลี่ยนแปลงในสถานะของแอปพลิเคชัน ซึ่งหมายความว่าบริการนี้จะต้องมีการพูดคุยมากกับแอปพลิเคชันอื่นๆ ซึ่งฉันไม่ได้คาดคิด แต่ทำให้ภารกิจของฉันยาก

เมื่อสามารถ convince เจ้านายของฉันได้ ฉันก็เริ่มศึกษาวิธีไมโครเซอร์วิสเพิ่มเติม นอกจากบทความที่กล่าวถึงข้างต้น ฉันยังพบว่า 'Building Microservices' ของ Sam Newman เป็นทรัพยากรที่มีคุณค่าอย่างมาก ฉันจะอ้างถึงทั้งสองอย่างนี้บ่อยในโพสต์ของฉัน

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

ฉันเลือกสแต็คที่แตกต่างออกไปเพียงเล็กน้อยจากที่เราใช้สำหรับโมโนลิธและเริ่มสร้าง การก่อสร้างนั้นดำเนินไปอย่างรวดเร็ว ใช้เวลาสักสองสามสัปดาห์ในการผลิตแอปพลิเคชันแบบสแตนด์อโลนที่มี REST API เพียงแค่นั้นจริงๆ ความท้าทายที่แท้จริงเริ่มขึ้น

ฉันต้องทำให้บริการพูดคุยกับโมโนลิธ ในจุดนี้ที่ฉันได้เรียนรู้ว่า การจัดการเซสชันมีความเชื่อมโยงกันมากเพียงใดกับโค้ดที่เหลือ ใช้เวลาสักระยะเพื่อแยกฟังก์ชันที่มีอยู่และแปลพวกเขาเป็นการเรียก API ซึ่งเป็นเรื่องยาก เนื่องจากบริการเซสชันและโมโนลิธมีสคีมาฐานข้อมูลของตัวเอง ฉันจึงต้องเขียนตรรกะใดๆ ในโมโนลิธที่ใช้ทรัพยากรเซสชันจากฐานข้อมูลเก่าใหม่และปรับโครงสร้างข้อมูลที่ขอบเขตของแอปพลิเคชันเพื่อรักษาความเข้ากันได้กับไคลเอนต์เช่นปลั๊กอิน Javascript ของเรา

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

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

ฉันยังคงมั่นใจในแนวคิดของไมโครเซอร์วิส และฉันมองว่าความพยายามในการแยกบริการนี้เป็นการทดลองที่ประสบความสำเร็จ ฉันได้เรียนรู้มากมายเกี่ยวกับสถาปัตยกรรมแอปพลิเคชันและการสร้างโมเดลโดเมนในกระบวนการนี้ และพัฒนาความเข้าใจของฉันเกี่ยวกับหลักการ REST เป็นต้น ซึ่งมีผลกระทบโดยตรงในพื้นที่อื่นๆ ของโค้ดของเรา

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

Shoprocket จะเดินต่อไปในเส้นทางสู่ไมโครเซอร์วิส เราหวังว่าจะได้บอกเล่าเพิ่มเติมในส่วนที่ 2!