ส่วนที่ 2 มาพูดคุยกันเล็กน้อยเกี่ยวกับสถาปัตยกรรมซอฟต์แวร์

เนื้อหานี้เป็นส่วนหนึ่งของชุด " บทนำสู่การพัฒนาองค์กร " ส่วนแรกเกี่ยวกับเครือข่ายอยู่ที่ นี่ สถาปัตยกรรมซอฟต์แวร์เป็นโครงสร้างบนพื้นฐานของการสร้างแอปพลิเคชันและโมดูลและส่วนประกอบของโปรแกรมทั้งหมดโต้ตอบกัน โปรแกรมเมอร์พยายามสร้างสถาปัตยกรรมที่ดีมาเป็นเวลานาน ดังนั้นจึงไม่น่าแปลกใจที่ตอนนี้เรารู้รูปแบบสถาปัตยกรรมมากมายแล้ว คุณต้องเข้าใจสิ่งเหล่านี้: เมื่อคุณเขียนเว็บแอปพลิเคชัน ปัญหาของสถาปัตยกรรมจะรุนแรงขึ้น เนื่องจากมีส่วนประกอบและโมดูลมากกว่าในแอปพลิเคชันทั่วไป รูปแบบสถาปัตยกรรมเป็นวิธีที่คิดไว้แล้วในการแก้ปัญหาการออกแบบซอฟต์แวร์บางอย่าง คุณอาจเคยเจอรูปแบบการออกแบบ เช่น Factory Method, Abstract Factory, Builder, Prototype, Singleton และอื่นๆ ใช้เพื่อเขียนโค้ด สร้างคลาส และวางแผนวิธีการโต้ตอบ รูปแบบทางสถาปัตยกรรมถูกนำมาใช้ในระดับนามธรรมที่สูงขึ้น - เมื่อวางแผนการโต้ตอบของผู้ใช้แอปพลิเคชันกับเซิร์ฟเวอร์ ข้อมูล และส่วนประกอบอื่น ๆ ของโครงการ มาดูเทมเพลตบางส่วนและวิธีใช้งานกันดีกว่า

สถาปัตยกรรมไคลเอ็นต์-เซิร์ฟเวอร์

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

ส่วนประกอบของสถาปัตยกรรมไคลเอ็นต์-เซิร์ฟเวอร์

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

1. ลูกค้า - จากชื่อเป็นที่ชัดเจนว่านี่คือผู้ใช้บริการ (แอปพลิเคชันเว็บ) ที่ติดต่อเซิร์ฟเวอร์เพื่อรับข้อมูลบางอย่าง

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

3. เครือข่ายนั้นเรียบง่าย: ช่วยให้มั่นใจได้ถึงการแลกเปลี่ยนข้อมูลระหว่างไคลเอนต์และเซิร์ฟเวอร์

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

• ไคลเอ็นต์ - มีอินเทอร์เฟซแบบกราฟิกสำหรับการอนุญาต การส่ง/รับข้อความ

• ฝั่งเซิร์ฟเวอร์ - เว็บแอปพลิเคชันที่โฮสต์บนเซิร์ฟเวอร์และรับข้อความจากผู้ใช้ ประมวลผล และส่งไปยังผู้รับ

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

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

นี่คือรูปแบบสถาปัตยกรรมที่แนะนำผู้เล่นคนที่สาม: คลังข้อมูล เมื่อใช้รูปแบบนี้ โดยปกติแล้วทั้งสามระดับจะเรียกว่าเลเยอร์:

1. เลเยอร์ไคลเอนต์เป็นส่วนต่อประสานกับผู้ใช้ นี่อาจเป็นเว็บเบราว์เซอร์ที่ใช้ส่งหน้า HTML หรือแอปพลิเคชัน GUI ที่เขียนโดยใช้ JavaFX สิ่งสำคัญคือด้วยความช่วยเหลือผู้ใช้สามารถส่งคำขอไปยังเซิร์ฟเวอร์และประมวลผลการตอบสนองได้

2. เลเยอร์ลอจิกคือเซิร์ฟเวอร์ที่ใช้ประมวลผลคำขอ/ตอบกลับ มักเรียกอีกอย่างว่าเลเยอร์เซิร์ฟเวอร์ การดำเนินการทางลอจิคัลทั้งหมดเกิดขึ้นที่นี่เช่นกัน: การคำนวณทางคณิตศาสตร์ การดำเนินการข้อมูล การเรียกใช้บริการอื่น ๆ หรือการจัดเก็บข้อมูล

3. ชั้นข้อมูลคือเซิร์ฟเวอร์ฐานข้อมูล: เซิร์ฟเวอร์ของเราเข้าถึงข้อมูลดังกล่าว เลเยอร์นี้จัดเก็บข้อมูลที่จำเป็นทั้งหมดที่แอปพลิเคชันใช้ระหว่างการดำเนินการ

ดังนั้นเซิร์ฟเวอร์ของเราจึงรับภาระผูกพันทั้งหมดในการเข้าถึงข้อมูล โดยไม่อนุญาตให้ผู้ใช้เข้าถึงข้อมูลโดยตรง

ประโยชน์ของสถาปัตยกรรมสามชั้น

การใช้สถาปัตยกรรมดังกล่าวทำให้เราได้รับข้อดีหลายประการ รวมไปถึง:

1. ความสามารถในการสร้างการป้องกันจากการแทรก SQL คือการโจมตีเซิร์ฟเวอร์ซึ่งมีการส่งโค้ด SQL และเมื่อมีการเรียกใช้โค้ดนี้ ผู้โจมตีอาจส่งผลกระทบต่อฐานข้อมูลของเราได้

2. การกำหนดขอบเขตข้อมูลที่เราต้องการควบคุมการเข้าถึงของผู้ใช้

3. ความสามารถในการแก้ไขข้อมูลก่อนที่จะส่งไปยังลูกค้า

4. ความสามารถในการปรับขนาด - ความสามารถในการขยายแอปพลิเคชันของเราไปยังเซิร์ฟเวอร์ต่างๆ ที่จะใช้ฐานข้อมูลเดียวกัน

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

คุณควรใช้รูปแบบสถาปัตยกรรมบ่อยแค่ไหน?

หากคุณคุ้นเคยกับ รูปแบบการออกแบบFactory Methodคุณอาจสงสัยว่าเมื่อใดจึงควรใช้มัน บางครั้งมันก็ยากที่จะตัดสินใจว่าจะทำอย่างไร: สร้างวัตถุโดยใช้ตัวดำเนินการใหม่หรือใช้วิธีการจากโรงงาน แต่เมื่อเวลาผ่านไป ความเข้าใจก็มา ด้วยรูปแบบทางสถาปัตยกรรม สิ่งต่างๆ จึงแตกต่างออกไปเล็กน้อย เฟรมเวิร์กระดับองค์กรได้รับการออกแบบมาเพื่อให้โปรแกรมเมอร์ใช้เพื่อสร้างโปรเจ็กต์ตามรูปแบบที่เป็นที่ยอมรับโดยทั่วไป ดังนั้น ก่อนที่จะเรียนรู้ Spring Framework คุณต้องเข้าใจอย่างชัดเจนว่าสถาปัตยกรรมไคลเอนต์-เซิร์ฟเวอร์ สถาปัตยกรรมสามระดับ และสถาปัตยกรรม MVC คืออะไร ไม่ต้องกังวล เราจะพูดถึงสถาปัตยกรรม MVC ในภายหลัง ส่วนที่ 1. สิ่งที่คุณต้องรู้ก่อนเรียนรู้ Spring และ JavaEE ส่วนที่ 3. โปรโตคอล HTTP/HTTPS ส่วนที่ 4. พื้นฐาน Maven ส่วนที่ 5. เซิร์ฟเล็ต การเขียนแอปพลิเคชันเว็บอย่างง่าย ตอนที่ 6 คอนเทนเนอร์ Servlet ตอนที่ 7 แนะนำรูปแบบ MVC (Model-View-Controller) ตอนที่ 8 การเขียนแอปพลิเคชัน spring-boot ขนาดเล็ก