SpringBoot开发的AI导航站技术架构剖析 —— 技术如何选型 - 第520篇
idea springboot woff/woff2/eot/ttf/svg等小图标不显示的问题 - 第515篇
Noisee AI中文站网页版 AI 音乐生成视频全新登场，快来抢先体验——国内第一个登场的中文站来袭 - 516篇
Spring的SmartLifecycle可以没用过，但没听过就不好了！- 第517篇
SpringBoot异常处理机制之自定义404、500错误提示页面 - 518篇
SpringBoot 中多例模式的神秘世界：用法区别以及应用场景，最后的灵魂拷问会吗？- 第519篇
导读
在前面的几篇文章提到了AI导航站，想必有些小伙伴会很好奇，现在不都前后端分离了吗？为什么博主你前端的代码还和后端放在一起呐？
这个问题就是一个技术选型的问题？本篇文章想和小伙伴们谈谈技术选型的问题 —— 观点仅代表个人意见，仅供参考！
项目地址：http://ai.dzwlai.com/
AI导航站，汇总800+工具集合：
缘起
一直有个梦 —— 拥有自己的一个导航站，刚好最近一直在研究AI相关的知识，所以就想那就从AI导航站开始吧 —— 梦该醒了。
AI导航站的思考
技术在落地之前，还是需要一定的可行性的思考的，对于AI导航站的落地实现方式有两种：
（1）纯静态前端代码：这种方式是不需要后端的，只要会前端代码编写就可以，维护的时候只需要修改前端的代码或者配置文件即可。好处就是实现简单，不会后端也可以搞定；弊端就是没有后台维护起来会比较费劲。
（2）后端+前端代码：这种方式是需要后端的，导航站的信息数据都在后端进行管理和返回，前端只做页面的渲染。弊端就是实现难度会增加，好处就是维护可以通过后台进行维护。
对于想要自己的一个导航站的小伙伴，需要根据自己的实际情况进行实现。没有服务器预算的，如果是纯前端代码可以把代码放在一些平台上即可完成部署。
我这里使用的是后端+前端的实现方式。使用这种方式主要是基于以下进行思考：
（1）本身有现成的服务器在运行《AI写歌》的项目，关注公众号《SpringBoot》进行体验。
（2）希望自己可以通过后台进行维护，而不是每次维护都要修改代码，然后重新部署。—— O(∩_∩)O哈哈~ 我比较懒~
（3）我希望我开发的不仅仅是AI导航站，而是一个通用的导航站，可以根据不同的域名，展示不同的导航站。
AI导航站的技术架构
当对整体技术架构进行了规划，那么技术架构就可以慢慢落地了，当然在具体架构之前，还有一个点要思考，那就是要不要前后端分离：
（1）前后端分离：这种架构的好处，就是后端只需要提供接口，不需要懂前端的技术，另外就是一旦展示方式或者要多个前端网站，后端接口都不需要动。—— 前端只管前端，后端提供接口。
（2）前后端不分离：这种架构前端的代码逻辑和后端架构混合在一起，好处 就是开发效率，自己写接口，自己调用开发效率高；其次就是性能：由于前后端紧密结合，对于一些性能关键的场景，可以更方便地进行整体的优化。
总的来说：不管是使用哪种方式都是可以的，这个要根据实际情况进行选择。
我这里选择的是前后端不分离，主要是基于以下进行思考：
（1）对于vue框架不是很熟悉，对于html+js+css还是比较熟悉的；
（2）对于vue的单体应用不知道怎么进行SEO优化，对于html页面还是知道的；
（3）对于Spring MVC这种开发模式很熟悉；
（4）只有一个人开发，没有专业的前端配合。
到这里就可以确定技术架构了：
SpringBoot + MyBatis-Plus + MySQL + Thymeleaf
（1）SpringBoot：作为整个框架的核心，没的说。
（2）MyBatis-Plus：使用mybatis-plus进行数据库的操作，当然使用spring data jpa也是可以的。
（3）MySQL：使用MySQL进行数据的存储。
（4）Thymeleaf：使用Thymeleaf模板进行数据的渲染，当然这里你可以使用自己熟悉的模板引擎，比如：velocity、freemarker。我选择Thyemeleaf的音乐，是因为Thyemeleaf的模板文件还是html文件，不会破坏html结构。
对于表信息：导航中重要的两个核心信息是导航菜单以及对应的工具：NavMenu和NavTool，以下只提供关键字段：
（1）NavMenu：id（主键）、name（菜单名称）、icon（图标）、pid（父菜单）、type（类型，左边导航还是顶部导航）…
（2）NavTool：id（主键）、name（工具名称）、logo（logo）、menuId(菜单id)、url（链接地址）、description(描述)….
技术架构选型综合考虑点
（1）业务需求：
l 明确业务的功能和特性要求，例如是侧重数据处理、实时交互还是高并发访问。
l 考虑业务的未来发展和扩展性，能否支持业务规模的增长和功能的扩展。
n 比如一个电商平台，初期可能流量不大，但要考虑到促销活动时的高并发情况，以及未来增加新的业务模块如直播带货的可能性。
（2）性能要求：
l 评估系统的响应时间、吞吐量、资源利用率等性能指标的要求。
l 确定是否需要支持大规模数据处理和高速数据传输。
n 像金融交易系统，对响应时间要求极高，毫秒级的延迟都可能造成巨大损失。
（3）技术成熟度：
l 选择成熟稳定的技术，降低技术风险。
l 考察技术的社区支持和文档完善程度。
n 例如，Java 作为一种成熟的编程语言，拥有丰富的文档和强大的社区支持。
（4）开发效率：
l 考虑所选技术是否能提高开发人员的效率，减少开发时间和成本。
l 评估技术的学习曲线，是否易于团队成员掌握。
n 采用一些流行的开发框架，如 Spring Boot，可以提高开发效率。
（5）可维护性：
l 思考技术架构是否易于维护和故障排查。
l 代码的可读性和可扩展性如何。
n 良好的代码结构和模块化设计有助于后期的维护工作。
（6）安全性：
l 确保所选技术能够提供足够的安全保障，防止数据泄露和恶意攻击。
l 评估技术在身份验证、授权和加密方面的能力。
n 对于涉及用户隐私数据的系统，安全性至关重要。
（7）成本：
l 包括技术的许可费用、硬件成本、运维成本等。
l 考虑开源技术和商业技术的成本差异。
n 某些商业数据库软件可能需要高昂的授权费用，而开源数据库则可以节省成本。
（8）技术团队的技能水平：
l 结合团队成员现有的技术能力和经验，选择他们熟悉或能够快速上手的技术。
l 考虑是否需要为新技术进行培训和学习。
n 如果团队主要熟悉 Python 开发，那么选择基于 Python 的技术栈可能更合适。
（9）兼容性：
l 与现有系统和技术的兼容性，能否顺利集成。
l 考虑不同技术组件之间的兼容性。
n 新引入的数据库是否能与现有的应用服务器兼容。
（10）技术生态：
l 考察技术周边的工具和资源是否丰富，如测试工具、监控工具等。
l 第三方库和插件的可用性。
n 例如，JavaScript 拥有丰富的第三方库，可以满足各种功能需求。
总结
AI导航站整体的一个架构和开发还是不复杂的，博主在这里也这是把自己的一个思考过程和大家进行分享，在碰到技术的选型的时候要根据自身和团队的实际情况进行灵活的调整。
总之，技术架构选型是一个综合性的决策过程，需要全面权衡各种因素，以确保选择的技术架构能够满足业务需求，并为系统的长期稳定运行和发展提供有力支持。
历史文章（文章累计520+）《国内最全的Spring Boot系列之一》《国内最全的Spring Boot系列之二》《国内最全的Spring Boot系列之三》《国内最全的Spring Boot系列之四》《国内最全的Spring Boot系列之五》ES 深度分页问题及针对不同需求下的解决方案[ES系列] - 第509篇
抖音主播/电商人员有福了，利用Suno创作产品宣传，让产品动起来-小米Su7 - 第510篇
Spring Boot整合ElasticSearch实战 - 第511篇
Transaction rolled back because it has been marked as - 第512篇
一文讲清楚SpringBoot项目打包jar后运行报错template might not exist - 第514篇
idea springboot woff/woff2/eot/ttf/svg等小图标不显示的问题 - 第515篇
Noisee AI中文站网页版 AI 音乐生成视频全新登场，快来抢先体验——国内第一个登场的中文站来袭 - 516篇
Spring的SmartLifecycle可以没用过，但没听过就不好了！- 第517篇