技术解读Rainbond Service Mesh微服务架构_开源PaaS Rainbond

当我们谈论微服务架构时,我们在谈论什么?

服务发现和注册、弹性伸缩与负载均衡、容错处理(断路器与限流)、监控与报警、数据存储与共享、日志分析……

除了以上自然联想到的技术点,还有如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

原文发布于微信公众号 - 好雨云(goodrain-cloud)

原文发表时间:2018-05-15

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏逸鹏说道

浅谈web网站架构演变过程

前言   我们以javaweb为例,来搭建一个简单的电商系统,看看这个系统可以如何一步步演变。   该系统具备的功能: 用户模块:用户注册和管理 商品模块:商品...

1.9K610
来自专栏云计算

微服务的模式 - 同步与异步

微服务是一种架构范例。在这种架构中,多个小型独立组件协同工作,从而构成一个系统。尽管它的操作复杂性较高,但这种范式已经被迅速采用。这是因为它有助于...

1.5K40
来自专栏CSDN技术头条

携程开源Redis多数据中心解决方案XPipe

Redis在携程内部得到了广泛的使用,根据客户端数据统计,整个携程全部Redis的读写请求在每秒200W,其中写请求约每秒10W,很多业务甚至会将Redis当成...

47490
来自专栏匠心独运的博客

过来人的经验,谈谈一致性处理方案—分布式事务(DTS)

传统事务是使用数据库自身的事务属性(ACID),而数据库自身的事务属性是局限于当前实例,不能实现跨库。而对于大型分布式/微服务集群系统中,不仅存在着跨库的事务,...

45340
来自专栏Android 开发者

Android 开发者 | 应用兼容性注意事项

29240
来自专栏battcn

为什么要前后端分离?有什么优缺点?

前后端分离已成为互联网项目开发的业界标准使用方式,通过nginx+tomcat的方式(也可以中间加一个nodejs)有效的进行解耦,并且前后端分离会为以后的大型...

47120
来自专栏BestSDK

一提交代码系统就崩溃? 给你8个避免此尴尬的技巧

当一群人作为一个整体同时进行一个程序的编写时,每个个体都会面临两方面的权衡: ●个人部分的实现——你需要保证你负责的代码部分可以正常运行; ● 整体部分的实现—...

37970
来自专栏aCloudDeveloper

vhost:一种 virtio 高性能的后端驱动实现

什么是 vhost vhost 是 virtio 的一种后端实现方案,在 virtio 简介中,我们已经提到 virtio 是一种半虚拟化的实现方案,需要虚拟机...

1K60
来自专栏jerryteng的专栏

如何利用最低配的腾讯云快速搭建高并发在线服务

这里是作为开发用,我们就选择一个普通的服务器,我也是很不好意思的申请了相关的学生机,那我们就用学生机来搭建一个高并发的在线服务。这个机器配置很低,我还进行了降级...

1.1K100
来自专栏ytkah

测试了小程序的内嵌网页总结几点

  11月2日深夜微信团队宣布小程序内嵌页面开放了,很多开发者已经测试了小程序的内嵌网页,他们总结了以下几点: 1、内嵌网页的域名需要在小程序管理后台设置为业务...

35050

扫码关注云+社区

领取腾讯云代金券