业务积木式拼装

当前业务模块化和解耦的问题​

• 架构耦合度还是太高，解耦的不彻底 。比如通过微服务架构拆解的微服务，受开发语言和微服务框架限制，跨开发语言不能调用，跨框架也无法使用，还受限于部署环境，换个环境需要重新解决部署问题。
• 从开发者角度定义模块，而不是从使用者角度定义模块，导致使用体验不好 。现在我们定义的模块通常都是开发定义的，由于开发离实际使用场景比较远，主观的认为模块拆的细和小，不管有什么场景需求我的模块都能复用和满足，但从使用者角度，模块拆分的越小越细，学习和使用的成本就越高，甚至根本使用不起来，很多模块化是过度的拆解和过度的设计。
• 模块化发布复杂，维护和升级成本高 。现在的模块化本身是一个开发过程，定义和打包过程都需要开发参与，导致成本高。

基于 Rainbond 应用模型的解耦和实现思路​

Rainbond是一个云原生应用管理平台，可以管理应用全生命周期。下面我们详细讲解一下 Rainbond 如何解决上述问题。

Rainbond 的核心抽象和定义了一套应用模型，通过应用模型从架构上解决解耦问题，应用模型将应用、运维特性和底层基础设施彻底解耦，应用又由多个业务组件拼装而成，每个业务组件可以是不同开发语言和不同构建方式，只要符合业务契约就可以拼装。通过以上解耦方式，彻底将业务组件、运维能力和部署环境解耦，业务组件只需要专注纯业务，不再关心由于使用场景差异需要匹配不同开发框架、服务治理功能、运维工具和部署环境，业务组件、运维能力和部署环境实现根据使用场景自由组合和拼装。

基于业务组件的拼装场景：

• 从业务功能开发上，业务组件提供的是基于业务协议的服务，不受框架和开发语言限制，可以供其他业务场景复用；
• 从运维管理上，在开发测试环境不需要开启运维的特性，在生产环境对业务的治理、监控、性能、稳定性和安全性有更高的要求，按需开启通过插件机制实现的运维特性；
• 从部署环境上，应用模型底层实现对接标准 k8s API，所有符合 k8s 标准 API 的基础设施都可以实现对接和部署，也就实现了业务组件不需要改动就可以部署到公有云、私有云和边缘设备上。

解耦不仅能提高各种场景的灵活性，还能让业务组件、运维插件和基础设施复用率大幅度提高，当积累的可复用的能力越多，我们面对不同场景、不同用户和不同市场的响应能力也越强。

Rainbond 应用模型遵循“以应用为中心”的设计理念，将应用无关的底层复杂技术封装，简化理解和使用体验。应用模型可以以应用模版的形式展现和存储，以上可复用的能力通过应用模版发布到应用市场，供其他人使用，从而实现模块复用。通常我们实现模块化主要考虑开发者，而应用模版更多考虑使用者，从使用者角度抽象定义，让使用者能用起来，从而拉动应用模版的生产。从使用体验上，应用模版可以一键安装和一键升级，通过“拖拉拽”的方式实现业务拼装。应用模版有很强灵活性，应用模版支持不同颗粒度大小，模版和模版能拼装出新的模版，新的模版还可以持续拼装，颗粒的大小由使用者决定，由使用者赋予它意义。

应用模版具备可打包业务的能力，有四个特点：

1. 模块化，可以形成可复用的能力单元，按需拼装使用场景。
2. 自治，自给自足，可以独立安装、升级和管理，确保组合的灵活性。
3. 可编排，模版和模版可以拼装出新模版，具备无限拼装能力。
4. 可发现，通过内部服务和外部服务两种方式体现，可供业务和技术、开发者和其他应用访问。

应用模版的定义和实现内容：

• 应用基本的元数据
  • 名称
  • 时间戳
  • 版本号和别称
  • 资源占用情况
• 应用治理模式（ k8s service 模式、Service Mesh 内置和 Istio）
• 应用网关信息
  • 对外端口
  • 域名和证书
  • 发布策略
• 应用全局配置
• 一个或多个业务组件
  • 业务组件的依赖关系
  • 业务组件类型（源码、镜像、Helm 和第三方 API）
    • 组件的构建方式
    • 组件的存储方式
    • 组件的配置方式
    • 组件的运行方式
  • 业务组件的插件
  • 组件端口和协议
  • 组件环境变量

模块发布和拼装流程​

在 Rainbond 中应用模版是模块的表现形式，模块发布和拼装流程就是应用模版的发布和拼装过程。模块建设是一个长期过程，强调积累，更多是在实践过程中的沉淀，同时需要根据反馈来持续迭代。 这个过程分四步：

第一步： 模块以应用模版的形式一键发布，所见即所得​

发布业务组件首先需要从业务角度定义颗粒度和业务接口，然后将要发布的组件在 Rainbond 构建，Rainbond 支持各种构建源，构建的同时也在定义应用模版，只要构建成功，就可以一键发布成应用模版，也就意味着任何在使用平台的开发者都具备发布应用模版的能力，发布的门槛低有利于知识和经验的分享。

第二步： 通过应用市场存放不同颗粒度的模块​

应用模版支持不同颗粒度，针对不同使用场景包装不同颗粒度：

• 面向内部研发场景，主要积累技术模版，模版颗粒度相对较小，为了提高开发效率。
• 面向客户交付场景，主要积累业务模版，模版颗粒度较大，通过模版可以快速拼装客户解决方案，提高交付效率。
• 面向销售场景，主要积累可以销售的产品模版，颗粒度最大，能帮助销售快速演示、使用和整体交付。

第三步：通过应用模版实现模块化拼装​

从应用市场一键安装需要拼装的模块（应用模版），通过“拖拉拽”将多个模块拼装成需要场景，拼装后原模块发布新版本，在拼装好的场景里按需升级。新拼装好的场景发布成应用模版，可以是更大的模块支持更大场景的拼装，也通过应用模版实现后续客户交付流程。

第四步：在真实应用场景中，持续积累和迭代​

模块的建设过程，要避免过度设计和提前过度拆解，模块提早拆解或拆解的粒度太小，会导致模块开发和维护成本高，使用体验不好。所以，模块前期设计和开发只能占少部分，大部分模块在真实场景中才能看到它的价值，这时候再发布成可复用的模块，更加具备实用性。同时，模块的边界和功能在真实场景中才有意义，需要根据实际需求不断迭代。

使用场景​

可拼装的业务模块，提高开发效率和客户交付速度​

对于软件公司的研发和客户交付场景，通过可拼装的业务模块，在新项目研发和新客户交付过程中复用，减少重复性开发，能大幅度提高效率。

行业业务中台，实现行业能力积累和复用​

对于行业用户，实现数字化的过程，会建设很多套系统，这些系统有很多能力是通用的，把这些能力积累下来，后续建设过程直接复用，不仅减少了建设周期，复用成熟的能力还能提高系统成熟度。另外，需要业务融合和数据融场景，可以通过业务编排，实现系统之间的互联互通。

2B 软件公司的产品化包装和模块化销售​

对于 2B 软件公司，会面对项目个性化和产品标准化的矛盾，要解决这对矛盾有两个解决方案：一个是让个性化的项目也能快速沉淀出产品，这个过程通过发布应用模版能快速实现；另一个是将个性化的项目按模块化拆解，不同客户选择不同模块，实现根据客户需求个性化销售；这两个方案可以进一步融合，在早期，个性化项目是驱动力，项目的模版可以作为给其他客户演示和交付的产品基础，在不断的交付客户过程中，发现和拆解可复用的模块和个性化的模块，等交付客户越多，积累的可复用模块也就越多，也知道哪些模块有商业价值，模块化成为产品的基础，更好服务销售和交付，产品化也就越成熟。