这时候我就不得不又引用 V 友说的了：

搞个备案很简单的。

@Chad0000 #15
以后隔阂会越来越大，大大增加了外资进入的难度。

你尽管自研折腾，就算兼容安卓，国外 APP 基本上只会上 Google Play ，国内各种厂家的平台都不上。

@xuanbg #13
好吧，确实不够大胆。

床上运动后再睡，再不行就增加运动时长。

@nzynzynzy #53
那是相当有可能，也就是回一次国我才发现国内的 APP 相当臃肿，我才觉得 APP 经常被杀，内存不够用，比如谷歌导航和高德导航的区别（尤其是会导致手机发热）。甚至连使用都不够简洁，习惯了谷歌导航的简洁直观后，一下子无法快速适应国内导航 APP 。

PS 我当时用的还是 7P 。

楼上很多人真是矫情，自认为是 Pro 的人，公布一下自己买的配置就行了。不是所有人都追求高内存，即使同样是开发。比如我 C#，我开发不用 Docker （当然我也不用 Mac ），8G 是够的，只是 16G 会更好，32G 更更好。有的人选择了够用就行，有的人非得说没高刷就是残废（我用我老婆的 15PM 开了高刷，体验了一会儿就关了，有一些区别，但没那么大）。

@Sean46
嗯，就是这个。我都把方案搞出来了，开始写代码了，才看到这个框架。当然我也用不到因为我是 C#

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

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

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


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

基于此：

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

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

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

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

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

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

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

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

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