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.*