@kkk9 #6
问题他它可以让你随时回到单体或者微服务架构。“后悔”来得及。谷歌好像也在搞一个类似的框架，可独立也可同进程，go 写的。忘了名字了。

我也在给公司拆单体，我的方案更柔和：

- 先确保每个服务（我这里是模块）的独立性，尽量不要引用其他模块
- 模块功能抽象成接口，功能定义和实现分离
- 提出运行环境的概念，即负责跑这些模块的层
- 运行环境也负责对调用者返回实际实例
- 将大部分常见操作抽象，实现放运行层，即避免模块接触实现细节
- 模块只管触发事件，不订阅
- 设定一个统一的业务模块负责订阅所有消息，再通过运行层调用其他模块


关键部分：
- 一个运行环境可以托管任意个模块，如果模块调研在同一个环境则直接本地调用。
- 迁移过程中基本上只有一个运行环境就是单体本身，本地调用不影响性能
- 模块和它抽象的接口在单体完成依赖注入，这样单体可以直接调用新的模块
- 之后你可以实现跨运行环境通讯，也就是 RPC
- 可以将经常调用的模块放同一个运行环境中，以提升性能
- 模块所需基础能力（数据库访问/配置读取/缓存访问等）都抽象并由运行环境提供后，那么模块基本上可以动态加载了

基于此：

- 如果运行环境只跑一个模块，那就是微服务
- 如果运行环境跑所有模块，那就是单体
- 介于两者之间的，那就是混合模式
- 上述设计保障了只要你在运行环境你就可以访问所有模块
- 考虑到业务模块订阅了所有消息，那么每个运行环境都部署一个业务模块会避免更多的 RPC

目前这个计划实施得相当好。

@tanxnative #5
flink stateful function 。这个东西有用，后者暂时应该没用。

@shenjinpeng #6
不做中间件，是想设计一套框架直接就约束每个模块这样做。

@sumarker #4
数据库读写分离我知道，它能提升性能，但无法做到隔离影响，即模块自己的表修改后，相应的跨表查询之类全部都会受影响。

甚至有些特殊场景，比如查询性能要求高，那么原数据库和查询数据库可能就不是一种数据库。

@vacuitym #3
对，我的设计是想让每个模块都是完全独立不依赖其他模块，所以跨模块可能影响没那么大。

@mars2023 #1
嗯，就是类似微服务的设计。但我想把这个设计变成基础设施/约束，即平台本身就是这样设计的。

@gongquanlin #111
不是很同意 angular 落后的这个说法，要说它太重/深了还可以。

可能要打击一下 OP ，现在这些小工具基本上都可以交给 ChatGPT 了，更多时候它做得更好。

10：新买几天没注意
11：完成 25 次 5 分钟的体能训练

每月挑战在哪里设置？

访问量不高的情况下：直接保存在 DB 中，也不缓存，哈哈。

如果是我，我选择支持家人。

如果不是编译 iOS APP 必须得用 Mac ，它会比这个低很多。比如至少我就不用带着两个 Mac 设备了。