演示系统访问不了
Tunnel www.yeeyaa.net not found
【 在 jekler 的大作中提到: 】
: 标  题: 各位同学，我们在研发一种微服务的替代技术，欢迎交流
: 发信站: 水木社区 (Fri Jul 14 23:48:05 2023), 站内
:
: 本人做过些toB项目，深感当前的互联网技术对企业不友好，尤其是微服务和云架构，绝非大部分企业的理想选择。所以最近这些年一直在寻找解决方案。
:
: 最近一段时间我们研发了一种具有潜力的新技术，采用独特的设计思想，具备微服务的优点而没有它的缺陷。
:
: 现在尚在初期，但已经有了平台底座和线上演示环境，看上去还挺有趣。希望能为未来的企业应用带来新思路。
:
: 演示系统地址在
: https://www.yeeyaa.net/
:
: 这里有介绍的ppt
: https://jekler.github.io/eight/assets/images/eight.pdf
:
: 这里有线上文档，更为详细，帮助理解新技术的核心思想
: https://jekler.github.io/eight/
:
: 这里有介绍技术实现和细节的技术文档
: https://jekler.github.io/eight/assets/images/eightV1.0.pdf
:
: Eight开源地址
: https://github.com/jekler/eight
:
: 前端UI工具集EIS开源地址，这组工具包含支持IE早期版本的SVG渲染库、htc动态库和支持动态文字图标库等等
: https://github.com/jekler/eis  
:
: 水木同学们牛人众多，欢迎交流！
:
: --
:
: ※ 来源:·水木社区 mysmth.net·[FROM: 221.217.52.*]
--
FROM 1.202.162.*

不好意思，cdn不太稳定，已经修复了。
【 在 eventvwr 的大作中提到: 】
: 演示系统访问不了
: Tunnel www.yeeyaa.net not found
--
FROM 221.217.52.*

你觉得像就像呗。也不知这一天没几个帖子的板面有何花费时间做广告的价值。
【 在 huihaoqilai 的大作中提到: 】
: 我觉得像。
--
FROM 221.217.52.*

你错了，根本不理解行情，你根本没跟大型企业打过交道。自主可控的要义在于不能因为别人的闪失让自己承担责任。你仔细琢磨琢磨。
至于我说话就这样，伤到有些人的玻璃心那是他们自己太脆弱。你也不用拉偏架，这帖子各种夹枪带棒的发言多了去了。谁不经历社会捶打就敢出来混？社会比这尖刻刺骨的多了去了。只能说很多人在玻璃茧房里太容易自我沉迷和满足。然而大环境在改变，人得适应世界而不是让世界来适应人。
【 在 hothail 的大作中提到: 】
: 就说一点，saas的说的太绝对了
: 自主可控，也可以上，天翼云，中移动之类的就是在这个市场上做细分的
: 说话没必要这么冲，一下就否定别人的思路，让实践去检验真理，拭目以待
--
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.*