วิธีจัดการกับความซับซ้อนเมื่อออกแบบระบบซอฟต์แวร์

มันคือเรื่องอะไร?

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

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

ในบทความนี้ ฉันจะแบ่งปันประสบการณ์ของฉันเกี่ยวกับปัญหาบางประการที่ฉันพบขณะสร้างโปรแกรมซอฟต์แวร์

Cross-Cutting Concern คืออะไร?

หากเราลองค้นหาใน Wikipedia เราจะพบคำจำกัดความดังต่อไปนี้

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

มันอธิบายสิ่งที่มันเป็นได้อย่างชัดเจน แต่ฉันอยากขยายและทำให้มันง่ายขึ้นเล็กน้อย:

ข้อกังวลเชิงตัดขวาง คือแนวคิดหรือส่วนประกอบของระบบ/องค์กรที่ส่งผลกระทบ (หรือ 'ตัดขวาง') ส่วนอื่นๆ อีกมากมาย

ตัวอย่างที่ดีที่สุดของความกังวลดังกล่าว ได้แก่ สถาปัตยกรรมระบบ การบันทึก ความปลอดภัย การจัดการธุรกรรม การวัดระยะไกล การออกแบบฐานข้อมูล และอื่นๆ อีกมากมาย เราจะอธิบายรายละเอียดเพิ่มเติมในบทความนี้ในภายหลัง

ในระดับโค้ด ปัญหาที่เกี่ยวข้องกับการตัดขวางมักจะถูกนำมาใช้โดยใช้เทคนิคเช่น Aspect-Oriented Programming (AOP) ซึ่งปัญหาเหล่านี้จะถูกแบ่งส่วนเป็นส่วนประกอบแยกกันที่สามารถนำไปใช้ได้ทั่วทั้งแอปพลิเคชัน วิธีนี้จะช่วยแยกตรรกะทางธุรกิจออกจากปัญหาเหล่านี้ ทำให้โค้ดอ่านและบำรุงรักษาได้ง่ายขึ้น

การจำแนกประเภทด้านต่างๆ

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

ดังนั้นฉันจะแยกลักษณะออกเป็น มหภาค และ จุลภาค

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

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

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

ในบทความนี้ ฉันจะมุ่งเน้นไปที่ประเด็นมหภาคเป็นหลัก

มุมมองมหภาค

โครงสร้างองค์กร

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

องค์กรใดก็ตามที่ออกแบบระบบ (โดยกำหนดอย่างกว้างๆ) จะต้องผลิตการออกแบบที่มีโครงสร้างเป็นสำเนาของโครงสร้างการสื่อสารขององค์กร

ฉันเชื่อเสมอมาว่าแนวคิดนี้เป็นสากลมากและเป็นตัวแทนของกฎทอง

จากนั้น ฉันจึงเริ่มเรียนรู้แนวทาง Domain-Driven Design (DDD) ของ Eric Evans สำหรับการสร้างแบบจำลองระบบ Eric Evans เน้นย้ำถึงความสำคัญของการระบุบริบทที่มีขอบเขต แนวคิดนี้เกี่ยวข้องกับการแบ่งโมเดลโดเมนที่ซับซ้อนออกเป็นส่วนย่อยๆ ที่จัดการได้ง่ายกว่า โดยแต่ละส่วนจะมีชุดความรู้ที่จำกัดของตัวเอง แนวทางนี้ช่วยให้การสื่อสารในทีมมีประสิทธิภาพ เนื่องจากลดความจำเป็นในการมีความรู้ที่ครอบคลุมเกี่ยวกับโดเมนทั้งหมด และลดการสลับบริบทให้เหลือน้อยที่สุด ทำให้การสนทนามีประสิทธิภาพมากขึ้น การสลับบริบทเป็นสิ่งที่แย่ที่สุดและใช้ทรัพยากรมากที่สุดเท่าที่เคยมีมา แม้แต่คอมพิวเตอร์ก็ยังประสบปัญหาในการทำเช่นนี้ แม้ว่าจะไม่น่าจะทำให้ไม่มีการสลับบริบทโดยสมบูรณ์ แต่ฉันคิดว่านั่นคือสิ่งที่เราควรพยายามทำ

เมื่อกลับมาที่กฎของ Conway ฉันพบปัญหาหลายประการเกี่ยวกับเรื่องนี้

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

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

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

ก้อนโคลนขนาดใหญ่

รูปแบบหรือ “รูปแบบต่อต้าน” นี้ขับเคลื่อนการสร้างระบบที่ไม่มีสถาปัตยกรรมใดๆ ไม่มีกฎเกณฑ์ ไม่มีขอบเขต และไม่มีกลยุทธ์ในการควบคุมความซับซ้อนที่เพิ่มมากขึ้นอย่างหลีกเลี่ยงไม่ได้ ความซับซ้อนคือศัตรูที่น่ากลัวที่สุดในการสร้างระบบซอฟต์แวร์

เพื่อหลีกเลี่ยงการสร้างระบบประเภทดังกล่าว เราต้องปฏิบัติตามกฎและข้อจำกัดเฉพาะเจาะจง

สถาปัตยกรรมระบบ

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

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

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

รูปแบบสถาปัตยกรรมซอฟต์แวร์ เป็นชุดหลักการและรูปแบบที่กำหนดวิธีการสร้างซอฟต์แวร์

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

เช่นเช่น:

1. สถาปัตยกรรมแบบองค์รวม

2. การออกแบบตามโดเมน

3. แบบส่วนประกอบ

4. ไมโครเซอร์วิส

5. ท่อและไส้กรอง

6. ขับเคลื่อนด้วยเหตุการณ์

7. ไมโครเคอร์เนล

8. เน้นการบริการ

   
   

และอื่นๆอีกมากมาย…

แน่นอนว่าสถาปัตยกรรมเหล่านี้มีข้อดีข้อเสีย แต่สิ่งที่สำคัญที่สุดที่ฉันได้เรียนรู้ก็คือสถาปัตยกรรมจะค่อยๆ พัฒนาไปพร้อมๆ กับปัญหาที่เกิดขึ้นจริง การเริ่มต้นด้วยสถาปัตยกรรมโมโนลิธิกถือเป็นตัวเลือกที่ยอดเยี่ยมในการลดความซับซ้อนในการปฏิบัติงาน สถาปัตยกรรมนี้น่าจะตอบสนองความต้องการของคุณได้แม้หลังจากเข้าสู่ขั้นตอน Product-market Fit (PMI) ของการสร้างผลิตภัณฑ์แล้วก็ตาม ในระดับขนาดใหญ่ คุณอาจพิจารณาเปลี่ยนไปใช้แนวทางแบบอิงตามเหตุการณ์และไมโครเซอร์วิสเพื่อให้เกิดการปรับใช้แบบอิสระ สภาพแวดล้อมเทคสแต็กที่ไม่เป็นเนื้อเดียวกัน และสถาปัตยกรรมที่เชื่อมโยงกันน้อยลง (และโปร่งใสน้อยลงในระหว่างนี้เนื่องจากลักษณะของแนวทางแบบอิงตามเหตุการณ์และแบบ pub-sub หากนำแนวทางเหล่านี้มาใช้) ความเรียบง่ายและประสิทธิภาพนั้นมีความใกล้เคียงกันและส่งผลกระทบอย่างมากต่อกันและกัน โดยทั่วไป สถาปัตยกรรมที่ซับซ้อนจะส่งผลกระทบต่อความเร็วในการพัฒนาฟีเจอร์ใหม่ รองรับและรักษาฟีเจอร์ที่มีอยู่ และท้าทายวิวัฒนาการตามธรรมชาติของระบบ

อย่างไรก็ตาม ระบบที่ซับซ้อนมักจะต้องใช้สถาปัตยกรรมที่ซับซ้อนและครอบคลุม ซึ่งเป็นสิ่งที่หลีกเลี่ยงไม่ได้

จริงๆ แล้วนี่เป็นหัวข้อที่กว้างมาก และมีแนวคิดดีๆ มากมายเกี่ยวกับวิธีจัดโครงสร้างและสร้างระบบสำหรับวิวัฒนาการตามธรรมชาติ จากประสบการณ์ของฉัน ฉันได้คิดแนวทางต่อไปนี้:

1. โดยทั่วไปมักจะเริ่มต้นด้วยรูปแบบสถาปัตยกรรมโมโนลิธิก เนื่องจากรูปแบบนี้ช่วยขจัดปัญหาส่วนใหญ่ที่เกิดจากลักษณะของระบบแบบกระจายได้ นอกจากนี้ ยังสมเหตุสมผลที่จะใช้สถาปัตยกรรมโมโนลิธิกแบบโมดูลาร์เพื่อเน้นที่การสร้างส่วนประกอบที่มีขอบเขตชัดเจน การใช้แนวทางตามส่วนประกอบอาจช่วยให้ส่วนประกอบต่างๆ สื่อสารกันโดยใช้เหตุการณ์ แต่การเรียกใช้โดยตรง (หรือที่เรียกว่า RPC) ช่วยลดความซับซ้อนในตอนเริ่มต้น อย่างไรก็ตาม การติดตามความสัมพันธ์ระหว่างส่วนประกอบต่างๆ ถือเป็นสิ่งสำคัญ เนื่องจากหากส่วนประกอบ A รู้จักส่วนประกอบ B เป็นอย่างดี การรวมส่วนประกอบเหล่านี้เข้าเป็นหนึ่งจึงอาจสมเหตุสมผล
2. เมื่อคุณเข้าใกล้สถานการณ์ที่ต้องปรับขนาดการพัฒนาและระบบของคุณมากขึ้น คุณอาจพิจารณาปฏิบัติตามรูปแบบ Stangler เพื่อค่อยๆ แยกส่วนประกอบต่างๆ ออกมาซึ่งจำเป็นต้องปรับใช้โดยอิสระหรือแม้แต่ปรับขนาดตามข้อกำหนดเฉพาะ
3. ตอนนี้ หากคุณมีวิสัยทัศน์ที่ชัดเจนเกี่ยวกับอนาคต ซึ่งถือเป็นโชคช่วยเล็กน้อย คุณสามารถตัดสินใจเลือกสถาปัตยกรรมที่ต้องการได้ ในขณะนี้ คุณสามารถตัดสินใจเลือกสถาปัตยกรรมไมโครเซอร์วิสได้โดยใช้แนวทางการประสานงานและการจัดวางท่าทาง การรวมรูปแบบ CQRS สำหรับการเขียนและการอ่านในระดับอิสระ หรือแม้แต่ตัดสินใจเลือกใช้สถาปัตยกรรมแบบโมโนลิธิกหากตรงตามความต้องการของคุณ

นอกจากนี้ การทำความเข้าใจตัวเลขและเมตริกต่างๆ เช่น DAU (ผู้ใช้รายวัน), MAU (ผู้ใช้รายเดือน), RPC (คำขอต่อวินาที) และ TPC (ธุรกรรมต่อวินาที) ก็มีความจำเป็นเช่นกัน เนื่องจากข้อมูลเหล่านี้อาจช่วยให้คุณตัดสินใจเลือกได้ เนื่องจากสถาปัตยกรรมสำหรับผู้ใช้ 100 รายที่ใช้งานอยู่จริงและผู้ใช้ 100 ล้านรายที่ใช้งานอยู่จริงนั้นแตกต่างกัน

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

การเลือกสรรเทคโนโลยี

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

นี่คือรายการข้อควรพิจารณาพื้นฐานในการเลือกกลุ่มเทคโนโลยี:

• ข้อกำหนดและความซับซ้อนของโครงการ ตัวอย่างเช่น สามารถสร้างแอปพลิเคชันเว็บที่เรียบง่ายโดยใช้กรอบงาน Blazor ได้ หากนักพัฒนาของคุณมีประสบการณ์ในการใช้งาน แต่เนื่องจาก WebAssembly ยังไม่สมบูรณ์แบบ การเลือกใช้ React และ Typescript เพื่อความสำเร็จในระยะยาวอาจเป็นการตัดสินใจที่ดีกว่า
• ความสามารถในการปรับขนาดและความต้องการด้านประสิทธิภาพ หากคุณคาดว่าจะได้รับปริมาณการใช้งานจำนวนมาก การเลือกใช้ ASP.NET Core แทน Django อาจเป็นทางเลือกที่ชาญฉลาดเนื่องจากมีประสิทธิภาพที่เหนือกว่าในการจัดการคำขอพร้อมกัน อย่างไรก็ตาม การตัดสินใจนี้ขึ้นอยู่กับขนาดของปริมาณการใช้งานที่คุณคาดหวัง หากคุณจำเป็นต้องจัดการคำขอที่อาจมีจำนวนเป็นพันล้านรายการด้วยเวลาแฝงต่ำ การมีอยู่ของ Garbage Collection อาจเป็นเรื่องท้าทาย
• การจ้างงาน เวลาในการพัฒนา และต้นทุน ในกรณีส่วนใหญ่ สิ่งเหล่านี้เป็นปัจจัยที่เราต้องคำนึงถึง เวลาในการทำตลาด ต้นทุนการบำรุงรักษา และเสถียรภาพในการจ้างงานจะขับเคลื่อนความต้องการทางธุรกิจของคุณโดยไม่มีอุปสรรค
• ความเชี่ยวชาญและทรัพยากรของทีม ทักษะของทีมพัฒนาของคุณเป็นปัจจัยสำคัญ โดยทั่วไปแล้ว การใช้เทคโนโลยีที่ทีมของคุณคุ้นเคยอยู่แล้วจะมีประสิทธิภาพมากกว่า เว้นแต่จะมีเหตุผลอันสมควรที่จะต้องลงทุนเรียนรู้เทคโนโลยีใหม่ๆ
• ความเป็นผู้ใหญ่ ชุมชนที่แข็งแกร่งและระบบนิเวศที่อุดมสมบูรณ์ของไลบรารีและเครื่องมือต่างๆ สามารถทำให้กระบวนการพัฒนาง่ายขึ้นได้มาก เทคโนโลยีที่เป็นที่นิยมมักได้รับการสนับสนุนจากชุมชนที่ดีกว่า ซึ่งอาจมีค่าอย่างยิ่งสำหรับการแก้ปัญหาและการค้นหาทรัพยากร ดังนั้น คุณสามารถประหยัดทรัพยากรและมุ่งเน้นไปที่ผลิตภัณฑ์เป็นหลักได้
• การบำรุงรักษาและการสนับสนุนในระยะยาว พิจารณาถึงความยั่งยืนของเทคโนโลยีในระยะยาว เทคโนโลยีที่ได้รับการนำมาใช้และสนับสนุนอย่างกว้างขวางนั้นมีแนวโน้มที่จะล้าสมัยน้อยกว่า และโดยทั่วไปจะได้รับการอัปเดตและปรับปรุงเป็นประจำ

การมีเทคโนโลยีหลายชุดจะส่งผลต่อการเติบโตทางธุรกิจได้อย่างไร

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

แต่หลักการในการเลือกเครื่องมือที่ดีที่สุดสำหรับปัญหาเฉพาะเจาะจงคืออะไร?

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

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

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

จุดล้มเหลวเดี่ยว (SPOF)

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

มีเทคนิคพื้นฐานหลายประการที่เราสามารถนำไปใช้เพื่อขจัดจุดล้มเหลวเพียงจุดเดียว:

1. การสำรอง ข้อมูล นำการสำรองข้อมูลไปใช้กับส่วนประกอบที่สำคัญ ซึ่งหมายถึงการมีส่วนประกอบสำรองที่สามารถทำงานได้แทนหากส่วนประกอบหลักเกิดความล้มเหลว การสำรองข้อมูลสามารถนำไปใช้กับเลเยอร์ต่างๆ ของระบบได้ รวมถึงฮาร์ดแวร์ (เซิร์ฟเวอร์ ดิสก์) เครือข่าย (ลิงก์ สวิตช์) และซอฟต์แวร์ (ฐานข้อมูล เซิร์ฟเวอร์แอปพลิเคชัน) หากคุณโฮสต์ทุกอย่างไว้ในผู้ให้บริการคลาวด์รายหนึ่งและมีการสำรองข้อมูลไว้ที่นั่นด้วย ให้พิจารณาสร้างการสำรองข้อมูลเพิ่มเติมเป็นประจำในอีกรายหนึ่งเพื่อลดต้นทุนที่สูญเสียไปในกรณีที่เกิดภัยพิบัติ
2. ศูนย์ข้อมูล กระจายระบบของคุณไปตามสถานที่ทางกายภาพหลายแห่ง เช่น ศูนย์ข้อมูลหรือภูมิภาคคลาวด์ แนวทางนี้จะช่วยปกป้องระบบของคุณจากความล้มเหลวเฉพาะสถานที่ เช่น ไฟฟ้าดับหรือภัยธรรมชาติ
3. การสำรองข้อมูล ใช้แนวทางการสำรองข้อมูลสำหรับส่วนประกอบทั้งหมดของคุณ (DNS, CDN, ตัวปรับสมดุลการโหลด, Kubernetes, API Gateway และฐานข้อมูล) เนื่องจากปัญหาอาจเกิดขึ้นโดยไม่คาดคิด จึงจำเป็นอย่างยิ่งที่จะต้องมีแผนสำรองเพื่อแทนที่ส่วนประกอบใดๆ ด้วยโคลนตามความจำเป็นอย่างรวดเร็ว
4. บริการที่มีความพร้อมใช้งานสูง ให้แน่ใจว่าบริการของคุณได้รับการสร้างให้สามารถปรับขนาดได้ในแนวนอนและพร้อมใช้งานสูงตั้งแต่เริ่มต้นโดยยึดตามหลักการต่อไปนี้:
   • ปฏิบัติตามข้อกำหนดในการให้บริการและหลีกเลี่ยงการเก็บเซสชันผู้ใช้ในแคชภายในหน่วยความจำ ให้ใช้ระบบแคชแบบกระจาย เช่น Redis แทน
   • หลีกเลี่ยงการพึ่งพาลำดับเวลาของการใช้ข้อความเมื่อพัฒนาตรรกะ
   • ลดการเปลี่ยนแปลงที่มีผลเสียให้เหลือน้อยที่สุด เพื่อป้องกันไม่ให้เกิดการรบกวนต่อผู้บริโภค API หากเป็นไปได้ ให้เลือกการเปลี่ยนแปลงที่เข้ากันได้ย้อนหลัง นอกจากนี้ ควรพิจารณาถึงต้นทุนด้วย เนื่องจากบางครั้ง การนำการเปลี่ยนแปลงที่มีผลเสียมาใช้อาจคุ้มต้นทุนมากกว่า
   • รวมการดำเนินการโยกย้ายเข้าในกระบวนการปรับใช้
   • กำหนดกลยุทธ์ในการจัดการกับคำขอที่เกิดขึ้นพร้อมกัน
   • นำการค้นพบ การตรวจสอบ และการบันทึกบริการไปใช้เพื่อเพิ่มความน่าเชื่อถือและการสังเกต
   • พัฒนาตรรกะทางธุรกิจให้มีอุดมคติ โดยยอมรับว่าความล้มเหลวของเครือข่ายเป็นสิ่งที่หลีกเลี่ยงไม่ได้
5. การตรวจสอบการ พึ่งพา ตรวจสอบและลดการพึ่งพาภายนอกให้น้อยที่สุด การพึ่งพาภายนอกแต่ละครั้งอาจทำให้เกิด SPOF ได้ ดังนั้นการทำความเข้าใจและลดความเสี่ยงเหล่านี้จึงเป็นสิ่งสำคัญ
6. แบ่งปันความรู้เป็นประจำ อย่าลืมความสำคัญของการเผยแพร่ความรู้ภายในองค์กรของคุณ ผู้คนอาจคาดเดาไม่ได้ และการพึ่งพาบุคคลเพียงคนเดียวก็มีความเสี่ยง ส่งเสริมให้สมาชิกในทีมแปลงความรู้ของตนเป็นดิจิทัลผ่านเอกสาร อย่างไรก็ตาม ควรระมัดระวังการจัดทำเอกสารมากเกินไป ใช้เครื่องมือ AI ต่างๆ เพื่อลดความซับซ้อนของกระบวนการนี้

บทสรุป

ในบทความนี้ เราได้กล่าวถึงประเด็นสำคัญหลายประการ ของมาโคร และวิธีที่เราสามารถจัดการกับความซับซ้อนของประเด็นเหล่านั้นได้

ขอบคุณที่เข้ามาอ่านนะคะ เจอกันใหม่คราวหน้าค่ะ!