从技术实现的维度解读开源PaaS Rainbond如何支持ServiceMesh微服务架构
当我们谈论微服务架构时，我们在谈论什么？
服务发现和注册、弹性伸缩与负载均衡、容错处理（断路器与限流）、监控与报警、数据存储与共享、日志分析……
除了以上自然联想到的技术点，还有如Spring Cloud、Dubbo这样在过去几年受到广泛关注和应用的微服务架构框架，以及最近数个月内在国内外技术圈异军突起的Service Mesh。
什么是ServiceMesh
Service Mesh是一种非入侵、透明化的微服务治理框架。作为服务与服务直接通信的透明化管理框架，Service Mesh不限制服务开发语言、使用轻量级的通信协议（HTTP、gRPC等），并插件式的提供各类功能，如服务发现、负载均衡、智能路由、流量管控、性能分析等等，换而言之，用户通过Service Mesh得以用简单的方式获取高级的功能。
Rainbond原生支持Service Mesh，接下来我们将从服务发现和注册、弹性伸缩与负载均衡、容错处理（断路器与限流）、监控与报警、数据存储与共享、日志分析等方面进行解读。
服务发现和注册
服务注册是任何一个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在Service Mesh微服务架构方面，核心的原则在于开放，通过各类优秀解决方案标准化的接入，来为用户提供开箱即用、强大简单的微服务体验。
进一步了解开源PaaS Rainbond
- 网站: https://www.rainbond.com
- 试用Rainbond公有云: https://www.goodrain.com
- Github: https://github.com/goodrain/rainbond
- 码云: https://gitee.com/rainbond/Rainbond
- 微信群: 添加微信“zqg5258423”并接受邀请入群