开源 PaaS Rainbond v3.6.0：提供 service mesh 微服务架构开箱即用

Service Mesh 自 2018 年以来，受到了前所未有的关注，这种微服务架构允许我们在开发应用时，只关注业务代码，而不需要关心技术底层逻辑，被认为是企业扩展、保护和监控微服务的最佳方式。

好雨同样对 Sevice Mesh 微服务架构寄予厚望。经过过去三年对微服务架构不断的思考和实践，我们在开源 PaaS Rainbond v3.6.0 中，正式释出了对 Service Mesh 微服务架构开箱即用的支持，其主要特点如下——

• 业务代码无侵入
  • 以透明代理的形式提供服务间通信，不会与业务代码耦合
• 跨语言 & 跨协议
  • 不限制服务开发语言，使用 HTTP、gPRC 等轻量级通信协议
• 支持主流微服务架构
  • spring cloud 、 api gateway 、 dubbo
• 通过插件式扩展来实现治理功能
  • 服务发现和注册、弹性伸缩与负载均衡、容错处理（断路器与限流）、监控与报警、数据存储与共享、日志分析等

Rainbond Service Mesh 的实现

Rainbond 利用容器的 sidecar 模式，抽象出应用插件层，根据不同的插件类型提供不同的控制策略，例如可根据应用容器的启动顺序、运行环境等，并在全局应用运行时提供标准的服务发现接口、配置发现接口，相当于 Rainbond 通过插件的方式提供了 envoy 的运行环境。

ServiceMesh 功能在 Rainbond 中通过服务网络治理插件来实现，在“我的插件”中安装该插件，并在需要使用的应用中启用该插件，即在该应用上启用了 Service Mesh，示例如下：

- 安装服务网络治理插件

- 在应用中启用插件

- 配置插件

Rainbond 如何通过插件式扩展来实现治理功能

服务发现和注册

服务注册是任何一个 SOA/ 服务化 / 微服务框架必不可少的关键部分，与之密切相关的是一些强一致性分布式存储：Zookeeper、Etcd、Consul，其中 Consul 和 Etcd 基于 Raft 协议实现，Zookeeper 基于 PAXOS 协议实现。

几乎所有的服务注册和发现都需要基于以上强一致性分布式存储实现，例如 SpringCloud 的两个重要的子项目 Spring_Cloud_Consul/Spring_Cloud_Zookeeper。

对于 Rainbond 来说，通过应用 / 服务统一管理实现了所有部署应用 / 服务的自动注册。其原理在于 Rainbond 内部基于 Kubernetes 实现应用调度，注册于 Kubernetes 集群中的应用 / 服务信息，实际也是注册到了 Etcd 之中。应用实例每次重启，Rianbond 都会为其分配不同的 IP 地址，服务注册信息将动态地改变。

我们知道，应用与应用直接通信之前必须首先发现对方，在这方面，Rainbond 采用了声明式的发现机制，即当 A 服务需要与 B 服务通信，那么首先需要在 A 服务声明依赖 B 服务，而 Rainbond 应用运行时模块会基于用户声明发现对方服务地址，注入到 A 服务内部, 赋予 A 服务一个本地访问地址（127.0.0.1）访问 B 服务。

平台服务间的依赖关系

弹性伸缩与负载均衡

说到服务发现和注册，弹性伸缩与负载均衡也就不得不谈。

上文中 A 服务连接 B 服务，B 服务可以是有状态的数据库服务，例如 Mysql、MongoDB 等，也可以是无状态的 restfulAPI 服务。

对于可以水平伸缩的应用（无状态应用或者分布式有状态应用），服务发现注入多个端点地址，必然需要负载均衡，因此 A 服务内部需要支持 4 层网络代理或者 7 层网络代理，通过应用运行时模块发现的后端地址注入到代理插件内部。

Rainbond 默认的代理插件支持 4 层负载均衡，借助 Service Mesh 便于扩展得特性，我们可以再针对各种应用层协议匹配不同的网络治理插件，实现 7 层负载均衡，例如 HTTP、gRPC、Redis 等协议。

为什么需要 7 层负载均衡这样的高级功能？原因在于对于一些在线环境，我们希望可以对服务间调用实现热更改或者更好的容错，比方说 A/B 测试、灰度发布等等，必须要在 7 层负载均衡上完成。

Rainbond 目前提供“基于 envoy 的 7 层网络治理插件”（envoy 本身可以与安生运行于 Rainbond 插件体系之中），用户也可以选择和实现其他插件，Rainbond 运行时将提供完善的基础服务。

配置 7 层高级负载均衡的方式

容错处理（断路器与限流）

能够容忍其中某些服务异常情况的微服务架构，才称得上是健壮的生产级微服务架构。

比方说某购物网站，订单页面会推荐其他相关商品，在大流量异常情况下，为了保证订单功能可用，将推荐功能（计算耗时，性能不好）限制可用，需要优雅的服务降级，将有限的资源用于关键服务的同时，保证整个系统稳定。

这里有两种方案：限流，将某个服务设置其最大的请求量或者连接数，硬性保护下游服务；断路器，当下游服务错误率到达一个阀值，将上游请求快速失败返回，保护上游服务稳定，同时又不给下游服务增加压力，做到快速失败、快速返回。

以上功能的实现对于业务系统来说相对复杂，而在上文提到的 Rainbond 高级负载均衡支持下，仅需为每个调用线路配置简单的限流参数或者熔断参数，即可实现断路器和限流机制开箱即用。

监控与报警

传统运维关注监控物理资源，例如内存、CPU、负载等指标数据。Rainbond 在监控和警报方面，重点没有放在这些侧面体现运行状况的方式，除了基础的资源监控之外，Rainbond 核心选择了能够直接体现服务运行情况的吞吐率和响应时间作为关键指标，如吞吐率异常降低，响应时间增大证明当前服务压力过大，就表示需要扩容了。

Rainbond 的业务级监控分析如下图：

对于不同的服务协议，Rainbond 使用不同的指标实时表现吞吐率、响应时间，例如 HTTP 协议，使用 Path 的请求量和相应时间表达，Mysql 协议使用 SQL 执行量和响应时间表达。

后续 Rainbond 将支持除上述两种协议之外的更多的应用协议，包括 gRPC、Redis、postgreSQL 等。用户可以自动或手动在这些指标之上配置规则或自动学习规则，实现提供业务报警和自动伸缩。

数据存储与共享

分布式是微服务架构中不可缺少的部分，在运行多种不同类型应用、需求不同存储，并且不同数据中心和不同基础设施提供不同存储类型的情况下，实现和处理起来并不容易。

Rainbond 的实现方式是将存储和应用进行解耦和，插件式支持不同的存储类型，例如基于 NFS 的分布式文件存储、块设备存储、内存虚拟存储等，

当然不同的存储具有不同的属性，Rainbond 分布式无状态应用最常用的是共享文件存储，为每个应用分配的存储区域将挂载到所有实例之上，实时同步数据。用户可以自定义需要挂载的路径，应用到哪里，数据就跟到哪里。

日志分析

微服务架构中服务产生的日志处理也是一个难点，日志需要统一收集，同一个应用的多个实例产生的日志需要汇聚，然后需要分析和报警。

服务的日志一般会分为两部分：系统日志和访问日志，Rainbond 推荐将两类日志区别处理。

对于系统日志，其主要作用是调试系统、记录异常，Rainbond 提供基于应用级别的应用日志汇聚和实时展示，因此只需要将系统日志输出到标准输出 (stdout)，系统将自动收集和汇聚，以应用的维度存储。

对于访问日志，我们一般需要对其进行分析和监控，日志分析常用的方案是 ELK 系统，Rainbond 建议的方式是将访问日志输出到指定文件，并安装 Elasticsearch 插件，以便将收集文件日志发送到指定 Elasticsearch 服务端（平台一键部署 ELK 完整服务）。如果使用其他分析系统，同样使用插件的形式将应用日志输送到指定服务端即可。

关于 Rainbond

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

• Rainbond 项目网站
• 试用 Rainbond 公有云
• Github
• 码云
• 文档
• 微信群: 添加微信“zqg5258423”并接受邀请入群