云原生应用管理，管理移动应用等企业应用。当我们使用智能手机时，手机应用程序是从应用程序市场一键安装的，安装后即可使用。一键升级新版本时，如果不想用长按图标删除，整个过程非常简单，孩子也能熟练掌握。然而，对于企业应用来说，由于其结构复杂、可用性要求高、配置多，企业应用的管理极其复杂。一般企业都有专门的运维工程师来保证企业应用的正常运行。
Rainbond是一个云原生企业应用管理平台。本文将以it为例，讲解如何像管理手机app一样简化企业应用的管理。
移动电话的安装非常简单。在预装的APPStore中一键安装想要的应用。这种一键安装的体验过程，即使是小孩子也能很好的掌握。企业应用部署难度大，组件多，其安装的复杂度远高于手机app。那么，在企业应用安装领域，能否实现和安装手机app一样的一键体验？
类比手机APP的安装过程，APP store这个拥有大量APP的平台是必不可少的一环。让手机消费者随心所欲安装手机应用的，是苹果AppStore、Google Play等生态丰富的App Store。Rainbond AppStore是一个企业级的应用商店。每个用户都可以将自己部署在Rainbond上的企业应用发布到AppStore，供其他用户使用。其他用户只需要从app store一键安装升级，体验和手机app store差不多。
WechatIMG148对于终端用户的体验，开发移动应用的企业需要按照应用商店的标准进行开发和上架。企业应用商店的实现也差不多。企业应用的供应商需要按照企业应用商店的标准包装上架。Rainbond内置的应用商店有一套完整的应用打包、测试和上架，比如源代码打包、二进制文件打包、容器打包等。，所有这些都不需要改变原代码。按照应用商店的规范进行包装上架，不仅简化了应用的安装升级流程，也建立了企业应用的验收标准。
WechatIMG149企业应用管理复杂，该如何简化管理？就一个手机APP而言，我们能做的管理操作其实很少，只涉及安装、升级、删除。虽然企业应用程序要复杂得多，但是企业应用程序所需的管理操作至少包括以下几点:
生命周期管理:就像手机用户需要安装、使用、升级、删除app一样，安装、升级、启动、关闭、删除等生命周期管理相关的操作是企业应用需要的最基本的管理操作。
批量管理:手机APP只需要管理一个组件，而企业应用往往是由多个服务组件相互依赖组合而成。所以会有批量操作的需求。
资源分配:手机用户从来不需要关心一个APP需要分配多少资源，而企业应用的管理者必须关心为每个组件分配合理的计算资源。计算资源分配不足会使企业应用运行不畅甚至无法运行，而计算资源分配过多则会导致资源浪费。
伸缩特性:手机APP不需要运行多个副本，只需要保证在手机中正常运行就可以满足机主的个人使用压力。无论是在高可用性还是反并发性方面，企业都需要水平可伸缩性。
可观察性:手机用户从不关心是否能看到手机app的运行状态，只关心其功能。而企业应用管理者会对企业应用提出很高的可观测性要求，包括运行状态、资源占用、性能、运行稳定性等等。
恢复:手机用户允许应用程序偶尔闪退，只是为了重新打开一次。企业应用管理人员对企业应用的期望是，即使企业应用出现问题，也能快速从故障状态中恢复。
迁移/备份:手机APP的用户数据全部存储在云端，数据迁移和备份操作简单。企业应用重视数据，对迁移、备份等操作要求较高，有些场景甚至需要跨集群迁移和备份。
对比后可以发现，企业应用需要注意管理，比手机app复杂很多。但这并不意味着企业应用程序管理人员必须付出更多的努力来管理企业应用程序。选择合适的企业应用管理工具将使企业应用管理工作更加有效。
Rainbond从三个方面简化了企业应用程序的管理:
让日常管理变得简单易用，安装、升级、启动、关机、删除、扩容收缩、域名配置等管理操作都可以一步完成。
复杂运维流程的自动化，如安装/升级/启动操作流程、健康检查、服务的高可用性、自动伸缩等。
实时的流程监控和可视化，由于管理流程已经实现了简单的操作和自动化，所以需要加强监控和可视化，以了解应用程序的运行情况，从而对流程进行控制和管理。
让企业应用常规管理简单容易上手之前分析过，手机用户对APP的管理仅限于打开关闭等简单操作。对于企业应用，我们希望企业应用管理器发起的管理操作足够简单。企业应用管理器通过图形界面完成企业应用的生命周期管理。
对于作为一个整体的企业应用程序，可以执行批处理管理操作:
应用整体的管理应用批量管理与生命周期管理相关的操作包括但不限于:
启动、停止、更新、构建和升级整个企业。
企业应用程序中所有组件的批量启动、关闭、更新、构建、重启和删除。
对于希望将企业应用完全迁移到其他集群或者进行备份的场景，图形化操作的迁移/备份功能可以解决问题:
image-20211123172110092对于给定的服务组件，可以执行更多的主动管理操作:
image-20211210181939473除了常见的生命周期管理之外，企业应用程序的管理人员还可以采取更多的主动行动:
版本管理，一键升级或多个版本之间的回滚。
image-20211210211647240可扩展管理，主动设置服务组件的计算资源和实例数量。
image-20211210211718070配置，主动为服务组件设置环境变量，并挂载配置文件。
image-20211210211742077存储，主动为服务组件添加持久化设置，使数据持久化。
image-20211210211814601端口管理，主动为服务组件添加端口访问策略。
image-20211210211836683插件管理，主动为可以扩展运维能力的服务组件安装插件。
image-20211210211905872进入Web终端，直接操作当前服务组件的容器外壳环境。
image-20211210211623350常规的企业应用管理操作基本都是UI界面，流程不需要学习底层技术。可以通过界面摸索入门。
复杂的运维过程实现自动化企业应用确实比手机app复杂很多，但是我们也希望企业应用的管理者少管管，所以需要提供自动化的运维能力。
Rainbond被设计为一个具有强大自动操作和维护能力的平台。这些自动化的运维能力可以最大限度的解放企业应用管理人员的双手，有效提高生产力。这些自动化运维能力是从众多工程师长期的运维工作经验中提炼出来的。这些能力往往表现在企业IT系统的底层，平日里并不明显，但却关系到企业应用运行的质量。
自动化日常管理流程。
企业应用本身的日常管理是相当复杂的。为了使前端操作简单，后端实现过程必须自动化。例如:
安装过程是自动化的，安装过程需要自动完成每个服务的软件包安装、服务配置、端口管理、服务启动等步骤。升级过程是自动的，升级过程需要自动完成版本差异比较、差异安装、滚动升级等步骤。
启动过程自动化。当企业应用程序有多个子服务时，它也需要自动处理其服务启动序列。
健康检测和故障恢复
企业应用管理人员不想为了应对不知道什么时候会发生的企业应用故障而一直在机房值班。因此，Rainbond提供健康测试能力，替代企业应用管理人员，时刻关注企业应用的健康状态。并提供可选的异常处理手段，在异常发生时自动处理。
Rainbond platform支持两种探测模式，可自动检测服务组件中所有实例的健康状态。TCP模式探测器将定期检测服务组件的指定端口是否可以连接。这种检测基于网络和端口之间的连通性。HTTP模式下的探针每隔一段时间就会请求指定的URL，根据HTTP返回的代码判断实例的健康状态。相对来说，TCP探针应用广泛，HTTP探针更准确。因为可能存在这样的软件设计缺陷，WEB服务器工作状态正常，端口可以正常监听，但是业务接口已经不能提供正确的返回，这也是对于最终用户应该检测到的错误。
对于检测失败后的处理，平台提供离线和重启两种策略。
使问题实例脱离负载平衡是一种降级行为。离线被触发后，没有新的请求到达问题实例，问题实例将从巨大的访问压力中解脱出来。接下来，如果服务组件足够健壮，它将在处理大量积压请求后恢复，并在通过健康测试后再次上线。这里有一个隐藏的假设，要求服务组件具有多实例特性，否则问题实例的离线会导致服务组件整体无法提供服务。
重启是一种比较随意的处理方式。但是，不可否认的是，在服务组件不那么健壮的情况下，重启实例是最简单有效的恢复方法。
008 i3 sk nly gxb 0 mqzdb 6j 30 yt0 u 0 q 4 I高可用性
Rainbond为企业应用提供高可用性支持。在Rainbond集群中，通常有许多具有不同身份的服务器节点，并且有多个具有不同身份的服务器节点。这意味着Rainbond本身具有高可用性，运行在其上的企业应用也可以在不同的主机节点之间自由漂移。
当Rainbond集群中的一个服务器出现故障时，Rainbond集群不会受到它的影响，受服务器故障影响的企业应用会被重新调度到其他标准服务器上。企业应用管理人员只需要事后修复故障服务器，整个Rainbond集群就会完成自愈，而企业应用在这个过程中的影响可以忽略不计，尤其是企业应用本身在扩展和收缩多个实例时，可以达到最终用户没有感觉的处理体验。
自动膨胀和收缩能力如果企业应用的最终用户是人，其访问压力将具有潮汐特征。比如一个企业内部员工使用的OA系统，工作日的流量远高于休息日，工作时间的流量远高于下班时间。那么这个OA系统可以根据流量自动调整实例数量吗？忙的时候启动足够数量的实例抵抗访问压力，闲的时候自动减少实例数量，把资源留给其他企业申请。Rainbond平台可以为企业应用提供自动扩展的能力。
Rainbond platform了解其托管的每个企业应用程序的当前状态。当然，我们也知道当前企业应用的资源使用是否接近分配的上限。通过自动缩放的设置，您可以为企业应用程序设置一个上限。当Rainbond发现企业应用使用的资源已经超过这个设定值时，就会自动扩展实例的数量。该设置可以是内存使用率/速率或CPU使用率/速率，或者是两种资源的组合。
图片-20211210220826994管理过程可观测和可视化，做到可控可管用户不会考虑观察APP内部的运行状态，企业应用管理者也不会这么想。可观察性是一切管理工作的前提，只有看得见，才能摸得着。
Rainbond提供的可观测性无处不在，从集群维度，到应用层面，最后到每个服务组件层面，体现了丰富的可观测性。
对于一个企业应用程序来说，看到它的内部拓扑和所有组件的运行状态是最基本的可观察性需求。Rainbond提供应用拓扑接口，按照不同的颜色反映各个服务组件的运行状态。绿色表示运行，黑色表示停止，红色表示服务组件处于异常状态。
拓扑图.drawio对于单个服务组件，其可观察性的粒度更加详细。服务概述页面描述了当前服务组件的详细信息，服务组件的每个实例也反映了自己的运行状态。
image-20211210222909066下面的操作记录详细描述了服务组件发生的所有事情。
image-20211210223104722组件的监控页面体现了关于其运行状态的各种可视化图表。
反映业务绩效的实时分析曲线
image-202112102235169905分钟的请求排名有助于优化计划
image-20211210223622015每个实例的资源使用曲线
image-20211210223953109基于普罗米修斯系统的出口商指标自动绘制
Rainbond的监控大屏幕系统提供了全球观测中心。
image-20211210224803749写在最后Rainbond为解决企业应用的管理问题提供了新的思路。不仅优化了管理和使用体验，还高效管理应用供应商。应用商店还允许管理人员独立控制应用程序，减少对供应商的依赖。
Rainbond是一个开源的云原生应用管理平台，简单易用，不需要了解容器和Kubernetes，支持多个Kubernetes集群的管理，提供企业级的应用生命周期管理。其功能包括应用开发环境、应用市场、微服务架构、应用持续交付、应用运维、应用级云管理等。
