k8s 1.8下安装 istio 0.8 手动注入Envoy容器有问题

Istioszihai 回复了问题 • 2 人关注 • 1 个回复 • 149 次浏览 • 2 天前 • 来自相关话题

我们真的需要Service Mesh吗?

ServiceMeshgoodrain 发表了文章 • 0 个评论 • 199 次浏览 • 4 天前 • 来自相关话题

[George Miranda](https://www.oreilly.com/ideas/ ... e-mesh)

业务对于Service Mesh微服务架构的讨论热度居高不下,很多人认为Service Mesh将是云原生应用基础设施解决方案的MUST,它在构建健壮微服务架构应用时的能量令人印象深刻。不过在人气飙升的同时,人们对于落地Service Mesh的确切价值仍有困惑,因此有必要深入了解什么是Service Mesh以及它解决了哪些问题,以便我们确定是否真的需要Service Mesh。

## Service Mesh

Service Mesh是一个用于处理服务之间通信的基础结构层,其体系结构的具体细节在不同实现中略有差异。一般来说,每个Service Mesh都是作为一个系列(或“mesh”)实现的,这些相互连接的网络代理设计允许我们更优雅地管理服务流量(service traffic)。

该解决方案随着微服务架构的广泛接受而兴起,它引入了一种全新的通信流量(communication traffic)概念。但不幸的是,采用者往往没有做太多的考虑。这有时被归因为南北流量模式与东西流量模式的区别。简单来说,南北流量是server-to-client流量,而东西流量则是server-to-server流量。以上命名来源于“映射”网络流量的关系图,图中通常用垂直线表示server-client流量,水平线表示server-to-server流量。在Server-to-server流量世界里,除了对网络和传输层(L3/L4)考量,在会话层(session layer)中还有一个重要的差异要考虑。

在这个新的世界中,service-to-service通信成为了应用在应用时行为的基本决定因素。应用函数在本地作为相同运行时的一部分出现,而不是以在不可靠的网络上传输的远程过程调用出现。这意味着,反映业务需求的复杂决策树(decision tree)的成功或失败,现在需要您考虑分布式系统编程的现实。对于大多数人来说,这是一个新的专业领域,需要创建并在代码中编写大量定制的工具。而Service Mesh,减轻了应用开发人员的负担,将工具与应用分离开来,并将这种“责任”推到了基础架构层。

使用Service Mesh,每个应用的endpoint(无论是容器、pod还是主机,无论如何在部署中设置这些endpoint)都被配置为“将通信路由到本地代理”(例如以sidecar容器形式安装)。本地代理公开了可以用于管理诸如重试逻辑、加密机制、自定义路由规则、服务发现等内容的原语。这些代理的集合构成了一个“网格”服务,共享公共网络流量的管理属性。这些代理可以从一个集中的控制平面进行控制,操作人员可以在该控制平面中对影响整个网格行为的策略加以组合。

由于service-to-service的通信是基于微服务的应用运行时行为的基本决定因素,能够从Sercice Mesh中获取价值的最明显的地方是管理用于远程过程调用(或API调用)的消息。对比Service Mesh和其他消息管理解决方案,如面向消息的中间件、企业服务总线(ESB)、企业应用程序集成模式(EAI)或API网关,Service Mesh可能与其中的一些功能有轻微重叠,但是作为一个整体,它面对的是一个更大的问题集。

Service Mesh是作为基础设施实现的,位于应用之外,因此应用不需要修改任何代码就可以使用Service Mesh。Service Mesh的价值起初是在检查rpc(或消息)管理时实现的,随后扩展到了所有入站和出站流量的管理。与直接将远程通信管理编码到应用中不同,Service Mesh允许您更容易地跨整个分布式基础设施管理该逻辑。

## The problem space

Service Mesh的核心是解决管理分布式系统带来的固有挑战。这并不是一格新的问题,但在微服务数量激增的情况下,越来越多用户开始面对这些问题。而关于分布式系统,存在着一下谬误——

网络是可靠的(The Network is Reliable)
延迟为零(Latency is Zero)
带宽是无限的(Bandwidth is Infinite)
网络是安全的(The Network is Secure)
拓扑不会改变(Topology does not Change)
有一名管理员(There is one Administrator)
传输成本为零(Transport Cost is Zero)
网络是同质的(The Network is Homogenous)

了解更多:[Service Mesh微服务架构的崛起](https://www.goodrain.com/2018/07/06/tech-20180706/)

这些错误往往会在大规模运行时出现,往往在发现时已经太晚了,不过好在,经过这么多年的实践,已经有了不少经过验证的解决方案。

过去,应用开发人员通过在应用中直接创建自定义工具来解决这些问题:打开一个socket、传输数据、在某个特定的时间段内重新尝试,当事务不可避免地需要终止时关闭socket,等等。分布式应用的编程负担直接落在了每个开发人员的肩上,因此这样做的逻辑与每个分布式应用紧密耦合。

作为实现可重用解决方案的渐进步骤,出现了网络弹性库(如Netflix的Hystrix或Twitter的Finagle)。在我们的应用代码中包含这些库,现在您已经准备好了一组预先开发的工具。虽然这些解决方案取得了令人难以置信的飞跃,但它们对多语言应用的价值有限。不同的编程语言需要不同的库,然后我们会遇到管理两者之间集成的挑战。在这一模型中,不同应用endpoint之间的一致管理是一个固有的挑战。

对于Service Mesh,它旨在解决分布式系统编程的挑战,这意味着我们需要首先搞明白一个问题:我们应用基础结构中,是否有许多服务彼此通信?

当然,如果我们主要管理的是一体化架构应用,我们也可以从Service Mesh中获得些许价值。

如果我们管理的是较小的服务,那么处理分布式计算错误的工作不可避免。随着微服务架构应用的发展,新特性通常作为附加的外部服务引入,我们对于Service Mesh的需求也将不断增长。

Service Mesh的存在解决了可靠性(重试、超时、减轻级联故障)、故障诊断(可观察性、监视、跟踪、诊断)、性能(吞吐量、延迟、负载平衡)、安全性(管理机密、确保加密)、动态拓扑(服务发现、自定义路由)以及在生产中管理微服务时常见的问题。

如果我们目前正在面临这些问题,或者已经次啊用了云原生和微服务架构,那么我们应该研究一下Service Mesh工具,并确定它是否适用于我们的环境。想要避免被各种炒作迷乱了双眼,我们应该量化Service Mesh的价值,而办法就像我们刚才讨论的那样,关注这类工具的存在并探索它是否可以解决特定的问题。

- END - 

## 关于Rainbond

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

* [Rainbond项目网站](https://www.rainbond.com)
* [试用Rainbond公有云](https://www.goodrain.com)
    * 注册或使用Demo账号/密码登录:rainbond-demo/rainbond-demo
* [Github](https://github.com/goodrain/rainbond)
* [码云](https://gitee.com/rainbond/Rainbond)
* [文档](https://www.goodrain.com/docs/stable/)
* 微信群: 添加微信“zqg5258423”并接受邀请入群

**阅读更多**

* `技术` [Service Mesh真的是云原生应用的绝配吗?](https://www.goodrain.com/2018/07/10/tech-20180710/)
* `技术` [Service Mesh微服务架构的崛起](https://www.goodrain.com/2018/07/06/tech-20180706/) `2018/0706`
* `技术` [Service Mesh:什么是Sidecar模式](https://www.goodrain.com/2018/06/21/tech-20180621/) `2018/06/21`
* `技术` [开源PaaS Rainbond v3.6.0正式发布,Service Mesh开箱即用](https://www.goodrain.com/2018/ ... 80620/) `2018/06/20`
* `技术` [解读Rainbond ServiceMesh微服务架构_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80515/) `2018/05/15`
* `技术` [Pinpoint-java性能分析最佳实践_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80508/) `2018/05/08`
* `技术` [通过Minio搭建私有化对象存储服务_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80426/) `2018/04/26`
* `技术` [揭秘高可用负载均衡组件Rainbond-Entrance_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80425/) `2018/04/25`
* `技术` [Rainbond插件体系设计简介_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80224/) `2018/02/24`
* `技术` [Rainbond如何对接外部Maven仓库_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80118/) `2018/01/18`
* `技术` [Spring Boot框架配置MySQL_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80110/) `2018/01/10`
* `技术` [基于Midonet的多租户网络设计_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80109/) `2018/01/09` 查看全部
[George Miranda](https://www.oreilly.com/ideas/ ... e-mesh)

业务对于Service Mesh微服务架构的讨论热度居高不下,很多人认为Service Mesh将是云原生应用基础设施解决方案的MUST,它在构建健壮微服务架构应用时的能量令人印象深刻。不过在人气飙升的同时,人们对于落地Service Mesh的确切价值仍有困惑,因此有必要深入了解什么是Service Mesh以及它解决了哪些问题,以便我们确定是否真的需要Service Mesh。

## Service Mesh

Service Mesh是一个用于处理服务之间通信的基础结构层,其体系结构的具体细节在不同实现中略有差异。一般来说,每个Service Mesh都是作为一个系列(或“mesh”)实现的,这些相互连接的网络代理设计允许我们更优雅地管理服务流量(service traffic)。

该解决方案随着微服务架构的广泛接受而兴起,它引入了一种全新的通信流量(communication traffic)概念。但不幸的是,采用者往往没有做太多的考虑。这有时被归因为南北流量模式与东西流量模式的区别。简单来说,南北流量是server-to-client流量,而东西流量则是server-to-server流量。以上命名来源于“映射”网络流量的关系图,图中通常用垂直线表示server-client流量,水平线表示server-to-server流量。在Server-to-server流量世界里,除了对网络和传输层(L3/L4)考量,在会话层(session layer)中还有一个重要的差异要考虑。

在这个新的世界中,service-to-service通信成为了应用在应用时行为的基本决定因素。应用函数在本地作为相同运行时的一部分出现,而不是以在不可靠的网络上传输的远程过程调用出现。这意味着,反映业务需求的复杂决策树(decision tree)的成功或失败,现在需要您考虑分布式系统编程的现实。对于大多数人来说,这是一个新的专业领域,需要创建并在代码中编写大量定制的工具。而Service Mesh,减轻了应用开发人员的负担,将工具与应用分离开来,并将这种“责任”推到了基础架构层。

使用Service Mesh,每个应用的endpoint(无论是容器、pod还是主机,无论如何在部署中设置这些endpoint)都被配置为“将通信路由到本地代理”(例如以sidecar容器形式安装)。本地代理公开了可以用于管理诸如重试逻辑、加密机制、自定义路由规则、服务发现等内容的原语。这些代理的集合构成了一个“网格”服务,共享公共网络流量的管理属性。这些代理可以从一个集中的控制平面进行控制,操作人员可以在该控制平面中对影响整个网格行为的策略加以组合。

由于service-to-service的通信是基于微服务的应用运行时行为的基本决定因素,能够从Sercice Mesh中获取价值的最明显的地方是管理用于远程过程调用(或API调用)的消息。对比Service Mesh和其他消息管理解决方案,如面向消息的中间件、企业服务总线(ESB)、企业应用程序集成模式(EAI)或API网关,Service Mesh可能与其中的一些功能有轻微重叠,但是作为一个整体,它面对的是一个更大的问题集。

Service Mesh是作为基础设施实现的,位于应用之外,因此应用不需要修改任何代码就可以使用Service Mesh。Service Mesh的价值起初是在检查rpc(或消息)管理时实现的,随后扩展到了所有入站和出站流量的管理。与直接将远程通信管理编码到应用中不同,Service Mesh允许您更容易地跨整个分布式基础设施管理该逻辑。

## The problem space

Service Mesh的核心是解决管理分布式系统带来的固有挑战。这并不是一格新的问题,但在微服务数量激增的情况下,越来越多用户开始面对这些问题。而关于分布式系统,存在着一下谬误——

网络是可靠的(The Network is Reliable)
延迟为零(Latency is Zero)
带宽是无限的(Bandwidth is Infinite)
网络是安全的(The Network is Secure)
拓扑不会改变(Topology does not Change)
有一名管理员(There is one Administrator)
传输成本为零(Transport Cost is Zero)
网络是同质的(The Network is Homogenous)

了解更多:[Service Mesh微服务架构的崛起](https://www.goodrain.com/2018/07/06/tech-20180706/)

这些错误往往会在大规模运行时出现,往往在发现时已经太晚了,不过好在,经过这么多年的实践,已经有了不少经过验证的解决方案。

过去,应用开发人员通过在应用中直接创建自定义工具来解决这些问题:打开一个socket、传输数据、在某个特定的时间段内重新尝试,当事务不可避免地需要终止时关闭socket,等等。分布式应用的编程负担直接落在了每个开发人员的肩上,因此这样做的逻辑与每个分布式应用紧密耦合。

作为实现可重用解决方案的渐进步骤,出现了网络弹性库(如Netflix的Hystrix或Twitter的Finagle)。在我们的应用代码中包含这些库,现在您已经准备好了一组预先开发的工具。虽然这些解决方案取得了令人难以置信的飞跃,但它们对多语言应用的价值有限。不同的编程语言需要不同的库,然后我们会遇到管理两者之间集成的挑战。在这一模型中,不同应用endpoint之间的一致管理是一个固有的挑战。

对于Service Mesh,它旨在解决分布式系统编程的挑战,这意味着我们需要首先搞明白一个问题:我们应用基础结构中,是否有许多服务彼此通信?

当然,如果我们主要管理的是一体化架构应用,我们也可以从Service Mesh中获得些许价值。

如果我们管理的是较小的服务,那么处理分布式计算错误的工作不可避免。随着微服务架构应用的发展,新特性通常作为附加的外部服务引入,我们对于Service Mesh的需求也将不断增长。

Service Mesh的存在解决了可靠性(重试、超时、减轻级联故障)、故障诊断(可观察性、监视、跟踪、诊断)、性能(吞吐量、延迟、负载平衡)、安全性(管理机密、确保加密)、动态拓扑(服务发现、自定义路由)以及在生产中管理微服务时常见的问题。

如果我们目前正在面临这些问题,或者已经次啊用了云原生和微服务架构,那么我们应该研究一下Service Mesh工具,并确定它是否适用于我们的环境。想要避免被各种炒作迷乱了双眼,我们应该量化Service Mesh的价值,而办法就像我们刚才讨论的那样,关注这类工具的存在并探索它是否可以解决特定的问题。

- END - 

## 关于Rainbond

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

* [Rainbond项目网站](https://www.rainbond.com)
* [试用Rainbond公有云](https://www.goodrain.com)
    * 注册或使用Demo账号/密码登录:rainbond-demo/rainbond-demo
* [Github](https://github.com/goodrain/rainbond)
* [码云](https://gitee.com/rainbond/Rainbond)
* [文档](https://www.goodrain.com/docs/stable/)
* 微信群: 添加微信“zqg5258423”并接受邀请入群

**阅读更多**

* `技术` [Service Mesh真的是云原生应用的绝配吗?](https://www.goodrain.com/2018/07/10/tech-20180710/)
* `技术` [Service Mesh微服务架构的崛起](https://www.goodrain.com/2018/07/06/tech-20180706/) `2018/0706`
* `技术` [Service Mesh:什么是Sidecar模式](https://www.goodrain.com/2018/06/21/tech-20180621/) `2018/06/21`
* `技术` [开源PaaS Rainbond v3.6.0正式发布,Service Mesh开箱即用](https://www.goodrain.com/2018/ ... 80620/) `2018/06/20`
* `技术` [解读Rainbond ServiceMesh微服务架构_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80515/) `2018/05/15`
* `技术` [Pinpoint-java性能分析最佳实践_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80508/) `2018/05/08`
* `技术` [通过Minio搭建私有化对象存储服务_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80426/) `2018/04/26`
* `技术` [揭秘高可用负载均衡组件Rainbond-Entrance_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80425/) `2018/04/25`
* `技术` [Rainbond插件体系设计简介_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80224/) `2018/02/24`
* `技术` [Rainbond如何对接外部Maven仓库_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80118/) `2018/01/18`
* `技术` [Spring Boot框架配置MySQL_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80110/) `2018/01/10`
* `技术` [基于Midonet的多租户网络设计_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80109/) `2018/01/09`

Service Mesh真的是云原生应用的绝配吗

ServiceMeshgoodrain 发表了文章 • 0 个评论 • 269 次浏览 • 2018-07-10 14:11 • 来自相关话题

[Richard Li](https://www.infoq.com/articles ... -peril)

随着越来越多企业开始落地微服务架构,Service Mesh和相关的解决方案在社区内的讨论热度开始逐渐上涨。Service Mesh所提倡的“全栈可观察性”、透明安全性、系统弹性等特性令人着迷,但它真的是云原生应用的绝配吗?本文将对Service Mesh何时make sense、何时不那么make sense作出一些思考。

## 做好微服务架构可以让我们更敏捷

当下来看,产品和服务的“time to market”决定了企业的竞争力,能够对市场和客户需求快速反应的公司想不成功都难。微服务架构为软件敏捷性和整个工作流的“速度”提供了强有力的支持,通过授权不同团队分别处理应用的不同部分,决策是“去中心化”的。

“去中心化”的决策带来了两个关键结果。首先,软件团队可以在架构、发布、测试等方面作出“本地化”的最优决策,不需要依赖全局标准。举个例子,每个团队都有自己的发布工具,而不是单一的标准化应用发布。第二,团队可以更快进行决策,传统模式下韵味、架构等等集中功能之上的阻碍减少了。

## 微服务架构不是“免费”的——带来了新的失败模式

采用微服务对您的组织、流程和体系结构具有深远的影响。微服务架构本身是一个分布式系统,在基于微服务架构的应用中,业务逻辑分布在通过网络相互通信的多个服务之间,而分布式系统有更多的故障模式(failure mode)。

考虑到这些失败模式,有一个体系结构和过程来防止小的失败变成大的失败是非常重要的。当我们很“快”的时候,失败是不可避免的,例如服务更新时引入了错误,服务在负载下崩溃等等。

随着应用变得越来越复杂,对于失败管理的需求也越来越迫切。当应用由少量微服务组城市,故障还比较容易隔离和排除,但想象数十个、上百个微服务,以及分布在各地的团队,我们的失败管理体系需要与应用一起“伸缩”。

## 管理失败

我们一般会采取三种失败管理策略:主动测试(proactive testing)、缓解(mitigation)、快速想用(rapid response)。

* 主动测试:利用流程和系统来测试应用或服务,以便尽早发现故障。QA通常包含在这一方法中,虽然传统测试团队专注于预发布测试,但现在经常扩展到生产测试。
* 缓解:实施特定策略以便在特定故障发生时减少影响和损失。例如,取保服务多个实例间的负载均衡,当单个实例失败,整个服务仍然可以相应
* 快速反应:通过流程和系统快速识别和处理特定故障

## Service mesh

当服务失败时,会对其上游和下游服务产生影响。通过正确管理服务之间的通信,可以极大地减轻失败服务的影响。这就是Service Mesh的用武之地。

Service Mesh管理服务级别(例如7层代理)通信,提供了强大的原语,可用于所有三种失败管理策略:

* 动态路由,可用于不同的发布和测试策略,如金丝雀路由、流量阴影或蓝绿部署
* 弹性,通过诸如断路和速率限制等策略来减轻故障的影响
* 可观察性,通过收集度量标准,为服务间通信添加context(例如跟踪数据)来提高响应时间

Service Mesh以一种对应用开发人员非常透明的方式添加这些特性。

## Service Mesh可以帮助我们更快构建应用吗?

决定Service Mesh对于我们的企业是否有益,首先要思考两个关键问题:

* 服务拓扑结构有多复杂?
* 如何将Service Mesh集成到软件开发生命周期中?

### 服务拓扑

如果只是单个微服务,Service Mesh的好处是有限的。增量版本也可以通过现有的基础设施(如Kubernetes或API网关)来完成。

然而随着服务拓扑结构越来越复杂,Service Mesh将发挥巨大威力。需要考虑的关键约束是服务调用链的深度。如果您有一个浅层的拓扑结构,您的monolith直接调用了十几种微服务,那么Service Mesh的好处仍然是有限的。当您引入更多的服务到服务的通信时,服务A调用服务B调用服务C,Service Mesh就变得十分重要了。

### 将您的服务网格集成到您的SDLC中

Service Mesh对于服务是同名的,它是一个丰富的7层网络,微服务不需要任何的代码修改。

然而部署Service Mesh并不会自动加速应用的速率和敏捷性。我们需要将Service Mesh集成到开发过程中。

## 将实现故障管理策略作为SDLC的一部分

Service Mesh为故障管理提供了强大的原语,接下来我们将讨论各个失败管理策略以及如何应用到SDLC中。

### 主动测试

微服务应用的测试策略应该尽可能贴近真实情况。考虑到多服务应用的复杂性,当前的测试策略强调在生产中进行测试(或使用生产数据)。

Service Mesh通过控制L7传输到服务的流量来在生产环境中进行测试。例如,服务网格可以将1%的流量路由到服务的v1.1版本, 99%的流量路由到v1.0(金丝雀部署)。这些功能通过声明式路由规则(例如linkerd dtab或Istio路由规则)公开。

Service Mesh不是主动测试的唯一方法。其他补充策略包括使用容器调度器(如Kubernetes)进行滚动更新、可以进行金丝雀部署的API网关或chaos engineering。

有了所有这些策略,谁管理测试工作流的问题就变得很明显了。在Service Mesh中,路由规则可以由管理网格的同一团队集中管理。

### 缓解

由于各种原因,服务可能会失败:代码错误、资源不足、硬件故障。限制失败服务的爆炸半径对于整个应用程序继续运行(尽管处于降级状态)非常重要。

Service Mesh通过负载平衡、断路器和服务到服务通信的速率限制等弹性模式来减轻故障的影响。例如在重载下的服务可以限制速率,以便仍然处理某些响应,而不会导致整个服务在负载下崩溃。

减轻失败的其他策略包括使用智能RPC库(例如Hystrix)或依赖容器调度程序。像Kubernetes这样的容器调度器支持健康检查、自动扩展和对不响应健康检查的服务的动态路由。

当为给定的服务适当地配置这些缓解策略时,它们是最有效的。例如,不同的服务可以处理不同数量的请求,需要不同的速率限制。如何制定利率限制等政策?Netflix已经实现了一些自动配置算法来设置这些值。其他方法是将这些功能公开给服务作者,他们可以正确配置服务。

### 可观察性

失败是不可避免的。实现可观察性——跨越监控、警报/可视化、分布式跟踪和日志记录——对于将响应时间最小化到给定的故障是非常重要的。

Service Mesh自动收集关于服务到服务通信的详细指标,包括吞吐量、延迟和可用性的数据。此外,服务网格可以注入必要的headers来支持分布式跟踪。注意,这些headers仍然需要由服务本身传播。

收集类似度量的其他方法包括使用监视代理、通过statsd收集度量以及通过库实现跟踪(例如,Jaeger工具库)。

可观察性的一个重要组成部分是向服务作者公开警报和可视化。收集度量只是第一步,考虑您的服务作者如何创建适合于给定服务的警报和可视化对于关闭可观察性循环非常重要。

------

开源PaaS Rainbond在v3.6.0版本中加入了Service Mesh开箱即用的特性,主要特点包括业务代码无入侵、跨语言&跨协议、支持主流微服务架构、通过插件式扩展来实现治理功能等。

* [开源PaaS Rainbond v3.6.0正式发布,Service Mesh开箱即用](https://www.goodrain.com/2018/ ... 80620/)
* [解读Rainbond ServiceMesh微服务架构](https://blog.goodrain.com/2018 ... 80515/)
* [Rainbond插件体系设计简介](https://blog.goodrain.com/2018 ... 80224/) 查看全部
[Richard Li](https://www.infoq.com/articles ... -peril)

随着越来越多企业开始落地微服务架构,Service Mesh和相关的解决方案在社区内的讨论热度开始逐渐上涨。Service Mesh所提倡的“全栈可观察性”、透明安全性、系统弹性等特性令人着迷,但它真的是云原生应用的绝配吗?本文将对Service Mesh何时make sense、何时不那么make sense作出一些思考。

## 做好微服务架构可以让我们更敏捷

当下来看,产品和服务的“time to market”决定了企业的竞争力,能够对市场和客户需求快速反应的公司想不成功都难。微服务架构为软件敏捷性和整个工作流的“速度”提供了强有力的支持,通过授权不同团队分别处理应用的不同部分,决策是“去中心化”的。

“去中心化”的决策带来了两个关键结果。首先,软件团队可以在架构、发布、测试等方面作出“本地化”的最优决策,不需要依赖全局标准。举个例子,每个团队都有自己的发布工具,而不是单一的标准化应用发布。第二,团队可以更快进行决策,传统模式下韵味、架构等等集中功能之上的阻碍减少了。

## 微服务架构不是“免费”的——带来了新的失败模式

采用微服务对您的组织、流程和体系结构具有深远的影响。微服务架构本身是一个分布式系统,在基于微服务架构的应用中,业务逻辑分布在通过网络相互通信的多个服务之间,而分布式系统有更多的故障模式(failure mode)。

考虑到这些失败模式,有一个体系结构和过程来防止小的失败变成大的失败是非常重要的。当我们很“快”的时候,失败是不可避免的,例如服务更新时引入了错误,服务在负载下崩溃等等。

随着应用变得越来越复杂,对于失败管理的需求也越来越迫切。当应用由少量微服务组城市,故障还比较容易隔离和排除,但想象数十个、上百个微服务,以及分布在各地的团队,我们的失败管理体系需要与应用一起“伸缩”。

## 管理失败

我们一般会采取三种失败管理策略:主动测试(proactive testing)、缓解(mitigation)、快速想用(rapid response)。

* 主动测试:利用流程和系统来测试应用或服务,以便尽早发现故障。QA通常包含在这一方法中,虽然传统测试团队专注于预发布测试,但现在经常扩展到生产测试。
* 缓解:实施特定策略以便在特定故障发生时减少影响和损失。例如,取保服务多个实例间的负载均衡,当单个实例失败,整个服务仍然可以相应
* 快速反应:通过流程和系统快速识别和处理特定故障

## Service mesh

当服务失败时,会对其上游和下游服务产生影响。通过正确管理服务之间的通信,可以极大地减轻失败服务的影响。这就是Service Mesh的用武之地。

Service Mesh管理服务级别(例如7层代理)通信,提供了强大的原语,可用于所有三种失败管理策略:

* 动态路由,可用于不同的发布和测试策略,如金丝雀路由、流量阴影或蓝绿部署
* 弹性,通过诸如断路和速率限制等策略来减轻故障的影响
* 可观察性,通过收集度量标准,为服务间通信添加context(例如跟踪数据)来提高响应时间

Service Mesh以一种对应用开发人员非常透明的方式添加这些特性。

## Service Mesh可以帮助我们更快构建应用吗?

决定Service Mesh对于我们的企业是否有益,首先要思考两个关键问题:

* 服务拓扑结构有多复杂?
* 如何将Service Mesh集成到软件开发生命周期中?

### 服务拓扑

如果只是单个微服务,Service Mesh的好处是有限的。增量版本也可以通过现有的基础设施(如Kubernetes或API网关)来完成。

然而随着服务拓扑结构越来越复杂,Service Mesh将发挥巨大威力。需要考虑的关键约束是服务调用链的深度。如果您有一个浅层的拓扑结构,您的monolith直接调用了十几种微服务,那么Service Mesh的好处仍然是有限的。当您引入更多的服务到服务的通信时,服务A调用服务B调用服务C,Service Mesh就变得十分重要了。

### 将您的服务网格集成到您的SDLC中

Service Mesh对于服务是同名的,它是一个丰富的7层网络,微服务不需要任何的代码修改。

然而部署Service Mesh并不会自动加速应用的速率和敏捷性。我们需要将Service Mesh集成到开发过程中。

## 将实现故障管理策略作为SDLC的一部分

Service Mesh为故障管理提供了强大的原语,接下来我们将讨论各个失败管理策略以及如何应用到SDLC中。

### 主动测试

微服务应用的测试策略应该尽可能贴近真实情况。考虑到多服务应用的复杂性,当前的测试策略强调在生产中进行测试(或使用生产数据)。

Service Mesh通过控制L7传输到服务的流量来在生产环境中进行测试。例如,服务网格可以将1%的流量路由到服务的v1.1版本, 99%的流量路由到v1.0(金丝雀部署)。这些功能通过声明式路由规则(例如linkerd dtab或Istio路由规则)公开。

Service Mesh不是主动测试的唯一方法。其他补充策略包括使用容器调度器(如Kubernetes)进行滚动更新、可以进行金丝雀部署的API网关或chaos engineering。

有了所有这些策略,谁管理测试工作流的问题就变得很明显了。在Service Mesh中,路由规则可以由管理网格的同一团队集中管理。

### 缓解

由于各种原因,服务可能会失败:代码错误、资源不足、硬件故障。限制失败服务的爆炸半径对于整个应用程序继续运行(尽管处于降级状态)非常重要。

Service Mesh通过负载平衡、断路器和服务到服务通信的速率限制等弹性模式来减轻故障的影响。例如在重载下的服务可以限制速率,以便仍然处理某些响应,而不会导致整个服务在负载下崩溃。

减轻失败的其他策略包括使用智能RPC库(例如Hystrix)或依赖容器调度程序。像Kubernetes这样的容器调度器支持健康检查、自动扩展和对不响应健康检查的服务的动态路由。

当为给定的服务适当地配置这些缓解策略时,它们是最有效的。例如,不同的服务可以处理不同数量的请求,需要不同的速率限制。如何制定利率限制等政策?Netflix已经实现了一些自动配置算法来设置这些值。其他方法是将这些功能公开给服务作者,他们可以正确配置服务。

### 可观察性

失败是不可避免的。实现可观察性——跨越监控、警报/可视化、分布式跟踪和日志记录——对于将响应时间最小化到给定的故障是非常重要的。

Service Mesh自动收集关于服务到服务通信的详细指标,包括吞吐量、延迟和可用性的数据。此外,服务网格可以注入必要的headers来支持分布式跟踪。注意,这些headers仍然需要由服务本身传播。

收集类似度量的其他方法包括使用监视代理、通过statsd收集度量以及通过库实现跟踪(例如,Jaeger工具库)。

可观察性的一个重要组成部分是向服务作者公开警报和可视化。收集度量只是第一步,考虑您的服务作者如何创建适合于给定服务的警报和可视化对于关闭可观察性循环非常重要。

------

开源PaaS Rainbond在v3.6.0版本中加入了Service Mesh开箱即用的特性,主要特点包括业务代码无入侵、跨语言&跨协议、支持主流微服务架构、通过插件式扩展来实现治理功能等。

* [开源PaaS Rainbond v3.6.0正式发布,Service Mesh开箱即用](https://www.goodrain.com/2018/ ... 80620/)
* [解读Rainbond ServiceMesh微服务架构](https://blog.goodrain.com/2018 ... 80515/)
* [Rainbond插件体系设计简介](https://blog.goodrain.com/2018 ... 80224/)

Service Mesh微服务架构的崛起

ServiceMeshgoodrain 发表了文章 • 0 个评论 • 726 次浏览 • 2018-07-06 10:32 • 来自相关话题

[SAMIR BEHARA](https://dotnetvibes.com/2018/0 ... cture/)

本文将解释Service Mesh相关概念,为什么云原生应用需要它,以及这项技术被社区热烈拥抱、积极采用的原因。

毫不夸张地说,微服务已经席卷了整个软件行业。从Monolith过渡到微服务架构,可以让我们频繁、独立而可靠地部署应用。

然而,在微服务架构中,一切都不是绿色的,它必须处理在设计分布式系统时遇到的相同问题。

然而,微服务架构不是万能的,在设计分布式系统时会遇到很多有待解决的问题。说到这里,我们不妨首先回顾一下关于分布式计算的8大谬误——

* 网络是可靠的(The Network is Reliable)
* 延迟为零(Latency is Zero)
* 带宽是无限的(Bandwidth is Infinite)
* 网络是安全的(The Network is Secure)
* 拓扑不会改变(Topology does not Change)
* 有一名管理员(There is one Administrator)
* 传输成本为零(Transport Cost is Zero)
* 网络是同质的(The Network is Homogenous)

在微服务体系结构中,对于网络的依赖带来了可靠性问题。随着服务数量的增加,我们必须处理它们之间的交互,监视整个系统的健康状况,处理容错、日志记录,处理多个故障点等等。每个微服务都需要有这些共同的功能,以便服务通信是平滑和可靠的。但是,如果你要处理几十上百个微服务,操作难度光是听起来就有些吓人。

## 什么是服务网格?

Service Mesh可以定义为在微服务体系结构中处理服务间通信的基础结构层,它减少了与微服务体系结构相关的复杂性,并提供了许多治理功能,如 -

* 负载均衡(Load Balancing)
* 服务发现(Service Discovery)
* 健康检查(Health Check)
* 身份验证(Authentication)
* 流量管理和路由(Traffic Management & Routing)
* 断路和故障转移(Circuit Breaking and Failover Policy)
* 安全(Security)
* 监控(Metrics & Telemetry)
* 故障注入(Fault Injection)

## 为什么需要Service Mesh?

在微服务架构中,处理服务到服务的通信是企业IT的一大挑战。大多数时候,我们需要依赖第三方库或者组件来提供服务发现、负载均衡、断路器、监控等功能。像Netflix这样的公司,他们开发了自己的库,比如Hystrix for Circuit Breaker、Eureka for Service Discovery、Ribbon for Load balanced等,在其组织中得到了广泛的使用。

然而,这些组件需要在应用代码中进行配置,而且语言不同,实现方式策略也会有所不同。在升级这些外部组件时,我们需要更新应用、验证并部署所有改动。如此便产生了一个问题,我们的应用代码编程了业务和这些附加配置混合体。这种紧密耦合增加了整个应用的复杂性——开发人员现在还需要了解这些组件是如何配置的,以便在遇到任何问题时能够排除故障。

> Service Mesh适时出现,将复杂性从应用中分离了出来,并将其放入服务代理(service proxy)代为处理。这些服务代理提供了如流量控制、断路、服务发现、身份验证、监控、安全性等等功能特性。那么对于应用来说,只需要关心业务功能的实现即可。

假设在我们的微服务体系结构中,您有5个服务相互通信。与其在每个微服务中构建配置、路由、遥测、日志记录、断路等常见的必要功能,不如将其抽象为一个单独的组件——这里称为“服务代理”(service proxy)。

随着Service Mesh的引入,责任的划分变得清晰,开发人员的生活也更加轻松——如果存在问题,开发人员可以根据应用程序或网络相关的原因,轻松地确定根源。

## Service Mesh是如何实现的?

要实现Service Mesh,可以将代理与服务一起部署,该模式被称为sidecar。

Sidecars抽象了应用程序的复杂性,处理了诸如服务发现、流量管理、负载平衡、线路中断等功能。

Lyft的**Envoy**是目前非常流行的云原生应用开源代理。特使在每个服务旁运行,并以平台无关的方式提供必要的特性。所有到我们的服务的流量都通过特使代理。

而Istio是一个连接、管理和保护微服务的开放平台。它在Kubernetes社区非常流行,并被广泛采用。

> 在这一点上,Istio是服务网格的最佳实现之一,它使我们能够在不深入了解底层基础设施的情况下部署微服务。

开源PaaS Rainbond在v3.6.0版本中加入了Service Mesh开箱即用的特性,主要特点包括业务代码无入侵、跨语言&跨协议、支持主流微服务架构、通过插件式扩展来实现治理功能等。

* [开源PaaS Rainbond v3.6.0正式发布,Service Mesh开箱即用](https://www.goodrain.com/2018/ ... 80620/)
* [解读Rainbond ServiceMesh微服务架构](https://blog.goodrain.com/2018 ... 80515/)
* [Rainbond插件体系设计简介](https://blog.goodrain.com/2018 ... 80224/)

-----

## 关于Rainbond

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

* [Rainbond项目网站](https://www.rainbond.com)
* [试用Rainbond公有云](https://www.goodrain.com)
    * 注册或使用Demo账号/密码登录:rainbond-demo/rainbond-demo
* [Github](https://github.com/goodrain/rainbond)
* [码云](https://gitee.com/rainbond/Rainbond)
* [文档](https://www.goodrain.com/docs/stable/)
* 微信群: 添加微信“zqg5258423”并接受邀请入群 查看全部
[SAMIR BEHARA](https://dotnetvibes.com/2018/0 ... cture/)

本文将解释Service Mesh相关概念,为什么云原生应用需要它,以及这项技术被社区热烈拥抱、积极采用的原因。

毫不夸张地说,微服务已经席卷了整个软件行业。从Monolith过渡到微服务架构,可以让我们频繁、独立而可靠地部署应用。

然而,在微服务架构中,一切都不是绿色的,它必须处理在设计分布式系统时遇到的相同问题。

然而,微服务架构不是万能的,在设计分布式系统时会遇到很多有待解决的问题。说到这里,我们不妨首先回顾一下关于分布式计算的8大谬误——

* 网络是可靠的(The Network is Reliable)
* 延迟为零(Latency is Zero)
* 带宽是无限的(Bandwidth is Infinite)
* 网络是安全的(The Network is Secure)
* 拓扑不会改变(Topology does not Change)
* 有一名管理员(There is one Administrator)
* 传输成本为零(Transport Cost is Zero)
* 网络是同质的(The Network is Homogenous)

在微服务体系结构中,对于网络的依赖带来了可靠性问题。随着服务数量的增加,我们必须处理它们之间的交互,监视整个系统的健康状况,处理容错、日志记录,处理多个故障点等等。每个微服务都需要有这些共同的功能,以便服务通信是平滑和可靠的。但是,如果你要处理几十上百个微服务,操作难度光是听起来就有些吓人。

## 什么是服务网格?

Service Mesh可以定义为在微服务体系结构中处理服务间通信的基础结构层,它减少了与微服务体系结构相关的复杂性,并提供了许多治理功能,如 -

* 负载均衡(Load Balancing)
* 服务发现(Service Discovery)
* 健康检查(Health Check)
* 身份验证(Authentication)
* 流量管理和路由(Traffic Management & Routing)
* 断路和故障转移(Circuit Breaking and Failover Policy)
* 安全(Security)
* 监控(Metrics & Telemetry)
* 故障注入(Fault Injection)

## 为什么需要Service Mesh?

在微服务架构中,处理服务到服务的通信是企业IT的一大挑战。大多数时候,我们需要依赖第三方库或者组件来提供服务发现、负载均衡、断路器、监控等功能。像Netflix这样的公司,他们开发了自己的库,比如Hystrix for Circuit Breaker、Eureka for Service Discovery、Ribbon for Load balanced等,在其组织中得到了广泛的使用。

然而,这些组件需要在应用代码中进行配置,而且语言不同,实现方式策略也会有所不同。在升级这些外部组件时,我们需要更新应用、验证并部署所有改动。如此便产生了一个问题,我们的应用代码编程了业务和这些附加配置混合体。这种紧密耦合增加了整个应用的复杂性——开发人员现在还需要了解这些组件是如何配置的,以便在遇到任何问题时能够排除故障。

> Service Mesh适时出现,将复杂性从应用中分离了出来,并将其放入服务代理(service proxy)代为处理。这些服务代理提供了如流量控制、断路、服务发现、身份验证、监控、安全性等等功能特性。那么对于应用来说,只需要关心业务功能的实现即可。

假设在我们的微服务体系结构中,您有5个服务相互通信。与其在每个微服务中构建配置、路由、遥测、日志记录、断路等常见的必要功能,不如将其抽象为一个单独的组件——这里称为“服务代理”(service proxy)。

随着Service Mesh的引入,责任的划分变得清晰,开发人员的生活也更加轻松——如果存在问题,开发人员可以根据应用程序或网络相关的原因,轻松地确定根源。

## Service Mesh是如何实现的?

要实现Service Mesh,可以将代理与服务一起部署,该模式被称为sidecar。

Sidecars抽象了应用程序的复杂性,处理了诸如服务发现、流量管理、负载平衡、线路中断等功能。

Lyft的**Envoy**是目前非常流行的云原生应用开源代理。特使在每个服务旁运行,并以平台无关的方式提供必要的特性。所有到我们的服务的流量都通过特使代理。

而Istio是一个连接、管理和保护微服务的开放平台。它在Kubernetes社区非常流行,并被广泛采用。

> 在这一点上,Istio是服务网格的最佳实现之一,它使我们能够在不深入了解底层基础设施的情况下部署微服务。

开源PaaS Rainbond在v3.6.0版本中加入了Service Mesh开箱即用的特性,主要特点包括业务代码无入侵、跨语言&跨协议、支持主流微服务架构、通过插件式扩展来实现治理功能等。

* [开源PaaS Rainbond v3.6.0正式发布,Service Mesh开箱即用](https://www.goodrain.com/2018/ ... 80620/)
* [解读Rainbond ServiceMesh微服务架构](https://blog.goodrain.com/2018 ... 80515/)
* [Rainbond插件体系设计简介](https://blog.goodrain.com/2018 ... 80224/)

-----

## 关于Rainbond

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

* [Rainbond项目网站](https://www.rainbond.com)
* [试用Rainbond公有云](https://www.goodrain.com)
    * 注册或使用Demo账号/密码登录:rainbond-demo/rainbond-demo
* [Github](https://github.com/goodrain/rainbond)
* [码云](https://gitee.com/rainbond/Rainbond)
* [文档](https://www.goodrain.com/docs/stable/)
* 微信群: 添加微信“zqg5258423”并接受邀请入群


Service Mesh简史

ServiceMeshgoodrain 发表了文章 • 0 个评论 • 1446 次浏览 • 2018-06-25 13:50 • 来自相关话题

[William Morgan](https://thenewstack.io/author/william-morgan/)

Service Mesh是一个相当新的概念,讲它的“历史”似乎有些勉强。就目前而言,Service Mesh已经在部分企业生产环境中运行了超过18个月,它的源头可以追溯到2010年前后互联网公司面对大规模业务的开发。

那么Service Mesh为什么会突然变成一个热门话题的?

Service Mesh是一个软件基础设施层,用于控制和监视微服务应用的内部、服务到服务的通信,通常的形式是部署在应用旁网络代理的“数据平面(data plane)”,或者是与浙西诶代理交互的“控制平面(control plane)”。在Service Mesh模式下,开发者对服务网格无感知,而运维人员获得了一套新工具,协助确保服务的可靠性、安全性和可见性。

它通常采用部署在应用程序代码旁边的网络代理的“数据平面”和用于与这些代理交互的“控制平面”的形式。在这个模型中,开发人员(“服务所有者”)不知道服务网格的存在,而操作员(“平台工程师”)获得了一套新的工具,以确保可靠性、安全性和可见性。

对于很多公司来说,Docker和Kubernetes已经“解决了部署”(至少一开始是这样的),但还没有解决运行时的问题,这正是Service Mesh的用武之地。

“解决了部署”是什么意思?使用Docker和Kubernetes等工具可以显著降低部署时的操作负担。有了这些工具,部署100个应用程序或服务的工作量不再是部署一个应用程序的100倍。这是向前迈出的一大步,对许多公司来说,这将显著降低采用微服务的成本。这不仅因为Docker和Kubernetes在所有合适的级别上提供了强大的抽象,而且因为它们标准化了整个组织的打包和部署模式。

但是一旦应用程序开始运行,又是怎样的情形?毕竟,部署不是生产的最后一步——这个应用程序仍然需要运行、需要交付、需要产生价值。因此,问题就变成了:我们是否可以用Docker和Kubernetes标准化部署时间操作(deploy-time ops)的相同方式来标准化应用程序的运行时操作?

要回答这个问题,不妨求教Service Mesh。Service Mesh的核心是提供统一的、全局的方法来控制和测量应用程序或服务之间的所有请求流量(用数据中心的话说,就是“east-west”流量)。对于采用了微服务的公司来说,这种请求流量在运行时行为中扮演着关键角色。因为服务通过响应传入请求和发出传出请求来工作,所以请求流成为应用程序在运行时行为的关键决定因素。因此,标准化流量管理成为标准化应用程序运行时的工具。

通过提供api来分析和操作此流量,Service Mesh为跨组织的运行时操作提供了标准化的机制——包括确保可靠性、安全性和可见性的方法。与任何好的基础架构层一样,Service Mesh采用的是独立于服务的构建方式。

## Service Mesh如何形成

那么,Service Mesh是从哪里来的呢?通过做一些“软件考古学”,我们发现服务网格提供的核心功能——诸如request-level的负载均衡、断路器、重试、检测——并不是基本的新特性。相反,Service Mesh是功能的重新打包——a shift in where,not what。

Service Mesh起源于2010年左右应用架构的三层模型——一种简单的体系结构,一度为web上的绝大多数应用提供“动力”。在这个模型中,应用流量首先由“web层”来处理,后者又会与“应用层”进行对话,之后又会与“数据库层”对话。web层中的web服务器被设计成能够非常快速地处理大量传入的请求,并将它们小心地交给相对较慢的应用服务器(Apache、NGINX和其他流行的web服务器都有非常复杂的逻辑来处理这种情况)。同样,应用层使用数据库库与back stores进行通信。这些库通常以一种针对这个用例进行优化的方式处理缓存、负载均衡、路由、流控制等。

So far so good,但是这个模型面对大规模业务时开始显露出疲态——尤其是在应用层,随着时间的推移它会变得非常大。早期的网络规模公司——谷歌、Facebook、Netflix、Twitter——学会了把这块巨石分解成许多独立运行的碎片,催生了微服务的兴起。在引入微服务的那一刻,east-west traffic随之引入。在这个世界上,通信不再是专门的,而是在每个服务之间。当它出错时,网站就会崩溃。

这些公司都以类似的方式进行应对——他们编写了“fat client”库来处理请求流量。这些库——谷歌的Stubby、Netflix的HYstrix、Twitter的Finagle——提供了跨所有服务的统一的运行时操作方式。开发者或服务所有者将使用这些库向其他服务发出请求,库将在后台执行负载均衡、路由、断路等等。通过为应用中的每个服务提供统一的行为、可见性和控制点,这些库表面上形成了第一个Service Mesh。

## 代理崛起

当我们回到当下以云为本的世界,这些库仍然存在。但是,由于进程外代理提供的操作便利,库的吸引力正在降低——尤其是在与容器和编排的出现所带来的部署复杂性显著降低的情况下。

代理绕过了库的许多缺点。例如,当一个库发生更改时,这些更改必须在每个服务中部署,这个过程通常需要复杂的组织协作。而代理,无需重新编译和重新部署,就可以升级应用。同样,代理允许使用多种语言系统,应用可以由不同的语言编写,当然这种方法对于库来说代价是非常大的。

也许对于大型组织来说,最重要的是,在代理服务器而不是库中实现——服务网格负责将运行时操作所需的功能提供给服务所有者,并被这些功能的最终用户掌握 - 平台团队。提供者和消费者的这种对齐,允许这些团队掌握自己的命运,并将dev和ops之间的复杂依赖关系分离。

以上这些因素共同促成了Service Mesh的兴起,也使运行时操作变得更为健全。通过部署一个分布式代理的“网”,可以作为底层基础设施的一部分维护,而不是维护应用本身,并通过提供集中的api来分析和操作流量,Service Mesh为整个组织运行时操作提供了一个标准的机制,同时确保可靠性、安全性和可见性。

- END -

开源PaaS [Rainbond](https://www.rainbond.com) v3.6.0现已发布,新增Service Mesh微服务架构开箱即用,通过插件式扩展来实现治理功能,并支持spring cloud、api gateway、dubbo等主流微服务架构。


**阅读更多**

* `技术` [Service Mesh:什么是Sidecar模式](https://www.goodrain.com/2018/06/21/tech-20180621/) `2018/06/21`
* `技术` [开源PaaS Rainbond v3.6.0正式发布,Service Mesh开箱即用](https://www.goodrain.com/2018/ ... 80620/) `2018/06/20`
* `技术` [解读Rainbond ServiceMesh微服务架构_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80515/) `2018/05/15`
* `技术` [Pinpoint-java性能分析最佳实践_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80508/) `2018/05/08`
* `技术` [通过Minio搭建私有化对象存储服务_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80426/) `2018/04/26`
* `技术` [揭秘高可用负载均衡组件Rainbond-Entrance_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80425/) `2018/04/25`
* `技术` [Rainbond插件体系设计简介_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80224/) `2018/02/24`
* `技术` [Rainbond如何对接外部Maven仓库_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80118/) `2018/01/18`
* `技术` [Spring Boot框架配置MySQL_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80110/) `2018/01/10`
* `技术` [基于Midonet的多租户网络设计_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80109/) `2018/01/09` 查看全部
[William Morgan](https://thenewstack.io/author/william-morgan/)

Service Mesh是一个相当新的概念,讲它的“历史”似乎有些勉强。就目前而言,Service Mesh已经在部分企业生产环境中运行了超过18个月,它的源头可以追溯到2010年前后互联网公司面对大规模业务的开发。

那么Service Mesh为什么会突然变成一个热门话题的?

Service Mesh是一个软件基础设施层,用于控制和监视微服务应用的内部、服务到服务的通信,通常的形式是部署在应用旁网络代理的“数据平面(data plane)”,或者是与浙西诶代理交互的“控制平面(control plane)”。在Service Mesh模式下,开发者对服务网格无感知,而运维人员获得了一套新工具,协助确保服务的可靠性、安全性和可见性。

它通常采用部署在应用程序代码旁边的网络代理的“数据平面”和用于与这些代理交互的“控制平面”的形式。在这个模型中,开发人员(“服务所有者”)不知道服务网格的存在,而操作员(“平台工程师”)获得了一套新的工具,以确保可靠性、安全性和可见性。

对于很多公司来说,Docker和Kubernetes已经“解决了部署”(至少一开始是这样的),但还没有解决运行时的问题,这正是Service Mesh的用武之地。

“解决了部署”是什么意思?使用Docker和Kubernetes等工具可以显著降低部署时的操作负担。有了这些工具,部署100个应用程序或服务的工作量不再是部署一个应用程序的100倍。这是向前迈出的一大步,对许多公司来说,这将显著降低采用微服务的成本。这不仅因为Docker和Kubernetes在所有合适的级别上提供了强大的抽象,而且因为它们标准化了整个组织的打包和部署模式。

但是一旦应用程序开始运行,又是怎样的情形?毕竟,部署不是生产的最后一步——这个应用程序仍然需要运行、需要交付、需要产生价值。因此,问题就变成了:我们是否可以用Docker和Kubernetes标准化部署时间操作(deploy-time ops)的相同方式来标准化应用程序的运行时操作?

要回答这个问题,不妨求教Service Mesh。Service Mesh的核心是提供统一的、全局的方法来控制和测量应用程序或服务之间的所有请求流量(用数据中心的话说,就是“east-west”流量)。对于采用了微服务的公司来说,这种请求流量在运行时行为中扮演着关键角色。因为服务通过响应传入请求和发出传出请求来工作,所以请求流成为应用程序在运行时行为的关键决定因素。因此,标准化流量管理成为标准化应用程序运行时的工具。

通过提供api来分析和操作此流量,Service Mesh为跨组织的运行时操作提供了标准化的机制——包括确保可靠性、安全性和可见性的方法。与任何好的基础架构层一样,Service Mesh采用的是独立于服务的构建方式。

## Service Mesh如何形成

那么,Service Mesh是从哪里来的呢?通过做一些“软件考古学”,我们发现服务网格提供的核心功能——诸如request-level的负载均衡、断路器、重试、检测——并不是基本的新特性。相反,Service Mesh是功能的重新打包——a shift in where,not what。

Service Mesh起源于2010年左右应用架构的三层模型——一种简单的体系结构,一度为web上的绝大多数应用提供“动力”。在这个模型中,应用流量首先由“web层”来处理,后者又会与“应用层”进行对话,之后又会与“数据库层”对话。web层中的web服务器被设计成能够非常快速地处理大量传入的请求,并将它们小心地交给相对较慢的应用服务器(Apache、NGINX和其他流行的web服务器都有非常复杂的逻辑来处理这种情况)。同样,应用层使用数据库库与back stores进行通信。这些库通常以一种针对这个用例进行优化的方式处理缓存、负载均衡、路由、流控制等。

So far so good,但是这个模型面对大规模业务时开始显露出疲态——尤其是在应用层,随着时间的推移它会变得非常大。早期的网络规模公司——谷歌、Facebook、Netflix、Twitter——学会了把这块巨石分解成许多独立运行的碎片,催生了微服务的兴起。在引入微服务的那一刻,east-west traffic随之引入。在这个世界上,通信不再是专门的,而是在每个服务之间。当它出错时,网站就会崩溃。

这些公司都以类似的方式进行应对——他们编写了“fat client”库来处理请求流量。这些库——谷歌的Stubby、Netflix的HYstrix、Twitter的Finagle——提供了跨所有服务的统一的运行时操作方式。开发者或服务所有者将使用这些库向其他服务发出请求,库将在后台执行负载均衡、路由、断路等等。通过为应用中的每个服务提供统一的行为、可见性和控制点,这些库表面上形成了第一个Service Mesh。

## 代理崛起

当我们回到当下以云为本的世界,这些库仍然存在。但是,由于进程外代理提供的操作便利,库的吸引力正在降低——尤其是在与容器和编排的出现所带来的部署复杂性显著降低的情况下。

代理绕过了库的许多缺点。例如,当一个库发生更改时,这些更改必须在每个服务中部署,这个过程通常需要复杂的组织协作。而代理,无需重新编译和重新部署,就可以升级应用。同样,代理允许使用多种语言系统,应用可以由不同的语言编写,当然这种方法对于库来说代价是非常大的。

也许对于大型组织来说,最重要的是,在代理服务器而不是库中实现——服务网格负责将运行时操作所需的功能提供给服务所有者,并被这些功能的最终用户掌握 - 平台团队。提供者和消费者的这种对齐,允许这些团队掌握自己的命运,并将dev和ops之间的复杂依赖关系分离。

以上这些因素共同促成了Service Mesh的兴起,也使运行时操作变得更为健全。通过部署一个分布式代理的“网”,可以作为底层基础设施的一部分维护,而不是维护应用本身,并通过提供集中的api来分析和操作流量,Service Mesh为整个组织运行时操作提供了一个标准的机制,同时确保可靠性、安全性和可见性。

- END -

开源PaaS [Rainbond](https://www.rainbond.com) v3.6.0现已发布,新增Service Mesh微服务架构开箱即用,通过插件式扩展来实现治理功能,并支持spring cloud、api gateway、dubbo等主流微服务架构。


**阅读更多**

* `技术` [Service Mesh:什么是Sidecar模式](https://www.goodrain.com/2018/06/21/tech-20180621/) `2018/06/21`
* `技术` [开源PaaS Rainbond v3.6.0正式发布,Service Mesh开箱即用](https://www.goodrain.com/2018/ ... 80620/) `2018/06/20`
* `技术` [解读Rainbond ServiceMesh微服务架构_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80515/) `2018/05/15`
* `技术` [Pinpoint-java性能分析最佳实践_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80508/) `2018/05/08`
* `技术` [通过Minio搭建私有化对象存储服务_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80426/) `2018/04/26`
* `技术` [揭秘高可用负载均衡组件Rainbond-Entrance_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80425/) `2018/04/25`
* `技术` [Rainbond插件体系设计简介_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80224/) `2018/02/24`
* `技术` [Rainbond如何对接外部Maven仓库_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80118/) `2018/01/18`
* `技术` [Spring Boot框架配置MySQL_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80110/) `2018/01/10`
* `技术` [基于Midonet的多租户网络设计_开源PaaS Rainbond](https://blog.goodrain.com/2018 ... 80109/) `2018/01/09`

Service Mesh:什么是Sidecar模式

ServiceMeshgoodrain 发表了文章 • 0 个评论 • 727 次浏览 • 2018-06-21 10:57 • 来自相关话题

​谈到Service Mesh微服务架构,就不得不谈Sidecar模式——一种单节点、多容器的应用设计形式。Sidecar主张以额外的容器来扩展或增强主容器,而这个额外的容器被称为Sidecar容器。

一些例子如下:
 
Web-server容器可以与一个sidecar容易共同部署,该sidecar容器从文件系统中读取由Web-server容器生成的web-server日志,并将日志/stream发送到原称服务器(remote server)。Sidecar容器通过处理web-server日志来作为web-server容器的补充。当然,可能会有人说,为什么web-server不自己处理自己的日志?答案在于以下几点:
 
隔离(separation of concerns):让每个容器都能够关注核心问题。比如web-server提供网页服务,而sidecar则处理web-server的日志,这有助于在解决问题时不与其他问题的处理发生冲突;
 
单一责任原则(single responsibility principle):容器发生变化需要一个明确的理由。换句更容易理解的话来说,每个容器都应该是能够处理好“一件”事情的,而根据这一原则,我们应该让不同的容器分别展开工作,应该让它们处理的问题足够独立;
 
内聚性/可重用性(Cohesiveness/Reusability):使用sidecar容器处理日志,这个容器按道理应该可以应用的其他地方重用;
 以上例子正如下图所示:

另一个例子是在web-server容器与sidecar容器共同部署时,将文件系统与git存储库同步。(我们需要注意Git同步容器的重用醒)如下图所示,应用容器知识链接到本地机器的Redis服务器上:

开源PaaS Rainbond v3.6.0版本现已发布,提供Service Mesh微服务架构的开箱即用,插件式扩展治理功能,并支持spring cloud、api gateway、dubbo等框架。

进一步了解:Rainbond
开源PaaS Rainbond v3.6.0正式发布,Service Mesh开箱即用解读Rainbond ServiceMesh微服务架构_开源PaaS RainbondPinpoint-java性能分析最佳实践_开源PaaS Rainbond通过Minio搭建私有化对象存储服务_开源PaaS Rainbond揭秘高可用负载均衡组件Rainbond-Entrance_开源PaaS RainbondRainbond插件体系设计简介_开源PaaS RainbondRainbond如何对接外部Maven仓库_开源PaaS RainbondSpring Boot框架配置MySQL_开源PaaS Rainbond基于Midonet的多租户网络设计_开源PaaS Rainbond
查看全部
​谈到Service Mesh微服务架构,就不得不谈Sidecar模式——一种单节点、多容器的应用设计形式。Sidecar主张以额外的容器来扩展或增强主容器,而这个额外的容器被称为Sidecar容器。

一些例子如下:
 
Web-server容器可以与一个sidecar容易共同部署,该sidecar容器从文件系统中读取由Web-server容器生成的web-server日志,并将日志/stream发送到原称服务器(remote server)。Sidecar容器通过处理web-server日志来作为web-server容器的补充。当然,可能会有人说,为什么web-server不自己处理自己的日志?答案在于以下几点:
 
  • 隔离(separation of concerns):让每个容器都能够关注核心问题。比如web-server提供网页服务,而sidecar则处理web-server的日志,这有助于在解决问题时不与其他问题的处理发生冲突;

 
  • 单一责任原则(single responsibility principle):容器发生变化需要一个明确的理由。换句更容易理解的话来说,每个容器都应该是能够处理好“一件”事情的,而根据这一原则,我们应该让不同的容器分别展开工作,应该让它们处理的问题足够独立;

 
  • 内聚性/可重用性(Cohesiveness/Reusability):使用sidecar容器处理日志,这个容器按道理应该可以应用的其他地方重用;

 以上例子正如下图所示:

另一个例子是在web-server容器与sidecar容器共同部署时,将文件系统与git存储库同步。(我们需要注意Git同步容器的重用醒)如下图所示,应用容器知识链接到本地机器的Redis服务器上:

开源PaaS Rainbond v3.6.0版本现已发布,提供Service Mesh微服务架构的开箱即用,插件式扩展治理功能,并支持spring cloud、api gateway、dubbo等框架。

进一步了解:Rainbond

开源PaaS Rainbond v3.6.0正式发布,Service Mesh开箱即用

ServiceMeshgoodrain 发表了文章 • 0 个评论 • 751 次浏览 • 2018-06-20 14:09 • 来自相关话题

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

Service Mesh微服务架构是开源PaaS Rainbond在v3.6.0版本中的重点新增特性,可以开箱即用。

这种微服务架构经过过去一年多的发展,已然成为云原生技术堆栈中不容忽视的关键组件。它允许我们在开发应用时,只关注业务代码,而不需要关心技术底层逻辑,服务拆分带来的复杂性问题也迎刃而解。

Rainbond的Service Mesh微服务架构以透明代理的形式提供服务间通信,不会与业务代码耦合,换句话说,Service Mesh对于业务是无侵入的。

其次,Rainbond通过插件式扩展来实现治理功能,例如服务发现和注册、弹性伸缩与负载均衡、容错处理(断路器与限流)、监控与报警、数据存储与共享、日志分析等等。
 
解读Rainbond ServiceMesh微服务架构Rainbond插件体系设计简介
 另外值得一提的是,Rainbond的Service Mesh微服务架构对spring cloud、api gateway、dubbo等框架有良好支持。

除了以上特性,Rainbond v3.6.0还新增了应用的备份与恢复以及快数据中心的应用迁移功能(详见下文)。同时,Rainbond经过本次更新,在稳定性方面得到了大幅度提升,解决了2个生产环境中可能会造成严重影响的bug:
解决了docker进程由于默认xfs文件系统io阻塞导致卡死的问题解决了由于etcd服务连接异常导致各组件cpu泄漏的问题
 本次版本升级详细介绍如下:
 
新特性1:ServiceMesh开箱即用

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

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

在应用中启用插件

配置插件


更多信息参考相关文档:
应用A/B测试方案应用灰度发布方案

 新特性2:应用组备份与恢复
无论是测试还是生产环境,业务系统的备份、迁移与恢复都是比较复杂和耗时的工作。Rainbond收集多家企业级用户和公有云用户的反馈,经过2个月的开发,推出了应用组的备份、迁移与恢复功能,用户仅需轻松点击就可以解决复杂业务组的备份、迁移与恢复。



详细文档请参考:应用备份和恢复

 新特性3:内部应用市场管理
针对内部应用市场,Rainbond过往版本可以将应用发布到内部应用市场,供其他团队安装使用。本次升级支持将云市同步或者内部分享的应用打包下载,这样用户可以将应用迁移到离线Rainbond,或其他Docker环境下运行,目前支持好雨应用打包格式和docker-compose.yaml格式。


 
Rainbond v3.6.0详细更新日志
应用控制台
支持应用组的完整备份和恢复对运行的业务系统状态进行整体、全面快照,一旦出现无法解决的问题可快速回滚到备份时刻支持应用组跨数据中心、跨租户迁移支持内部应用市场管理应用和插件的同步、删除与卸载内部应用市场应用的导出,可导出兼容docker-compose或可导入Rainbond平台的rainbondApp应用包支持离线导入RainbondApp到内部市场支持基于Github、Gitlab的Webhook自动部署源码创建的应用支持站内信公告监控模块支持自动发现监控服务,自动配置监控项目控制台支持用户自定义角色的权限控制

底层服务
Rainbond组件全面高可用支持,RegionDB可使用CockroachDB,UI DB可使用TiDB集群DNS升级,提供更高的查询性能,支持自定义普通域名和泛域名解析重构rbd-monitor组件(Prometheus),支持服务高可用与分布式部署,并增加服务自动注册/发现机制

插件
服务网络治理插件插件开箱即用的支持ServiceMesh架构,并可根据需要自定义扩展支持应用的灰度发布和,A/B测试(HTTP)支持服务到服务的限流和熔断机制(HTTP)支持服务到服务的智能路由(HTTP)支持服务到服务的性能分析和错误跟踪,基于应用拓扑图展示完整流量拓扑支持从云市场或内部市场分享和安装应用插件
 
MySQL数据库热备份插件 (基于Percona XtraBackup实现)PostgreSQL数据库备份插件 (基于pg_dump实现)MongoDB数据库备份插件 (基于mongodump实现)日志收集对接ES插件
 
rbd-lb 增加vrrpd功能,支持VIP(测试阶段,默认不启用)

Rainbond安装程序
支持一键扩容管理节点重构安装流程,支持全局配置文件增加升级与维护模块,方便后续执行升级维护操作增加CockroachDB支持(需要手动修改配置)增加Rainbond组件最大内存限制功能

解决的BUG
修复了自定义域名不生效的问题修复了自定义https不生效的问题解决了某些情况下重新部署应用负载均衡不更新问题解决了插件重新构建后,应用重启插件新版不生效问题解决了应用性能分析数据历史查询问题解决了性能监控数据有负数的问题解决了源码创建应用高级设置页面显示BUG,支持定义php、java等源码类型的中间件版本和依赖库解决了docker进程由于xfs文件系统io阻塞导致卡死的问题解决了由于etcd server退出导致各组件cpu泄漏问题
 


快捷链接
Rainbond项目网站试用Rainbond公有云Github码云文档微信群: 添加微信“zqg5258423”并接受邀请入群
 
相关阅读
解读Rainbond ServiceMesh微服务架构_开源PaaS RainbondPinpoint-java性能分析最佳实践_开源PaaS Rainbond通过Minio搭建私有化对象存储服务_开源PaaS Rainbond揭秘高可用负载均衡组件Rainbond-Entrance_开源PaaS RainbondRainbond插件体系设计简介_开源PaaS RainbondRainbond如何对接外部Maven仓库_开源PaaS RainbondSpring Boot框架配置MySQL_开源PaaS Rainbond基于Midonet的多租户网络设计_开源PaaS Rainbond
查看全部


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


Service Mesh微服务架构是开源PaaS Rainbond在v3.6.0版本中的重点新增特性,可以开箱即用。

这种微服务架构经过过去一年多的发展,已然成为云原生技术堆栈中不容忽视的关键组件。它允许我们在开发应用时,只关注业务代码,而不需要关心技术底层逻辑,服务拆分带来的复杂性问题也迎刃而解。

Rainbond的Service Mesh微服务架构以透明代理的形式提供服务间通信,不会与业务代码耦合,换句话说,Service Mesh对于业务是无侵入的。

其次,Rainbond通过插件式扩展来实现治理功能,例如服务发现和注册、弹性伸缩与负载均衡、容错处理(断路器与限流)、监控与报警、数据存储与共享、日志分析等等。
 

 另外值得一提的是,Rainbond的Service Mesh微服务架构对spring cloudapi gateway、dubbo等框架有良好支持。

除了以上特性,Rainbond v3.6.0还新增了应用的备份与恢复以及快数据中心的应用迁移功能(详见下文)。同时,Rainbond经过本次更新,在稳定性方面得到了大幅度提升,解决了2个生产环境中可能会造成严重影响的bug:
  • 解决了docker进程由于默认xfs文件系统io阻塞导致卡死的问题
  • 解决了由于etcd服务连接异常导致各组件cpu泄漏的问题

 本次版本升级详细介绍如下:
 
新特性1:ServiceMesh开箱即用

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

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


  • 在应用中启用插件


  • 配置插件



更多信息参考相关文档:



 新特性2:应用组备份与恢复
无论是测试还是生产环境,业务系统的备份、迁移与恢复都是比较复杂和耗时的工作。Rainbond收集多家企业级用户和公有云用户的反馈,经过2个月的开发,推出了应用组的备份、迁移与恢复功能,用户仅需轻松点击就可以解决复杂业务组的备份、迁移与恢复。



详细文档请参考:应用备份和恢复


 新特性3:内部应用市场管理
针对内部应用市场,Rainbond过往版本可以将应用发布到内部应用市场,供其他团队安装使用。本次升级支持将云市同步或者内部分享的应用打包下载,这样用户可以将应用迁移到离线Rainbond,或其他Docker环境下运行,目前支持好雨应用打包格式和docker-compose.yaml格式。


 
Rainbond v3.6.0详细更新日志
应用控制台
  • 支持应用组的完整备份和恢复
  • 对运行的业务系统状态进行整体、全面快照,一旦出现无法解决的问题可快速回滚到备份时刻
  • 支持应用组跨数据中心、跨租户迁移
  • 支持内部应用市场管理
  • 应用和插件的同步、删除与卸载
  • 内部应用市场应用的导出,可导出兼容docker-compose或可导入Rainbond平台的rainbondApp应用包
  • 支持离线导入RainbondApp到内部市场
  • 支持基于Github、Gitlab的Webhook自动部署源码创建的应用
  • 支持站内信公告
  • 监控模块支持自动发现监控服务,自动配置监控项目
  • 控制台支持用户自定义角色的权限控制


底层服务
  • Rainbond组件全面高可用支持,RegionDB可使用CockroachDB,UI DB可使用TiDB
  • 集群DNS升级,提供更高的查询性能,支持自定义普通域名和泛域名解析
  • 重构rbd-monitor组件(Prometheus),支持服务高可用与分布式部署,并增加服务自动注册/发现机制


插件
  • 服务网络治理插件插件
  • 开箱即用的支持ServiceMesh架构,并可根据需要自定义扩展
  • 支持应用的灰度发布和,A/B测试(HTTP)
  • 支持服务到服务的限流和熔断机制(HTTP)
  • 支持服务到服务的智能路由(HTTP)
  • 支持服务到服务的性能分析和错误跟踪,基于应用拓扑图展示完整流量拓扑
  • 支持从云市场或内部市场分享和安装应用插件

 
  • MySQL数据库热备份插件 (基于Percona XtraBackup实现)
  • PostgreSQL数据库备份插件 (基于pg_dump实现)
  • MongoDB数据库备份插件 (基于mongodump实现)
  • 日志收集对接ES插件

 
  • rbd-lb 增加vrrpd功能,支持VIP(测试阶段,默认不启用)


Rainbond安装程序
  • 支持一键扩容管理节点
  • 重构安装流程,支持全局配置文件
  • 增加升级与维护模块,方便后续执行升级维护操作
  • 增加CockroachDB支持(需要手动修改配置)
  • 增加Rainbond组件最大内存限制功能


解决的BUG
  • 修复了自定义域名不生效的问题
  • 修复了自定义https不生效的问题
  • 解决了某些情况下重新部署应用负载均衡不更新问题
  • 解决了插件重新构建后,应用重启插件新版不生效问题
  • 解决了应用性能分析数据历史查询问题
  • 解决了性能监控数据有负数的问题
  • 解决了源码创建应用高级设置页面显示BUG,支持定义php、java等源码类型的中间件版本和依赖库
  • 解决了docker进程由于xfs文件系统io阻塞导致卡死的问题
  • 解决了由于etcd server退出导致各组件cpu泄漏问题

 


快捷链接

 
相关阅读

service mesh istio 小实验

Istiowill835559313 发表了文章 • 0 个评论 • 558 次浏览 • 2018-06-18 17:57 • 来自相关话题

service mesh 入门实验

1.使用vagrant快速搭建linux实验环境
http://www.maogx.win/posts/20/

2.安装配置k8s(kubernetes)集群
http://www.maogx.win/posts/15/
http://www.maogx.win/posts/16/

3.istio安装测试
http://www.maogx.win/posts/24/

4.istio微服务实验
http://www.maogx.win/posts/25/

5.istio微服务实验之监控日志与可视化
http://www.maogx.win/posts/26/ 
 
6.istio-0.8长期支持版安装测试
http://www.maogx.win/posts/30/
 
7.istio-0.8长期支持版微服务实验
http://www.maogx.win/posts/31/
  查看全部
service mesh 入门实验

1.使用vagrant快速搭建linux实验环境
http://www.maogx.win/posts/20/

2.安装配置k8s(kubernetes)集群
http://www.maogx.win/posts/15/
http://www.maogx.win/posts/16/

3.istio安装测试
http://www.maogx.win/posts/24/

4.istio微服务实验
http://www.maogx.win/posts/25/

5.istio微服务实验之监控日志与可视化
http://www.maogx.win/posts/26/ 
 
6.istio-0.8长期支持版安装测试
http://www.maogx.win/posts/30/
 
7.istio-0.8长期支持版微服务实验
http://www.maogx.win/posts/31/
 

Service Mesh服务网格:是什么和为什么

交流问答goodrain 发表了文章 • 0 个评论 • 1840 次浏览 • 2018-05-24 14:31 • 来自相关话题

​https://www.shantala.io/service-mesh-for-microservices/
Service Mesh(服务网格)会是今年微服务生态的主角吗?从趋势来看,众多企业正在将这项理微服务复杂性的技术/工具,搬进他们的IT“火药库”之中。什么是Service Mesh?

根据Linkerd CEO William Morgan定义,Service Mesh是用于处理服务间通信的基础设施层,用于在云原生应用复杂的服务拓扑中实现可靠的请求传递。在实践中,Service Mesh通常是一组与应用一起部署,但对应用透明的轻量级网络代理。


Service Mesh与传统基础设施层不同之处在于,它形成了一个分布式的互连代理网络,以sidecar形式部署在服务两侧,服务对于代理无感知,且服务间所有通信都由代理进行路由。


 
为什么需要Service Mesh?

“Smart endpoint and dumb pipes”是微服务架构在集成服务时采用的一个核心理念,这一理念改变了过去臃肿集中的ESB(企业服务总线),无疑是正确方向上的一大进步,但同时也给我们出了一些难题——多智能才不会过于智能,而服务轻重大小的程度如何拿捏?我们应该如何处理微服务系统中服务间交互的复杂性?放在服务内部还是外部?如果是内部,如何处理业务逻辑关系,或者应该与基础设施更为相关?如果是外部,如何避免重蹈ESB的覆辙?

皮的不谈,先来看看处理服务间通信时需要关注的点:
服务发现负载均衡路由流量控制通信可靠性弹性安全监控/日志
似乎都是老生常谈,存在于任何需要处理网络的分布式系统之中,区别在于,当所涉及微服务数量呈指数级增加,这些问题也会被相应放大。

一个已经被广泛应用的解决方案是利用api网关来处理服务外部和服务之间的请求,提供例如服务发现、路由、监控、流量控制等。

然而,api网关有一个比较致命的缺陷,它容易出现单点故障并且实践不当很有可能会变得异常臃肿。另一方面,api网关核心是面向用户,也就是说它可以解决从用户到微服务的流量问题,但不能解决所有问题,而我们需要的是一个完整的方案,或者至少是一些能够与api网关互补的方案和工具。

另一种选择是在网络堆栈的较低层级(4/3)进行可靠性、监控、流量控制等方面处理。这种选择的问题是,在较低较低的操作难易满足应用层的问题。联想end-to-end(端到端)的理论,我们前面提到的那几个关注点实际上还是集中在应用层,也只能在应用层成功实现。

像Netflix、Twitter等SOA/微服务的早期采用者,他们通过建立内部库的方式处理这些问题,然后提供给所有服务使用。这种方法的问题在于,把库扩展到成百上千个微服务中难度极高,而且这些库相对来说是比较”脆弱“的,我们很难保证他们可以适应所有的技术堆栈选择。

程度上来说,Service Mesh与这些库很类似,但Service Mesh是与服务相邻的独立进程。服务连接到代理,代理反过来又与其他代理(HTTP1.1/2、GRPC)进行通信。它们是相对独立的进程,在应用层或应用层之下分布和运行,进而解决了上述两个方案存在的缺陷。Service Mesh架构
Service Mesh由data plane构成,其中所有服务通过sidecar代理进行服务通信。(所有代理相互连接形成一个Mesh,Service Mesh由此得名)网格同时包含一个control plane——可以将所有独立的sidecar代理连接到一个分布式网络中,并设置网格还包括一个控制平面——它将所有独立的sidecar代理连接到一个分布式网络中,并设置由data plane指定的策略。

Control plane定义服务发现、路由、流量控制等策略。这些策略可以是全局的,也可以是限定的。Data plane负责在通信时应用和执行这些策略。最后总结来说,Service Mesh是“时间的产物”,Docker、Kubernetes等容器技术直接推进了对于Service Mesh的需求,让复杂的系统可以被轻松部署和管理。

未来Service Mesh将如何发展还未可知,或许会像TCP/IP一样形成标准,或许不同工具和平台会独具一格……但有一点是确认的,Service Mesh对于微服务生态的价值令人难以忽视,能够将繁重的服务治理工作变得简单高效,何乐而不为?

相关阅读
解读Rainbond ServiceMesh微服务架构_开源PaaS Rainbond
 
开源PaaS Rainbond原生支持Service Mesh,在线体验请注册公有云(新用户7天免费)
查看全部
https://www.shantala.io/service-mesh-for-microservices/
Service Mesh(服务网格)会是今年微服务生态的主角吗?从趋势来看,众多企业正在将这项理微服务复杂性的技术/工具,搬进他们的IT“火药库”之中。什么是Service Mesh?

根据Linkerd CEO William Morgan定义,Service Mesh是用于处理服务间通信的基础设施层,用于在云原生应用复杂的服务拓扑中实现可靠的请求传递。在实践中,Service Mesh通常是一组与应用一起部署,但对应用透明的轻量级网络代理。


Service Mesh与传统基础设施层不同之处在于,它形成了一个分布式的互连代理网络,以sidecar形式部署在服务两侧,服务对于代理无感知,且服务间所有通信都由代理进行路由。


 
为什么需要Service Mesh?

“Smart endpoint and dumb pipes”是微服务架构在集成服务时采用的一个核心理念,这一理念改变了过去臃肿集中的ESB(企业服务总线),无疑是正确方向上的一大进步,但同时也给我们出了一些难题——多智能才不会过于智能,而服务轻重大小的程度如何拿捏?我们应该如何处理微服务系统中服务间交互的复杂性?放在服务内部还是外部?如果是内部,如何处理业务逻辑关系,或者应该与基础设施更为相关?如果是外部,如何避免重蹈ESB的覆辙?

皮的不谈,先来看看处理服务间通信时需要关注的点:
  • 服务发现
  • 负载均衡
  • 路由
  • 流量控制
  • 通信可靠性
  • 弹性
  • 安全
  • 监控/日志

似乎都是老生常谈,存在于任何需要处理网络的分布式系统之中,区别在于,当所涉及微服务数量呈指数级增加,这些问题也会被相应放大。

一个已经被广泛应用的解决方案是利用api网关来处理服务外部和服务之间的请求,提供例如服务发现、路由、监控、流量控制等。

然而,api网关有一个比较致命的缺陷,它容易出现单点故障并且实践不当很有可能会变得异常臃肿。另一方面,api网关核心是面向用户,也就是说它可以解决从用户到微服务的流量问题,但不能解决所有问题,而我们需要的是一个完整的方案,或者至少是一些能够与api网关互补的方案和工具。

另一种选择是在网络堆栈的较低层级(4/3)进行可靠性、监控、流量控制等方面处理。这种选择的问题是,在较低较低的操作难易满足应用层的问题。联想end-to-end(端到端)的理论,我们前面提到的那几个关注点实际上还是集中在应用层,也只能在应用层成功实现。

像Netflix、Twitter等SOA/微服务的早期采用者,他们通过建立内部库的方式处理这些问题,然后提供给所有服务使用。这种方法的问题在于,把库扩展到成百上千个微服务中难度极高,而且这些库相对来说是比较”脆弱“的,我们很难保证他们可以适应所有的技术堆栈选择。

程度上来说,Service Mesh与这些库很类似,但Service Mesh是与服务相邻的独立进程。服务连接到代理,代理反过来又与其他代理(HTTP1.1/2、GRPC)进行通信。它们是相对独立的进程,在应用层或应用层之下分布和运行,进而解决了上述两个方案存在的缺陷。Service Mesh架构
Service Mesh由data plane构成,其中所有服务通过sidecar代理进行服务通信。(所有代理相互连接形成一个Mesh,Service Mesh由此得名)网格同时包含一个control plane——可以将所有独立的sidecar代理连接到一个分布式网络中,并设置网格还包括一个控制平面——它将所有独立的sidecar代理连接到一个分布式网络中,并设置由data plane指定的策略。

Control plane定义服务发现、路由、流量控制等策略。这些策略可以是全局的,也可以是限定的。Data plane负责在通信时应用和执行这些策略。最后总结来说,Service Mesh是“时间的产物”,Docker、Kubernetes等容器技术直接推进了对于Service Mesh的需求,让复杂的系统可以被轻松部署和管理。

未来Service Mesh将如何发展还未可知,或许会像TCP/IP一样形成标准,或许不同工具和平台会独具一格……但有一点是确认的,Service Mesh对于微服务生态的价值令人难以忽视,能够将繁重的服务治理工作变得简单高效,何乐而不为?

相关阅读

 
开源PaaS Rainbond原生支持Service Mesh,在线体验请注册公有云(新用户7天免费)

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

ServiceMeshgoodrain 发表了文章 • 0 个评论 • 1050 次浏览 • 2018-05-15 12:06 • 来自相关话题

```
从技术实现的维度解读开源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”并接受邀请入群
 
  查看全部
```
从技术实现的维度解读开源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”并接受邀请入群