我觉得像。
【 在 jekler 的大作中提到: 】
: 标  题: Re: 各位同学，我们在研发一种微服务的替代技术，欢迎交流
: 发信站: 水木社区 (Thu Jul 20 16:27:59 2023), 站内
:
: 搞笑了，我怼这帮小白看起来像招徕客户？
: 【 在 huihaoqilai 的大作中提到: 】
: : 您是来做广告的吧？
: --
:
: ※ 来源:·水木社区 http://m.mysmth.net·[FROM: 221.217.52.*]
--
FROM 171.41.73.*

我还是仔细捋一捋这里面的几个逻辑
1，微服务经常跟云架构混淆，然而两者并不相同，微服务出现比容器云早，之初并没有云做支撑也在用，配置管理挺复杂罢了。有了云容器后发现这东西很适合管理它的就是这样。
2，微服务架构主要就为解决一个问题，复杂系统的模块分治。它允许大型系统按模块分组开发，局部升级和迭代，而不是如单体应用那样几千几万人共用一个不可以维护的庞大项目。带来的是服务注册与发现，状态管理，服务监控，消息队列，调用链管理等等一堆服务。如果不用微服务，云容器里可以没有这堆服务。
3，云容器跟微服务无关，用不用微服务架构跟云环境没有必然关联。云容器还能提供节点扩容，负载均衡，故障转移，熔断降级等一堆支撑功能，这些功能无论是不是微服务架构都有可能用到。
4，综上，云容器不依赖微服务，但微服务很难不依赖云容器，否则维护和管理成本很高。但正是因为微服务把各种东西都混杂到了应用这一层，所以现在多数人也不区分是因为业务逻辑和模块独立而切割的服务，还是物理扩容的应用，还是提供数据的应用等等。
5，这些年企业的业务越来越复杂，他们急需解决方案，目前来说，他们上微服务只能上云，企业出于数据安全和业务可控的要求，天然需要私有化部署，这种情况下私有云解决方案给多数企业带来沉重负担。
6，标题里说的很清楚eight是微服务的替代方案而不是云架构的，解决的就是复杂系统开发，维护和迭代的问题。只不过它也实现在局部业务层的组件管理和可观测，这些功能有点类似云管理的应用实例。eight可以与云环境结合，提供一个更清晰层次的云架构，减少大量割出的服务，同时使用云提供的扩容，负载均衡等其他功能。
7，但eight也能单独使用，直接建立一个动态部署的企业应用集群并对之有效管理，这正是线上系统做的（目前很初级）。至于云提供的其他功能，如负载均衡，故障转移，熔断也并不是只有上k8s，简单的集群解决方案加一个可控的反向代理就行（如带脚本的openresty），仔细看看你们下载的demo那个应用，里面的router管理想想是用来干啥的？至于动态伸缩，只要eight节点启动了，上面随时可以伸缩不同应用。
8，简单说，企业只需要部署openresty，redis，eight节点等几个简单组件，就可以构建功能与k8s和微服务类似的体系，并且运行是私有化和内部化的，运维却可以外包。从而摆脱一定得要上云的依赖，所以，从这个角度来说也是云架构的一种廉价替代。这对多数企业来说是有重要意义的（互联网公司除外）
【 在 jekler 的大作中提到: 】
: 你不要沉湎于过去。线上平台就是用来管理java节点的，尽管还很初级。但要论比k8s和docker麻烦。。。呵呵
--
FROM 221.217.52.*

首先 微服务是不挑语言的
【 在 jekler 的大作中提到: 】
: 本人做过些toB项目，深感当前的互联网技术对企业不友好，尤其是微服务和云架构，绝非大部分企业的理想选择。所以最近这些年一直在寻找解决方案。  
:  
: 最近一段时间我们研发了一种具有潜力的新技术，采用独特的设计思想，具备微服务的优点而没有它的缺陷。  
:  
: 现在尚在初期，但已经有了平台底
: ..................

发自「今日水木 on SHARK KSR-A0」
--
FROM 115.196.238.*

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

传统行业信息化，我的经验是，
1、传统行业太多主观性的非逻辑性的内容了，随便找个工业领域的技术标准，用随便那种编程语言翻译一下，就会发现太多漏洞和不严谨的地方了。
2、全流程自动化比半自动人工可介入的自动化好做100倍，面向非严格理性人的信息比面向机器的信息麻烦太多。

真正的未来是，凡是理工类行业公司全员会编程，自己维护自己的微服务，并且产业结构重塑，产业标准重塑。

但可能这一天还没到来，机器人就已经替代人类了。

楼主开发的这种技术，小白不会用，大牛又怕被框架牵制。

楼主既然开源了，可能目的也不是把软件作为自己公司的利器，以第二方的身份用利器高效率的优势打败竞争对手为B方直接服务。

这种软件如果是美国顶级软件企业出身，母胎带着流量和光环，自然有人愿意去传播还行，否则太难了。

【 在 hgoldfish 的大作中提到: 】
: k8s 的用户是互联网软件行业。我前面说过了，互联网公司一般会弄很大规模几百台机器组成的单一集群。所以他们的技术不适合你是正常的。但你的技术框架也不适合他们啊。
: 而对于定制型的 tob 应用，你做的 eight 是有用的，但是 eight 框架是侵入性的，而 k8s 是非侵入性的。所以从项目推广上恐怕会非常难：
: 1. 做企业应用受甲方的限制，不能随心所欲。不是你想改就能改的，甲方认为有风险或者没有预算就做不下去。所以我才说你这个适合新项目，想改造老旧的项目恐怕很难。
: ...................
--
FROM 117.81.120.*