其实也不复杂。参考介绍文档，在演示系统下操作示例，就可以在几分钟内（确实就需要几分钟）在一台机器上（只需要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.*