我倒是比较理解楼主的技术使用场景，因为我现在也做 tob 的服务。

tob 的服务最赚钱的肯定是一些 SaaS 平台类型的，比如钉钉、飞书、WPS 云盘之类的。但是还有很多 tob 服务只是比较弱势的工具型软件，企业会要求私有化布署或者像我们是布署在企业自己买的云里面，不是物理机。

像我们这样的服务场景，需要布署大量高度重复性的小型系统。管理的机器非常多。有多少客户就要管理多少个小型集群。每个集群的机器有时候是一台，有时候是两三台，但一般不会超过五台。

这样的环境里面使用互联网常用的微服务体系是很不适应的。可以想象一下在一台 4c8g 机器里面跑 spring cloud.

我大概看了一下楼主的项目，与其说是微服务，不如说是宏服务：

1. 项目仍然是单体应用，通常服务跑在一个进程里面。所以一个简单的事务不会变成复杂的分布式事务。
2. 粒度更大。
3. 与 spring 的依赖注入类似，但 spring 在注入的时候写清楚了类型。eight 项目在这些类型之上再次抽象出接口，注入的时候使用 osgi 加载并初始化。

【 在 jekler 的大作中提到: 】
: 本人做过些toB项目，深感当前的互联网技术对企业不友好，尤其是微服务和云架构，绝非大部分企业的理想选择。所以最近这些年一直在寻找解决方案。
: 最近一段时间我们研发了一种具有潜力的新技术，采用独特的设计思想，具备微服务的优点而没有它的缺陷。
: 现在尚在初期，但已经有了平台底座和线上演示环境，看上去还挺有趣。希望能为未来的企业应用带来新思路。
: ...................
--
修改:hgoldfish FROM 110.81.1.*
FROM 110.81.1.*

k8s 的用户是互联网软件行业。我前面说过了，互联网公司一般会弄很大规模几百台机器组成的单一集群。所以他们的技术不适合你是正常的。但你的技术框架也不适合他们啊。

而对于定制型的 tob 应用，你做的 eight 是有用的，但是 eight 框架是侵入性的，而 k8s 是非侵入性的。所以从项目推广上恐怕会非常难：

1. 做企业应用受甲方的限制，不能随心所欲。不是你想改就能改的，甲方认为有风险或者没有预算就做不下去。所以我才说你这个适合新项目，想改造老旧的项目恐怕很难。

2. 做企业应用的团队大多数技术水平不怎么样，技术离互联网团队差很多。

3. 很多传统行业对 IT 不止不重视还鄙视，程序员不如服务器值钱，压根不配搞信息化。财大气粗的石油、银行等好的客户也瓜分完了。咱一般人还是别碰这个领域了。说得难听一点，程序员累死累活为那些客户多赚了几百亿，他们又会分给乙方多少钱呢。

4. 最近几年，互联网行业被大厂压得喘不过气来。所以有些以前做互联网的现在也搞企业应用。可能会习惯性用 k8s 等互联网常用的技术。

从技术角度看，你那个思路和以前的 DCOM 很像。连命名都差不多。可以看作你把 Java 变成了动态语言，所以便于组装起来。我上个帖子是真的看完你写的几篇文章和两个 PDF 得出的结论，不是拍脑袋哦。

【 在 jekler 的大作中提到: 】
: 所以你终于认真点了，不过到底是没看懂。
: 原理如何，架构如何其实不值得说太多，因为osgi和spring都是古老技术，架构根本不需要我去说。
: 真正关键的正是你觉得很绕没有聚焦的地方。这里是原理，谈的是依赖，讲的却是模块化和解耦的问题。微服务之所以诞生还把现在系统搞得这么复杂就是因为过去几十年这个事情就没做好。如果能做好，20年前的技术就能解决掉你们的问题。
: ...................
--
修改:hgoldfish FROM 110.81.1.*
FROM 110.81.1.*