你搞笑了，你就是你们一贯bs企业用户的话术罢了。你看那个新闻，你准备客户怎么换jdk？换啥版本？客户的关键应用最多只能用在windows xp上，windows xp能用啥jdk你敢说你懂吗？java1.7而已，或许你认为1，6是垃圾，1.7就是高大上的互联网时代产品？还是你觉得你的解决方案就是nb哄哄的用高大上的golang和rust给客户论一个机场空管系统，反正这老东西都几十年历史了？呵呵，我看你也就只会吹而已。
【 在 JulyClyde 的大作中提到: 】
: 那种连jdk都不换的系统，是不会做改造去适配你这个的
--
FROM 221.217.52.*

可惜大多数javaer还在坚守1.8，还有我再这样坚守1.6的。
另外你可能不知道1.8比11的存活期更久。
【 在 JulyClyde 的大作中提到: 】
: 1.8其实也太老……
: 至少11LTS吧
: 好歹是一个值得托bang付si的版本
--
FROM 221.217.52.*

嗯嗯，你们都nx，顺带就给企业都升级操作系统了。只在嘴皮子上顺带就是不见有啥具体方案。
倒是企业用上我的系统后，能够逐渐先集成传统应用，然后逐渐在这个平台上一个模块一个模块迁移应用，不至于影响企业既有业务，最终做到“顺带”升级至最新版本jvm，从而拜托对底层操作系统的依赖。
你们也就光说不练的水平而已。
【 在 jyw 的大作中提到: 】
: 赞同，既然都做微服务改造了，Java 版本升级顺带就做了，甚至可以认为是理所应当的
:
--
FROM 221.217.52.*

你有几点就没搞明白。
在国内做saas没什么前景，你去问问国企央企政府谁用公有saas？合规就不允许！什么叫做“自主可控“？saas符合那一条？连公有云都不会去用更别提saas。
剩下的大一点的企业，有钱点的都是自建云，不是他们业务复杂到必须上云而是没有选择。
再剩下的就是没钱小企业了，他们不是不想私有化，只是没钱没选择。所以saas就是一群搞互联网思维的闭门造车的程序员自嗨的产物，不想着解决企业核心关注，又不愿承担企业内部定制和运维的承重负担，为图自己方便罢了。结果是坑次坑次费半天力做了个自觉很nb的企业应用，却发现找不到客户，只收罗一批每年付费意愿不超过1k还能不停抱怨的用户。做saas死的不要太多太多。

其次，你应该没有认真看过eight，否则你的见解就不会南辕北辙。eight既不是所谓单体的宏服务，也不是对spring做了层抽象，osgi加载。
eight可以做到比所谓微服务更细粒度的动态加载和系统可观测，以前所谓服务组成的系统，可以在一个进程内成为组件组装的系统。如果用在你们熟悉的互联网云框架上，也能大大减少微服务数量，使得整体系统更为简洁，调用链更简单，局部故障更少，网络流量更少，资源消耗更少。同时还保证你们所需要的模块独立分治，分组开发，不定周期局部迭代一点不少的满足。并且更新与升级更快更平滑，资源消耗更少。
至于你或许以为这个事情不过就是osgi加点spring很容易就搞定。但滑稽的是无论osgi还是spring资格都比微服务老多了，如果他们这么easy就解决你们微服务花了老鼻子劲又是服务注册又是服务发现又是故障检测又是分布式状态维持又是调用链跟踪。。。才勉强做到的事情，微服务根本就不可能诞生。
仔细说，为何靠osgi做不到这一点而eight为何能做到，我为何要开发这个架构写那么多奇怪的代码，尽管我在线上介绍里写清楚原理了，但估计你压根理解不了。
这并不奇怪，自以为是的人太多。
【 在 hgoldfish 的大作中提到: 】
: 我倒是比较理解楼主的技术使用场景，因为我现在也做 tob 的服务。
: tob 的服务最赚钱的肯定是一些 SaaS 平台类型的，比如钉钉、飞书、WPS 云盘之类的。但是还有很多 tob 服务只是比较弱势的工具型软件，企业会要求私有化布署或者像我们是布署在企业自己买的云里面，不是物理机。
: 像我们这样的服务场景，需要布署大量高度重复性的小型系统。管理的机器非常多。有多少客户就要管理多少个小型集群。每个集群的机器有时候是一台，有时候是两三台，但一般不会超过五台。
: ...................
--
FROM 221.217.52.*

说的接近了一些，但我把解决方案说的很清楚。
只不过你也没看明白，或者还没认识到，所谓代码耦合，所谓类或接口依赖，实质是思维依赖。如果解除这个依赖，即便是Java这种所谓“静态语言”也能表现出惊人的可变化性，如果解除不了，即便你们把系统拆解成微服务物理隔离，也是牵一发而动全身，修改一个核心服务影响的范围都是不可控。所以说起来微服务就是程序员们对复杂系统如何隔离分治感到穷途末路的产物，才是没有从根本上解决。所以，eight的线上系统就是用eight做的，全是由一堆部件组合起来的。你可以看看有没有解决问题。毕竟talking is cheap不是吗？

如何解决思维上彼此关联和思维依赖问题，这才是提供一组固定不变共识接口的原因。共识接口原本并不是为解决java的class依赖造成loader无法卸载设计的，虽然它客观上确实起到这种作用。它的关键在于对人的模块设计思维进行约束，也就是通过约束可用谓词来约束人对事物的表达，依靠的是共同经验的人对相同的事物有相似的表达，来使不同的开发者在开发彼此关联的模块时不需要（深入）沟通就能构建相互独立又彼此能够连接的模块。这样的组件自然是独立而少依赖的，自然容易被集成，动态装卸和更新。这就是原理。

说具体一点，给你个模块：实现一个爬虫模块，它从互联网上收集文本信息（它本身不含网页抓取模块）并按关键字计数保存。你把这个需求给你手下三个程序员，让他们独立开发不要讨论接口和实现细节，看看会写出来啥。约定只能使用共识接口的processor和resource族接口，看看写出来啥，几个人实现的差异如何？然后再让一个人用这两套接口实现一个抓取模块，另一个人实现一个关键字计数存取模块，都独立开发，完事你看组件能否装配在一起，如果不能，通过少许参数转化是否能够装配。

最后，如果抓取模块不是从web上来，而是从其它地方来（比如数据库），是否容易就此做一个小组件把功能动态替换掉。这种独立性和动态性从何而来认真思考下，只是因为他们用了相同的接口吗？他们不需要沟通就能做出来彼此能够结合的模块的根本原因是什么？原先固化在代码的依赖被解除后静态语言变得如此动态的原因又是什么？

我给你我的解答：这个模块需要一套输入，设计为一个iprocessor，输入一个key（url），返回一个ilistableresource，resource里面全是key（可以下钻检索）和value（文本内容）。需要一个输出iresource（为何不需要listable？），将关键字统计后作为key，count作为value放入该resource。
你回头看看你的下属做的模块跟这个差别有多大。
【 在 blackhill 的大作中提到: 】
: 共识接口，和微服务插件化
: 总结的对么？
: 看里面从哲学的角度探讨了大量问题，但感觉并没有从根本上去解决，看的粗略，妄谈见谅。
: ...................
--
修改:jekler FROM 221.217.52.*
FROM 221.217.52.*