springboot-plus adalah sistem backend manajemen berdasarkan SpringBoot 2, yang mencakup manajemen pengguna, manajemen organisasi, manajemen peran, manajemen titik fungsi, manajemen menu, alokasi izin, alokasi izin data, pembuatan kode, dan fungsi lainnya.
Sistem ini didasarkan pada teknologi Spring Boot2, dan bagian depannya menggunakan Layui2. Basis data menggunakan MySQL sebagai contoh, dan secara teoritis merupakan platform lintas basis data.
Plus adalah platform pengembangan cepat Java yang cocok untuk sistem monolitik dan pemisahan sistem. Ini juga dapat diubah menjadi platform layanan mikro (saya dulu membuatnya, tapi saya merasa Plus harus fokus pada inti sistem daripada sekadar menumpuk fungsi, jadi aku menyerah)
Berikut perbedaan sistem monolitik, sistem kecil, dan layanan mikro
Sistem monolitik adalah metode desain sistem yang umum, dan juga merupakan metode desain paling penting dalam sepuluh tahun terakhir. Semua fungsi dari satu sistem ada dalam satu proyek, dikemas ke dalam paket perang, dan dikerahkan. Hal ini mempunyai manfaat nyata sebagai berikut:
1. Metode pengembangan sistem tunggal itu sederhana. Ketika kita mempelajari pemrograman dari awal, pengembang hanya perlu berkonsentrasi pada pengembangan proyek saat ini.
2. Mudah untuk dimodifikasi. Jika Anda perlu memodifikasi fungsi apa pun, ini sangat mudah. Anda hanya perlu memodifikasi kode dalam lingkup proyek.
3. Pengujiannya sederhana. Tidak perlu mempertimbangkan sistem lain saat menguji satu sistem, dan menghindari berbagai panggilan REST dan MQ yang disebutkan dalam volume kedua buku ini.
4. Penerapannya juga sangat mudah: tidak perlu mempertimbangkan hubungan dengan sistem lain, cukup kemas paket perang dan terapkan ke server web
5. Performanya mudah untuk diperluas, dan aplikasi dapat diterapkan ke beberapa server melalui Nginx.
Dengan pengembangan dan rekonstruksi bisnis, terdapat semakin banyak sistem monolitik. Ketika mengembangkan sistem monolitik yang besar, akan terdapat kelemahan berikut:
1. Sistem tunggal sangat besar dan semakin sulit untuk memahami sistem tunggal. Perubahan kecil melibatkan banyak aspek, menyebabkan tim pengembangan berhati-hati dan kecepatan pengembangan akan menjadi semakin lambat. Selain itu, memulai satu sistem besar mungkin memerlukan waktu 3 menit atau lebih.
2. Beberapa fungsi dikembangkan pada sistem tunggal yang sama, sehingga pengujian menjadi lebih lambat dan lambat. Misalnya, pengujian harus terjadwal dan pengujian serial
3. Jika Anda ingin meningkatkan teknologi suatu sistem, biayanya akan sangat tinggi. Jika sistemnya kecil, Anda dapat memilih sistem kecil untuk dicoba terlebih dahulu. Secara teknis hampir tidak mungkin untuk mengupgrade satu sistem besar.
4. Semua fungsi dari satu sistem dijalankan di JVM yang sama, dan fungsi tersebut akan saling mempengaruhi. Misalnya, fungsi yang menghitung nomor halaman dokumen word yang diunggah akan menghabiskan banyak CPU tidak tersedia karena pemanggilan fungsi statistik. , fenomena mati suri muncul
Oleh karena itu, ketika merancang suatu sistem, semakin banyak arsitek yang akan mempertimbangkan untuk membagi sistem menjadi beberapa sistem kecil individual atau bahkan layanan mikro. Untuk aplikasi perusahaan tradisional, lebih tepat untuk membaginya menjadi sistem kecil. Untuk sistem Internet, lebih tepat menggunakan layanan mikro
1. Sistem TI tradisional pada dasarnya masih menggunakan database, sedangkan layanan mikro menganjurkan satu layanan dan satu database.
2. Sistem TI tradisional jarang perlu memanggil layanan modul lainnya. Sistem TI tradisional menghubungkan subsistem lain melalui alur kerja. Layanan mikro e-niaga berinteraksi melalui RPC dan metode lainnya, yang merupakan protokol ringan. Sistem TI tradisional juga dapat berinteraksi dengan sistem lain (non-subsistem) melalui SOA dan JMS, menggunakan protokol kelas berat.
3. Layanan mikro memiliki persyaratan yang sangat tinggi pada infrastruktur sistem, seperti tata kelola layanan mikro, perpustakaan elastis, dll. Hanya sistem e-niaga yang memiliki sumber daya manusia dan material untuk melakukan hal semacam ini, sedangkan sistem TI tradisional, meskipun berkantong tebal , tidak memiliki kemampuan layanan mikro untuk saat ini
Oleh karena itu, untuk sebagian besar aplikasi TI tradisional, tidak ada risiko teknis dalam memisahkan satu sistem kecil dan merupakan arsitektur yang dapat segera diimplementasikan. Berikut ini adalah arsitektur fisik sistem tunggal setelah pemisahan
Bagi pengguna, mengakses fungsi menu yang berbeda akan menemukan subsistem yang berbeda dan menyediakan layanan.