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

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

背景

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

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

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

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

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

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

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

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

使用Rainbond打包业务模块,实现业务积木式拼装_第1张图片

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

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

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

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

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

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

模块发布和拼装流程

使用Rainbond打包业务模块,实现业务积木式拼装_第2张图片

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

第一步: 模块以应用模版的形式一键发布,所见即所得

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

使用Rainbond打包业务模块,实现业务积木式拼装_第3张图片

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

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

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

使用Rainbond打包业务模块,实现业务积木式拼装_第4张图片

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

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

使用Rainbond打包业务模块,实现业务积木式拼装_第5张图片

第四步:在真实应用场景中,持续积累和迭代

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

使用场景

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

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

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

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

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

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

你可能感兴趣的:(组件化,paas,kubernetes)