- 主题:各位同学，我们在研发一种微服务的替代技术，欢迎交流
你觉得像就像呗。也不知这一天没几个帖子的板面有何花费时间做广告的价值。
【 在 huihaoqilai 的大作中提到: 】
: 我觉得像。
--
FROM 221.217.52.*
然而微服务各位都在给企业各种洗脑啊，各种高大上解决方案，各种鼓吹业务都得要上云，不然就是懒啊，落后啊，不时髦啊，低价值用户啊。动辄就给企业拿一个几千万的云方案，然后再给企业一个大几百万的维护团队预算，用不起的就活该不配得到技术服务，这不是版面上某些人的观点吗？
用不着急于否认，实际情况是什么你不清楚吗？现在企业信息化需求很高，业务也逐渐复杂。你说说除了鼓吹上云让企业付诸高昂的成本，你们这些年又有过什么像样的解决方案？恐怕从没考虑过务实的问题吧。
至于微服务还需要贬低吗？即便用在你们互联网，它有多少毛病你们自己不清楚？这就是个臃肿，易坏，低效的东西，从设计最初就透露出各种丑陋。但凡能把服务数量降低到原先的十分之一，各种乱七八糟的问题能降低99%，运维人员能裁剪一大半。不过从这个意义上说，你们热衷推崇微服务也是对的，毕竟饭碗重要不是吗？
【 在 hothail 的大作中提到: 】
: 你想推广一种（思维，服务，框架） 不一定要敌视另一种
: 并且在我看来，eight和微服务是不同赛道。微服务出身就是为互联网企业服务的，不适用企业用户也未尝不可
: ，没必要强求啊
--
FROM 221.217.52.*
你错了，根本不理解行情，你根本没跟大型企业打过交道。自主可控的要义在于不能因为别人的闪失让自己承担责任。你仔细琢磨琢磨。
至于我说话就这样，伤到有些人的玻璃心那是他们自己太脆弱。你也不用拉偏架，这帖子各种夹枪带棒的发言多了去了。谁不经历社会捶打就敢出来混？社会比这尖刻刺骨的多了去了。只能说很多人在玻璃茧房里太容易自我沉迷和满足。然而大环境在改变，人得适应世界而不是让世界来适应人。
【 在 hothail 的大作中提到: 】
: 就说一点，saas的说的太绝对了
: 自主可控，也可以上，天翼云，中移动之类的就是在这个市场上做细分的
: 说话没必要这么冲，一下就否定别人的思路，让实践去检验真理，拭目以待
--
FROM 221.217.52.*
这个其实是个没太大意义的问题。eight也可以不用java实现，只不过java碰巧有现成的组装工具效果挺不错罢了。目前只能用java并不准确，至少kotlin和scala是可以用的，至于groovy，jruby我不打算单独当语言。
并且也没毛病，十年前的几乎所有企业应用就是用java的。java基本上在企业后台没什么短板，大数据时代的基础构件也大都是跑jvm的。
至于可以用不同语言混编服务挺难说是个好还是不好的特点，毕竟混合的技术栈对于企业（包括互联网公司）算个负担，需要额外的成本。所以最终往往一个公司内的语言栈还是相对单一的。
至于非得要说一些云原生的程序语言有多优秀，怎么说呢？例如最常用的微服务语言golang，常常夸耀的协程多高效做网络编程多厉害，看起来很对微服务架构模型的特点。且不说究竟是不是真的厉害，网络rpc再快能快过线程内栈方法调用根本不用串行化rpc根本不需要网络调用吗？所以，这是个“解决了根本不存在的问题”（某人语录）的伪问题罢了。
【 在 wenhuazhang 的大作中提到: 】
: 首先 微服务是不挑语言的
: 发自「今日水木 on SHARK KSR-A0」
--
FROM 221.217.52.*
大哥，你说我传销也得我的下线（比如你）思维能跟上啊，不然你不是连传销的能力都没有吗？
你思维跟不上也就愿意花个十分钟粗粗看一眼你啥都不明白不是理所当然吗？你看看你也就愿意花十分钟，所以我不写底层技术实现就对了啊，你注意力能有几分钟？写那么多不是更没人看，况且那些原本不重要嘛。
所以我故意就是不写那些，才让你看了十分钟那算是真正重要的东西，而且介绍的非常清楚。
我前面举了一个关于网络爬虫关键字计数的例子。那里面我简单把一个小功能划分了三个更小的组件，然后设想它分发给三个开发人员去实现，并且不允许他们之间对接口和实现细节进行任何交流。我可以打赌，只要这三个开发者具备正常水平实现了这几个组件，不管他们具体实现方式是什么，我都能将这几个东西组装起来构成完整功能的系统，不需要额外代价或很少代价。你能明白其中的原理吗？你能懂这件事情的意义吗？甚至你能想象这种可能吗？你什么都想象不到，自然看不出有啥独到之处了。毕竟人无法理解超出他自身经验的事物。
但是其意义我还是可以跟你说一下的。
1，这样开发的组件是完全解耦的，因为从编码时就不存在任何相互依赖的可能
2，这也解释了为啥使用eight平台时，jvm这种对class释放极其敏感的运行环境能够轻松的装卸模块，变得高度动态。因为它们确确实实就没有关联
3，这意味着一个大型系统能够更加广泛和廉价的组织，管理和开发，因为它对沟通的需求很弱
4，这意味着一个开发的组件能够广泛的复用，a能够与不了解的b交互，当然也可以跟各种cdefg交互。这意味着企业应用的瓶颈，一个软件往往只能为单一用户使用而无法低成本复制摊薄成本可以被突破
5，至于系统的切割粒度，你自己可以想想，比微服务弱还是强
这些重要吗？有独到之处吗？有谁做到过吗？这些，并不仅仅只涉及到什么跟微服务比较之类的话题了。这里才是问题的根本，复杂系统的分割与分治方法论。如果没有这些，即便你们把系统分割成几十上百个微服务又能怎样？你们真的能摆脱依赖吗？升级一个服务干倒一大片的情况不要太常见，幸运的是你们还有测试环境。
至于前面那些雾里看花的帖子都挺浅薄的。什么eight不过是封装了spring和osgi之类的，如果看看源代码就知道几万行代码里压根就没有几个类import过spring和osgi的包。
spring和osgi只不过是一种组装的工具罢了，恰好它们存在并且实现的让人满意，所以被选用来实现eight的基本架构。换句话说，eight的核心就在我给你看的东西里面，它并不一定是Java，更提不上spring或osgi这些具体技术。
你看过ppt，那你应该看过第一页，里面对eight的描述，首先是一种新的设计思想，其次是一种不同的开发方法，至于运行容器的地位排倒数，你所恋恋不忘的技术实现原本没什么值得详细介绍的，把它设想为跑用这种设计思想做出来的组件的环境就行，无论它用啥做的。
当然，你要想了解具体实现，难道一切不是公开的吗？源代码就摆在那里，底座就在你手上，你自己看看跑跑不就得了？但如果你连我那几篇论述也看不明白，你估计也看不明白代码。所以，结果可能是你自以为比你家五姑娘更熟悉的20年前的jvm，以一种你不能理解的方式跑着你不能理解的代码，以至于你怀疑这一切都是个圈套罢了。
算了，认知不在一个层面上的人终究是无法相互理解，你有何欺骗的价值呢？
【 在 pangwa 的大作中提到: 】
: 大哥， 是你在传销你的技术啊， 可我花了10几分钟都没看明白这个技术有啥独道之处， 也没那么多时间浪费不是
--
FROM 221.217.52.*
你首先的给企业找一个会上的程序员是吗。至于1台机器都能上你也就说个笑话。
你用k8s是为了一个机器上跑吗？你给企业做一个机器上跑的云方案？你们方案的成本是多少，每年的运维费用多少？何必自欺欺人呢？
【 在 iwannabe 的大作中提到: 】
: k8s 1台机器到1000台机器都行，为啥不能上？
--
FROM 221.217.52.*
这个完全想错了。我下阶段就是准备给企业提供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.*