1.1 สถาปัตยกรรมแอปพลิเคชัน
หลักสูตรนี้ออกแบบมาสำหรับผู้เริ่มต้น เนื่องจากคุณจะไม่ได้ออกแบบสถาปัตยกรรมของแอปพลิเคชันที่จริงจังเป็นเวลานาน แต่ไม่ต้องกังวล สถาปัตยกรรมที่ดีเป็นข้อยกเว้นมากกว่ากฎ การเลือกสถาปัตยกรรมแอปพลิเคชันที่เหมาะสม ก่อนสร้างแอปพลิเคชันเป็นเรื่องยากมาก
ตัวอย่างของสถาปัตยกรรมยอดนิยมสำหรับแอปพลิเคชันเซิร์ฟเวอร์ขนาดใหญ่:
- สถาปัตยกรรมแบบเลเยอร์ (Layered Architecture)
- สถาปัตยกรรมฉัตร.
- สถาปัตยกรรมเชิงบริการ (SOA)
- สถาปัตยกรรมไมโครเซอร์วิส (Microservice Architecture)
แต่ละคนมีข้อดีและข้อเสีย แต่การศึกษาพวกเขาจะไม่ให้อะไรเลย สถาปัตยกรรมคือคำตอบสำหรับคำถาม"วิธีจัดระเบียบปฏิสัมพันธ์ของวัตถุนับพันภายในระบบ" . และจนกว่าคุณจะพบกับความซับซ้อนทั้งหมดของปัญหา คุณจะไม่สามารถเข้าใจความอเนกประสงค์ทั้งหมดของโซลูชันได้
แอปพลิเคชันทั้งหมดใช้สถาปัตยกรรมบางประเภทหรืออย่างน้อยก็หลอกใช้ ดังนั้น ความรู้เกี่ยวกับวิธีการที่นิยมในการออกแบบแอปพลิเคชันจะช่วยให้คุณเข้าใจวิธีการทำงานของแอปพลิเคชันได้อย่างรวดเร็วและดีขึ้น และนั่นหมายถึงการเปลี่ยนแปลงตรงจุดที่คุณต้องการ
“ทำการเปลี่ยนแปลงที่จำเป็น” หมายความว่าอย่างไร มีสถานที่ใดบ้างที่คุณไม่จำเป็นต้องทำการเปลี่ยนแปลง อย่างแน่นอน.
พูดให้เจาะจง สมมติว่าคุณกำลังทำงานในโครงการแบ็กเอนด์ขนาดกลาง มันถูกเขียนขึ้นเป็นเวลา 5 ปีโดยทีมงาน 20 คน โครงการนี้ใช้เวลา 100 ปีและมีโค้ดประมาณ 100,000 บรรทัด โดยรวมแล้วประกอบด้วยสองพันคลาสซึ่งแบ่งออกเป็น 10 โมดูลที่มีขนาดต่างกัน
และเพิ่มความเป็นจริงที่รุนแรง ตรรกะของงานบางอย่างกระจายไปหลายโมดูล นอกจากนี้ ตรรกะทางธุรกิจสามารถอยู่ในส่วนหน้า (เขียนด้วย JavaScript) และ/หรือเขียนเป็นขั้นตอนการจัดเก็บโดยตรงในฐานข้อมูล คุณยังแน่ใจหรือไม่ว่าคุณสามารถกำหนดสถานที่ที่จะทำการเปลี่ยนแปลงได้ ทันที ?
นี่ไม่ใช่ฝันร้ายที่ฉันสร้างขึ้นเพื่อทำให้คุณกลัว นี่เป็นโครงการทั่วไป มันยิ่งเลวร้ายลงไปอีก ทำไมสิ่งนี้ถึงเกิดขึ้น? อาจมีหลายสาเหตุ แต่มักจะมีสาเหตุดังต่อไปนี้:
- ผู้คนจำนวนมากทำงานในโครงการ - แต่ละคนเห็นว่าแตกต่างกันเล็กน้อย
- เป็นเวลา 5 ปีมีการเปลี่ยนแปลง 10 คนในโครงการผู้มาใหม่ไม่เข้าใจมากนัก
- การสร้างซอฟต์แวร์เป็นการเปลี่ยนแปลงอย่างต่อเนื่องที่เปลี่ยนแปลงทุกสิ่งอย่างต่อเนื่อง
- เมื่อห้าปีที่แล้ว เมื่อเราตัดสินใจเลือกสถาปัตยกรรม แนวคิดของโครงการค่อนข้างแตกต่างออกไป
แต่สิ่งสำคัญคือไม่ว่าสถาปัตยกรรมของโครงการจะเป็นแบบใด โปรแกรมเมอร์ทุกคนที่ทำงานอยู่บนนั้นล้วนยึดมั่นในความเข้าใจเดียวกันว่าโครงการนี้ทำงานอย่างไร เริ่มจากแนวคิดที่ง่ายที่สุด - สถาปัตยกรรมไคลเอ็นต์เซิร์ฟเวอร์
1.2 แนวคิดของการโต้ตอบระหว่างไคลเอ็นต์และเซิร์ฟเวอร์
ตอนนี้เราจะเข้าใจแนวคิดที่อยู่ภายใต้ สถาปัตยกรรม ไคลเอนต์เซิร์ฟเวอร์และจะช่วยให้คุณเข้าใจได้ดีขึ้นว่ามีการจัดระเบียบการทำงานร่วมกันของโปรแกรมนับล้านบนอินเทอร์เน็ตอย่างไร
ตามชื่อที่แสดง แนวคิดนี้เกี่ยวข้องกับสองฝ่าย: ไคลเอ็นต์และเซิร์ฟเวอร์ ทุกอย่างเป็นเหมือนชีวิตที่นี่: ลูกค้าคือลูกค้าของบริการนี้หรือบริการนั้นและเซิร์ฟเวอร์คือผู้ให้บริการ ไคลเอนต์และเซิร์ฟเวอร์เป็นโปรแกรม ทางกายภาพ ตัวอย่างเช่นไคลเอนต์ทั่วไปคือเบราว์เซอร์
ตัวอย่างต่อไปนี้สามารถให้เป็นเซิร์ฟเวอร์ได้:
- เว็บเซิร์ฟเวอร์ เช่น Tomcat
- เซิร์ฟเวอร์ฐานข้อมูล เช่น MySQL
- เกตเวย์การชำระเงินเช่น Stripe
โดยปกติแล้วไคลเอ็นต์และเซิร์ฟเวอร์จะสื่อสารผ่านอินเทอร์เน็ต (แม้ว่าจะสามารถทำงานในเครือข่ายท้องถิ่นเดียวกันและโดยทั่วไปในเครือข่ายประเภทอื่นๆ) การสื่อสารเกิดขึ้นผ่านโปรโตคอลมาตรฐาน เช่น HTTP, FTP หรือโปรโตคอลระดับล่าง เช่น TCP หรือ UDP
โดยปกติจะเลือกโปรโตคอลตามประเภทของบริการที่เซิร์ฟเวอร์ให้บริการ ตัวอย่างเช่น หากเป็นการสนทนาทางวิดีโอ มักใช้ UDP
จำได้ไหมว่า Tomcat และเซิร์ฟเล็ตของมันทำงานอย่างไร? เซิร์ฟเวอร์ได้รับข้อความ HTTP แตกไฟล์ ดึงข้อมูลที่จำเป็นทั้งหมดจากที่นั่น และส่งไปยังเซิร์ฟเล็ตสำหรับการประมวลผล จากนั้นผลการประมวลผลจะถูกบรรจุกลับเป็นการตอบสนอง HTTP และส่งไปยังไคลเอ็นต์
นี่คือการโต้ตอบระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ทั่วไป เบราว์เซอร์เป็นเว็บไคลเอ็นต์และ Tomcat เป็นเว็บเซิร์ฟเวอร์ Tomcat เรียกว่าเว็บเซิร์ฟเวอร์ด้วยซ้ำ
แต่ถ้าคุณลองคิดดู ไม่ใช่ชื่อที่สำคัญ แต่เป็นสาระสำคัญ - การกระจายบทบาทระหว่างโปรแกรม สคริปต์ JS ของคุณที่ทำงานในหน้า HTML อาจเรียกได้ว่าเป็นไคลเอ็นต์และเซิร์ฟเล็ตของคุณก็เรียกว่าเซิร์ฟเวอร์ ท้ายที่สุดแล้ว พวกเขาทำงานเป็นคู่ภายใต้กรอบแนวคิดไคลเอนต์-เซิร์ฟเวอร์
1.3 ความแตกต่างที่สำคัญ
นอกจากนี้ยังเป็นที่น่าสังเกตว่าการโต้ตอบระหว่างไคลเอนต์กับเซิร์ฟเวอร์นั้นขึ้นอยู่กับหลักการที่การโต้ตอบดังกล่าวเริ่มต้นโดยไคลเอ็นต์ : เซิร์ฟเวอร์จะตอบไคลเอนต์และรายงานว่าสามารถให้บริการแก่ไคลเอนต์ได้หรือไม่ และถ้าเป็นเช่นนั้น เงื่อนไขใด .
ไม่สำคัญว่าลูกค้าจะอยู่ที่ใดและเซิร์ฟเวอร์อยู่ที่ใด ซอฟต์แวร์ไคลเอนต์และซอฟต์แวร์เซิร์ฟเวอร์มักจะติดตั้งในเครื่องที่แตกต่างกัน แต่สามารถทำงานบนคอมพิวเตอร์เครื่องเดียวกันได้เช่นกัน
แนวคิดนี้ได้รับการพัฒนาเป็นขั้นตอนแรกในการทำให้ระบบที่ซับซ้อนง่ายขึ้น เธอมีจุดแข็งเหล่านี้:
- การทำให้ตรรกะง่ายขึ้น : เซิร์ฟเวอร์ไม่รู้อะไรเกี่ยวกับไคลเอนต์และจะใช้ข้อมูลอย่างไรในอนาคต
- อาจมีไคลเอนต์ที่อ่อนแอ : งานที่ต้องใช้ทรัพยากรทั้งหมดสามารถถ่ายโอนไปยังเซิร์ฟเวอร์ได้
- การพัฒนารหัสลูกค้าและรหัสเซิร์ฟเวอร์อย่างอิสระ
- ไคลเอ็นต์ต่างๆ มากมาย เช่น Tomcat และเบราว์เซอร์ต่างๆ
การโต้ตอบเวอร์ชันพื้นฐานที่สุดระหว่างไคลเอนต์และเซิร์ฟเวอร์แสดงอยู่ในรูปภาพ:
สิ่งสำคัญคือต้องทราบรายละเอียดสองประการที่นี่ อันดับแรก รูปภาพแสดงให้เห็นว่าไคลเอ็นต์จำนวนมากสามารถเข้าถึงเซิร์ฟเวอร์เดียวได้ ประการที่สอง พวกเขาสามารถเข้าถึงได้ในเวลาเดียวกัน นี่เป็นส่วนสำคัญของเซิร์ฟเวอร์
ไคลเอ็นต์หนึ่งรายมักจะโต้ตอบกับผู้ใช้หนึ่งราย ดังนั้นบ่อยครั้งที่ไม่จำเป็นต้องมีการอนุญาต อย่างไรก็ตาม เซิร์ฟเวอร์ประมวลผลคำขอจากลูกค้าหลายพันราย และเมื่อพัฒนาโค้ดสำหรับไคลเอ็นต์ คุณต้องสามารถแยกความแตกต่างระหว่างการอนุญาตและการพิสูจน์ตัวตนได้
สิ่งสำคัญคือเซิร์ฟเวอร์ต้องประมวลผลคำขอหลายพันรายการพร้อมกัน และนั่นหมายความว่าเมื่อพัฒนาโค้ดส่วนหลัง คุณจะต้องคิดถึงงานในการเข้าถึงทรัพยากรพร้อมกันอยู่เสมอ นอกจากนี้ รหัสเซิร์ฟเวอร์มีความเป็นไปได้สูงที่จะเกิดสภาวะการแข่งขัน (การแข่งขันของเธรด) การหยุดชะงัก (การปิดกั้นเธรดร่วมกัน)
ต้องตรวจสอบวงจรชีวิตของวัตถุที่สำคัญ:
คุณไม่สามารถเริ่มเธรดใหม่บนเซิร์ฟเวอร์new Thread().start()ผ่าน คุณต้องมี ThreadPool ที่จะแชร์ระหว่างเธรดบริการทั้งหมดแทน
นอกจากนี้ คุณไม่สามารถเริ่มงานแบบอะซิงโครนัสได้ เนื่องจากงานเหล่านั้นจะถูกดำเนินการในเธรดที่แยกจากกัน เมื่อสร้างงานดังกล่าว คุณควรทราบเสมอว่ากลุ่มของเธรดใดกำลังดำเนินการอยู่ และจะเกิดอะไรขึ้นหากกลุ่มดังกล่าวล้น
การทำงานกับไฟล์และไดเร็กทอรีทั้งหมดต้องทำผ่านการลองใช้ทรัพยากร หากในแอปพลิเคชันปกติคุณลืมปิดสตรีมหรือไฟล์ นั่นเป็นปัญหาหรือไม่ มันจะปิดตัวเองเมื่อคุณออกจากโปรแกรม แต่ถ้าคุณลืมปิดไฟล์บนเซิร์ฟเวอร์ที่ใดที่หนึ่งในรหัสและเซิร์ฟเวอร์ของคุณทำงานมาหลายเดือนแล้ว ... ในไม่ช้าไฟล์ที่ไม่ได้ปิดดังกล่าวนับพันจะสะสมและระบบปฏิบัติการจะหยุดเปิดไฟล์ใหม่สำหรับการอ่าน (ทำงานกับไฟล์ ถูกควบคุมโดยระบบปฏิบัติการ) Teamlead จะไม่ลูบหัวคุณ...
1.4 สถาปัตยกรรมไคลเอ็นต์-เซิร์ฟเวอร์
อีกจุดสำคัญ สถาปัตยกรรมไคลเอนต์เซิร์ฟเวอร์กำหนดเฉพาะหลักการทั่วไปของการโต้ตอบระหว่างคอมพิวเตอร์รายละเอียดของการโต้ตอบนั้นกำหนดโดยโปรโตคอลต่างๆ
แนวคิดนี้ (ไคลเอ็นต์-เซิร์ฟเวอร์) บอกเราว่า เราจำเป็นต้องแบ่งเครื่องบนเครือข่ายเป็นเครื่องไคลเอ็นต์ซึ่งต้องการบางอย่างเสมอ และเครื่องเซิร์ฟเวอร์ซึ่งให้สิ่งที่พวกเขาต้องการ ในกรณีนี้ ไคลเอนต์จะเริ่มต้นการโต้ตอบเสมอ และโปรโตคอลที่อธิบายถึงกฎที่การโต้ตอบเกิดขึ้น
สถาปัตยกรรมปฏิสัมพันธ์ระหว่างไคลเอ็นต์กับเซิร์ฟเวอร์มีอยู่สองประเภท ประเภทแรกเรียกว่าสถาปัตยกรรมไคลเอ็นต์เซิร์ฟเวอร์ แบบสองชั้น ประเภทที่สองคือสถาปัตยกรรมไคลเอนต์เซิร์ฟเวอร์หลายระดับ (บางครั้งเรียกว่า สถาปัตยกรรมสามชั้นหรือสถาปัตยกรรมสามชั้น แต่เป็นกรณีพิเศษ)
หลักการทำงานของสถาปัตยกรรมสองชั้นของการโต้ตอบระหว่างไคลเอนต์และเซิร์ฟเวอร์คือการประมวลผลคำขอเกิดขึ้นบนเซิร์ฟเวอร์หนึ่งโดยไม่อ้างอิงถึงเซิร์ฟเวอร์อื่นในกระบวนการของการประมวลผลนี้
รูปแบบการโต้ตอบไคลเอนต์เซิร์ฟเวอร์สองชั้นสามารถวาดเป็นไดอะแกรมอย่างง่าย
ที่นี่คุณจะเห็นว่าระดับแรกคือทุกอย่างที่เกี่ยวข้องกับไคลเอ็นต์ และระดับที่สองคือทุกอย่างที่เกี่ยวข้องกับเซิร์ฟเวอร์