สถาปัตยกรรมสามชั้น

รู้เบื้องต้นเกี่ยวกับสถาปัตยกรรมสามชั้น

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

ดูเหมือนว่า:

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

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

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

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

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

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

ชั้นข้อมูลให้การจัดเก็บข้อมูลและวางในระดับที่แยกจากกัน ดำเนินการตามกฎโดยใช้ระบบจัดการฐานข้อมูล (DBMS) การเชื่อมต่อกับคอมโพเนนต์นี้มีให้จากระดับแอปพลิเคชันเซิร์ฟเวอร์เท่านั้น

เหตุผลในการแยกชั้นข้อมูล

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

ประการแรกฐานข้อมูลเริ่มต้องการหน่วยความจำและเวลาประมวลผลจำนวนมากในการประมวลผลข้อมูล ดังนั้นพวกเขาจึงเริ่มวางทุกที่บนเซิร์ฟเวอร์ที่แยกจากกัน

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

ประการที่สองฐานข้อมูลกลายเป็นสมาร์ท - พวกเขามีตรรกะทางธุรกิจของตัวเอง พวกเขาเริ่มสนับสนุนกระบวนงานที่เก็บไว้ ทริกเกอร์ ภาษาของตนเองเช่น PLSQL และแม้แต่โปรแกรมเมอร์ก็เริ่มเขียนโค้ดที่ทำงานภายใน DBMS

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

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

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

สำคัญ! เทคโนโลยีขั้นสูงทั้งหมดเกิดจากส่วนลึกขององค์กรไอทีขนาดใหญ่ เมื่อแนวทางแบบเก่าไม่สามารถรับมือกับความท้าทายใหม่ๆ ได้อีกต่อไป การทำให้ฐานข้อมูลเป็นเลเยอร์แยกต่างหากไม่ได้ถูกคิดค้นโดยโปรแกรมเมอร์ แต่โดยกลุ่มวิศวกรที่อยู่ระดับลึกของ Oracle หรือ IBM

น่าสนใจ! เมื่อ Zuckerberg เริ่มเขียน Facebook เขาทำงานบน PHP + MySQL เมื่อมีผู้ใช้หลายล้านคน พวกเขาเขียนตัวแปลพิเศษที่แปลโค้ด PHP ทั้งหมดเป็น C ++ และคอมไพล์เป็นโค้ดเนทีฟของเครื่อง

นอกจากนี้ MySQL ไม่สามารถจัดเก็บข้อมูลของผู้ใช้หลายพันล้านคนได้ ดังนั้น Facebook จึงพัฒนาแนวคิดของฐานข้อมูล NoSQL และเขียน NoSQL DBMS ฝั่งเซิร์ฟเวอร์ที่มีประสิทธิภาพ - Cassandra อย่างไรก็ตาม มันเขียนด้วยภาษาจาวาทั้งหมด

ความคลุมเครือตำแหน่งตรรกะของแอปพลิเคชัน

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

ตัวอย่างของความไม่ชัดเจนดังกล่าวแสดงไว้ในภาพด้านล่าง:

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

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

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

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