关于kubernetes:使用Rainbond打包业务模块实现业务积木式拼装

背景

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

以后业务模块化和解耦的问题

  • 架构耦合度还是太高,解耦的不彻底 。比方通过微服务架构拆解的微服务,受开发语言和微服务框架限度,跨开发语言不能调用,跨框架也无奈应用,还受限于部署环境,换个环境须要从新解决部署问题。
  • 从开发者角度定义模块,而不是从使用者角度定义模块,导致应用体验不好 。当初咱们定义的模块通常都是开发定义的,因为开发离理论应用场景比拟远,主观的认为模块拆的细和小,不论有什么场景需要我的模块都能复用和满足,但从使用者角度,模块拆分的越小越细,学习和应用的老本就越高,甚至基本应用不起来,很多模块化是适度的拆解和适度的设计。
  • 模块化公布简单,保护和降级老本高 。当初的模块化自身是一个开发过程,定义和打包过程都须要开发参加,导致老本高。

基于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软件公司,会面对我的项目个性化和产品标准化的矛盾,要解决这对矛盾有两个解决方案:一个是让个性化的我的项目也能疾速积淀出产品,这个过程通过公布利用模版能疾速实现;另一个是将个性化的我的项目按模块化拆解,不同客户抉择不同模块,实现依据客户需要个性化销售;这两个计划能够进一步交融,在晚期,个性化我的项目是驱动力,我的项目的模版能够作为给其余客户演示和交付的产品根底,在一直的交付客户过程中,发现和拆解可复用的模块和个性化的模块,等交付客户越多,积攒的可复用模块也就越多,也晓得哪些模块有商业价值,模块化成为产品的根底,更好服务销售和交付,产品化也就越成熟。

【腾讯云】云产品限时秒杀,爆款1核2G云服务器,首年50元

阿里云限时活动-2核2G-5M带宽-60G SSD-1000G月流量 ,特惠价99元/年(原价1234.2元/年,可以直接买3年),速抢

本文由乐趣区整理发布,转载请注明出处,谢谢。

您可能还喜欢...

发表评论

您的电子邮箱地址不会被公开。

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据