中台能带来看的见的好处：
1. 引用 6 楼 `某个大佬觉得相似的业务功能为什么要两个团队单独维护`,同样功能的代码只写一次并由同一个团队维护
2. 针对公司的编码规范可以出台对应的编码方案，以 spring 为例，rest 接口的请求参数、返回对象和异常码返回等可以通过提供 starter 的方式统一起来，当公司内部人员发生调动时，能快速适应代码
中台的困难：
1. 很多功能可能广泛存在于不同系统，例如用户管理等，但具体到每个不同系统中他们可能又有些许差异，而中台在编码时不可能完全考虑到所有情况，而业务侧一旦产生需求，可能没有时间等待中台去做升级
2. 中台对于企业有个很严重的问题就是产出很难量化，即使你做了很多工作但是没办法表示你的产出，做的再好业务端没有产出也没用，当业务端有产出时也很难量化中台在其中的作用，因此对于大多数公司而言中台是一个纯投入型的项目
针对困难 1 ，比较好的方式是，中台在提供功能时同时提供扩展性，例如使用 SPI 或 spring factory 这种机制，业务侧在对现有功能提出需求时，优先向中台发起请求，中台评估该新功能或增强是否应该由中台完成，以及给出相应时间计划，时间不允许的情况下，业务侧再自行完成需求，后续看情况将代码合进中台。
显然这种方式也会带来困难 2 ，业务侧觉得，功能都是我提交上去的，我做了中台的事，要你中台干嘛，在特别极端的情况下甚至会出现由于某个项目的领域特别新，使用的技术要求较高，一段时间内长期向中台提供内容而并未从中台获利，从公司整体而言这部分功能只要有其他业务也在使用当然是赚的，但对于这个项目组而言就不一样了。
中台的管理问题更大于技术问题。

1. logback 有 DBAppender
2. 如果需要自定义日志内容请参考[美团的这篇文章]( https://tech.meituan.com/2021/09/16/operational-logbook.html)
3. 如果有条件建议上 loki ，有 docker-plugin ，集成方便。

聊天的话无所谓，一般不会聊天打字还校验几遍，正式文档那又是另一回事了，出现错字是 0 容忍的

文件本身应该是都会读取的吧，重复的按优先级取值？我是这么理解的，另外好像有个 bootstrap 是预先读取，在 application 之前

LG 27UL650-W +1

https://www.evanmiller.org/how-not-to-sort-by-average-rating.html
这个好像是个挺老的了，不过应该够用

keycloak

这两天摆弄了下，这里顺便分享下遇到的问题和感受吧，
springboot3 主要亮点就是 graalvm ，打包 native-image ，
1. pom 里改好相关插件的配置，
2. 我本机是 windows ，所以需要下载 MSVC 的一套组件，然后必须得在“Developer Command Prompt for VS” 这个终端里执行构建命令。
3. 打包出来 jar 包是 73M ，exe 文件是 137M ，启动确实是秒启动，但是 install 的时间上去了，这个对开发人员的体验还不好说，目前 IDEA 感觉适配还不大行
4. 聊一下遇到的兼容性问题，目前 Mybatis 已经出了 3.0 版本，升上去就行，但是 MybatisPlus 还不行。Knife4j 这个文档项目则是由于 javax （需要 jakarta ）的问题也暂时不能用。这个 jakarta 的问题应该大多数项目都会遇到。然后就是 apache.commons.logging 也有个奇怪的问题，由于我没用这个包是阿里云 osssdk 用的，也没继续研究（直接把这个包去掉了）。
后面会再试下 docker 构建，总之目前来说旧项目升级还不是很适合。
graalvm 启动时间是快，但是如果编译时间上去了感觉对开发环境来说并不是太友好
以上

这个东西`nginxWebUI`符合你的需求，不过这个目前不太适合用于 k8s 的环境，只适合单机部署， 我不了解 docker swarm ，不清楚用 docker swarm 和 k8s 的区别，所以还需要你自行判断

快递区：老猫鱼不吃鱼
书画区：周观鱼 UP
医学科普：兔叭咯
理论物理区：茂的模
计算机：Ele 实验室
财经：付鹏的财经世界
文学：天真的和感伤的小说家
生物学：龙女之声、芳斯塔芙
蹭热点的：太阳星 sunstar （这个内容深度和上面差很多）

从描述上看

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

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

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

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

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

什么情况应该拆分了呢？
（ ps: 将“生成 Excel 、PDF 这个块”简称模块 A ）
1. 模块 A 很占资源，长期占用大量内存、cpu ，以至于影响本来的业务。
2. 模块 A 速度太慢，想并发执行，需要启动多个实例跑。
拆分之后如何调用呢？
1. 整体换成微服务架构，微服务提供完整的服务间调用、路由、限流等功能。
2. 使用 mq 通讯即可。

loki ，docker 有 loki 的插件很方便，但是你的'这个请求又发到哪个机器上去了'需求，这应该属于链路追踪了，需要其他方案，简单一点日志里加入 traceId ，重一点用链路追踪工具

部署的机器一点都不能动的话，好像只有 10 楼说的 appendor 这种方式了，不然像 promtail 什么的都可以采集，docker 还有 loki 的插件。

helm 或者 k8s operator ，rancher 上有部分可以提供 GUI 操作

为什么看 blog 发布时间是 20 年呀