สร้างอนาคต: สถาปัตยกรรมไมโครเซอร์วิส

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

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

1. สถาปัตยกรรมเพื่อการเติบโตของธุรกิจ: เนื่องจากระบบให้บริการลูกค้ามากขึ้นและประมวลผลธุรกรรมมากขึ้น ระบบจึงต้องการความจุและทรัพยากรมากขึ้น อย่างไรก็ตาม ไม่ใช่ว่าทุกส่วนของระบบอาจเติบโตด้วยความเร็วเท่ากัน
2. การจัดการยอดการรับส่งข้อมูล: ตามหลักการแล้ว ระบบควรจะสามารถปรับขนาดได้โดยอัตโนมัติหรืออย่างน้อยแบบไดนามิกในลักษณะที่โครงสร้างพื้นฐานไม่ถูกผลักดันให้มีความจุสูงสุดเพื่อรองรับการรับส่งข้อมูลสูงสุดตลอดเวลา
3. เวลาในการออกสู่ตลาดเร็วขึ้น: การเพิ่มหรือแก้ไขคุณลักษณะมีคุณค่าอย่างมากต่อธุรกิจโดยใช้เวลาเป็นวันหรือเป็นสัปดาห์แทนที่จะเป็นเดือน และไม่ต้องการการทดสอบการถดถอยที่มากเกินไป (และมักจะมีราคาแพง) และการรีสตาร์ทแอปพลิเคชันทั้งหมดที่ทำงานอยู่ในสภาพแวดล้อมทั้งหมด คำตอบสำหรับสิ่งนี้คือความเป็นโมดูลและการออกแบบเพื่อให้สามารถทดแทนได้ ซึ่งไมโครเซอร์วิสอำนวยความสะดวกให้
4. การเปลี่ยนแปลงเนื้อหาและประสบการณ์ของผู้ใช้อย่างรวดเร็วและทันที: ระบบออนไลน์แบบดั้งเดิมจำนวนมากสร้างเนื้อหาแบบไดนามิกที่ฝั่งเซิร์ฟเวอร์ จากเว็บแอปพลิเคชันเดียวกันที่มีฟังก์ชันสำหรับการชำระเงิน บัญชีของฉัน และคุณลักษณะอื่นๆ (เช่น เสาหิน) ซึ่งหมายความว่าในขณะที่เนื้อหาที่ลูกค้าเผชิญอยู่สามารถเป็นปัจจุบัน อาจเป็นส่วนตัวและจัดการได้ โดยสร้างใหม่อย่างต่อเนื่องซึ่งเนื้อหานั้นใช้วงจร CPU จำนวนมาก สร้างการพึ่งพาออนไลน์ในการจัดเก็บข้อมูลและระบบย่อยอื่นๆ ที่อาจเกิดขึ้น

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

แนวคิดในที่นี้คือการมีระบบที่ประกอบด้วยบริการต่างๆ ที่มีอยู่ในตัว ปรับขนาดได้ และเปลี่ยนได้

อิฐทีละก้อน: ค่อยๆ ย้ายระบบ

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

อาจเป็นแนวทางที่ดีกว่าในการตกลงกับสถาปัตยกรรมเป้าหมายและเริ่มค่อยๆ ย้ายระบบไปสู่เป้าหมาย โดยรวมกิจกรรมการจัดโครงสร้างใหม่ไว้ในแผนพัฒนาแผนงาน:

1. ระบุการเปลี่ยนแปลงที่จะจัดการกับข้อกังวลทางธุรกิจที่มีลำดับความสำคัญสูงสุดและวางแผนสำหรับการปรับโครงสร้างใหม่/การย้ายข้อมูล ตัวอย่างเช่น "การแยกการจัดการเนื้อหาออกจากส่วนธุรกรรมของระบบ " เพื่อให้สามารถผลักดันการเปลี่ยนแปลงไปยังไซต์ได้รวดเร็วยิ่งขึ้น
2. เมื่อเพิ่มคุณสมบัติ (เช่น 'คุณอาจชอบ' หรือ 'หากคุณใช้จ่ายเพิ่มอีก X…') แทนที่จะรวมเข้ากับแอปปัจจุบัน ให้พิจารณาว่าเป็นสิ่งที่สามารถให้คุณค่าเป็นบริการแบบสแตนด์อโลนที่แสดงอินเทอร์เฟซและ สามารถจัดการได้อย่างอิสระ ไม่จำเป็นต้องรันเป็นกระบวนการแบบสแตนด์อโลนหรือปรับใช้ได้ด้วยตัวเองในตอนเริ่มต้น แต่ควรมีการห่อหุ้มอย่างดีด้วยการพึ่งพาขั้นต่ำที่เข้าใจดี
3. เมื่อทำการเปลี่ยนแปลงที่สำคัญกับระบบย่อย เช่น MyAccount ให้พิจารณาว่านี่อาจเป็นเวลาที่เหมาะสมในการสร้างแอปหรือบริการด้วยตัวเองหรือไม่ อีกครั้ง ปัจจัยสำคัญคือการพิจารณาการพึ่งพา—ในโค้ดและระดับรันไทม์

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

• • บริการสื่อสารอีเมลลูกค้า
  • ชำระเงินเป็นบริการ
  • บริการความพร้อมของสินค้า
  • เครื่องมือค้นหาการค้า
  • บริการให้คำปรึกษาหรือแนะนำส่วนบุคคลต่างๆ
  • วิจารณ์สินค้า/บริการให้คะแนน

ปรับขนาดโปรเจ็กต์ของคุณอย่างถูกวิธี: กำหนดกระบวนการและแผนสถาปัตยกรรมไมโครเซอร์วิส

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

ความชัดเจนของสถาปัตยกรรม: นี่ไม่ได้หมายถึงแนวทาง 'การออกแบบครั้งใหญ่ล่วงหน้า' แต่ทีมจำเป็นต้องแบ่งปันวิสัยทัศน์และความเข้าใจร่วมกันเกี่ยวกับบริการที่ระบบจะประกอบด้วย และวิธีที่จะสร้างและใช้งานบริการ และเฝ้าติดตาม ทีมต้องเตรียมพร้อมในการปรับใช้แนวทางปฏิบัติที่แตกต่างกัน (API-first), เฟรมเวิร์ก (Spring Cloud), องค์ประกอบโครงสร้างพื้นฐานของแอปพลิเคชันทั่วไป—API Gateway, เซิร์ฟเวอร์การตรวจสอบสิทธิ์, การลงทะเบียนบริการ ฯลฯ ไม่จำเป็นเสมอไป แต่ต้องเป็น การตัดสินใจทางสถาปัตยกรรมอย่างมีสติว่าจะเป็นส่วนหนึ่งของระบบหรือไม่

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

สถาปัตยกรรมไมโครเซอร์วิส: ทำให้ถูกต้อง

มีหลายวิธีในการทำให้การโยกย้ายไปยังไมโครเซอร์วิสผิดพลาด: เพียงแค่ทำตามกระแสเทคโนโลยีโดยไม่ต้องมีกรณีธุรกิจจริง ระบุบริการที่ไม่เหมาะสมซึ่งต้องพึ่งพากันและกันมากเกินไป ล้มเหลวในการนำแนวปฏิบัติ DevOps มาใช้เพื่อจัดการกับความซับซ้อน ไม่พัฒนา ทักษะที่เหมาะสมภายในทีม เป็นต้น

อย่างไรก็ตาม ด้วยการวางแผนที่เหมาะสมและการจัดการความเสี่ยง หลังจากผ่านไประยะหนึ่ง (และความเครียด ข้อสงสัย และความตื่นตระหนกของ PM) ทีมงานควรเริ่มรู้สึกถึงผลกระทบเชิงบวกบางประการ:

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

แผนงานสถาปัตยกรรมเป็นเครื่องมือที่ช่วยกำหนดทิศทางสำหรับวิวัฒนาการของระบบในอีกสองสามปีข้างหน้า

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