- 主题:各位同学，我们在研发一种微服务的替代技术，欢迎交流
这个完全想错了。我下阶段就是准备给企业提供2b业务，以更廉价的方式提供私有化部署的业务侧解决方案。至于推广倒是想多了，我没准备给太多人用。有兄弟能提供客户资源欢迎站内联系，倒是诸位想要用反而要注意下协议，需要得到授权的。版主要觉得这个算广告可以删了。
你说这堆都没说到点子上，关键不在于企业业务是不是你说的那么清晰，也不在于未来会不会按你想象的走到自动化（其实我看不出这些论点之间有何联系）。
做企业业务唯一的黄金定律是成本。企业只忠诚于成本和利益，其他都是扯，这原本就是理所当然的事情。你能用比别人更低的成本实现企业业务，你能报出别人n分之一的报价，你就能让你所有对手去死。
所以，为何要搞可以远程开发，远程部署，远程运维的私有化部署应用呢？
为何要搞高度隔离的可复用组件呢？
为何要搞少数几个基本应用就能跑起来的低成本集群呢？
至于推广不推广，市场接受不接受纯属多想。人在利益面前都是诚实的，什么大牌小牌？如果你们单纯从技术分析上都不得不承认这个方案的低成本，压根就不需要有太多推销。
所以，为什么你们会觉得我有动机去宣传推广呢？水木这小山头也不是什么宣传推广的好地方嘛。
最后，不得不提，你们把那些舶来品地位看得太高。这也是你们一听国内有个人做了些啥，第一反应是“这傻鸟，解决了一个根本不存在的问题”，第二反应是”不可能，这个问题国外肯定已经解决了，做的肯定更好”，第三反应是”就算是这样，你这也根本没有解决问题“所以，我才把东西直接在你们面前跑。但即便如此，还有第四反应“这也没有啥独到之处嘛”。
这也是你们把舶来的微服务这种蠢笨的架构奉若神明的原因。你们几十年如一日也只会跟在别人身后亦步亦趋，你们做过了啥？你们考虑过这个东西从根子上都可能是烂的吗？
所以你们学到一套屠龙之技，就满世界寻找恶龙。遇到问题只会一个劲劝企业上云，稍稍复杂一点用不了springboot简单解决的就只有这一招。无视一套私有云动辄几千万的建设成本，无视每年运维可能数百万的负担，最好还来一套serverless彻底把企业云绑定。仿佛支付不起的企业都是懒，或者穷，或者又懒又穷，不配享有高大上的现代技术。然而，企业有何义务支付这些溢价呢？如果一套方案，大多数企业都用不起，到底是哪里出了问题？这里存在一个巨大的供需失衡。
所以，我目前也只是需要敲门砖，根本不需要你们眼里国外牛企背书，也无意做什么技术推广。
【 在 blackhill 的大作中提到: 】
: 传统行业信息化，我的经验是，
: 1、传统行业太多主观性的非逻辑性的内容了，随便找个工业领域的技术标准，用随便那种编程语言翻译一下，就会发现太多漏洞和不严谨的地方了。
: 2、全流程自动化比半自动人工可介入的自动化好做100倍，面向非严格理性人的信息比面向机器的信息麻烦太多。
: ...................
--
修改:jekler FROM 221.217.52.*
FROM 221.217.52.*
然而，仔细理一理，你有想过微服务到底带来什么收益，付出什么代价？你觉得互联网公司用微服务（不谈云架构）就是走了正道？
归根到底，任何业务层系统面对的核心问题无非以下几条
1，系统越来越复杂，架构应当可以进行大规模的组织开发，升级和维护（最核心要求，系统分治）
2，系统应当跟随业务而不断变化，同时系统变化时最好能够保证业务持续在线（运行时部署和升级）
3，系统能够跟随业务规模而弹性伸缩。
4，系统能够感知运行时状态，对各种故障做出响应。
就是些，就这么简单的需求。海内外几十万各种p搞了十多年，掏出来个什么怪东西呢？你们谈论微服务谈的头头是道时自己没觉得有多丑？
这里面只有第一点是微服务试图去解决的，第二点跟微服务有点关系。第三四点都是云架构提供的能力，与微服务无关。但就是前两点，微服务那种臃肿，复杂，脆弱，低效意义又何在？你们前面几十个帖子，唯一能拿出来说的不过就是微服务可以用几种不同的语言开发罢了，如果这算个优点。即便如此，你们还是不承认微服务本身就是个彻底的失败品，毕竟你们在它身上投入了太多精力不是吗？
事实上，上面几条需求，我只需要一个eight集群（用于管理，分发，动态部署业务），一套redis（用于集群状态共享）就可以办到，最多在加一套openresty做第三四点。基本上就能办到以上所有需求，为何要上云？要上微服务？
这可以让企业只需雇佣两个北大青鸟的培训生，学会安装启动几个简单的应用，不需要大厂的大牛们屈尊到三线城市的小企业去负责企业系统管理。
可以让企业的应用运行在本地，运维集中外包给tob公司
可以让企业内部系统由专业的tob公司开发，组装，下发，升级，监控和维护，节省企业成本，提供系统质量
可以通过垂直行业的大规模组件复用，摊薄应用成本，提升系统质量
我可以给出你们云方案n分之一的报价，提供更为成熟优质的系统服务。
不要抱怨企业如何吝啬，如何不懂得赏识你们的价值。或许你们确实不值那么多。
就我所知的企业，不是舍不得花钱。即便是高度产品化的系统，也是少则几万多则几十万的每年费用，稍稍定制化一下，一百多万几百上千万的很常见。你们做toc，那些c们每个一年给你们多少收益？说到底，你们不过靠系统的复用摊薄了成本罢了。但对于企业这套不适用，你们既没办法让你们的体系架构复用，又抱怨企业不能像toc一样一套支付个几千万上亿的整体成本来体现你们所谓价值，你们不想想你们是哪里有问题以至于水土不服吗？
适应这个世界而不是让这个世界来适应你们。接点地气把。
【 在 hgoldfish 的大作中提到: 】
: k8s 的用户是互联网软件行业。我前面说过了，互联网公司一般会弄很大规模几百台机器组成的单一集群。所以他们的技术不适合你是正常的。但你的技术框架也不适合他们啊。
: 而对于定制型的 tob 应用，你做的 eight 是有用的，但是 eight 框架是侵入性的，而 k8s 是非侵入性的。所以从项目推广上恐怕会非常难：
: 1. 做企业应用受甲方的限制，不能随心所欲。不是你想改就能改的，甲方认为有风险或者没有预算就做不下去。所以我才说你这个适合新项目，想改造老旧的项目恐怕很难。
: ...................
--
FROM 221.217.52.*
呵呵，你真以为我说eight没打算给互联网公司用指的是这个吗？你要能找到微服务有啥优点算你赢（异构系统算不上什么优点我前面论述了）。
【 在 hgoldfish 的大作中提到: 】
: k8s 的用户是互联网软件行业。我前面说过了，互联网公司一般会弄很大规模几百台机器组成的单一集群。所以他们的技术不适合你是正常的。但你的技术框架也不适合他们啊。
: 而对于定制型的 tob 应用，你做的 eight 是有用的，但是 eight 框架是侵入性的，而 k8s 是非侵入性的。所以从项目推广上恐怕会非常难：
: 1. 做企业应用受甲方的限制，不能随心所欲。不是你想改就能改的，甲方认为有风险或者没有预算就做不下去。所以我才说你这个适合新项目，想改造老旧的项目恐怕很难。
: ...................
--
FROM 221.217.52.*
至于k8s非侵入性就纯扯了。eight对标微服务，跟k8s啥关系？eight不能上云？eight云原生好吧。
你们上微服务用微服务去拆服务，服务化改造不侵入？搞笑把你。自己把自己概念都绕晕了。
然后，eight上完全可以运行一个spring webapp或tomcat，不带改一行代码的。你啥都不知道就会武断拍脑门。
【 在 hgoldfish 的大作中提到: 】
: k8s 的用户是互联网软件行业。我前面说过了，互联网公司一般会弄很大规模几百台机器组成的单一集群。所以他们的技术不适合你是正常的。但你的技术框架也不适合他们啊。
: 而对于定制型的 tob 应用，你做的 eight 是有用的，但是 eight 框架是侵入性的，而 k8s 是非侵入性的。所以从项目推广上恐怕会非常难：
: 1. 做企业应用受甲方的限制，不能随心所欲。不是你想改就能改的，甲方认为有风险或者没有预算就做不下去。所以我才说你这个适合新项目，想改造老旧的项目恐怕很难。
: ...................
--
FROM 221.217.52.*
大哥， 您说的都对
【 在 jekler 的大作中提到: 】
: 大哥，你说我传销也得我的下线（比如你）思维能跟上啊，不然你不是连传销的能力都没有吗？
: 你思维跟不上也就愿意花个十分钟粗粗看一眼你啥都不明白不是理所当然吗？你看看你也就愿意花十分钟，所以我不写底层技术实现就对了啊，你注意力能有几分钟？写那么多不是更没人看，况且那些原本不重要嘛。
: 所以我故意就是不写那些，才让你看了十分钟那算是真正重要的东西，而且介绍的非常清楚。
: ...................
--
FROM 58.34.53.*
除了扣帽子和人身攻击你还会干啥，你哪只眼睛看我 spring 保守了？
但是特别旧版本就是没办法用比较新的 Java 是事实，要不你用 spring boot 1.5 (spring
framework 4.x) 支持个 Java 11/17 看看？ Java 8 升 Java 11/17 才是目前大多数场景考虑的点好吗。
至于你说的 1.6 还用大牛鄙视？2018 年 Oracle 就已经不维护了，只有 Azul 支持到
2026 年。
言尽于此，谢绝回复。
【 在 jekler 的大作中提到: 】
: spring并不是你所谓的保守，它作为一种平台工具设计上跟我考虑的一样，就是兼容性，照顾的是尽可能多的应用场景。
: spring的兼容性是3.x可以兼容到jdk1.5，维护至2016年。4.x可以兼容到jdk1.6，维护至2020年。5.x以上兼容jdk1.8。你看，人家看没版上大牛那样bsjdk1.6喔。
: 至于你所谓人身攻击我觉得你想多了，你这水平用不着攻击你。你说的没一句对的。
: ...................
--
FROM 61.148.243.*
不是“BS”1.6，而是说用这种早已EoL很多年的基础设施做的系统，
不论是技术原因还是业务方的顾虑还是供应方的权衡，大概率很难
去动它，尤其很难再去套上你新发明的东西。
当然，如果预算充足，什么都不是问题。美国海军不还是斥巨资买
微软的XP延保嘛。
【 在 jekler 的大作中提到: 】
: spring并不是你所谓的保守，它作为一种平台工具设计上跟我考虑的一样，就是兼容性，照顾的是尽可能多的应用场景。
: spring的兼容性是3.x可以兼容到jdk1.5，维护至2016年。4.x可以兼容到jdk1.6，维护至2020年。5.x以上兼容jdk1.8。你看，人家看没版上大牛那样bsjdk1.6喔。
: 至于你所谓人身攻击我觉得你想多了，你这水平用不着攻击你。你说的没一句对的。
: ...................
--
FROM 125.118.103.*
我大概1台机器跑rancher跑了一年了，云上，跑gitlab cicd，还有测试环境
最近要上生产，加了一台
成本，一台tx云轻量级主机，3年1400，oss存储，一年100不到（容量+流量+cdn）
【 在 jekler 的大作中提到: 】
: 你首先的给企业找一个会上的程序员是吗。至于1台机器都能上你也就说个笑话。
: 你用k8s是为了一个机器上跑吗？你给企业做一个机器上跑的云方案？你们方案的成本
: 是多少，每年的运维费用多少？何必自欺欺人呢？
--
FROM 119.139.198.*
估计横着发被认为有违禁词
【 在 pangwa 的大作中提到: 】
: 您这是怎么了、错乱了。。
: ╔═╤═╤═╤═╤═╤═╤═╤═╤═╤═╗
: ║微│身│，│，│其│又│。│的│微│那║
: ...................
--
FROM 112.97.63.*
编程范式上很有启发,感谢
【 在 jekler 的大作中提到: 】
: 本人做过些toB项目，深感当前的互联网技术对企业不友好，尤其是微服务和云架构，绝非大部分企业的理想选择。所以最近这些年一直在寻找解决方案。
: 最近一段时间我们研发了一种具有潜力的新技术，采用独特的设计思想，具备微服务的优点而没有它的缺陷。
: 现在尚在初期，但已经有了平台底座和线上演示环境，看上去还挺有趣。希望能为未来的企业应用带来新思路。
: ...................
--
FROM 112.117.57.*