低成本的云
某种意义上，Eight可以被看作为一种轻量级的云。比之于现在的云技术（如基于docker的k8s或mesos等），它更为简单灵巧，便于使用。 它适用于软硬件基础设施薄弱的企业，以及缺乏专业的技术人员团队的用户。对于缺乏资金与人才储备的中小型企业，它是一种廉价的云方案。
Eight建立了一种新的合作模型，在软件的使用者和维护管理者之间划出了更为明智的边界，大大降低了对使用者的资源和能力要求，同时又大大降低了维护管理者的触达成本。
这种新的形态，能够在贫瘠的环境和技术资源中，迅速构建起复杂的软件体系和服务集群。使得优质的技术力量，能够便捷的深入到企业深处。
但同时，Eight又与云容器处于不同的生态位，是一种互补的关系。事实上，Eight可以用于克服现在的云技术存在的很多问题，即便是应用云技术非常成熟的企业，如互联网企业或大型私有云企业，使用Eight都有深远意义。
微服务的缺陷
现代的云主体上是采用虚拟化（面向硬件的资源层）和容器化（面向应用的服务层）的微服务体系架构，微服务体系架构本身存在较多缺陷。
首先是微服务使系统复杂化和零散化，带来大量运维消耗：
(某厂云环境架构图，感谢友人的大力协助)
- 微服务的小粒度组件化和模块化，让一个系统变成了几十、几百甚至更多部件的系统，每一个需要独立配置、部署、运行，然后还要彼此关联
- Docker，k8s，istio等技术能一定程度减少这种复杂度，智能运维能够一定程度协助排查故障，但配置与部署、服务关联、日常维护、故障处理仍需消耗大量人工
- 微服务的广泛依赖使得系统对外界环境变得敏感，很多确定性问题由于服务化变得不确定，同时，使得问题的追踪与定位变得复杂
- 大量异构子系统需要运维人员对各种技术都有一定程度的理解，对人员要求较高
而云原生本身就会带来大量问题
(某厂云原生架构图，感谢友人的大力协助)
- 微服务本身就会带来大量额外的模块，如服务注册与发现模块，用于异步服务请求缓存的消息队列，服务链路分析模块，服务的熔断与降级模块，服务的观测与故障追踪模块，分布式事务调度器等等等等，这会更加加大系统复杂度
- 微服务的发展使得未来软件体系架构变成云原生（如Service Mesh，FaaS，Serverless），更加不能脱离云基础架构，难以复制迁移和广泛使用
- 云原生又更将带来额外的更多模块，如多云混合部署调度，FinOps成本管理，AIOps运维智能等等等等，这些东西原本是微服务本身带来的，并非业务需求，而他们本身的可用性和可靠性也需运维来保证，系统复杂度在云化过程中螺旋上升
- 而云基础架构建设、开发、维护、运行成本高昂，并且需要高质量团队支撑管理和持续优化，绝非大多数企业能够实施得起
其次，微服务对应用系统本身也带来诸多影响：
- 服务依赖与故障追踪：
- 过度服务化带来了系统结构的复杂联系，造成服务依赖与故障追踪难题。微服务并没有完全解耦依赖，反而使之更为复杂。微服务初衷是通过服务化解耦模块关联，使得系统局部的调整不会影响整体，但实践中这种依赖往往会内化到服务的内部逻辑中（潜依赖），以至于影响范围难以评估，核心服务重要到了复杂而不能改的地步；
- 而原本无关的模块因为各种间接联系而彼此产生相关，原本用破除耦合的微服务架构却因为共同服务而耦合；
- 服务的治理与故障的定位成为一个难题，对于模块问题的排查需要对其依赖链的进行追踪；
- 广泛的依赖模式下，模块的影响范围难以评估，模块的修改、模块的故障等造成影响难以控制等等。
- 服务的不可获得性：
- 微服务的服务自治架构，导致任意时刻都需要处理服务的不可获得问题，然而这个问题并不容易解决；
- 通过消息队列进行业务请求的缓存，只在没有强事务要求和没有服务响应速度要求的场景下使用，不能保证服务质量和最终服务的达成；
- 通过服务的熔断或降级，则要求所有的业务单元都需要处理相关业务逻辑，或载入处理模块，增加了开发和测试的复杂度；
- 同时，熔断和降级并不解决服务不可获得的问题，只是提供了劣化的服务响应（或仅仅提供了服务异常的提示）。
- 数据与业务的分裂，事务一致性的难题。微服务将一个业务分割成若干个服务阶段，由于：
- 直到所有的服务完成，该业务才算完成；
- 而任何一个服务不能够控制和管理其他服务的状态；
- 各个阶段的模块分别管理自身的数据；
- 要求这些数据在事务级别处于一致的状态；
- 结果，一个简单事务变成了分布式事务，事务的完成或回滚需要除开业务模块外的其他模块（如事务协调器）来保证，增加了复杂度和开销，也难以保证最终一致性。
- rpc的消耗：
- 微服务要求各模块使用进程间调用方式连接，使用网络通讯协议进行互通（http restful，rpc等等）；
- Rpc过程（串行化、网络交互、故障重连、反串行化）带来大量的消耗；
- 同时，微服务将以前用内存进行传输的数据（单一系统的模块间调用）变更为网络间传输，导致微服务架构的系统对于网络带宽与网络稳定性要求飞快上升，而这些带宽对企业硬件基础环境提出很高要求；
- 甚至，网络本身的问题影响的范围不再局限于客户端与服务端之间的请求与响应，业务的每一个步骤，都有可能因为网络的故障带来各种失败；
- 这种情况在使用微服务之前是不存在的
此类问题还有很多。事实上，对于很多业务场景，使用微服务带来的问题比解决的问题还多。其高昂的使用成本和人员要求更是普通企业难以承受的。
但这些问题，真的是云技术导致的吗？
其实不然，基于docker的云技术本身是伟大的技术革新，建立了可控的应用层管理架构。但是它被滥用了，原本不属于应用层的问题，被切割成大量的应用丢给了它。这也是近年来的服务化改造的由来，更派生出云原生这类架构。事实上，大部分的问题，集中于应用层之上的业务层，有着更为简练优雅的解决方案。
那么这些服务化究竟是要解决什么问题呢？最初问题的起因是什么？
问题的根本
要弄明白问题的根本原因，只要弄明白为什么会诞生微服务体系架构，它试图解决什么问题。相比之微服务所替代的 All in One系统，微服务还是有明显的优势的：
- 系统的模块化。微服务的最大特征就是模块化（服务化），它的好处在于：
- 迫使开发者用一种模块化思想分解业务领域
- 迫使开发者在设计之初就划清模块的边界
- 迫使开发者规范各个模块的功能、接口定义和输入输出
- 迫使开发者随着业务系统的发展不断的抽象和抽取新的公共模块
- 模块化本身的好处很多，例如：
- 问题分而治之
- 大型系统的分工与协作
- 对互联网企业的开发模式有着天然的适应
- 快速开发、局部部署、分组维护与微量迭代。对于互联网企业来说，行业软件的生命周期趋短，需求变化与迭代趋于频繁：
- 公用的服务组件能为新生业务快速搭建起基本框架
- 不断变化的需求体现为某一局部模块的迭代需求
- 微服务将变化隔离在某一局部模块内，对于快速响应提供便利
- 微服务能在总体系统不变的情况下局部部署新的模块，可以把系统迭代造成的代价大大减小（秒级更替）
- 微服务的整个迭代过程，都是微创式的，造成的影响也是相对微小的
- 微服务便于互联网公司的人员和工作组织，使不同的专业人员分组维护系统的不同服务
- 弹性伸缩、局部扩展与适应需求：
- 不同业务、不同发展阶段、不同时间点，不同模块的计算与响应的规模可能大不相同
- 动态的应需增减集群能力显得非常重要
- 微服务将业务划入不同的模块，当模块过热（持续高强度响应）时可以动态增加处理节点，当模块趋冷时可以回收计算资源。同时，由于服务模块相对较小，使得这些资源能有效应用在关键的计算逻辑上
- 异构系统的融合与引进先进技术。微服务的每个服务单元，只要规定了接口和输入输出，其技术实现可由任意的技术框架来完成：
- 很容易用更先进有效的技术手段来提升某个独立模块的服务能力，从而提升整体系统的服务指标
- 很容易在其它环境不变的情况下，分析和比较不同技术实现在服务能力上的差异，从而对技术选择提供实践依据
- 很容易在系统关键部位，置换上优势技术模块（如python之于数据分析、go之于网络通讯），从而提升整体系统的能力
认真分析以上的优点，其实前两点与后面的并不在一个层面上，前两点是关于业务本身的开发与变化，后面是关于系统运行的资源和环境。
事实上，微服务的核心意义正是前面两点，微服务诞生的大背景正是业务日益的庞杂和系统规模的不断扩大而单体应用不再满足需要。微服务使得一个大规模系统的开发、协作、管理、升级和维护在技术上成为了可能。
第三点则是容器化技术带来的便利，使业务系统的扩张可以跟随业务规模而改变。这个属于容器化最具价值的特征之一，但却与业务实现方式无关。换句话说，无论业务系统是否用微服务思想设计开发，容器化都能够提供动态扩张的弹性，即便它是个单体应用。
第四点则是个有利有弊的可选特征。毕竟，只要能够完成功能，应用系统并不一定非得要采用各种不同的技术。而采用多种多样的技术，必然对人员能力、技术栈、环境资源的复杂度、系统的可维护性等构成负面影响。
所以，容器化的云架构本身还是相当有价值的（但并非不可或缺，尤其是考虑到其高昂成本时），但微服务系统设计思想却未必如此。
云上之云
通过以上分析，我们可以看到，微服务实质上解决的是大规模系统的切割与划分问题。这个问题原本是一个业务层面的结构设计问题，却最终变成应用层面的体系架构解决方案。这种糟糕的局面根本上是人们对事物的认知出现了偏差，带来软件工程的误入歧途。
之前在介绍Eight原理时，我们探讨过动态系统为何难以实现，分析了为何系统难以切割、分散开发和动态组建。提出了人们思想上的误区才是导致系统难以模块化的罪魁祸首。
而Eight独特的世界观和设计哲学，预示了另外一条道路。毕竟，微服务要解决的核心问题其实是：复杂系统的模块化开发与协作、快速迭代及局部更新，在Eight下得到了另一种完整的解决：
- Eight对外是一个单体进程，对内则是一个组件化系统。其组件架构于进程之内，兼具两者的优势；
- 相较于单体应用，系统任何一个局部都可以独立成组件，独立开发、部署、运维，能够局部更新；组件间完全解耦，毫无依赖，任何部分的变化不影响其他部分，能够快速迭代；
- 容易扩展节点和部署、调整应用，适用于弹性扩容管控；
- 可以动态运行时更新，完全无缝切换，不存在服务离线状态。Eight的业务更新是一个线程加载操作，没有进程的重启也不存在运行时状态的丢失。所以，即便Eight完全更换一套系统，这个过程也是无缝而透明的，也许上一个请求还在使用旧的代码和数据，新的请求已经同时在使用新的代码和内存数据结构了。旧的代码和数据只会在不再被引用时释放。这对于持续化高敏感度的业务升级提供了前所未有的解决方案；
- 可轻易的将应用系统发布至成千上万节点上，且应用体积极轻，单个组件体积往往仅有几十kb到几百kb；
- 相较于微服务，Eight是非常轻量的集群，只需一行命令运行一个jar包，构建简单方便，几乎没有技能要求；
- Eight无须沉重的云平台环境，没有各种复杂的支撑服务，如服务注册与发现、服务调用链管理、服务请求的消息队列、熔断与故障转移等等，大大降低应用系统的复杂度，对于一般企业更容易实施；
- 较之于docker的进程重启，Eight的组件加载卸载更为轻量。较之于docker的秒级更新，Eight的更新是一个毫秒操作，对网络带宽和计算资源消耗更少；
- Eight的
组件比微服务的服务天然的粒度更细。能更好切割系统，系统可观测性也更强，动态更新更快，资源消耗更少； - 与容器化云环境结合使用时，能够将大量以往切割成微服务的模块组合在一个节点中，减少微服务数量，简化系统结构和复杂度
- Eight具备单体应用的优势，例如不存在组件不可获得性问题，能够用统一的事务管理整个业务流程，不存在进程间调用，节省序列化和网络操作等消耗
那么，Eight是否能够像微服务那样扩容和伸缩呢？凭借Eight自身的能力并不困难，毕竟Eight的节点上运行多少组件和运行几套系统都是可控的。但当与云环境结合时，这个事情还有更为优雅的解决方案。
Eight本身是非常适合作为一个服务被打包成docker镜像，融入到云平台之中的。就像我们看到的，Eight底座是稳定不变的，而且只需要一行参数命令就可以变成一个节点，节点上运行的业务通过网络发布动态变化且容易操控。Eight天然是云原生的。
如果企业已经存在了私有云环境，那么部署Eight集群是再方便不过，可以轻松的扩展数以千计的节点。而此时，系统的弹性由云平台来负责就再好不过了，毕竟Eight更倾向于成为业务层的架构。
如前所述，云技术是个伟大的进步，只不过如今被滥用了。事实上，作为应用层的虚拟化设施，容器应该提供的是应用层部件，例如各种应用服务（Eight、Kafka、ngnix）和数据服务（mysql、redis、hadoop）的进程管理，以及对这些服务资源的扩展与收缩，服务状态的监控和维护等。而不应该涉足到业务的切割和模块的划分这个领域，业务层的事情应该由业务层的云来处理。
如图所示，未来的云架构层次性会更为显著，每个层次的边界更为清晰：
- openstack或类似的公有云主要提供硬件基础设施，将硬件计算资源和存储设备集中管理和作为可分配单位提供出来供上层使用；
- 基于docker的云容器则是建立在硬件和操作系统之上的应用，提供各种应用服务、包括服务的部署、管理和伸缩；
- 基于Eight的业务层是业务实施和组建的平台，是组件仓库和应用管理的中心。软件开发、模块划分、业务的分割、开发人员的分工合作、应用的组装和部署推送，都应该在这个层面上实现。
这样的架构，是未来大型系统的发展方向。当对微服务架构进行Eight化改造之后，我们将收获一个新的云层，这将大大扩展云架构的能力：
- Eight代替微服务进行业务层切割，将微服务原先不必要的切割省略，大大精简微服务数量，简化系统服务依赖，增强系统的稳健性和可管理性
- Eight给云系统提供了一个新的维度——业务层虚拟化，使得云的管理者可以深入到运行时的业务模块深处，对其进行观测、分析、调试和细粒度管理
- Eight能够以更轻、代价更小的方式跟随业务而变化，并且处理事务、rpc等问题时能够得到更佳的选择
当然，对于中小型系统而言，Eight的架构可选方案很多，并不一定依赖于云架构：
可见，Eight可以很方便的在各种环境和条件下部署系统，也可以在各种混合环境下部署集群，只需要把这些节点加入到同一个管理平台即可。
超越云的云
云的一个基本特征是向下屏蔽异构系统的差异，向上提供统一的功能界面。每一层云都起到这样的作用：
- IaaS层虚拟化屏蔽硬件层差异，向上提供统一的单位化的硬件资源，如cpu、内存、网络带宽、存储空间等；
- 容器层屏蔽运行环境差异，向上提供统一的应用执行环境，如docker所基于的操作系统内核和各种动态链接库；
- 而Eight层则屏蔽的业务模块差异，向上提供统一的接口规范和连接方式，使业务开发与具体的硬件资源、执行环境和外部业务依赖解耦。
同时，就像docker并不依赖于IaaS一样，eight也不依赖于docker和K8S。而每一层云对建立其上的系统是屏蔽了其下的差异的，所以其上的系统是无须受限于其下的差异。当一个虚拟机镜像在虚拟机中运行时，它无须辨别底层的硬件设备也不受其影响；当一个docker镜像在容器中运行时，它无须考虑底层是K8S环境还是一个简单的docker；当一套业务在Eight中运行时，它也不需考虑它是在云环境中，还是一个运行在某个操作系统中的独立进程（硬件层、应用层的差异已经被jvm屏蔽了）。
这是有特殊意义的。考虑到Eight本身就是一个云管理平台，这意味着可以建立起一个前所未有的云，一个跨越容器与各种孤立的、边缘的、离散的、无法上云的系统和节点的广义的云，并对其进行统一的开发、部署、运维、更新、调试和扩展。这尤其有利于信息架构和组织架构比互联网复杂的企业环境：
- 企业存在大量分支节点（如银行、电信、超市网点，邮局、加油站等大型企业分支机构）；
- 企业存在大量的孤立节点、独立系统和传统应用（如工业智能设备、OA办公节点、遗留传统系统）
- 企业存在大量的边缘节点，分布广泛，难以触达（智能汽车、智能家居、物联网）
- 这些节点和系统分处各处、本地运行、无法上云、不能集中管理；
- Eight兼容性极佳、资源消耗少、易于部署，能将各种节点纳入到整体环境之中
Eight能建立一种新形态的云，包含大量离散节点和边缘节点的云，补完企业的全局系统。Eight能实现超越现在所有云形态的环境，并孕育新的系统架构和业务方案，将企业的触角渗透到每一个角落。