Rainbond

Sidecar设计模式正在收到越来越多的关注和采用。作为Service Mesh的重要要素，Sidecar模式对于构建高度高度可伸缩、有弹性、安全且可便于监控的微服务架构系统至关重要。而Service Mesh也已经被证明，正在改变企业IT的“游戏规则”，它降低了与微服务架构相关的复杂性，并提供了负载平衡、服务发现、流量管理、电路中断、遥测、故障注入等功能特性。 什么是Sidecar模式？ Sidecar模式是一种将应用功能从应用本身剥离出来作为单独进程的方式。该模式允许我们向应用无侵入添加多种功能，避免了为满足第三方组件需求而向应用添加额外的配置代码。 就像边车加装在摩托车上一样，在软件架构中，sidecar附加到主应用，或者叫父应用上，以扩展/增强功能特性，同时Sidecar与主应用是松耦合的。 举个例子，假设现在有6个相互通信的微服务，每个微服务都需要具有可观察性、监控、日志记录、配置、断路器等功能，而所有这些功能都是在微服务中使用一些第三方库实现的。 这样一组服务的实际情况可能会非常复杂，增加了应用的整体复杂性，尤其是当每个微服务用不同的语言编写、使用不同的基于.net、Java、Python等语言的第三方库…… Sidecar模式的好处 通过将公用基础设施相关功能抽象到不同的层来降低微服务的代码复杂性 由于我们不需要在每个微服务中编写配置代码

Kubernetes Autoscaling是如何工作的？这是最近我们经常被问到的一个问题。 所以本文将从Kubernetes Autoscaling功能的工作原理以及缩放集群时可以提供的优势等方面进行解释。 什么是Autoscaling 想象用水龙头向2个水桶里装水，我们要确保水在装满第一个水桶的80%时，开始注入第二个水桶。解决方法很简单，只要在适当的位置在两个水桶间装置管道连接即可。而当我们想要扩大装水量，我们只需要用这种办法增加水桶即可。 同样的道理放在我们的应用或者服务上，云计算的弹性伸缩功能可以让我们从手动调节物理服务器/虚拟机之中解放出来。那么把“水桶装水”和“应用消耗计算资源”相比较—— 水桶 - 缩放单位 - 解释我们缩放什么的问题 80%标记 - 缩放的度量和触发器 - 解释我们什么时候缩放的问题 管道 - 实现缩放的操作 - 解释我们怎样进行缩放的问题 我们缩放什么？ 在Kubernetes集群环境中，作为用户我们一般会缩放两个东西： Pods - 对于某个应用，假设我们运行X个副本（replica），当请求超过X个Pods的处理量，我们就需要扩展应用。而为了使这一过程无缝工作，我们的Nodes应该由足够的可用资源，以便成功调度并执行这些额外的Pads； Nodes - 所有Nodes的总容量代表我们的集群容量。如果工作负载需求超过该容量

Kubernetes自从 1.6 起便号称可以承载5000个以上的节点，但是从数十到5000的路上，难免会遇到问题。 本片文章即分享Open API在kubernetes 5000之路上的经验，包括遇到的问题、尝试解决问题以及找到真正的问题。 遇到的问题以及如何解决 问题一：1 ~ 500个节点之后 问题： kubectl 有时会出现 timeout（p.s. kubectl -v=6 可以显示所有API细节指令） 尝试解决： 一开始以为是kube-apiserver服务器负载的问题，尝试增加proxy做replica协助进行负载均衡 但是超过10个备份master的时候，发现问题不是因为kube-apiserver无法承受负载，GKE通过一台32-core VM就可以承载500个节点 原因： 排除以上原因，开始排查master上剩下的几个服务(etcd、kube-proxy) 开始尝试调整etcd 通过使用 datadog 查看etcd吞吐量，发现有异常延迟(latency spiking ~100 ms) 通过 Fio 工具做性能评估，发现只用到10%的IOPS(Input/Output Per Second)，由于写入延迟(write latency 2ms)降低了性能 尝试把SSD从网络硬盘变为每台机器有个local temp drive（SSD） 结果从~100ms —>

概述 Minio是建立在云原生的基础上；有分布式和共享存储等功能；旨在多租户环境中以可持续的方式进行扩展的对象存储服务。它最适合存储非结构化数据，如：照片、视频、日志文件、容器/虚拟机/映像等，单次存储对象的大小最大可达5TB。 实现架构 单节点 根据存储是否为远端，可直接使用FS或NFS直接操作存储中的Object 调用S3接口，通过Minio使用FS或NFS来操作Object 多节点 多节点的Minio会根据不同的Access_key及Secret_Key来区分不同租户，每个租户可操作对应Server获取Object。Minio Server间可以通过不同的 进程模型 、容器或是虚拟机来互相隔离。 分布式 分布式Minio在无共享架构中根据需求扩展到尽可能多的服务器，所有节点需要使用相同的Access_key及Secret_key来登录。分布式Minio使用Web负载均衡器或DNS轮循(DNS round-robin)，在各服务器之间实现负载均衡。 功能特性 Amazon S3兼容 Minio使用Amazon S3 v2 / v4 API。可以使用Minio SDK，Minio Client，AWS SDK和AWS CLI访问Minio服务器。 数据保护 Minio使用 Minio Erasure Code 来防止硬件故障。也许会损坏一半以上的driver，但是仍然可以从中恢复

2020年的春节与往年不同，突如其来的新型冠状病毒肺炎自华中始，并向全国各地蔓延，冲淡了原有年味儿的喜庆热闹。从23号武汉封城，到多地纷纷效仿，最后到一级响应预警，全国各地都是严阵以待。面对严峻疫情防控形势，社会各界齐心协力抗击疫情，好雨科技也积极投入到抗击疫情的实际行动中。 咸阳市大数据管理局是咸阳市政府下属机构，负责咸阳全市信息化建设、大数据管理和信息网络运行维护等工作。2019年，咸阳大数据管理局以Rainbond为基座，建设咸阳市的智慧社会操作系统，智慧社会操作系统的主要任务是连接资源、连接应用、连接数据、连接用户，2019年底已经完成智慧社会操作系统的主体建设工作。 挑战 2月4日，由于复工返岗高峰的到来，大规模的人口流动重新启动，为遏制疫情蔓延扩散，做好外来返工人员的防控和服务工作，咸阳市大数据需要用最短的时候完成咸阳市疫情登记应用和相关管控应用的开发和上线，并在3天内完成整个咸阳市130万人信息上报和管控服务。 在这过程中面对两大个挑战： 咸阳大数据管理局的工作人员也在家办公，疫情防控应用必须在短时间开发完成，需要高效的远程协作，并支撑应用快速迭代上线和业务不间断升级。 应用要支撑130万人短时间访问要求，在某些时间点会有大量并发，需要快速完成性能优化，支撑大并发。 通过Rainbond实现远程协作、快速迭代开发和持续交付 疫情来的非常突然

下载安装 安装文档参考: https://v5.2-doc.rainbond.com/docs/quick-start/rainbond_install/ 版本变更 安装与运维 Rainbond系统安装和运维管理重构为Operator模式，运行于Kubernetes集群内部。 解除对Kubernetes的强依赖关系，Rainbond不再维护Kubernetes集群安装脚本，推荐使用 easzup Rainbond-Operator安装采用Helm包管理工具安装。 Rainbond系统安装提供UI界面，实时把控安装进度，后续版本UI提供系统运维、升级等功能。 安装提供多种参数可选配置，包括镜像仓库、数据库、ETCD集群等关键配置。 系统组件生命周期由Kubernetes和Rainbond-Operator共同维护和管理。 一句话，你有Kubernetes集群（1.13及以上）就可以试试Rainbond带来的不一样的体验。 应用存储 Rainbond 组件存储抽象支持存储类型支持通过Kubernetes StorageClass 扩展，通过增加集群中的StorageClass即可扩充Rainbond支持的存储类型，目前测试接入的存储类型包括阿里云盘、Ceph块设备等 组件存储模型增加容量、挂载状态属性。 应用分享安装、跨集群迁移等用例中基于简要算法选择合适的存储类型

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> API Gateway Kong在Rainbond上的部署 什么是Kong Kong是一个可扩展的开源API平台（也称为API网关，API中间件或微服务服务网格）。Kong最初是由 Kong Inc. （以前称为Mashape）实现的，用于为其API Marketplace维护、管理和扩展超过15,000个微服务，这些微服务每月产生数十亿个请求。 技术上讲，Kong是在Nginx中运行的Lua应用程序，并且通过 lua-nginx-module 实现。Kong是与 OpenResty 一起分发的，而不是使用此模块来编译Nginx， OpenResty 已经包括lua-nginx-module。 了解更多有关Kong的事情，你需要点击 了解一下 。 从应用市场安装 快速安装 目前我们已经将最新版本（v1.4.X）的Kong发布到了应用市场，如果你想要快速的搭建以及使用Kong，你只需要做一件事情，那就是点击一下安装： 等待一小段时间后，Kong就已经部署在了你的Rainbond集群中了。在这个应用中，我们已经集成了 Konga 作为UI管理工具，接下来的步骤，需要你访问Konga，做几步简单的设置，就可以愉快的探索Kong了。 注册Konga <img src="https://tva1.sinaimg.cn

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 值此春节假期即将来临之际，我们给社区带来了Rainbond v5.0.3 版本更新，提前恭祝大家新年快乐，Rainbond是开源的企业应用云操作系统，支撑企业应用的开发、架构、交付和运维的全流程，通过无侵入架构，无缝衔接各类企业应用，底层资源可以对接和管理IaaS、虚拟机和物理服务器。 Rainbond 5.0 版本带来了众多的功能和体验优化, 越来越多的企业用户测试和使用，同时也在社区反馈了较多的问题，Rainbond团队每周更新一个BUG修复版本修复用户反馈，使得Rainbond 5.0版本更加稳定。于此同时我们也带来了一些小功能，比如当前版本支持了基于Docker Hub Webhook的应用自动构建。 示例1：镜像创建服务并开启外网访问 示例2：Python源码创建服务 优化 优化扩容节点,使用节点id作为唯一标识; 安装调整默认应用实例的cidr,移除默认镜像加速源,添加默认calicoctl配置文件 #28; 优化调整安装前端口检测方式 #659; 优化控制台加入团队流程; 优化构建版本数据显示, 增加构建成功率的统计显示; 优化服务日志展示页面UI; 优化控制台团队资源配额限制, 增加集群资源不足提醒; 优化应用自动构建流程，调整到服务构建源设置; BUG修复 修复rbd-app-ui 持久化问题

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Rainbond在v3.7.0版本中释出了大量平台稳定性更新，并在应用管理功能、安全性和系统安装三方面进行了部分优化。 作为IT基础系统平台，Rainbond从 低耦合的架构设计 、 高可用的部署方式 、 自恢复与容错的设计 三方面评估和保障分布式系统可用性，以最终达到无人值守的效果。 在低耦合架构设计方面，Rainbond将分布式系统抽象为管理、计算、存储等三类节点，不同节点属性由不同服务组件构成，以解除服务间耦合关系，同时对于不同节点，可用性的最低要求也不尽相同 —— 管理节点 ：面向用户，提供应用构建、控制、调度、交付以及数据存储等系列管理功能，在异常情况下没有管理节点，已有应用依然能正常运行 计算节点 ：负责实际运行应用并为应用运行提供环境保障，在异常情况下可以容忍降级，将应用调度到其他计算节点运行 存储节点 ：用于存储应用持久化数据并提供数据访问服务，存储节点异常，无状态应用依然可以正常运行。 为了更好地保证高可用的部署，Rainbond本身所有模块和组件均支持高可用 —— 管理节点 ：支持等幂部署多个节点以保证高可用 计算节点 ：等幂部署多个计算节点以组建冗余资源池，从而容忍单节点资源限制或故障 存储节点 ：采用冗余部署的方式形成存储资源池，对计算节点提供稳定服务，任何存储节点故障，业务不会中断

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 本次 v3.7.0-rc1 版本，在上月发布3.6.1版本基础上，重点围绕系统生产稳定性展开，包括双重健康检查守护（Systemd进程级加Rainbond-Node业务级）、Prometheus监控指标暴露支持、管理节点上线下线支持等多项新增特性和优化。 除此之外，本次更新还对应用管理功能、安全性和系统安装三方面进行了部分优化，更新详情如下： 稳定性增强 所有平台服务使用Systemd进程级守护加Rainbond-Node业务级健康检查守护 所有平台服务支持健康检查和Prometheus的监控指标暴露 管理节点支持上线和下线以隔离由于节点故障导致的平台不可用 计算节点健康检查异常时支持自动隔离和恢复 支持配置自定义报警规则用于对节点物理监控、服务监控的报警 租户使用资源（内存、磁盘）的统计由单个节点完成（Rainbond-Worker Master节点故障时自动切换） 支持通过命令行工具便捷查询数据中心健康状态、所有节点健康状态 应用管理功能 支持 .NetCore(2.1)语言一键构建应用，运行于Linux系统 支持对接SVN代码仓库持续构建应用 增加自动构建的入口，支持通过自定义API、Gitee-Webhook、Gogs-Webhook触发自动构建,更好的于第三方CI系统集成。 支持应用