大家好。
关于系统设计菜鸟求问
背景：有一个业务系统，是 springboot 应用，大而全，所有业务功能都放在里面。
想法：因为业务流程中有一些异步方法或是耗时很大的功能 /方法，想把这些功能剥离成一个单独的应用(会部署在同一个服务器上面)，比如调用第三方服务发送短信，或是生成 Excel 、PDF 文件等。
问题：这是不是可以用微服务这个概念来解决？或是就单纯地再起一个应用(大概率还是 Java)，那主应用和这个新的基础服务应用应该用何种方式通讯呢？ http 应该是不合适吧？

微服务包括服务间的调度和熔断，按照你的描述我觉得你单独搞个服务 HTTP 访问是最方便的，由内部业务变成网络请求

微服务肯定比巨石要容易维护，但你这个问题和微服务没关系。异步方法就用异步的交互方式好了，至于把他们都硬捏到一块么？譬如你举的这几个例子，都可以前端轮询的方式去查结果啊。

反正我导出 Excel 就是这样处理，服务端导出后上传文件到 OSS ，然后把文件的 url 写到数据库里面。前端查到 url ，就显示下载按钮。你看，这不是很简单？

这种其实适合 serverless ，在 serverless 实现具体的业务逻辑。

没啥不合适，springcloud 就是用的 http 。
看你的描述应该不是什么大并发的需求，单独拆成 springboot 跑也没啥问题啊。

上微服务是杀鸡用牛刀了，另外起一个用胶水语言写的提供发送短信、生成 excel 、PDF 等服务功能的服务，通过消息队列调用就好了。

直接起各公共服务，http 调用就好了

为啥要拆服务，是 Java 不支持多线程了么？

就拆出一个单独的模块，然后 api 设计为异步，搞个线程池不就完了。

坚决反对拆无必要模块的想法。

坚决拥护单体应用 @

CompletableFuture

单独拉个模块，集中管理队列、线程池就够了
除非有成熟团队，否则坚决反对拆项目

你这个需求，搞个异步任务就行了

微服务通讯本质也是互相发请求，http 虽然不是针对微服务这场景做的协议，但一般也够用了，如果并发特别大才要用 rpc ，太菜了还没遇到过瓶颈是因为通讯协议

完全同意，只需要一个异步 /后台 任务系统。

从描述上看

会部署在同一个服务器上面

这说明应用没有性能压力，只是由于异步且耗时较大所以想拆分。而微服务并不解决这个问题。

大而全，所有业务功能都放在里面。

这里我觉得想法应该是觉得这块异步的功能比较独立，想拆分出来让代码更好管理一点。这个没问题，但是像楼上说的代码层面单独拆出一个模块就好了。

综上，从你的描述上看应该是不必拆分的。

什么情况应该拆分了呢？
（ ps: 将“生成 Excel 、PDF 这个块”简称模块 A ）

1. 模块 A 很占资源，长期占用大量内存、cpu ，以至于影响本来的业务。
2. 模块 A 速度太慢，想并发执行，需要启动多个实例跑。
   拆分之后如何调用呢？
3. 整体换成微服务架构，微服务提供完整的服务间调用、路由、限流等功能。
4. 使用 mq 通讯即可。

要明白服务切分的意义。例如隔离影响、方便服务扩展和加机器。

如果流量不大属实没什么必要切分，分开后你要多处理各种异常情况，后续如果有新增什么复杂功能你可以提议新增一个服务避免影响旧服务。

自己搞个线程池 异步跑一下就行
当然有时间折腾分拆一个服务也可以

RSocket Broker

问个问题， 如果把项目拆分成多个功能独立的子服务，子服务可以独立部署，服务之间通过 http 或者 rpc 相互调用，没有 api 网关，没有服务注册与发现，只是单纯的拆分成多个服务，这样可以叫微服务吗？

通讯方式 MQ 、Redis 、数据库 都行。

异步任务类的，不建议直接请求。

能拆就拆，早期拆分成本还会低点，不然一台服务挂了，全都 jgg ， 通信的话，Http 或者 Mq 都行

+1

如果是生成 excel 、pdf 台占用服务器资源，可以拆分到单独服务
如果是仅处理时间过长，应将业务使用后台任务处理