Rainbond

本篇文章主要讲解Rainbond如何获取私有源代码仓库进行源码构建。 原理解读 通过自定义源码的方式创建应用 当你填写Git地址时，平台会自动判断地址的协议，如果是HTTP的Git地址，平台会提示你输入Git仓库的用户名和密码，如果是公开项目，用户名密码可以省略。当输入的Git地址是SSH协议时，平台会提示你将Rainbond的SSH公钥复制到Git仓库中。Rainbond会为每个团队生成独立的公钥以避免多团队密钥冲突。 当你填写Svn代码地址时，平台提示输入账号名和密码，如果是私有仓库，请务必输入账号。 操作流程 本文主要讲解通过 SSH 公钥的方式对接私有部署的Git仓库，以 GitLab 为示例进行说明。 Gitlab创建新项目 如果你已有项目，此步骤跳过 新建项目 填写项目名称 创建示例代码 切换到SSH地址后，需要记住项目的SSH地址，后续创建应用时需要用到，这里的地址是 git@172.16.210.205:test/helloworld.git 新建一个index.html 的文件，内容为 hello world,hello goodrain! 提交。 配置SSH公钥对接私有仓库 获取公钥 进入【创建应用】-【从源码创建】-【自定义源码】，将项目的SSh协议的地址复制到【Git仓库地址】栏中时，会提示【配置授权Key】连接，点开显示详细信息： 将公钥添加到Git仓库

近日，好雨科技与龙芯中科共同进行了好雨科技旗下云帮（Rainbond）PaaS平台与龙芯中科最新龙芯3B3000芯片的测试认证。 测试结果表明：在最新龙芯3B3000芯片上（具备向下兼容），云帮PaaS的通用兼容性、运行稳定性、功能可靠性等方面均达到生产要求，能够满足军工、政务等用户的关键性需要。 好雨科技作为云计算时代的PaaS服务商，立足于“数字化业务驱动企业价值增长”，打造“以应用为中心”的PaaS平台，管理企业数字化业务的“开发、架构、交付、运维”应用全生命周期。 龙芯中科定位于面向国家信息化建设的需求，面向国际信息技术前沿，以创新发展为主题，以产业发展为主线，以体系建设为目标，坚持自主创新，掌握计算机软硬件的核心技术，为信息产业及工业信息化的创新发展提供高性能、低成本、低功耗的处理器。 此次互认证为好雨科技及龙芯中科提供更大的合作空间，有助于双方共同拓展军工、政务等领域，推进云计算融合创新能力，提供安全可靠的云环境，构建稳定健康的云生态。 来源： oschina 链接： https://my.oschina.net/u/584116/blog/3076292

SAMIR BEHARA 本文将解释Service Mesh相关概念，为什么云原生应用需要它，以及这项技术被社区热烈拥抱、积极采用的原因。 毫不夸张地说，微服务已经席卷了整个软件行业。从Monolith过渡到微服务架构，可以让我们频繁、独立而可靠地部署应用。 然而，在微服务架构中，一切都不是绿色的，它必须处理在设计分布式系统时遇到的相同问题。 然而，微服务架构不是万能的，在设计分布式系统时会遇到很多有待解决的问题。说到这里，我们不妨首先回顾一下关于分布式计算的8大谬误—— 网络是可靠的（The Network is Reliable） 延迟为零（Latency is Zero） 带宽是无限的（Bandwidth is Infinite） 网络是安全的（The Network is Secure） 拓扑不会改变（Topology does not Change） 有一名管理员（There is one Administrator） 传输成本为零（Transport Cost is Zero） 网络是同质的（The Network is Homogenous） 在微服务体系结构中，对于网络的依赖带来了可靠性问题。随着服务数量的增加，我们必须处理它们之间的交互，监视整个系统的健康状况，处理容错、日志记录，处理多个故障点等等。每个微服务都需要有这些共同的功能，以便服务通信是平滑和可靠的

Lori Macvittie 微服务架构是把双刃剑，我们享受它带来的开发速度（development velocity），却也不得不面对服务间通讯带来的复杂性问题。 目前大多数扩展容器化微服务的架构多是基于proxy-based复杂均衡器实现的。在这些架构的问题在于，容器环境内部伸缩往往依赖于IP tables，并受制于传统网络层。 所有这些代理提供相同的核心功能：扩展容器环境中的分布式服务。这些服务是一种短暂的构建（ephemeral constructs），实际上并不存在——除了在定义它们的资源（配置）文件中。基于IP tables的扩展解决方案的问题是，这些服务是7层(HTTP)构造，通常充当单个API调用的“后端”，而非整个应用程序。 正如我们所知道的，从客户端显示为单个、整体构造的应用，实际上由许多不同的(和分布式的)微服务组成。有些服务是纯内部的，供其他服务使用，这意味着要在容器环境中进行大量的service-to-service通信。 在这些环境中，一切都是HTTP/HTTP2之上的api，因此我们需要L7(HTTP)路由。我们还需要一致的安全、身份验证和策略执行。所有这些都是基于IP tables的方法无法实现的。 针对种种微服务架构服务间通讯的问题和难点，目前出现的一些Service Mesh相关开源项目已经开始着手解决这些挑战，核心集中于以下8个方面： 构建 -

George Miranda 业务对于Service Mesh微服务架构的讨论热度居高不下，很多人认为Service Mesh将是云原生应用基础设施解决方案的MUST，它在构建健壮微服务架构应用时的能量令人印象深刻。不过在人气飙升的同时，人们对于落地Service Mesh的确切价值仍有困惑，因此有必要深入了解什么是Service Mesh以及它解决了哪些问题，以便我们确定是否真的需要Service Mesh。 Service Mesh Service Mesh是一个用于处理服务之间通信的基础结构层，其体系结构的具体细节在不同实现中略有差异。一般来说，每个Service Mesh都是作为一个系列(或“mesh”)实现的，这些相互连接的网络代理设计允许我们更优雅地管理服务流量（service traffic）。 该解决方案随着微服务架构的广泛接受而兴起，它引入了一种全新的通信流量（communication traffic）概念。但不幸的是，采用者往往没有做太多的考虑。这有时被归因为南北流量模式与东西流量模式的区别。简单来说，南北流量是server-to-client流量，而东西流量则是server-to-server流量。以上命名来源于“映射”网络流量的关系图，图中通常用垂直线表示server-client流量，水平线表示server-to-server流量。在Server-to

文章来源 Senraの小窝 ，Rainbond团队感谢支持！ 一.介绍 和之前介绍的Crane不同，来自好雨云(GoodRain)的云帮( CloudHelp 目前已改名RainBond)是基于K8S的，说实话，感觉比Crane的开源态度更好点，看得出来是认真在弄的。Crane我发的issue至今无人回复，感觉应该是凉了 关于云帮的定位，可以参考下官方的FAQS Q: 云帮开源版的定位是什么？ A: 中小企业CI/CD平台，生产环境的应用管理平台。云帮不是拉近开发和运维的距离，而是让开发和运维做他们本来应该做的事情。开发对程序和业务负责，运维对资源负责，云帮作为开发和运维的助手。 Q: 发布开源版的目的是什么？ A: 希望能有更多的企业和个人爱好者享受到容器及云计算技术所带来的高效与便利。通过社区版让广大的用户了解云帮产品的设计理念。 Q: 开源版发展规划 A: 云帮是个平台级的产品，即使是开源版我们首要关注的是稳定性，产品设计会本着 功能简洁够用 的原则，降低使用门槛，让用户以最简单的方式来体验容器技术带来的红利。 Q: 云帮企业版是否有生产环境运行的案例？开源版是不是只是演示和测试的“玩具”？ A: 说到这个问题，我想需要明确一下大家判断一项技术或产品在“生产环境” 运行的标准是什么。只有对这个标准或定义明确了，讨论这个问题才有意义。咱们从稳定性、可维护性、扩展性

Maven 多模块项目构建识别策略 Maven 多模块项目是根据 pom.xml 文件(下面简称 pom)来划分的, Rainbond 对它的识别也是建立在 pom 的基础上的. 主要是识别出具体模块(module)的构建命令和启动命令. 构建命令的作用是指定需要构建的模块, 是类似于 "mvn install -pl 'module name' -am" 的 mvn 命令. 启动命令的作用是在构建完成后, 指定需要执行的 Jar 包, 是类似于 "web: java $JAVA_OPTS -jar *.jar" 的命令. 识别策略: 根据根 pom 中的 modules 中的 module 标签, 找到相应模块下的 pom. 如果 pom 中的 packing 标签的值是 jar(war), 则解析出当前 pom 对应的模块名和 jar(war)包名. packing 标签的值为空, 会认为是 jar. 模块名由名级父 pom 中的 module 标签的值组成, 用 "/" 分割, 类似于: rbd-worker/rbd-thirdparty. jar(war) 包名默认是 ${artifaceId}-*.jar(war). 如果设置了 finalName 标签, 则会使用 finalName 标签的值; 如果finalName 标签使用了变量${project.name}或$

Mysql主从同步原理 1）在Slave 服务器上执行sart slave命令开启主从复制开关，开始进行主从复制。 2）此时，Slave服务器的IO线程会通过在master上已经授权的复制用户权限请求连接master服务器，并请求从执行binlog日志文件的指定位置（日志文件名和位置就是在配置主从复制服务时执行change master命令指定的）之后开始发送binlog日志内容。 3）Master服务器接收到来自Slave服务器的IO线程的请求后，其上负责复制的IO线程会根据Slave服务器的IO线程请求的信息分批读取指定binlog日志文件指定位置之后的binlog日志信息，然后返回给Slave端的IO线程。返回的信息中除了binlog日志内容外，还有在Master服务器端记录的IO线程。返回的信息中除了binlog中的下一个指定更新位置。 4）当Slave服务器的IO线程获取到Master服务器上IO线程发送的日志内容、日志文件及位置点后，会将binlog日志内容依次写到Slave端自身的Relay Log（即中继日志）文件（Mysql-relay-bin.xxx）的最末端，并将新的binlog文件名和位置记录到master-info文件中