背景
每个程序员在学习开发的过程中，都晓得解耦和模块化的重要性，也心愿本人设计和开发的程序反对模块化，开发好的模块其他人就能疾速复用，为了达成这个成果，咱们学习各种模块化和解耦的技术，从面向对象的设计模式到微服务架构，近几年大家感觉微服务架构是模块化的银弹，都朝微服务架构革新，但实际效果不仅没有很好模块化，反而陷入利用部署和运维的泥潭里。本文将讲讲 Rainbond 解决利用架构解耦和模块化的一些新思路。
以后业务模块化和解耦的问题
- 架构耦合度还是太高，解耦的不彻底 。比方通过微服务架构拆解的微服务，受开发语言和微服务框架限度，跨开发语言不能调用，跨框架也无奈应用，还受限于部署环境，换个环境须要从新解决部署问题。
- 从开发者角度定义模块，而不是从使用者角度定义模块，导致应用体验不好 。当初咱们定义的模块通常都是开发定义的，因为开发离理论应用场景比拟远，主观的认为模块拆的细和小，不论有什么场景需要我的模块都能复用和满足，但从使用者角度，模块拆分的越小越细，学习和应用的老本就越高，甚至基本应用不起来，很多模块化是适度的拆解和适度的设计。
- 模块化公布简单，保护和降级老本高 。当初的模块化自身是一个开发过程，定义和打包过程都须要开发参加，导致老本高。
基于 Rainbond 利用模型的解耦和实现思路
Rainbond 是一个云原生利用治理平台，能够治理利用全生命周期。上面咱们具体解说一下 Rainbond 如何解决上述问题。
Rainbond 的外围形象和定义了一套利用模型，通过利用模型从架构上解决解耦问题，利用模型将利用、运维个性和底层基础设施彻底解耦，利用又由多个业务组件拼装而成，每个业务组件能够是不同开发语言和不同构建形式，只有合乎业务契约就能够拼装。通过以上解耦形式，彻底将业务组件、运维能力和部署环境解耦，业务组件只须要专一纯业务，不再关怀因为应用场景差别须要匹配不同开发框架、服务治理性能、运维工具和部署环境，业务组件、运维能力和部署环境实现依据应用场景自由组合和拼装。
基于业务组件的拼装场景：
- 从业务性能开发上 ，业务组件提供的是基于业务协定的服务，不受框架和开发语言限度，能够供其余业务场景复用；
- 从运维治理上 ，在开发测试环境不须要开启运维的个性，在生产环境对业务的治理、监控、性能、稳定性和安全性有更高的要求，按需开启通过插件机制实现的运维个性；
- 从部署环境上 ，利用模型底层实现对接规范 k8s API，所有合乎 k8s 规范 API 的基础设施都能够实现对接和部署，也就实现了业务组件不须要改变就能够部署到私有云、公有云和边缘设施上。
解耦不仅能进步各种场景的灵活性，还能让业务组件、运维插件和基础设施复用率大幅度提高，当积攒的可复用的能力越多，咱们面对不同场景、不同用户和不同市场的响应能力也越强。
Rainbond 利用模型遵循“以利用为核心”的设计理念，将利用无关的底层简单技术封装，简化了解和应用体验。利用模型能够以利用模版的模式展示和存储，以上可复用的能力通过利用模版公布到利用市场，供其他人应用，从而实现模块复用。通常咱们实现模块化次要思考开发者，而利用模版更多思考使用者，从使用者角度形象定义，让使用者能用起来，从而拉动利用模版的生产。从应用体验上，利用模版能够一键装置和一键降级，通过“利落拽”的形式实现业务拼装。利用模版有很强灵活性，利用模版反对不同颗粒度大小，模版和模版能拼装出新的模版，新的模版还能够继续拼装，颗粒的大小由使用者决定，由使用者赋予它意义。
利用模版具备可打包业务的能力，有四个特点：
- 模块化 ，能够造成可复用的能力单元，按需拼装应用场景。
- 自治 ，自力更生，能够独立装置、降级和治理，确保组合的灵活性。
- 可编排 ，模版和模版能够拼装出新模版，具备有限拼装能力。
- 可发现 ，通过外部服务和内部服务两种形式体现，可供业务和技术、开发者和其余利用拜访。
利用模版的定义和实现内容：
-
利用根本的元数据
- 名称
- 工夫戳
- 版本号和别称
- 资源占用状况
- 利用治理模式（k8s service 模式、Service Mesh 内置和 Istio）
-
利用网关信息
- 对外端口
- 域名和证书
- 公布策略
- 利用全局配置
-
一个或多个业务组件
- 业务组件的依赖关系
-
业务组件类型（源码、镜像、Helm 和第三方 API）
- 组件的构建形式
- 组件的存储形式
- 组件的配置形式
- 组件的运行形式
- 业务组件的插件
- 组件端口和协定
- 组件环境变量
模块公布和拼装流程
在 Rainbond 中利用模版是模块的表现形式，模块公布和拼装流程就是利用模版的公布和拼装过程。模块建设是一个长期过程，强调积攒，更多是在实际过程中的积淀，同时须要依据反馈来继续迭代。
这个过程分四步：
第一步：模块以利用模版的模式一键公布，所见即所得
公布业务组件首先须要从业务角度定义颗粒度和业务接口，而后将要公布的组件在 Rainbond 构建，Rainbond 反对各种构建源，构建的同时也在定义利用模版，只有构建胜利，就能够一键公布成利用模版，也就意味着任何在应用平台的开发者都具备公布利用模版的能力，公布的门槛低有利于常识和教训的分享。
第二步：通过利用市场寄存不同颗粒度的模块
利用模版反对不同颗粒度，针对不同应用场景包装不同颗粒度：
- 面向外部研发场景，次要积攒技术模版，模版颗粒度绝对较小，为了进步开发效率。
- 面向客户交付场景，次要积攒业务模版，模版颗粒度较大，通过模版能够疾速拼装客户解决方案，进步交付效率。
- 面向销售场景，次要积攒能够销售的产品模版，颗粒度最大，能帮忙销售疾速演示、应用和整体交付。
第三步：通过利用模版实现模块化拼装
从利用市场一键装置须要拼装的模块（利用模版），通过“利落拽”将多个模块拼装成须要场景，拼装后原模块公布新版本，在拼装好的场景里按需降级。新拼装好的场景公布成利用模版，能够是更大的模块反对更大场景的拼装，也通过利用模版实现后续客户交付流程。
第四步：在实在利用场景中，继续积攒和迭代
模块的建设过程，要防止适度设计和提前适度拆解，模块提前拆解或拆解的粒度太小，会导致模块开发和保护老本高，应用体验不好。所以，模块后期设计和开发只能占少部分，大部分模块在实在场景中能力看到它的价值，这时候再公布成可复用的模块，更加具备实用性。同时，模块的边界和性能在实在场景中才有意义，须要依据理论需要一直迭代。
应用场景
可拼装的业务模块，进步开发效率和客户交付速度
对于软件公司的研发和客户交付场景，通过可拼装的业务模块，在新我的项目研发和新客户交付过程中复用，缩小重复性开发，能大幅度提高效率。
行业业务中台，实现行业能力积攒和复用
对于行业用户，实现数字化的过程，会建设很多套零碎，这些零碎有很多能力是通用的，把这些能力积攒下来，后续建设过程间接复用，不仅缩小了建设周期，复用成熟的能力还能进步零碎成熟度。另外，须要业务交融和数据融场景，能够通过业务编排，实现零碎之间的互联互通。
2B 软件公司的产品化包装和模块化销售
对于 2B 软件公司，会面对我的项目个性化和产品标准化的矛盾，要解决这对矛盾有两个解决方案：一个是让个性化的我的项目也能疾速积淀出产品，这个过程通过公布利用模版能疾速实现；另一个是将个性化的我的项目按模块化拆解，不同客户抉择不同模块，实现依据客户需要个性化销售；这两个计划能够进一步交融，在晚期，个性化我的项目是驱动力，我的项目的模版能够作为给其余客户演示和交付的产品根底，在一直的交付客户过程中，发现和拆解可复用的模块和个性化的模块，等交付客户越多，积攒的可复用模块也就越多，也晓得哪些模块有商业价值，模块化成为产品的根底，更好服务销售和交付，产品化也就越成熟。