在简单了解了Eight的功能与特征之后，我们接下来看看Eight可能的应用场景。也即Eight有什么用？可以被用来解决什么问题？
企业应用的常见问题
企业应用与互联网应用存在较大差异，企业应用的一些突出痛点例如：
- 企业应用的业务逻辑往往复杂而独特，需要较多的业务定制，且业务也会不断发生变化，对定制和维护的需求较多；
- 企业应用往往分布和扩散在企业的整个体系之中，在各个业务部门、分支机构甚至离散或边缘节点中存在，这与典型的互联网应用将系统集中架设于可控的核心设施（如公有云上）并不一致；
- 企业应用的标准化程度较低，复用程度较差，不能够像互联网应用那样依靠大量的使用者来摊薄开发和维护成本。往往企业应用被定制后唯一的使用方就是企业本身，企业对高昂的研发成本承担能力有限；
- 企业大多不具备先进的信息化技术使用条件（如平台虚拟化和私有云），也缺乏足够的技术人才队伍。一些先进的互联网技术难以落地，更难以管理和维护；
- 企业内部的计算基础设施环境复杂，存在各种边缘节点和信息孤岛，运行着大量的遗留系统和老旧设备，存在着不稳定的网络环境和重重阻隔的安全策略。企业应用系统需要在这样的环境中部署和延伸；
特别的，在中国，因为国情、政策和长期形成的技术传统：
- 中国企业更倾向于使用私有化、本地化的解决方案，尤其大型企业和国企央企，由于政策法规的要求，业务和数据的安全和私有化是核心诉求。这意味着以上所有问题，都不能通过SaaS化的互联网服务而得到缓解；
- 中国地域发展不平衡，技术人员集中于少数几个城市，而企业、尤其是大型国企央企，业务则遍布全国各地。一般说来，企业难以建设技术队伍，更难于在自己的分支机构建设此类队伍。
拥有庞大分支机构的全国性企业
此类企业在国内是比较典型的，如银行、证券、金融保险、石油、电力等等。此类企业系统的特点是：
- 有私有云和优良的基础建设，主体系统集中建设在私有云上；
- 在中心城市拥有一支有质量的研发队伍，能够研发和维护集中建设的系统；
- 大量分布各地的分支机构主要使用私有云上的SaaS系统；
- 仍有不少应用不能依赖于网络和SaaS（如各种离线业务系统），此类系统和终端需要管理、升级和维护，此类工作需要投入大量成本建设全国性的技术支撑队伍。
以银行为例，其信息化系统资源结构大体如下：
这种模式适应于最近些年来发展壮大的面向互联网的先进技术，如大数据、虚拟化、私有云等等，此类企业也拥有足够的能力来建设一套软硬件设施及人才队伍。
但此类企业主要痛点在于对于分支机构的系统维护成本偏高，尤其是当维护涉及软件和业务时，少量的业务研发人员集中于核心城市，而问题却可能出现在各地，当地的运维人员也不具备足够的能力和权限去解决问题。所以目前是尽可能将业务迁移到云上集中管理，但离线业务的存在是难以回避的现实。
如果对于分支机构的本地化应用采用Eight的解决方案，此类企业可以建设集中的应用分发和维护体系。将业务系统集中研发并部署于中央节点上，分支机构人员采用简单的方式对接中央节点的服务，中央节点即可部署和升级系统到本地。当出现运维需求时，分支节点连接到中央系统，则研发人员可以在线跟踪、调试和维护这些远程的本地系统。
这对于银行的即时解决节点故障，降低运维人员成本很有帮助。
相比于以往方案，增加Eight基础设施之后的优势在于：
- 降低运维成本，有利于建设符合客观规律的系统-人员结构，使得企业能够用少量的优质技术资源解决遍布各地的远程问题。国内的客观现状是优质技术人才集中于一线核心城市，其它地区派驻高技术人员不仅成本高昂，而且乏人可用。Eight将系统的中央分发和远程可控提升到一个更高层次，使集中少量优质人员维护管理成为可能。这不仅减少人员消耗，解除中小城市缺乏人才之困境，更重要的是使企业的各个网点都能享有优质的技术服务；
- 提高问题和故障响应效率，可以在故障发生的第一时间消除故障，对于银行、金融、电信等需要业务及时响应的企业组织有特别意义；
- 更容易的接触现场，分析原因，查明故障，提高产品质量。Eight可以远程进入一个运行时系统内部，观测每个功能组件的能力，这将大大方便排查实时或随机故障的能力；
- 使大量业务不再依赖于SaaS成为可能。当前大量业务SaaS化并非完全出于业务自身要求，而是很大程度上受限于技术手段。过去的技术手段需要尽可能的集中业务到私有云，以此来方便集中管理和升级更新。然而SaaS化应用有其固有的弊端，如过度依赖于网络而不能承受网络节点波动；过度依赖于中心以致中心系统成为瓶颈；过度集中和统一，以致于难以对不同分支部门因地制宜等等。再加上很多业务本身就可能体现为本地应用（如不少线下线上结合应用）。 Eight为这类情况提供了新的选择，Eight分发的应用，本质上就是本地应用，可以不依赖SaaS网络环境运行，同时也保障对此类应用的维护、升级和管理，企业今后可以根据业务特征而非技术条件来灵活选择解决方案，提供更为健壮而因地制宜的应用和服务。
- Eight在此类企业相对容易实施。此类企业已经拥有了自己的私有化网络系统和云平台，Eight的业务发布可以构建于中央的云平台上，而各地分支机构只需要根据业务需求部署Eight底座，通过可信网络连接到云平台上，即可由企业软研进行业务下发。
管理边缘系统
另一种常见场景则在于工业制造业。随着工业互联网的发展，大量的传统或新兴企业开始拥有各种系统，这些系统往往分布范围广泛，基础环境复杂，系统的稳定性和可靠性都难以保证。
典型的应用场景，比如智能汽车。对于汽车厂商而言，如何触达和管理遍布在世界各地的几百万汽车是一个难题，特别是这些汽车出厂时间跨度可能长达数十年，其上部署的系统和应用可谓千奇百怪。 这个问题在即将到来的智能汽车时代会更为严重，届时汽车可能即智能手机之后，成为人们日常生活的通道。但是汽车跟手机不同的是人们不会频繁的更换，也不太愿意升级车机。 自然，现代化的车机大多可以进行OTA，但是OTA的范围和周期也很难评估。毕竟OTA需要客户的配合，占用很长时间，并且不能在汽车运行时进行，汽车又往往会在停止后断电断网，往往会在4S保养时才找到更新的机会。
所以，这并不是一种在网即行的解决方案。
假设一个场景，如对用户在车机上的操作行为进行数据采集。采集的数据内容和格式是可能需要根据厂商的需求而不断变换的，若需要统一数据格式和采集内容，则需要厂商将远销世界各地的数以百万计的汽车同时都进行OTA，这几乎是不可能办到的。
否则，厂商将长期忍受兼容各种不同的数据格式和内容，新的采集业务始终无法落地，这显然会对厂商的应用需求造成严重影响。而作为数据推动增长策略，这种采集需求的变化则可能很频繁，每一次变化都意味着同样的难题。
这种情况，就可以考虑Eight方案，如下：
相比于以往方案，采用Eight之后的优势在于：
- Eight本身提供了
在网即行应用部署能力，在不影响基础功能（也即无须OTA）的情况下，厂商可以获得一个可以任意支配的轻量级更新容器，将需要高度控制和管理的业务装载进去； - 就如前一节所述，与OTA动辄数百MB乃至上G的更新包不同，Eight下的应用体积非常小，往往整套系统只有数百KB；更新单个组件，则往往只有十几到几十KB。这样，即便汽车的网络环境不佳，也能在3G或2G网络下，在数毫秒至数秒内完成全部推送（其过程实质上是一个简单的http请求），这些操作是只要有网络就可以进行的，这对于汽车这类环境不稳定的节点，提供了非常实际的更新能力；
- Eight部署的是一个本地应用，也即除了部署和维护需要在线之外，应用本身不一定需要网络。这对网络环境不稳定的边缘节点尤为有用（如车机）。这种情况下，设计的应用可以更灵活，不必考虑持续在线需求（比如对于数据采集，可以采用持续采集本地存储，再在联网时批量更新的策略）；
- Eight设计时充分考虑了兼容性需求，Eight最低支持java 1.6，可以在Android 2.3以上的所有设备设备上运行，这基本上覆盖了现在运行着的智能终端。
管理离散节点
另外一种场景，在于工业企业的制造。有大量的离散系统和节点存在于企业内部，如何将这些孤岛连接成整体系统，对其进行集中的监控、管理、升级和维护？如何将其与企业未来的智能化生产和制造体系整合？
这个问题其实目前并无解决方案。无论是私有云还是OTA，都没有设想过给工厂内各种环境下的各种设备、终端、局部应用系统和分散业务提供方案。这些地方被遗忘了，既无法部署k8s，也不能使用android。
但是，Eight提供了解决方案：
采用了Eight后：
- Eight设计时充分考虑了传统系统的兼容问题，几乎可以运行在任何时代遗留的设备环境上（windows兼容至上世纪90年代的winnt4和win9X，linux兼容至上世纪90年代的kenrel 2.4.x，关于Egiht的设计和兼容能力，参考）；
- Eight部署方便，占用资源很少，适合在各种资源紧张的系统上持续运行；
- 传统的企业信息化集中在21世纪最初10年，这个时代大量应用本身就是基于Java的，使用Eight可以天然的与这些系统融合和对接；
- Java本身提供的丰富的库和扩展，能够方便的操控离散节点和应用。比如对于基于C开发的应用，可以用jni与其对接，进行监控、数据采集和操纵；
- 与ssh等远程登录管理方案不同，Eight不需要透过安全策略穿透层层子网直达设备节点，特别当这些离散节点藏于企业深处时；甚至也不需要节点持续联网，这对各类安全管理下的设备尤为有用。节点可以透过层层防火墙，通过受限网络方便的连接中控节点，成为受控系统；
- 一旦所有离散节点连接成为一个整体，企业可以将
控制的触角延伸到每一个角落，对企业各处的系统进行监控、维护、升级和应用部署，可以将各种数据收集、整合、业务打通，构成现代化只能企业的组成部分。