ระบบการจัดการพื้นหลัง springboot-plus v2.7.18

springboot-plus เป็นระบบแบ็กเอนด์การจัดการที่ใช้ SpringBoot 2 ซึ่งรวมถึงการจัดการผู้ใช้ การจัดการองค์กร การจัดการบทบาท การจัดการจุดฟังก์ชัน การจัดการเมนู การจัดสรรสิทธิ์ การจัดสรรสิทธิ์ข้อมูล การสร้างโค้ด และฟังก์ชันอื่นๆ

ระบบนี้ใช้เทคโนโลยี Spring Boot2 และส่วนหน้าใช้ Layui2 ฐานข้อมูลใช้ MySQL เป็นตัวอย่าง และเป็นแพลตฟอร์มข้ามฐานข้อมูลในทางทฤษฎี

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

ต่อไปนี้เป็นข้อแตกต่างระหว่างระบบเสาหิน ระบบขนาดเล็ก และไมโครเซอร์วิส

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

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

2. ง่ายต่อการแก้ไข หากคุณต้องการแก้ไขฟังก์ชั่นใด ๆ ก็สะดวกมาก คุณจะต้องแก้ไขโค้ดภายในขอบเขตของโครงการเท่านั้น

3. การทดสอบนั้นง่ายดาย ไม่จำเป็นต้องพิจารณาระบบอื่นเมื่อทำการทดสอบระบบเดียว และหลีกเลี่ยงการเรียก REST และ MQ ต่างๆ ที่กล่าวถึงในเล่มที่สองของหนังสือเล่มนี้

4. การ Deployment นั้นง่ายมาก: ไม่จำเป็นต้องคำนึงถึงความสัมพันธ์กับระบบอื่น ๆ เพียงแค่ทำแพ็คเกจ War Package และปรับใช้กับเว็บเซิร์ฟเวอร์

5. ประสิทธิภาพขยายได้ง่าย และแอปพลิเคชันสามารถนำไปใช้กับเซิร์ฟเวอร์หลายเครื่องผ่าน Nginx

ด้วยการพัฒนาธุรกิจและการสร้างใหม่ จะมีระบบเสาหินมากขึ้นเรื่อยๆ เมื่อพัฒนาระบบเสาหินขนาดใหญ่ จะมีข้อเสียดังต่อไปนี้:

1. ระบบเดียวมีขนาดใหญ่และยากขึ้นเรื่อยๆ ที่จะเข้าใจระบบเดียว การเปลี่ยนแปลงเล็กๆ น้อยๆ เกี่ยวข้องกับแง่มุมต่างๆ มากมาย ทำให้ทีมพัฒนาระมัดระวังและความเร็วในการพัฒนาจะช้าลงเรื่อยๆ นอกจากนี้ การเริ่มต้นระบบเดียวขนาดใหญ่อาจใช้เวลา 3 นาทีขึ้นไป

2. มีการพัฒนาฟังก์ชันหลายอย่างบนระบบเดียว ส่งผลให้การทดสอบช้าลงและช้าลง เช่น การทดสอบต้องกำหนดเวลาและการทดสอบแบบอนุกรม

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

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

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

1. ระบบไอทีแบบดั้งเดิมยังคงใช้ฐานข้อมูลเป็นหลัก ในขณะที่ไมโครเซอร์วิสสนับสนุนบริการเดียวและฐานข้อมูลเดียว

2. ระบบไอทีแบบเดิมแทบไม่ต้องเรียกใช้บริการโมดูลอื่นๆ ระบบไอทีแบบดั้งเดิมเชื่อมต่อระบบย่อยอื่นๆ ผ่านเวิร์กโฟลว์ ไมโครเซอร์วิสอีคอมเมิร์ซโต้ตอบผ่าน RPC และวิธีการอื่นๆ ซึ่งเป็นโปรโตคอลขนาดเล็ก ระบบไอทีแบบดั้งเดิมยังสามารถโต้ตอบกับระบบอื่นๆ (ที่ไม่ใช่ระบบย่อย) ผ่าน SOA และ JMS โดยใช้โปรโตคอลรุ่นหนา

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

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

สำหรับผู้ใช้ การเข้าถึงฟังก์ชั่นเมนูต่างๆ จะค้นหาระบบย่อยที่แตกต่างกันและให้บริการ