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

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

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

• 业务代码无侵入
  •  以透明代理的形式提供服务间通信，不会与业务代码耦合
• 跨语言&跨协议
  • 不限制服务开发语言，使用HTTP、gPRC等轻量级通信协议
• 支持主流微服务架构
  • ospring 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
• 码云
• 文档

转自 http://www.infoq.com/cn/news/2018/07/PaaS-Srvice-Rainbond