使用Rainbond打包业务模块，实现业务积木式拼装使用Rainbond打包业务模块，实现

背景每个程序员在学习开发的过程中，都知道解耦和模块化的重要性，也希望自己设计和开发的程序支持模块化，开发好的模块其他人就能快速复用，为了达成这个效果，我们学习各种模块化和解耦的技术，从面向对象的设计模式到微服务架构，近几年大家觉得微服务架构是模块化的银弹，都朝微服务架构改造，但实际效果不仅没有很好模块化，反而陷入应用部署和运维的泥潭里。本文将讲讲Rainbond解决应用架构解耦和模块化的一些新思路。
当前业务模块化和解耦的问题

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

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

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

文章图片

【使用Rainbond打包业务模块，实现业务积木式拼装】解耦不仅能提高各种场景的灵活性，还能让业务组件、运维插件和基础设施复用率大幅度提高，当积累的可复用的能力越多，我们面对不同场景、不同用户和不同市场的响应能力也越强。
Rainbond 应用模型遵循“以应用为中心”的设计理念，将应用无关的底层复杂技术封装，简化理解和使用体验。应用模型可以以应用模版的形式展现和存储，以上可复用的能力通过应用模版发布到应用市场，供其他人使用，从而实现模块复用。通常我们实现模块化主要考虑开发者，而应用模版更多考虑使用者，从使用者角度抽象定义，让使用者能用起来，从而拉动应用模版的生产。从使用体验上，应用模版可以一键安装和一键升级，通过“拖拉拽”的方式实现业务拼装。应用模版有很强灵活性，应用模版支持不同颗粒度大小，模版和模版能拼装出新的模版，新的模版还可以持续拼装，颗粒的大小由使用者决定，由使用者赋予它意义。
应用模版具备可打包业务的能力，有四个特点：

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

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

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

模块发布和拼装流程

文章图片

在Rainbond中应用模版是模块的表现形式，模块发布和拼装流程就是应用模版的发布和拼装过程。模块建设是一个长期过程，强调积累，更多是在实践过程中的沉淀，同时需要根据反馈来持续迭代。
这个过程分四步：
第一步：模块以应用模版的形式一键发布，所见即所得发布业务组件首先需要从业务角度定义颗粒度和业务接口，然后将要发布的组件在Rainbond构建，Rainbond支持各种构建源，构建的同时也在定义应用模版，只要构建成功，就可以一键发布成应用模版，也就意味着任何在使用平台的开发者都具备发布应用模版的能力，发布的门槛低有利于知识和经验的分享。

文章图片

第二步：通过应用市场存放不同颗粒度的模块应用模版支持不同颗粒度，针对不同使用场景包装不同颗粒度：

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

文章图片

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

文章图片

第四步：在真实应用场景中，持续积累和迭代模块的建设过程，要避免过度设计和提前过度拆解，模块提早拆解或拆解的粒度太小，会导致模块开发和维护成本高，使用体验不好。所以，模块前期设计和开发只能占少部分，大部分模块在真实场景中才能看到它的价值，这时候再发布成可复用的模块，更加具备实用性。同时，模块的边界和功能在真实场景中才有意义，需要根据实际需求不断迭代。
使用场景可拼装的业务模块，提高开发效率和客户交付速度对于软件公司的研发和客户交付场景，通过可拼装的业务模块，在新项目研发和新客户交付过程中复用，减少重复性开发，能大幅度提高效率。
行业业务中台，实现行业能力积累和复用对于行业用户，实现数字化的过程，会建设很多套系统，这些系统有很多能力是通用的，把这些能力积累下来，后续建设过程直接复用，不仅减少了建设周期，复用成熟的能力还能提高系统成熟度。另外，需要业务融合和数据融场景，可以通过业务编排，实现系统之间的互联互通。
2B软件公司的产品化包装和模块化销售对于2B软件公司，会面对项目个性化和产品标准化的矛盾，要解决这对矛盾有两个解决方案：一个是让个性化的项目也能快速沉淀出产品，这个过程通过发布应用模版能快速实现；另一个是将个性化的项目按模块化拆解，不同客户选择不同模块，实现根据客户需求个性化销售；这两个方案可以进一步融合，在早期，个性化项目是驱动力，项目的模版可以作为给其他客户演示和交付的产品基础，在不断的交付客户过程中，发现和拆解可复用的模块和个性化的模块，等交付客户越多，积累的可复用模块也就越多，也知道哪些模块有商业价值，模块化成为产品的基础，更好服务销售和交付，产品化也就越成熟。