สถาปัตยกรรมแบ็กเอนด์หมายถึงวิธีการจัดโครงสร้างแบ็กเอนด์ของเว็บแอปพลิเคชัน สถาปัตยกรรมแบ็กเอนด์เป็นตัวกำหนดวิธีที่ส่วนต่างๆ ของแอปพลิเคชันสื่อสารกันเพื่อประมวลผลคำขอขาเข้าและสร้างการตอบกลับ เมื่อสร้างเว็บแอปพลิเคชัน ให้เลือกสถาปัตยกรรมแบ็กเอนด์โดยอิงตามข้อกำหนดและปัจจัยเฉพาะ เช่น ต้นทุน (ทั้งอย่างต่อเนื่องและในวงกว้าง) ความซับซ้อนของแอปพลิเคชัน การปรับขนาดเป้าหมาย และความชำนาญของทีม
โดยเฉพาะอย่างยิ่งสำหรับเว็บแอปพลิเคชันที่ขับเคลื่อนด้วยเนื้อหา เช่น อีคอมเมิร์ซ หนังสือพิมพ์ หรือบล็อก ข้อกำหนดที่สำคัญประกอบด้วยความสอดคล้องของข้อมูลและประสิทธิภาพ โดยเฉพาะอย่างยิ่งเมื่อแอปพลิเคชันของคุณเติบโตในระดับสากลและอาจมีการกระจายมากขึ้น สำหรับเว็บแอปพลิเคชันที่ขับเคลื่อนด้วยเนื้อหา พื้นที่เก็บข้อมูลที่แอปพลิเคชันใช้ก็มีความสำคัญเช่นกัน และจะมีการอธิบายรายละเอียดเพิ่มเติมในคู่มือพื้นที่เก็บข้อมูล การก้าวให้ไกลกว่าสถาปัตยกรรมแอปพลิเคชันทั่วไป การโฮสต์เนื้อหา และการทำให้ผู้ใช้เข้าถึงเนื้อหาได้นั้นสำคัญอย่างยิ่งในการเพิ่มประสิทธิภาพการทำงานของแอป ดูข้อมูลเพิ่มเติมเกี่ยวกับการเลือกกลยุทธ์โฮสติ้งที่เหมาะสมและการเพิ่มประสิทธิภาพแอปในคู่มือโฮสติ้ง
หากคุณมีแบ็กเอนด์สำหรับเว็บแอปพลิเคชันอยู่แล้ว ให้พิจารณาขีดจำกัดของสถาปัตยกรรมปัจจุบัน ตัวอย่างเช่น เมื่อแอปพลิเคชันขยายตัวและมีความต้องการด้านประสิทธิภาพและความเสถียรเพิ่มขึ้น ให้พิจารณาว่าควรปรับโครงสร้างบางส่วนของแอปพลิเคชันหรือเปลี่ยนไปใช้สถาปัตยกรรมอื่นให้เหมาะกับขนาดที่เพิ่มขึ้นหรือไม่ ตัวอย่างเช่น สถาปัตยกรรมแบบผสม (หรือมัลติคลาวด์) ช่วยให้คุณย้ายภาระงานบางส่วนไปยังระบบคลาวด์ได้ก่อนที่จะเปลี่ยนโดยสมบูรณ์ การพิจารณาต้นทุน เวลา และความเสี่ยงที่เกี่ยวข้องกับการย้ายข้อมูลก็เป็นสิ่งสำคัญเช่นกัน
สถาปัตยกรรมแบบโมโนลิธ
สถาปัตยกรรมแบบโมโนลิธมีโครงสร้างที่เป็นหนึ่งเดียว โดยมีองค์ประกอบทั้งหมดของแอปพลิเคชันผสานรวมอย่างแน่นแฟ้นในฐานของโค้ดเดียว แอปพลิเคชันทั้งหมดสร้างขึ้นเป็นหน่วยการทำงานเดี่ยว สถาปัตยกรรมแบบโมโนลิธมีหลายชั้น โดยที่เลเยอร์ต่างๆ ของแอปพลิเคชันจะทำงานที่เฉพาะเจาะจงได้
เลเยอร์โครงสร้าง
- อินเทอร์เฟซผู้ใช้ (UI) ซึ่งมีคอมโพเนนต์ในการนำเสนอฟีเจอร์ต่างๆ ของแอปพลิเคชัน ซึ่งมักจะเป็นแอปพลิเคชันบนเว็บหรือเดสก์ท็อปที่โต้ตอบกับผู้ใช้
- ตรรกะของแอปพลิเคชันคือที่ที่ฟังก์ชันหลักอยู่ ฐานของโค้ดส่วนนี้มีกฎ การคำนวณ และการดำเนินการที่กำหนดวิธีการทำงานของแอปพลิเคชัน
- เลเยอร์การเข้าถึงข้อมูลมีฟังก์ชันสำหรับการอ่านและเขียนข้อมูลและการแปลระหว่างโครงสร้างข้อมูลของแอปพลิเคชันและสคีมาของฐานข้อมูล เลเยอร์นี้มีหน้าที่ในการโต้ตอบกับ ฐานข้อมูลหรือพื้นที่เก็บข้อมูลของแอปพลิเคชัน
- ฐานข้อมูลคือที่ที่แอปพลิเคชันจัดเก็บข้อมูล โดยปกติแล้วจะมีฐานข้อมูลเดียวที่เก็บข้อมูลทั้งหมดของแอปพลิเคชัน ซึ่งได้แก่ ข้อมูลผู้ใช้ การกำหนดค่า และข้อมูลอื่นๆ
- คอมโพเนนต์มิดเดิลแวร์จะจัดการงานต่างๆ เช่น การตรวจสอบสิทธิ์ การกำหนดเส้นทางคำขอ และการตรวจสอบข้อมูล คอมโพเนนต์เหล่านี้จะช่วยจัดการการไหลของข้อมูลและคำขอ
- แอปพลิเคชันแบบโมโนลิธบางตัวมีจุดผสานรวมกับบริการหรือ API ภายนอก จุดเหล่านี้ช่วยให้แอปพลิเคชันโต้ตอบกับบริการของบุคคลที่สาม แหล่งข้อมูล หรือระบบอื่นๆ ได้
เลเยอร์โครงสร้างมักเป็นส่วนหนึ่งของฐานของโค้ดเดี่ยว Codebase นี้ประกอบไปด้วยแอปพลิเคชันทั้งหมดและมักจัดระเบียบเป็นไดเรกทอรี โมดูล และคลาส นักพัฒนาซอฟต์แวร์ทำงานในส่วนต่างๆ ของโค้ดเบสเพื่อสร้างและบำรุงรักษาแอปพลิเคชัน อย่างไรก็ตาม แอปพลิเคชันทั้งหมดมักได้รับการทำให้ใช้งานได้เป็นหน่วยเดียว เมื่อมีการอัปเดตหรือทำการเปลี่ยนแปลง แอปพลิเคชันทั้งหมดก็จะใช้งานได้อีกครั้ง
ความท้าทายที่อาจเกิดขึ้น
- ในขณะที่แอปพลิเคชันแบบโมโนลิธมีขนาดใหญ่ขึ้น ฐานของโค้ดก็มีแนวโน้มที่จะซับซ้อนและดูแลได้ยาก ซึ่งอาจส่งผลให้มีวงจรการพัฒนาที่ยาวนานและ มีปัญหาในการทำความเข้าใจฐานของโค้ดทั้งหมด
- การนำการเปลี่ยนแปลงไปใช้กับแอปพลิเคชันแบบโมโนลิธอาจมีความเสี่ยง เนื่องจากการเปลี่ยนแปลงที่ดำเนินการกับส่วนหนึ่งของโค้ดอาจส่งผลต่อส่วนอื่นๆ ของแอปพลิเคชันโดยไม่ได้ตั้งใจ ซึ่งทำให้กระบวนการติดตั้งใช้งานใช้เวลานานและมีโอกาสเกิดข้อผิดพลาดได้
- แอปพลิเคชันแบบโมโนลิธอาจปรับขนาดได้ยากเนื่องจากมีการนำไปใช้เป็นหน่วยเดียว คุณต้องปรับขนาดแอปพลิเคชันทั้งหมดแม้ว่าจะมีความต้องการเพิ่มขึ้นเพียงคอมโพเนนต์เดียว
- แอปพลิเคชันแบบโมโนลิธมักอาศัยสแต็กเทคโนโลยีหรือภาษาโปรแกรมเดียว ความสามารถในการใช้เครื่องมือที่ดีที่สุดสำหรับงานเฉพาะภายในแอปพลิเคชันอาจมีจำกัด
- แม้ในช่วงที่มีความต้องการน้อย แต่การใช้งานแบบโมโนลิธจำเป็นต้องใช้ทรัพยากรจำนวนมากในการทำงาน ค่าใช้จ่ายในการบำรุงรักษายังเพิ่มขึ้นเมื่อแอปพลิเคชันมีอายุมากขึ้น เนื่องจากการอัปเดตและแพตช์แอปพลิเคชันนั้นทำได้ยากขึ้นโดยไม่ก่อให้เกิดการถดถอย
- ทีมพัฒนาที่ทำงานเกี่ยวกับแอปพลิเคชันแบบโมโนลิธมักมีการจัดระเบียบไว้ตลอดทั้งแอปพลิเคชัน ทำให้ทีมใหญ่ขึ้นและการประสานงานของสมาชิกในทีมมีความซับซ้อนมากขึ้น
การใช้งานที่แนะนำ
สถาปัตยกรรมแบบโมโนลิธจะเหมาะสมเมื่อแอปพลิเคชันมีข้อกำหนดไม่ซับซ้อน และทีมพัฒนาที่มีขนาดเล็ก เมื่อแอปพลิเคชันเติบโตขึ้นทั้งความซับซ้อนและการปรับขนาด หรือเมื่อส่วนต่างๆ ของแอปพลิเคชันต้องใช้เทคโนโลยีหรือกลยุทธ์การทำให้ใช้งานได้ที่แตกต่างกัน สถาปัตยกรรมแบบโมโนลิธอาจมีความยืดหยุ่นน้อยลงและยากต่อการจัดการมากขึ้น
คุณสร้างและจัดการเครื่องเสมือนที่เรียกใช้แอปพลิเคชันแบบโมโนลิธได้ใน Compute Engine คุณควบคุมระบบปฏิบัติการ ซอฟต์แวร์ และการจัดการเครื่องเสมือนเหล่านี้ได้อย่างเต็มที่เพื่อเรียกใช้แอปพลิเคชันแบบโมโนลิธ
บริการแพลตฟอร์มที่เป็นบริการอย่าง App Engine ช่วยให้คุณสร้างแอปพลิเคชันและเรียกใช้บนโครงสร้างพื้นฐานที่มีการจัดการครบวงจรซึ่งจะปรับขนาดตามคำขอโดยอัตโนมัติได้
หากแอปพลิเคชันแบบโมโนลิธมีคอนเทนเนอร์ คุณจะเรียกใช้ได้โดยใช้ Google Kubernetes Engine (GKE) หรือ Cloud Run บริการต่างๆ เช่น Cloud SQL หรือ Cloud Spaner สามารถใช้เพื่อจัดเก็บข้อมูลสำหรับแอปพลิเคชันแบบโมโนลิธได้ พิจารณาชุดค่าผสมของบริการและระบบตาม ข้อกำหนดเฉพาะของแอปพลิเคชัน
สถาปัตยกรรมแบบ Serverless
เมื่อใช้สถาปัตยกรรมแบบ Serverless คุณจะสร้างและเรียกใช้แอปพลิเคชันได้โดยไม่ต้องจัดการเซิร์ฟเวอร์จริงหรือเสมือน ผู้ให้บริการระบบคลาวด์จะจัดการโครงสร้างพื้นฐาน การปรับขนาด และการจัดสรรทรัพยากรโดยอัตโนมัติเพื่อให้นักพัฒนาซอฟต์แวร์มุ่งเน้นที่การเขียนโค้ดสำหรับแอปพลิเคชันของตนได้ สถาปัตยกรรมแบบ Serverless ทำให้การพัฒนาง่ายขึ้น ลดค่าใช้จ่ายในการดำเนินการ และเพิ่มประสิทธิภาพต้นทุนได้โดยขจัดความจำเป็นในการดูแลรักษาเซิร์ฟเวอร์ โดยเหมาะกับ Microservice, การประมวลผลข้อมูลแบบเรียลไทม์, เว็บแอปพลิเคชันที่มีภาระงานที่เปลี่ยนแปลงได้ และการประมวลผลเหตุการณ์
สถาปัตยกรรมแบบ Serverless ตามเหตุการณ์
สถาปัตยกรรมแบบ Serverless ตามเหตุการณ์เป็นสถาปัตยกรรมการประมวลผลแบบ Serverless ที่เฉพาะเจาะจงซึ่งอาศัยเหตุการณ์หรือทริกเกอร์เพื่อเริ่มการทำงานของฟังก์ชันหรือ Microservice คอมโพเนนต์ของระบบจะสื่อสารผ่านเหตุการณ์ และ มีการเรียกใช้ฟังก์ชันเพื่อตอบสนองต่อเหตุการณ์ ซึ่งมักจะใช้การสื่อสารแบบไม่พร้อมกันเนื่องจากเหตุการณ์จะทริกเกอร์โดยเหตุการณ์ จากนั้นจะประมวลผลแบบอิสระ และอาจสร้างเหตุการณ์ที่จะทริกเกอร์การดำเนินการตามมาหลังจากนั้น สถาปัตยกรรมแบบ Serverless ประเภทนี้เป็นตัวเลือกที่ดีในการสร้างระบบที่รองรับการปรับขนาด ปรับเปลี่ยนตามอุปกรณ์ และมีการเชื่อมต่อแบบหลวมๆ
Google Cloud Functions และ Cloud Functions for Firebase ช่วยให้คุณสร้างและทำให้ฟังก์ชันที่ขับเคลื่อนด้วยเหตุการณ์ใช้งานได้ในสภาพแวดล้อมแบบ Serverless ที่มีการจัดการครบวงจร ซึ่งช่วยให้คุณเรียกใช้โค้ดเพื่อตอบสนองต่อเหตุการณ์และทริกเกอร์ต่างๆ ได้ ซึ่งรวมถึงคำขอ HTTP, ข้อความ Cloud Pub/Sub, การเปลี่ยนแปลงใน Google Cloud Storage, การอัปเดตฐานข้อมูลเรียลไทม์ของ Firebase โดยไม่ต้องจัดการโครงสร้างพื้นฐาน ฟีเจอร์สำคัญๆ ได้แก่ การรองรับหลายภาษา ความสามารถในการปรับขนาด การเรียกเก็บเงินแบบละเอียด การผสานรวมกับบุคคลที่สาม การบันทึกและการตรวจสอบที่มีประสิทธิภาพ ตลอดจนการผสานรวมกับบริการอื่นๆ ของ Google และ Firebase
สถาปัตยกรรมแบบ Serverless เป็นวิธีที่คุ้มค่าสำหรับกรณีการใช้งานจำนวนมาก โดยเฉพาะอย่างยิ่งสำหรับแอปพลิเคชันที่มีภาระงานที่แตกต่างกัน ความต้องการในการพัฒนาอย่างรวดเร็ว และการรับส่งข้อมูลที่คาดเดาไม่ได้ ความเสถียรจะขึ้นอยู่กับผู้ให้บริการระบบคลาวด์ โดยมีข้อตกลงระดับการให้บริการ (SLA) เพื่อให้มั่นใจว่าเป้าหมายด้านประสิทธิภาพและความเสถียรมีความเฉพาะเจาะจง คุณต้องประเมินกรณีการใช้งานและข้อกำหนดเฉพาะเพื่อระบุว่าสถาปัตยกรรมแบบ Serverless เป็นตัวเลือกที่ดีที่สุดหรือไม่
การขนส่งด้วยคอนเทนเนอร์
การขนส่งด้วยคอนเทนเนอร์ช่วยให้แอปพลิเคชันและ Dependency ของแอปพลิเคชันต่างๆ รวมอยู่ในคอนเทนเนอร์น้ำหนักเบาและพกพาสะดวก แพลตฟอร์มนี้มีสภาพแวดล้อมของแอปพลิเคชันที่สอดคล้องกัน ซึ่งรองรับการพัฒนาและการติดตั้งใช้งานในระบบและแพลตฟอร์มต่างๆ แพลตฟอร์ม Serverless บางแพลตฟอร์มมีความสามารถในการเรียกใช้ภาระงานที่มีคอนเทนเนอร์ การเรียกใช้คอนเทนเนอร์ภายในสภาพแวดล้อมแบบ Serverless อาจมีประโยชน์เมื่อคุณมีภาระงานที่ซับซ้อนหรือเก็บสถานะซึ่งไม่สามารถแสดงเป็นฟังก์ชันพื้นฐานได้ มอบความยืดหยุ่นในด้านการรองรับภาษาและสภาพแวดล้อมรันไทม์
Cloud Run เป็นแพลตฟอร์มการประมวลผลแบบ Serverless ที่ช่วยให้นักพัฒนาซอฟต์แวร์ติดตั้งใช้งานและเรียกใช้แอปพลิเคชันที่มีคอนเทนเนอร์ในสภาพแวดล้อมที่มีการจัดการครบวงจรได้ มอบวิธีที่ตรงไปตรงมาในการสร้าง ทำให้ใช้งานได้ และปรับขนาดแอปพลิเคชันโดยไม่ต้องจัดการโครงสร้างพื้นฐานที่สำคัญ เหมาะสำหรับแอปพลิเคชันบนเว็บและ Microservice มากมาย โดยเฉพาะอย่างยิ่งแอปพลิเคชันที่มีภาระงานแปรผันได้ รวมถึงในกรณีที่การขนส่งด้วยคอนเทนเนอร์ให้ประโยชน์ในแง่ของการแพ็กเกจและความสอดคล้องของแอปพลิเคชัน
สถาปัตยกรรม Microservice
แอปพลิเคชันจะแบ่งออกเป็นส่วนเล็กๆ ที่เชื่อมต่อกันอย่างหลวมและใช้ฟีเจอร์หรือความสามารถที่แตกต่างกัน บริการเหล่านี้อาจสื่อสารผ่านข้อความแบบไม่พร้อมกัน ช่องทางตามเหตุการณ์ หรือโดยตรงด้วยการแสดงอินเทอร์เฟซ แต่ละบริการได้รับการพัฒนา ทดสอบ และปรับขนาดแยกกันในคอนเทนเนอร์ของบริการ ซึ่งมักจะจัดการผ่านบริการการจัดการเป็นกลุ่ม เช่น Kubernetes หรือติดตั้งใช้งานด้วยแพลตฟอร์มที่มีการจัดการ เช่น Cloud Run
การติดตั้งใช้งาน Microservice มักจะใช้ประโยชน์จากรูปแบบแอปพลิเคชันแบบ Serverless ด้วยการไม่พึ่งพาเซิร์ฟเวอร์ส่วนกลาง
การแยกแอปพลิเคชันเป็นบริการแบบอิสระสามารถลดความซับซ้อนของระบบที่ซับซ้อนได้ ขอบเขตและวัตถุประสงค์ที่กำหนดไว้อย่างชัดเจนจะช่วยเร่งการพัฒนาและปรับปรุงการบำรุงรักษา แต่ละบริการขนาดเล็กสามารถพัฒนาได้อย่างอิสระโดยใช้เฟรมเวิร์กหรือเครื่องมือที่มีประสิทธิภาพมากที่สุด การสื่อสารระหว่างบริการมักจัดการโดยใช้เหตุการณ์ การสื่อสารการเผยแพร่การสมัครรับข้อมูล ไปป์ไลน์ข้อความ หรือการเรียกใช้โพรซีเยอร์ระยะไกล เช่น gRPC
สำหรับการจัดการงานต่างๆ ภายในสถาปัตยกรรม Microservice ให้พิจารณาใช้เฟรมเวิร์กที่รองรับแพลตฟอร์มที่คุณกำหนดเป้าหมาย ความลึกที่เพียงพอสำหรับงานและประเภทเวิร์กโฟลว์ที่คุณจัดเป็นกลุ่ม ตลอดจนการจัดการข้อผิดพลาดและการวัดและส่งข้อมูลทางไกลเพื่อแก้ไขข้อบกพร่อง ตัวเลือกยอดนิยม ได้แก่ Conductor หรือข้อเสนอจากผู้ให้บริการคลาวด์ เช่น Google Workflows
แอปพลิเคชันแบบ Microservice อาจซับซ้อนในการพัฒนาและบำรุงรักษาเนื่องจากลักษณะการกระจายตัวและความจำเป็นสำหรับการสื่อสารภายในบริการ ดังนั้น การจัดการการทำให้ใช้งานได้ การตรวจสอบ และการบันทึกจึงมีความซับซ้อนมากกว่าตัวเลือกสถาปัตยกรรมอื่นๆ เนื่องจากความเสถียรจะขึ้นอยู่กับสถาปัตยกรรมของแต่ละบริการ ลักษณะแบบกระจายอาจช่วยให้มีความยืดหยุ่นมากขึ้น โดยเฉพาะอย่างยิ่งเมื่อมีการใช้และเปิดใช้งานการตรวจสอบและการวัดและส่งข้อมูลทางไกลหากจำเป็น
การเปรียบเทียบสถาปัตยกรรมต่างๆ สำหรับแบ็กเอนด์เว็บแอปพลิเคชันที่ขับเคลื่อนด้วยเนื้อหา
ตารางต่อไปนี้จะเปรียบเทียบสถาปัตยกรรมกับข้อกำหนดสำคัญสำหรับแบ็กเอนด์ของเว็บแอปพลิเคชันที่ขับเคลื่อนด้วยเนื้อหา
| สถาปัตยกรรมแบบโมโนลิธ | สถาปัตยกรรมแบบ Serverless ที่อิงตามเหตุการณ์ | สถาปัตยกรรมแบบ Serverless | |
|---|---|---|---|
| ความซับซ้อนและการบำรุงรักษา |
|
|
|
| ความสามารถในการปรับขนาดและประสิทธิภาพ |
|
|
|
| การปรับตัวและกลยุทธ์สำรอง |
|
|
|
| ประสบการณ์การพัฒนา |
|
|
|
| ค่าใช้จ่าย |
|
|
|
ดูข้อมูลเพิ่มเติมเกี่ยวกับสถาปัตยกรรมแบ็กเอนด์สำหรับเว็บแอปพลิเคชันที่ขับเคลื่อนด้วยเนื้อหา
ต่อไปนี้เป็นแหล่งข้อมูลบางส่วนเพื่อเรียนรู้เพิ่มเติมเกี่ยวกับสถาปัตยกรรมสำหรับเว็บแอปพลิเคชันที่ขับเคลื่อนด้วยเนื้อหา รวมถึงวิธีย้ายข้อมูลแอปไปยังสถาปัตยกรรมอื่น
- ดูข้อมูลเพิ่มเติมเกี่ยวกับสถาปัตยกรรมแบ็กเอนด์ของเว็บแอปที่เชื่อมต่อแบบหลวม รวมถึงเว็บแอปพลิเคชันแบบโมโนลิธแบบ Serverless แบบลำดับชั้น