企业级应用统一管理

建立企业应用商店，从应用商店一键安装企业应用​

手机 APP 的安装已经做到了极致的简单，在预装好的 AppStore 中一键安装想要的 APP 即可。这种一键安装的体验流程，哪怕一个小朋友都可以很好的掌握。企业应用部署难度大，组件数量多，其安装的复杂程度远高于手机 APP 。那么在企业应用的安装领域，能否做到安装手机 APP 一样的一键式体验呢？

类比手机 APP 的安装过程，应用商店这个集合了大批 APP 的平台是必不可少的一环，正是有苹果 AppStore、Google Play 这样生态繁盛的应用商店，才让手机消费者随心所欲的安装手机 APP。Rainbond 应用商店是企业级的 AppStore。每个用户都可以将自己部署在 Rainbond 上的企业应用发布到应用商店中去，供其他用户使用，其他用户只要从应用商店一键安装和升级，使用体验和手机 AppStore 的体验类似。

为了最终用户的使用体验，开发手机 APP 的企业需要按应用商店的标准开发和上架，企业应用商店的实现也是类似的思路，企业应用的供应商需要按企业应用商店的标准打包和上架，Rainbond 内置的应用商店有一整套的应用打包、测试和上架过程，比如从源码打包、二进制文件打包、容器打包等，这些打包过程都不需要改动原有代码。按应用商店的规范打包和上架，不仅简化了应用的安装和升级过程，同时也建立了企业应用的验收标准。

企业应用管理复杂，该如何简化管理？​

对于一个手机 APP 而言，实际上我们可以做的管理操作很少，仅仅涉及到安装、升级、删除。而一个企业应用则要复杂得多，一个企业应用所需要的管理操作，至少包含了以下这些点：

• 生命周期管理：就像手机用户需要安装、使用、升级、删除 APP 一样，安装、升级、启动、关闭、删除等生命周期管理相关的操作，是企业应用所需要的最基础的管理操作。
• 批量管理：手机 APP 只有一个组件需要管理，而企业应用往往是多个服务组件相互依赖组合形成的。所以会需要有批量操作的需求。
• 资源分配：手机用户从来不用关心需要为一个 APP 分配多少资源，而企业应用的管理者必须关心为每个组件分配合理的计算资源。计算资源分配不足会让企业应用运行不畅甚至无法运行，过多的分配计算资源会导致资源浪费。
• 伸缩特性：手机 APP 并没有运行多份的需求，它只需要保证在手机中正常运行， 满足主人的个人使用压力即可。企业应用无论是在高可用方面还是在抗并发方面，都会对横向伸缩能力提出要求。
• 可观测性：手机用户从来不关心是否能够看到手机 APP 的运行状态，只关心它们的功能。但是企业应用管理者会对企业应用提出很高的可观测性要求，包括运行状态、资源占用、性能表现、运行稳定性等。
• 故障恢复：手机用户允许 APP 偶尔出现闪退，无非是重新打开一次罢了。而企业应用管理者对企业应用的期待是，即使企业应用出现了问题，也可以快速从故障状态中恢复过来。
• 迁移/备份：手机 APP 的用户数据都保存在云端，数据的迁移、备份操作简单。企业应用重视数据，对迁移备份等操作要求很高，有的场景甚至要求跨集群迁移备份。

经过对比，可以发现企业应用在管理方面需要注重的点，比手机 APP 复杂得多。但这不意味着企业应用管理人员一定要付出更多的努力来管理企业应用。选择正确的企业应用管理工具，会使得企业应用管理工作事半功倍。

Rainbond 从三个方面简化企业应用的管理：

1. 让常规的管理简单容易上手，比如：安装、升级、启动、关闭、删除、伸缩、配置域名等管理操作都可以一步完成。
2. 复杂的运维过程实现自动化，比如：安装/升级/启动的操作过程、健康检测、服务高可用、自动伸缩等。
3. 过程实时监控和可视化，由于管理过程实现了简单操作和自动化，就需要加强监控和可视化了解应用运行情况，做到过程可控可管。

让企业应用常规管理简单容易上手​

前文已经分析过，手机用户对 APP 的管理操作是仅限于开启、关闭等简单的操作。对于企业应用而言，我们希望企业应用管理者主动发起的管理操作，也是足够简单的操作。企业应用管理人员完全通过图形化界面，来完成对企业应用的生命周期管理操作。

对于企业应用整体而言，可以执行批量的管理操作：

涉及到生命周期管理的操作包括但不限于：

• 企业应用整体的启动、停用、更新、构建、升级
• 面向企业应用内部所有组件的批量启动、关闭、更新、构建、重启、删除

对于希望将企业应用完整的迁移到其他集群，或者做一份备份的场景而言，图形化操作的迁移/备份功能可以解决问题：

对于指定的服务组件而言，可以进行的主动管理操作会更多：

除了较为常见的生命周期管理之外，企业应用的管理者还可以有更多的主动操作：

• 版本管理，在多个构建版本之间一键升级或回滚

• 伸缩管理，主动的为服务组件设置计算资源、实例数量

• 环境配置，主动为服务组件设置环境变量，挂载配置文件

• 存储管理，主动为服务组件添加持久化设置，使数据持久化的保存

• 端口管理，主动为服务组件添加端口访问策略

• 插件管理，主动为服务组件安装可以扩展运维能力的插件

• 进入 Web 终端，直接操作当前服务组件的容器 shell 环境

常规企业应用管理操作基本都是 UI 界面，过程也不需要学习底层技术，通过界面摸索就可以上手。

复杂的运维过程实现自动化​

企业应用确实比手机 APP 复杂太多，但是我们又希望企业应用的管理者尽量少操管理的心，那么提供自动化的运维能力就十分有必要。

Rainbond 被设计成一款具备强大自动化运维能力的平台。这些自动化运维能力，可以最大限度的解放企业应用管理人员的双手，切实提升生产力。这些自动化运维能力提炼自许多工程师长久以来的运维工作经验，这些能力往往表现在企业 IT 系统的底层，平日里不显山露水，但是却关乎企业应用运行的好坏。

1. 常规管理的过程实现自动化

   企业应用的常规管理本身是挺复杂的，为了前端的操作简单，后端的实现过程就必须自动化。 比如：

   • 安装过程自动化，安装过程需要为每一个服务自动化完成软件包安装、服务配置、端口管理、服务启动等步骤。
   • 升级过程自动化，升级过程需要自动化完成对比版本差异、差异安装、滚动升级等步骤。
   • 启动过程自动化，当一个企业应用有多个子服务时，还需要自动处理它的服务启动顺序。

2. 健康检测与故障恢复

   企业应用管理人员不希望为了应对不知何时会发生的企业应用故障而每时每刻值守在机房。因此 Rainbond 提供健康检测能力，来替代企业应用管理人员，时刻关注着企业应用的健康状况。并且提供可选的异常处理手段，在异常发生时自动处理。

   Rainbond 平台支持两种模式的探针来自动检测服务组件中所有实例的健康状况。TCP 模式的探针，会每隔一段时间侦测服务组件的指定端口是否可以联通，这种检测是基于网络和端口的联通性来实现的。而 HTTP 模式的探针，会每隔一段时间，请求指定的 URL，并根据 HTTP 返回码来判断实例的健康状况。相对而言，TCP 探针应用的范围更广泛，而 HTTP 探针会更加精确。因为可能存在这样一种软件设计缺陷，WEB SERVER 处于正常工作状态，端口可以正常监听，但是业务接口已经无法提供正确的返回，这对于最终用户而言，也是一种应该被检测到的错误。

   对于检测失败之后的处理，平台提供两种策略，下线与重启。

   将问题实例从负载均衡中下线，这是一种降级行为。触发下线后，不会再有新的请求到达问题实例，问题实例从巨大的访问压力中得以缓解。接下来，如果服务组件足够健壮，它会在处理完大量的积压请求后恢复，重新通过健康检测后上线。这里包含一个隐藏的假设，要求服务组件具备多实例特征，否则问题实例的下线会导致服务组件整体无法提供服务。

   重启则是一种相对武断的处理方式。但不可否认的是，在服务组件不那么健壮的情况下，重启实例是最简单有效的恢复手段。

   

3. 高可用能力

   Rainbond 为企业应用提供了高可用能力的支持。在一个 Rainbond 集群中，往往存在多种不同身份的服务器节点，而每种不同身份的服务器节点也不止一台。这意味着 Rainbond 本身就是高可用的，运行在其上的企业应用，也可以自由的在不同的宿主机节点之间漂移。

   在 Rainbond 集群中的某台服务器出现故障时，Rainbond 集群并不会受其影响，也会将受到服务器故障影响的企业应用重新调度到其他正常的服务器中去。企业应用管理人员只需要在事后修复故障的服务器，整个 Rainbond 集群又会完成自愈，而企业应用在这个过程中受到的影响是可以忽略不计，尤其是当企业应用本身伸缩了多个实例的状态下，可以做到最终用户无感的处理体验。

4. 自动伸缩能力

   如果企业应用的最终用户是人，那么它的访问压力情况，都会有潮汐特征。好比一款供企业内部人员使用的 OA 系统，工作日的流量远比休息日高，工作时间的流量远比下班时间高。那么可否让这款 OA 系统根据流量的大小，自动调整实例的数量。令其忙时启动足够数量的实例抵御访问压力，闲时自动降低实例数量，将资源留给其他企业应用。Rainbond 平台可以赋予企业应用自动伸缩的能力。

   Rainbond 平台对于其托管的每个企业应用的当前状态了如指掌。当然也了解当前企业应用的资源使用数量是否已经接近分配的上限。通过自动伸缩的设置，可以为企业应用设置一个上限，当 Rainbond 发现企业应用使用的资源已经超过这个设定值时，自动的扩展实例的数量。这个设定值，可以是内存使用量/率或 CPU 使用量/率，亦或是两种资源的综合设定值。

   

管理过程可观测和可视化，做到可控可管​

手机用户不会想着观察 APP 内部的运行状态，但是企业应用管理人员不这么想。可观测性是一切管理工作的前提，只有看得见，才能摸得着。

Rainbond 提供的可观测性无处不在，从集群维度开始，到应用级别，最终到每一个服务组件级别，都体现着丰富的可观测性。

对于一个企业应用而言，看到它内部的拓扑结构，和所有组件的运行状态是最基本的可观测性要求。Rainbond 提供了应用拓扑图界面，并根据不同的颜色来体现每一个服务组件的运行状态。绿色代表运行中，黑色代表已停止，而红色代表服务组件处于异常状态。

对于单个服务组件而言，其可观测性的粒度要更细致。服务组件的总览页面中，描述了当前服务组件的详细信息，服务组件的每个实例，也都体现自己的运行状态。

下方的操作记录，更是详细描述了服务组件发生过的每一件事。

服务组件的监控页面，集中的体现了有关其运行状态的各种可视化图表。

• 体现业务性能情况的实时分析曲线

• 有助于优化程序的 5 分钟请求排行

• 各个实例的资源用量曲线

• 支持基于 Prometheus 体系的 Exporter 指标自行绘图

Rainbond 的监控大屏系统，提供全局可观测性的中心。

写在最后​

Rainbond 提供一个解决企业应用的管理问题的全新思路，它不仅优化了管理和使用体验，还能高效管理应用供应商，应用商店也让管理人员对应用自主可控，减少对供应商的依赖。