本文将解读Rainbond集群的安装和运维的原理，使用户基本了解Rainbond的安装机制和运维重点，便于用户搭建大型Rainbond集群。

如果您现在已经有了自己的CI工作流程，并且想在云帮中持续部署您的应用，那么本文将引导您将自己的应用部署到云帮并设置持续部署。考虑到Jenkins是目前主流的持续集成工具，并且它在源码测试和Pipline方面已经做得非常成熟，所以我们提供了针对Jenkins的集成方案。一般情况下，我们的源码在经Jenkins的构建和集成后，产...

2019年8月12日，Rainbond发布5.1.6版本，本次版本更新带来了更简化的Rainbond高可用安装方案，解决了社区用户反馈的BUG问题。

根据大量的Rainbond用户反馈，我们发现在Rainbond源码构建java-maven项目的过程中，最容易出现问题的一环就是获取构件失败。

2）此时，Slave服务器的IO线程会通过在master上已经授权的复制用户权限请求连接master服务器，并请求从执行binlog日志文件的指定位置（日志文件名和位置就是在配置主从复制服务时执行change master命令指定的）之后开始发送binlog日志内容。

Apache Maven是跨平台的项目管理工具。主要服务于基于Java平台的项目构建，项目管理和项目信息管理。所谓的项目构建就是对项目进行清理、编译、测试、报告、打包、部署等一系列的过程称为项目的构建。

测试结果表明：在最新龙芯3B3000芯片上（具备向下兼容），云帮PaaS的通用兼容性、运行稳定性、功能可靠性等方面均达到生产要求，能够满足军工、政务等用户的关键性需要。

2019年7月8日，Rainbond发布5.1.5版本，本次版本更新带来了全新的应用市场交付Pipeline体验，并对源码类服务的运行机制、ServiceMesh架构、服务管理等方面做了大量优化。

今天为大家带来Rainbond 5.1系列第四个更新版本，本次版本更新的主要内容是复杂微服务架构应用整体升级和回滚，能实现复杂微服务架构的持续交付，和复杂架构企业级应用快速交付和升级，另外还有一些小的优化和BUG的修复。

Rainbond 原生支持 Service Mesh 微服务架构。也就是说，无论原来是什么，只要部署在 Rainbond 上，那么就天然的成为了 Service Mesh 微服务。这也是 Service Mesh 微服务架构的一大特点：对原应用无侵入。

今天为大家带来Rainbond 5.1系列第三个更新版本，本次版本更新的关键是降低Rainbond学习门槛，我们不仅增加了新用户指导任务来指引用户学习Rainbond的线路，同时在通过源码批量创建服务、通过Docker镜像批量智能创建服务等多个方面增加了大量改进来方便用户。

Rainbond是开源的企业应用云操作系统，支撑企业应用的开发、架构、交付和运维的全流程，通过无侵入架构，无缝衔接各类企业应用，底层资源可以对接和管理IaaS、虚拟机和物理服务器。

3月的北京春意盎然，Rainbond如期为大家带来了大版本V5.1更新，在此首先对所有为Rainbon项目提过建议的用户朋友们表示感谢，V5.1版本的较多思考就是来自于众多用户为Rainbond项目提出的建议。

​ 今天非常高兴向大家宣布Rainbond v5.0正式发布，Rainbond是开源的企业应用云操作系统，支撑企业应用开发、架构、交付和运维的全流程，通过无侵入架构，无缝衔接各类企业应用，底层资源可以对接和管理IaaS、虚拟机和物理服务器。

Rainbond支撑企业应用的开发、架构、交付和运维的全流程，通过“无侵入”架构无缝衔接各类企业应用，底层资源可以对接和管理IaaS、虚拟机和物理服务器

缩短time-to-makrt对于任何一家企业都至关重要，这直接决定了客户满意度、市场竞争力乃至盈利能力。但在部署应用时，大多数企业内的IT团队都或多或少会遇到Dev和Ops之间的问题，这两个部门围绕着同一个应用工作，但工作方式却截然不同。

Rainbond（云帮）是"以应用为中心”的开源PaaS，深度整合基于Kubernetes的容器管理、ServiceMesh微服务架构最佳实践、多类型CI/CD应用构建与交付、多数据中心资源管理等技术，为用户提供云原生应用全生命周期解决方案，构建应用与基础设施、应用与应用、基础设施与基础设施之间互联互通的生态体系，满足支撑业务高速发展...

持续交付（CD, Continuous delivery）就是说每次提交代码时立即构建，并可以将构建部署到生产环境中，本文将分享一些持续交付相关的方法和经验。

微服务架构允许我们再创建新应用时自由选择不同的技术和编程语言。不过究竟哪种语言更适合我们当下的硬件？回答这个问题，需要搞明白Java和Go编写的相同应用程序之间的性能差异。

Singleton（单例模式）、仓储模式（repository）、工厂模式（factory）、建造者模式（builder）、装饰模式（decorator）……大概每个上课听讲的程序员都不会陌生——软件的设计模式为我们提供了针对现有的、重复出现的问题以可靠的解决方案。

微服务架构并不是一种新的架构模式，但它的不断发展为那些寻求企业级私有云解决方案的公司，带来了诸多好处，将大型一体化架构应用拆分为可组合的微服务，赋予企业独立扩展和维护每个组件的能力以及DevOps能力。

如果我们想要构建一个生产就绪的系统，那么必须要权衡所有因素，其中选择微服务间的连接方法更是其中的一个难点。 作者在本文中介绍了一些常见的通信方法，并简要概述了其项目背景以及为何最终选择了RPC。 在决定微服务间连接方法前，我们需要搞清楚两个概念： 架构风格（Architectural Style） 传输协议（Transport Pro...

在应用层，我们有一个用Windows form和WPF编写的桌面客户端。应用与服务层对话，而服务层是完全用c#编写的SOA体系结构。这是我们（当时）唯一可以使用的语言。它们是通过WCF相互通信的单片有状态服务。我们使用SQL server作为后端存储。所有这些都在内部部署，这意味着我们的客户购买我们的软件并将其托管在自己的硬件上。

Rainbond是一款以应用为中心的开源PaaS，由好雨基于Docker、Kubernetes等容器技术自主研发，可作为企业在公有云或私有云环境下的应用交付平台、DevOps平台、自动化运维平台和行业云平台，或作为企业级的混合云多云管理工具、Kubernetes容器管理工具或Service Mesh微服务架构治理工具。

以典型的3层传统web应用为例，该应用由用户界面、数据库、服务器端应用组成。这里的服务器端应用被称为monolith（一体化），包含表现、业务层、数据层。所有代码都存在于同一个代码库中。为了让代码工作起来，它被部署成为一个单元。任何一个小的改动变化，都需要重新构建和部署整个应用。

许多公司都成功地将Kubernetes等工具用于部署，但仍面临着运行时的复杂性问题。而Service Mesh便是解决这些挑战的良方。它极大地简化了容器化应用的管理，使监视和保护基于微服务的应用变得更加容易。

在过去几个月里，Service Mesh是行业内毋庸置疑的焦点。关于Service Mesh、关于软件架构未来的文章观点，围绕着不同的技术供应商而高度分化，不过有一点共通的事，对于如何在企业中使用API的快速转换，以及这对于我们流量的拓扑意味着什么。

当下，已经有很大一部分公司完成了单体架构向微服务架构的迁移改造，并在疲于应对大量微服务间通信问题时，开始考虑采用Service Mesh微服务架构作为服务与服务直接通信的透明化管理框架，以插件式的方式实现各种业务所需的高级管理功能。

IDG报告表明，企业对云计算的投资力度在2018年有增无减，希望通过不断的云计算技术革新推动业务发展。在被调查的550家企业中，有超过73%的企业拥有至少一个“云”应用或一部分“云”基础架构，这表明，企业已经不在讨论是否要采用云的问题，而是把目光放在了如何利用云上。

谈到Service Mesh微服务架构，就不得不谈Sidecar模式——一种单节点、多容器的应用设计形式。Sidecar主张以额外的容器来扩展或增强主容器，而这个额外的容器被称为Sidecar容器。