你可以把帖子看完在发帖。我敢说你没做过企业应用，不然不会拍脑门。
我就问你个问题，1.8这个lts你知道最低的操作系统版本兼容到哪里？linux和windows都说下。
【 在 sleepddd 的大作中提到: 】
: “只需要java1.6”并不是个值得夸耀的事情。
: 1.8
: 11 LTS
: ...................
--
FROM 221.217.52.*

你说呢？大聪明？替换需要花六年时间呢！你要能轮一个给你几百万刀一点问题没有。毕竟全球那么多机场，延误一次就不止这个价了。
你们啊，就是嘴炮打得响，实操就一群小白。活该失业！
【 在 JulyClyde 的大作中提到: 】
: 仅仅是懒而已
: 难道这功能必须这软件实现么？
--
FROM 221.217.52.*

过誉，我不好高骛远，坦率说这个东西还很初期。
但是，它要解决的问题确实是客观存在的问题，并非凭空想象。并且不是一两年了，而是最近20年技术转向互联网化后没人替企业做考虑的恶果。这个问题其实影响很严重。大量企业不得不在沉重的云负担和20年前初浅的技术方案间做选择，企业系统化水平很低。
这对未来国家大力发展企业数字化智能化，技术转向企业是一个制约。
现在这东西只是个雏形，存在问题也是在所难免，所以我欢迎大家认真看看用一下提出技术见解。但我认为这个方向没有问题，关于“你就是个啥都不懂的民科”，“你这就是不懂前沿技术在闭门造车”这类的言论我会不给面子怼回去。得罪勿怪。
【 在 licy 的大作中提到: 】
: 做到这个规模很厉害
:
:
--
FROM 221.217.52.*

所以你们的思路就是让客户去适应你们喽，不适应就是客户水平不行。给你们这帮大牛点赞。
【 在 hgoldfish 的大作中提到: 】
: 确实。有些技术团队非常的凑合。都是能力所限，能够把当前的软件改到稳定状态，没有明显 BUG 就已经劳心费力，精疲力竭，更没有动力去改造大的系统。
: 像这种架构型的框架，只能吸引新的项目。
:
--
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.*