千呼万唤始出来，太忙了太忙了，本次带来腾讯云COS对象存储。也是因为搞项目正好用到COS，所以就记录下来，希望对大家有所帮助。

快一个月没有更新文章了，太忙了太忙了，虽然慢了一点，但是我肯定不会断更。上一篇文章是《Mysql主从复制》，光是数据库层面的主从复制可不行，应用层面也是需要读写分离的，所以接上一篇文章我们来讲如何通过Sharding-JDBC实现应用读写分离。

前面我们学习了基于Langchain4j的大模型的很多玩法，今天我们把这些玩法整合成一个综合案例：智能挂号系统，案例不会特别复杂，主要功能包括医疗问答，挂号咨询，预约挂号，取消挂号等几个功能，其中会使用到的技术包括：RAG知识库，回话记忆功能，Tools的使用，流式输出，提示词等等，希望该案例可以一点打面，给你更多的遐想，那么下面我们就开始吧。我们的tools会比较复杂，因为智能挂号相关的能力都主

比较传统的小型应用通常是一个项目使用一个数据库进行数据存储，这样的架构模式在数据量日益增长的情况下，数据库势必会成为性能瓶颈。几百万数据还可以通过数据库优化，索引优化等手段勉强支持，但是上千万，上亿的数据再怎么优化索引都无济于事。所以我们的优化手段可以是分库分表。

本篇文章介绍了RAG的优势和必要性，通过搭建PGVector本地向量数据库，使用Langchain4j创建RAG知识库的全过程。如果文章对你有帮助请一定三连哦，你的鼓励是我最大的动力！！！

前面的章节中我们并没有使用流式输出，不使用流式输出的问题在于内容是一次把内容全部输出，这个过程可能伴随着等待，当大模型响应的数据较多的时候，那么用户需要等待很久才能看到输出结果，所以本篇文章我们使用Langchain4j的流式输出功能。文件结束，本文介绍了如何通过langchin4j提供的reactor依赖让大模型支持流式输出，在企业级开发中流式输出肯定是必备的。如果文章对你有帮助请给个好评吧！！

在实际开发中我们通常需要协调多个大模型一起完成工作，如果使用过类似coze的工作流就能明白，很多时候一个任务是由多个环节构成的。对于大模型而言，每次用户提问它不应该去访问所有的tools，这样做很危险，会消耗大量的token，而且会带来一些意想不到的问题。正确的方式应该是根据不同的提问类型调用不同的tools做出相应的处理，如下图：本篇文章我们通过Lanchain4j实现根据用户的不同提问类型，调

今年莫名其妙的网上就冒出来一句话：前端已死后端已亡，然后就会有很多人说工作不好找，要求高等等，本人也是在编程领域混迹了很多年，今天我们就来客观的分析一下，现在互联网到底是一个什么情况。

在实际项目开发中有大量的通用功能比如发短信，文件上传等。SpringBoot提供了便利的方式支持我们对公共业务功能进行抽取封装，本篇文章是基于SpringBoot定义starter，以短信为例，定义通用的starter组件实现短信的发送。...

问题：软件的迭代过程包括，设计，编码，编译，构建，测试，发布，运维等等流程，早期的软件开发模式为瀑布式开发，这种开发模式迭代更新太慢，每个环境都需要耗费大量人力和时间成本。往往很长时间才迭代一次。如今企业追求的都是敏捷开发：快速开发快速迭代，尽可能的缩短软件的开发生命周期。DevOps 强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软