技术交流，并非广告，望版主手下留情
【 在 jekler 的大作中提到: 】
: 本人做过些toB项目，深感当前的互联网技术对企业不友好，尤其是微服务和云架构，绝非大部分企业的理想选择。所以最近这些年一直在寻找解决方案。
: 最近一段时间我们研发了一种具有潜力的新技术，采用独特的设计思想，具备微服务的优点而没有它的缺陷。
: 现在尚在初期，但已经有了平台底座和线上演示环境，看上去还挺有趣。希望能为未来的企业应用带来新思路。
: ...................
--
FROM 221.217.52.*

其实也不复杂。参考介绍文档，在演示系统下操作示例，就可以在几分钟内（确实就需要几分钟）在一台机器上（只需要java 1.6环境）部署一个集群节点，基本上无须任何技术知识。之后可以对该节点发布任何应用，应用的任何一部分可以运行时配置和变化。

设计思想主要是关于如何对一个大型应用进行模块化和组件化，以使得系统的各个部分得以确实的解耦，以至于可以对任何部分进行动态更新的。这部分原理相对复杂，在介绍文档的第二部分有进行介绍，稍有一点点抽象，不过也挺有趣。

对比单体应用以及微服务的优势在ppt里有详细介绍。
简单说主要有这么几点。
1，它无须微服务所依赖的云架构，无须系统的实际使用者（客户）配套优秀的技术人才和复杂的软硬件环境，就能在使用者本地环境部署业务层集群，集中管理任意节点上运行的系统，对其进行部署，升级，维护，观测，配置等等操作。这些运维工作可以远程集中进行，符合当前绝大多数企业对私有化部署有强烈要求而技术水平又跟不上，技术人才集中于核心城市而企业节点却分布全国各地的现状。能为企业和tob服务商节省大量成本。
2，并非所有的业务节点都可以上云，云归根到底是一种saas化集中管理的设计思想，运用集中建设和优势人才管理的手段，通过广泛使用降低单位成本。天生不是分散化系统，也很难为少量单一使用者（如企业内部）降低成本。何况企业与互联网不同，存在大量的分支机构，边缘节点，离散节点，这些地方运行的系统是无法云化的。本项目可以跨越所有这些节点对业务层进行集中管理和操作（类似于业务层被云化），构建起一种新的体系架构。便于企业将所有这些节点连接起来，把控制力贯通到每一个角落，通过少量优势技术人才管理企业每一部分的应用系统。当然也可以衍生新的业务形态。
3，相对云架构，它更为轻量，对基础环境（cpu，内存，网络）要求低的很多，运行容器消耗内存仅几十mb，可以在win9x，winnt4，linux kernel 2.4，android 2.3等90年代中后期以上的一切操作系统上运行节点，没有微服务那种大规模使用网络调用进行进程间通讯的特征，对网络带宽要求很低。这符合当前企业内部基础设施的环境特征。且应用体积很低，更新效率很高（一般微秒级），且无缝切换，没有停机。
4，比微服务粒度更细，属于业务层模块化。系统业务的任意部分，哪怕只有几行代码，如果在业务上有独立的意义（比如经常被复用，比如经常发生变化而需要运行时更新，比如需要经常调整参数设置），都可以独立出来成为一个单元（把某一段代码独立成单元组件几乎不会带来额外的运行成本），微服务很难做到这点。
相比于云架构只能观测各个进程（微服务的状态，业务层的云可以深入到业务内部。可观测到任何一个部分的状态，包括系统各部分的实时输入输出，日志记录数据，重放接口调用，运行时系统调试等等。相当有助于对运行时系统的各种业务逻辑进行跟踪和维护。
其他特点还有很多，欢迎先花几分钟试用：）
【 在 superisaac 的大作中提到: 】
: 这么多链接，懒得点了，就说说设计思想吧，为啥你这种比微服务和云架构好。
:
--
修改:jekler FROM 221.217.52.*
FROM 221.217.52.*

并没有炫耀什么。
兼容1.6主要理由很清楚。企业内部的应用环境非常复杂，有大量的传统应用牵制下的传统操作系统。如果需要集成至整个可控框架下，就必须具备足够的兼容性。这只是个务实的做法罢了，尽管这涉及不少backport也不太容易做到。
这个东西本来就不是给各种高大上的互联网公司设计的，诸位尽可以看不上。
【 在 JulyClyde 的大作中提到: 】
: “只需要java1.6”并不是个值得夸耀的事情哦
--
FROM 221.217.52.*

╔═╤═╤═╤═╤═╤═╤═╤═╤═╤═╗
║微│身│，│，│其│又│。│的│微│那║
║服│是│用│微│他│蹩│仔│模│服│请║
║务│有│上│服│所│脚│细│块│务│问║
║往│积│ｐ│务│谓│，│想│分│创│你║
║往│极│ｏ│没│什│像│想│治│生│有║
║离│意│ｄ│资│么│臭│是│问│到│考║
║不│义│一│格│弹│袜│不│题│现│虑║
║开│的│样│恬│性│子│是│，│近│过║
║云│，│是│居│伸│一│就│也│，│微║
║架│只│弹│其│缩│般│是│就│要│服║
║构│不│性│功│之│又│这│是│解│务║
║，│过│伸│。│类│臭│个│所│决│是║
║至│如│缩│换│的│又│？│谓│最│要║
║少│果│的│句│，│长│只│的│大│解║
║会│没│。│话│原│罢│不│服│的│决║
║相│有│从│说│本│了│是│务│问│什║
║当│条│这│，│是│。│这│化│题│么║
║不│件│个│即│云│　│个│，│不│问║
║方│不│意│便│架│　│事│所│过│题║
║便│必│义│是│构│　│情│谓│就│吗║
║。│强│上│个│提│　│它│的│是│？║
║　│上│云│单│供│　│做│切│复│　║
║　│。│架│体│的│　│的│割│杂│　║
║　│然│构│服│方│　│糟│服│系│　║
║　│而│本│务│便│　│糕│务│统│　║
╚═╧═╧═╧═╧═╧═╧═╧═╧═╧═╝
╔═╤═╤═╤═╤═╤═╤═╤═╤═╤═╗
║你│决│但│时│升│制│最│影│内│用║
║可│的│是│在│级│于│多│响│在│微║
║能│问│，│线│的│局│只│范│逻│服║
║说│题│它│的│同│部│是│围│辑│务║
║这│有│带│业│时│，│连│还│的│拆║
║个│更│来│务│保│可│带│不│依│分║
║东│优│的│的│持│以│其│可│赖│系║
║西│雅│麻│胃│宏│部│一│控│仍│统║
║跟│的│烦│口│观│分│级│。│然│，║
║云│解│显│罢│持│更│连│好│存│很║
║架│决│而│了│续│新│接│处│在│多║
║构│方│易│。│在│，│模│无│，│时║
║不│案│见│　│线│灰│块│非│所│候║
║是│，│。│　│。│度│伴│是│以│也║
║一│这│完│　│这│发│随│微│往│只║
║个│不│全│　│很│布│修│服│往│是║
║层│是│有│　│对│等│改│务│一│形║
║次│替│一│　│互│，│，│的│个│式║
║的│代│种│　│联│使│系│部│微│上║
║。│方│办│　│网│得│统│分│服│解║
║这│案│法│　│这│系│的│服│务│耦║
║个│是│让│　│类│统│震│务│的│了║
║不│什│它│　│２│在│动│修│修│模║
║错│么│想│　│４│微│被│改│改│块║
║，│？│解│　│小│观│控│，│其│，║
╚═╧═╧═╧═╧═╧═╧═╧═╧═╧═╝
╔═╤═╤═╤═╤═╤═╤═╤═╤═╤═╗
║　│　│　│　│　│　│　│　│，│云║
║　│　│　│　│　│　│　│　│我│架║
║　│　│　│　│　│　│　│　│ｐ│构║
║　│　│　│　│　│　│　│　│ｐ│属║
║　│　│　│　│　│　│　│　│ｔ│于║
║　│　│　│　│　│　│　│　│有│应║
║　│　│　│　│　│　│　│　│写│用║
║　│　│　│　│　│　│　│　│了│层║
║　│　│　│　│　│　│　│　│。│，║
║　│　│　│　│　│　│　│　│　│这║
║　│　│　│　│　│　│　│　│　│个║
║　│　│　│　│　│　│　│　│　│属║
║　│　│　│　│　│　│　│　│　│于║
║　│　│　│　│　│　│　│　│　│业║
║　│　│　│　│　│　│　│　│　│务║
║　│　│　│　│　│　│　│　│　│层║
║　│　│　│　│　│　│　│　│　│。║
║　│　│　│　│　│　│　│　│　│两║
║　│　│　│　│　│　│　│　│　│者║
║　│　│　│　│　│　│　│　│　│可║
║　│　│　│　│　│　│　│　│　│以║
║　│　│　│　│　│　│　│　│　│结║
║　│　│　│　│　│　│　│　│　│合║
║　│　│　│　│　│　│　│　│　│使║
║　│　│　│　│　│　│　│　│　│用║
╚═╧═╧═╧═╧═╧═╧═╧═╧═╧═╝

【 在 pangwa 的大作中提到: 】
: 你这个， 似乎和微服务并不在一个层次上的， 你这个看上去是个插件化服务运行平台。。。
--
FROM 221.217.52.*

这么说吧。其实问题不在于我有没有说要“替代”微服务，而在于互联网干了几十年技术进化，有没有为企业考虑过，企业有没有“替代”方案，还是被互联网所裹挟不得不“服务化改造”，不得不“上云”
你这样理解一下标题的意思看是不是更合适。
【 在 hothail 的大作中提到: 】
: 我觉得你的这些思考的也挺好的
: 既然考虑了这么多企业的应用的场景
: 这个架构的和微服不是~取代~的关系，而是各自有有自己的领域，（传统企业vs互联网领域）
: ...................
--
FROM 221.217.52.*