从技术实现的维度解读开源 PaaS Rainbond 如何支持 ServiceMesh 微服务架构
当我们谈论微服务架构时，我们在谈论什么？
服务发现和注册、弹性伸缩与负载均衡、容错处理（断路器与限流）、监控与报警、数据存储与共享、日志分析……
除了以上自然联想到的技术点，还有如 Spring Cloud、Dubbo 这样在过去几年受到广泛关注和应用的微服务架构框架，以及最近数个月内在国内外技术圈异军突起的 Service Mesh。
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
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.