高手问答第 300 期 —— toB 企业如何利用云原生做软件交付?

小白兔爱吃大灰狼 发布于 05/16 18:37
阅读 3K+
收藏 1
我们常说的 CD 是持续集成、持续部署,通常适用于 toC 的企业,一个环境或者多个环境进行持续集成。而标题中说的软件交付指的是 toB 软件交付,将企业内部开发完成的软件交付到客户的环境中。
在 toB 企业内部工作的我们很清楚,在面临软件交付的时候有多么复杂,特别是面对银行、政府等这些客户,投入的人力与成本会非常大。
在云原生的浪潮下,业务从单体演变成微服务,传统软件交付演变为云原生软件交付,但在云原生模式下交付微服务仍存在一些问题,例如:大规模微服务 YAML 过多、配置过多,Helm Chart 维护太复杂等等。
 
OSCHINA 本期高手问答 (5 月 17 日 - 5 月 23 日) 我们请来了 张齐老师 和大家一起探讨关于toB 企业如何利用云原生做软件交付的话题。
 
可讨论的内容包括但不限于以下几个方面:
  • 大规模微服务软件交付相关。
  • 在线、离线软件交付相关。
  • 研发交付一体化。
以及其他与微服务、交付相关问题,欢迎提问。

嘉宾简介

张齐,Rainbond 开源社区负责人,热爱开源,曾经也是一名 coder。
 

为了鼓励踊跃提问,我们会在问答结束后从提问者中抽取幸运会员赠予笔记本/马克杯一份。

OSChina 高手问答一贯的风格,不欢迎任何与主题无关的讨论和喷子。

下面欢迎大家就 toB 企业如何利用云原生做软件交付 相关问题向 张齐老师 提问,直接回帖提问既可。

加载中
0
小白兔爱吃大灰狼
小白兔爱吃大灰狼

高手问答第 300 期 —— toB 企业如何利用云原生做软件交付?

@滕勇志  @iman123 @NIGIAO  @pyboy58

恭喜以上四位网友分别获得笔记本 / 马克杯一份

请于6月1日前登陆账号, 私信  @小白兔爱吃大灰狼   告知快递信息(格式:姓名+电话+地址),过期视为自动放弃哦~

0
Li_Peng
Li_Peng

@Rainbond 您好,Rainbond除了应用级抽象、使用简单之外,与其他竞品的对比,还有哪些主要区别和优势呢?

Rainbond
Rainbond
Rainbond 的产品定位是云原生应用管理平台,面向的行业大多数是 toB 企业,同时也解决了应用开发 -> 应用交付整个流程。toB 的在线交付、离线交付是 Rainbond 独有的特色,还有拓扑图的微服务编排,以及基于 Rainbond 应用模型之上的应用市场等等,欢迎安装体验 Rainbond https://www.rainbond.com/
0
regend
regend

@Rainbond 您好,请问下tob场景的交付下,怎么解决不同应用之间的版本依赖问题

Rainbond
Rainbond
回复 @regend : 指的是服务之间的依赖吧,比如说 A服务依赖了 B服务这样的,Rainbond 这一层解决了这个问题,原生就带 Service mesh 治理,并且也会控制服务之间的依赖顺序,比如说几十个服务相互之间的依赖和谁先启动谁后启动,都可以控制,这也是 Rainbond 特色之一,k8s 中是没有的,包括其他的平台
regend
regend
回复 @Rainbond : 应用之间的版本依赖,部署依赖
Rainbond
Rainbond
您指的应用之间的版本依赖是指微服务模块之间的版本依赖么,还是别的什么,能否描述的更清晰些,这样我能更好的回答您的问题
0
滕勇志
滕勇志

@Rainbond 麻烦请介绍下离线交付的背后具体是做了那些工作

滕勇志
滕勇志
回复 @Rainbond : 明白了。感谢答复
Rainbond
Rainbond
回复 @滕勇志 : 公司内开发和客户现场都用 Rainbond,这样才能体验到 Rainbond 应用模型交付的便捷,不过应用模型也支持导出别的格式包,比如:docker-compose、helm 等等。
滕勇志
滕勇志
回复 @Rainbond : 这是不是也意味着客户也需要安装 rainbond
Rainbond
Rainbond
与 Helm Chart 不同的是 Rainbond 的这一套应用体系和打包、分发更加简单,不用编写复杂的 YAML 和 Chart 包,也不用管一堆的镜像和配置文件怎么处理,降低交付人员门槛的同时也提升了交付效率
Rainbond
Rainbond
Rainbond 基于 RAM (Rainbond Application Model)应用模型支撑,定义了应用的规范,基于此衍生了应用商店,可以一键将几十个大规模的微服务发布到应用商店,发布后可以导出一整个 tgz 压缩包,其中包含了镜像、元数据描述信息等,把离线包拿到客户现场,直接导入并且一键安装、交付即可。
0
NIGIAO
NIGIAO

@Rainbond请教下,在toB场景下,云原生的交付体系,相对于传统的jenkins或者gitlab的CD,能力上有什么增量吗?

Rainbond
Rainbond
曾经的业务架构很简单,就一个 war 包,交付也是通过 Jenkins 把 War 包打出来,然后拿到客户那去交付、运行,但技术也需要迭代、进步,转变为微服务架构之后,这种传统方式就行不通了,Jar 包和配置文件以及启动脚本等等,太多了,处理起来非常麻烦,这时候容器和容器编排就是很好的解决方案
0
pyboy58
pyboy58

@Rainbond  1.持续集成 怎么做到研发交付一体化??

2.rainbond 感觉和 rancher 做的事情很接近, 和rancher的差异化和共同点有哪些??

3.如果不用管一堆的镜像和配置文件, 怎么做到差异化管理容器和每个微服务的资源??

Rainbond
Rainbond
3. Rainbond 将一个微服务模块抽象成一个组件,每个组件都有它们对应的配置,包括镜像、环境变量、配置文件等等,当然这些配置还要管理的。我上面说的不用管理的意思是当我们通过 Helm Chart 交付的时候会有 Chart 包、很多镜像 tar 包、以及 SQL等等,而这些在 Rainbond 上交付时都能包含到一个 tgz 包内,导入后再去配置,会比较清晰、易用
Rainbond
Rainbond
2. Rainbond 与 rancher 完全两个路线哈,不冲突,rancher 做容器管理平台,包括容器周边的生态,k3s、rke、rke2 等等,Rainbond 底层的 k8s 集群还采用了 rke 呢,Rainbond 不做容器以下的事,做容器以上的事就是应用层的事情。共同点就是底层都是 k8s,差异化就比较大了,完全不一样
Rainbond
Rainbond
1. Rainbond 在开发测试环境使用的也比较广泛,从源码一键部署 -> 微服务编排 -> 持续集成 -> 测试等等,客户环境也用 Rainbond,当研发完成之后就发布到应用商店,客户环境安装,这是个简述版的研发交付一体化,当然还有别的更详细的场景,需要具体实践哈
0
LeoXu
LeoXu

@Rainbond 您好,基于咱这个主题(toB 企业如何利用云原生做软件交付),我想了解下典型的整个交付流程,老师能否概要地阐述一下?或者推荐一些博文资料,谢谢!

Rainbond
Rainbond
之前有写过一些文章,可以看看: https://mp.weixin.qq.com/s/Y2xqBkk-SA5pZFlx8vC0PA https://mp.weixin.qq.com/s/3Dx-Xs_JIjPTDYHL5RZ1eg
0
hi懒喵
hi懒喵

必须支持大规模云服务快速更新的能力、服务必须具有高健壮性、故障自愈能力

0
e
ericyan1

@Rainbond
您好,云原生软件交付后,运维和运营是怎么规划,请老师给些建议。

Rainbond
Rainbond
运营不太清楚你指的是什么,运维的话也得看客户需求,有些客户不需要频繁迭代,这就不需要太多运维工作。
0
pyboy58
pyboy58

@Rainbond  k8s集群有两个网段一个公网可以访问,一个只可以访问内部网,k8s容器化后网段怎么划分和隔离比较好?

Rainbond
Rainbond
描述的不是很具体哈,能否把场景描述的更具体写
OSCHINA
登录后可查看更多优质内容
返回顶部
顶部