共计 2787 个字符，预计需要花费 7 分钟才能阅读完成。
Rainbond 5.3.1 公布，反对 100+ 组件的超大利用一键交付
2021 年 7 月 5 日，Rainbond 5.3.1 正式公布。
Rainbond 是云原生且易用的利用治理平台。云原生利用交付的最佳实际。专一于以利用为核心的理念，赋能企业搭建云原生开发云、云原生交付云。
对于企业： Rainbond 是开箱即用的云原生平台，借助 Rainbond 能够疾速实现企业研发和交付体系的云原生转型。
对于开发者： 基于 Rainbond 开发、测试和运维企业业务利用，开箱即用的取得全方位的云原生技术能力。包含但不仅限于继续集成、服务治理、架构撑持、多维度利用观测、流量治理。
对于我的项目交付： 基于 Rainbond 搭建产品版本化管理体系，搭建标准化客户交付环境，使传统的交付流程能够自动化、简单化和可治理。
近一年，应用 Rainbond 云原生利用交付流程（见下图）的开源用户成为支流，面对不同用户的业务复杂性，对 Rainbond 交付流程的性能提出了新的要求。从 5.3.0 版本公布以来 4 个月的工夫，Rainbond 开发者以交付链路的性能优化为次要迭代方向。
在工业互联网、智慧园区建设、智慧城市建设等等畛域中，一个利用解决方案大多具备 50-100 个服务组件。在这些行业中，通常会有多家利用厂商来单干实现一个解决方案。Rainbond 在这个过程中提供多项能力：
（1）标准化利用交付模型，对立各个利用厂商的利用交付规范，使行业集成商低成本集成解决方案。
（2）对立交付环境，一键实现利用交付。大大降低销售过程中的演示场景、POC 场景和老本和最终交付的老本。
（3）智能利用运维治理，升高最终客户的运维老本。
要害变更
反对 100+ 组件规模利用交付
基于上述的 Rainbond 利用交付流程，以后版本在利用模型公布、利用模型装置、利用降级、利用生命周期治理四个维度进行性能优化。以利用模型装置为例，100 个组件的装置过程须要调用大量的计算资源，管制组件的启动程序，管制微服务零碎注册和配置散发。
<center> 多组件利用装置和降级演示 </center>
Helm 利用装置与治理 (Beta)
Rainbond 不反对 Helm 利用装置和治理早已是一个痛点。Rainbond 的产品状态是以治理自定义的利用标准为外围的云原生利用治理。与其余容器化平台不一样，咱们不提供 Kubernetes 原生的资源管理面板。因而在面对灵便的 Helm 利用包，咱们没有很好的形式将所有 Helm 利用转化为 Rainbond 的利用标准。在 OAM 标准的实现模式中，有一个思路是把每一个 Helm 利用定义为自定义的组件类型，对其进行资源类型辨认从而实现一些运维能力注入。咱们认为这种模式精细化治理有劣势，但用户落地老本很大。
以后版本咱们采纳一种新的模式来装置和治理 Helm 利用。咱们将其定位为 Rainbond 原生利用的补充，作为部署一些中间件的载体，所以咱们次要要思考解决以下问题：
（1）Helm 装置的利用如何接入 Rainbond ServiceMesh 微服务架构，实现原生利用可调用 Helm 利用。
（2）Helm 装置的利用如何接入 Rainbond 网关，实现内部拜访及流量治理。
（3）Helm 利用治理能力反对多少。
咱们定义了 Kubernets 自定义资源 HelmApp，实现 HelmApp 的多集群部署。用户对接上 Helm 利用商店后，即可抉择利用进行装置。装置过程中齐全反对 Helm 利用的配置标准进行利用配置，同时也反对 Rancher 定义的配置表单标准，实现配置表单主动生成。Helm 利用部署后自动识别其 Service 资源，进行服务的注册，实现 Rainbond 微服务和网关体系的接入。
逐渐适配 OAM 利用标准
从 5.3.1 版本开始，咱们开始逐渐适配 OAM 利用标准，晋升 Rainbond 的可扩展性。在以后版本中咱们基于 OAM 标准，从新实现第三方组件类型，定义了 ThirdComponent 作为第一个 ComponentDefinition，并在产品中实现对 ComponentDefinition 的根底管理机制。接下来 Rainbond 中现有的两种内置组件类型逐渐基于 ComponentDefinition 定义实现。而后凋谢用户自行扩大的能力，Rainbond 中提供整个支撑体系，包含通用运维特色能力注入、配置 UI 化、通用的微服务治理和流量治理、利用打包交付等。
具体变更点
新增性能
- 【利用商店】反对 Helm 利用仓库对接；
- 【利用治理】反对 Helm 利用装置和配置；
- 【微服务治理】反对通过网关或外部组件依赖两种形式拜访 Helm 装置的利用；
- 【微服务治理】新增 GRPC 协定的服务治理能力；
- 【微服务治理】新增对组件下容器启动顺序控制，实现 mesh 容器先于业务容器启动；
- 【组件治理】新增基于 kubernetes service 服务发现类型的第三方组件；
- 【源码构建】Go 语言新增对 Go 1.14、1.15、1.16 版本 Runtime 的反对；
- 【源码构建】Go 语言新增对构建模块和启动命令的配置；
- 【源码构建】Java、Go、PHP 等语言新增 pre_build、post_build 构建时 shell hook 的反对；
- 【企业治理】用户治理中新增对用户所在团队及角色的批量治理能力；
- 【企业治理】团队治理中新增开明集群的性能入口；
- 【集群装置】反对 RKE 集群配置，实现集群节点配置的灵便调整；
优化性能
- 【性能】利用降级体系优化，反对 100+ 组件批量降级；
- 【性能】从利用商店装置组件实现优化，反对 100+ 组件批量装置；
- 【性能】改良拓扑图加载逻辑，减速大利用下拓扑图加载速度；
- 【性能】优化在大量组件状况下的利用级生命周期操作 API 的性能；
- 【稳定性】利用网关优化，解决异样利用拜访导致网关内存泄露的故障；
- 【组件治理】反对空值的环境变量和配置组变量；
- 【监控报警】移除谬误的节点衰弱检测报警策略；
- 【组件治理】重构组件本地存储类型的实现，反对应用本地存储组件复用集群的调度策略；
- 【外部组件库】新增利用模型版本治理，反对在发布页展现版本介绍；
- 【组件治理】反对组件设置自定义主机名解析记录；
BUG 修复
- 【源码构建】修复 .netcore 源码构建工作无奈完结的故障；
- 【控制台】修复网关策略搜寻性能不可用故障；
- 【源码构建】修复 Maven 配置删除后源码构建无奈执行的故障；
- 【稳定性】修复谬误的网关策略参数导致网关故障；
- 【组件治理】修复组件实例数不统一的故障；
- 【稳定性】修复 rbd-worker 零碎组件因为 etcd 不稳固异样重启的故障；
- 【利用治理】修复对接非 HTTPS 镜像仓库时利用备份不可用的故障；
- 【集群装置】修复集群镜像仓库证书不统一的故障；
社区
如果您对 Rainbond 我的项目感兴趣，如果您有一些疑难，如果您对云原生、Kubernetes 等技术感兴趣，欢送退出 Rainbond 社区钉钉群。
装置应用请参考文档：疾速装置
从 5.3.0 降级到 5.3.1: 降级参考文档
