Service Mesh:什么是Sidecar模式

ServiceMeshgoodrain 发表了文章 • 0 个评论 • 9 次浏览 • 3 小时前 • 来自相关话题

谈到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的日志,这有助于在解决问题时不与其他问题的处理发生冲突;
n different containers as their concerns are segregated well enough.

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

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

以上例子正如下图所示:

![](https://grstatic.oss-cn-shangh ... r1.png)

Another example could be to use have web server deployed with a sidecar container that synchronizes file system with git repository; Notice the reusability of git synchronizer container. Application container is simply connecting to a Redis server on localhost. Following diagram represents the same:

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

![](https://grstatic.oss-cn-shangh ... r2.png)

-----

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

进一步了解:[Rainbond](https://www.rainbond.com)

* `技术`[开源PaaS Rainbond v3.6.0正式发布,Service Mesh开箱即用](https://www.goodrain.com/2018/ ... 80620/)
* `技术` [解读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模式——一种单节点、多容器的应用设计形式。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的日志,这有助于在解决问题时不与其他问题的处理发生冲突;
n different containers as their concerns are segregated well enough.

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

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

以上例子正如下图所示:

![](https://grstatic.oss-cn-shangh ... r1.png)

Another example could be to use have web server deployed with a sidecar container that synchronizes file system with git repository; Notice the reusability of git synchronizer container. Application container is simply connecting to a Redis server on localhost. Following diagram represents the same:

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

![](https://grstatic.oss-cn-shangh ... r2.png)

-----

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

进一步了解:[Rainbond](https://www.rainbond.com)

* `技术`[开源PaaS Rainbond v3.6.0正式发布,Service Mesh开箱即用](https://www.goodrain.com/2018/ ... 80620/)
* `技术` [解读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`

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

ServiceMeshgoodrain 发表了文章 • 0 个评论 • 38 次浏览 • 23 小时前 • 来自相关话题

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

Service Mesh微服务架构是开源PaaS Rainbond在[v3.6.0](https://github.com/goodrain/ra ... v3.6.0)版本中的重点新增特性,可以开箱即用。

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

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

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

* [解读Rainbond ServiceMesh微服务架构](https://blog.goodrain.com/2018 ... 80515/)
* [Rainbond插件体系设计简介](https://blog.goodrain.com/2018 ... 80224/)

另外值得一提的是,Rainbond的Service Mesh微服务架构对[spring cloud](https://github.com/cloudframeworks-springcloud)、[api gateway](https://github.com/cloudframeworks-apigateway)、dubbo等框架有良好支持。

除了以上特性,Rainbond v3.6.0还新增了应用的备份与恢复以及快数据中心的应用迁移功能(详见下文)。同时,Rainbond经过本次更新,在稳定性方面得到了大幅度提升,解决了2个生产环境中可能会造成严重影响的bug:

- 解决了docker进程由于默认xfs文件系统io阻塞导致卡死的问题
- 解决了由于etcd服务连接异常导致各组件cpu泄漏的问题

本次版本升级详细介绍如下:

## 新特性1:ServiceMesh开箱即用

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

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

- 安装**服务网络治理插件** 

![servicemesh01](https://static.goodrain.com/im ... 01.gif)

- **在应用中启用插件**

![servicemesh02](https://static.goodrain.com/im ... 02.gif)

- **配置插件**

![servicemesh03](https://static.goodrain.com/im ... 03.png)

> 更多信息参考相关文档:
>
> - [应用A/B测试方案](https://www.rainbond.com/docs/ ... p.html)
> - [应用灰度发布方案](https://www.rainbond.com/docs/ ... p.html)

## 新特性2:应用组备份与恢复

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

![backup](https://static.goodrain.com/im ... up.gif)

> 详细文档请参考:[应用备份和恢复](https://www.rainbond.com/docs/ ... p.html)

## 新特性3:内部应用市场管理

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

![](https://static.goodrain.com/im ... pp.png)

## 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

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


![](https://t.goodrain.com/uploads ... e8.png)

**快捷链接**

* [Rainbond项目网站](https://www.rainbond.com)
* [试用Rainbond公有云](https://www.goodrain.com)
* [Github](https://github.com/goodrain/rainbond)
* [码云](https://gitee.com/rainbond/Rainbond)
* [文档](https://www.goodrain.com/docs/stable/)
* 微信群: 添加微信“zqg5258423”并接受邀请入群

**相关阅读**

* `技术` [解读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` 查看全部
> [Rainbond](https://www.rainbond.com)是以应用为中心的开源PaaS,由好雨基于Docker、Kubernetes等容器技术自主研发,可作为公有云或私有云环境下的应用交付平台、DevOps平台、自动化运维平台和行业云平台,或作为企业级的混合云多云管理工具、kubernetes容器管理工具或Service Mesh微服务架构治理工具。

Service Mesh微服务架构是开源PaaS Rainbond在[v3.6.0](https://github.com/goodrain/ra ... v3.6.0)版本中的重点新增特性,可以开箱即用。

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

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

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

* [解读Rainbond ServiceMesh微服务架构](https://blog.goodrain.com/2018 ... 80515/)
* [Rainbond插件体系设计简介](https://blog.goodrain.com/2018 ... 80224/)

另外值得一提的是,Rainbond的Service Mesh微服务架构对[spring cloud](https://github.com/cloudframeworks-springcloud)、[api gateway](https://github.com/cloudframeworks-apigateway)、dubbo等框架有良好支持。

除了以上特性,Rainbond v3.6.0还新增了应用的备份与恢复以及快数据中心的应用迁移功能(详见下文)。同时,Rainbond经过本次更新,在稳定性方面得到了大幅度提升,解决了2个生产环境中可能会造成严重影响的bug:

- 解决了docker进程由于默认xfs文件系统io阻塞导致卡死的问题
- 解决了由于etcd服务连接异常导致各组件cpu泄漏的问题

本次版本升级详细介绍如下:

## 新特性1:ServiceMesh开箱即用

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

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

- 安装**服务网络治理插件** 

![servicemesh01](https://static.goodrain.com/im ... 01.gif)

- **在应用中启用插件**

![servicemesh02](https://static.goodrain.com/im ... 02.gif)

- **配置插件**

![servicemesh03](https://static.goodrain.com/im ... 03.png)

> 更多信息参考相关文档:
>
> - [应用A/B测试方案](https://www.rainbond.com/docs/ ... p.html)
> - [应用灰度发布方案](https://www.rainbond.com/docs/ ... p.html)

## 新特性2:应用组备份与恢复

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

![backup](https://static.goodrain.com/im ... up.gif)

> 详细文档请参考:[应用备份和恢复](https://www.rainbond.com/docs/ ... p.html)

## 新特性3:内部应用市场管理

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

![](https://static.goodrain.com/im ... pp.png)

## 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

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


![](https://t.goodrain.com/uploads ... e8.png)

**快捷链接**

* [Rainbond项目网站](https://www.rainbond.com)
* [试用Rainbond公有云](https://www.goodrain.com)
* [Github](https://github.com/goodrain/rainbond)
* [码云](https://gitee.com/rainbond/Rainbond)
* [文档](https://www.goodrain.com/docs/stable/)
* 微信群: 添加微信“zqg5258423”并接受邀请入群

**相关阅读**

* `技术` [解读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 istio 小实验

Istiowill835559313 发表了文章 • 0 个评论 • 72 次浏览 • 2 天前 • 来自相关话题

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 个评论 • 1122 次浏览 • 2018-05-24 14:31 • 来自相关话题

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

### 什么是Service Mesh?

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

![](https://grstatic.oss-cn-shangh ... -1.png)

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

![](https://grstatic.oss-cn-shangh ... -2.png)

### 为什么需要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指定的策略。

![](https://grstatic.oss-cn-shangh ... -3.png)

Control plane定义服务发现、路由、流量控制等策略。这些策略可以是全局的,也可以是限定的。Data plane负责在通信时应用和执行这些策略。

### 最后

总结来说,Service Mesh是“时间的产物”,Docker、Kubernetes等容器技术直接推进了对于Service Mesh的需求,让复杂的系统可以被轻松部署和管理。

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

https://www.shantala.io/service-mesh-for-microservices/ 

-----

**相关阅读**

* `技术`[解读Rainbond ServiceMesh微服务架构_开源PaaS Rainbond](https://www.goodrain.com/2018/ ... 80515/) `2018/05/15`

**开源PaaS [Rainbond](https://www.rainbond.com)原生支持Service Mesh,在线体验请注册[公有云](https://www.goodrain.com)(新用户7天免费)** 查看全部
Service Mesh(服务网格)会是今年微服务生态的主角吗?从趋势来看,众多企业正在将这项理微服务复杂性的技术/工具,搬进他们的IT“火药库”之中。

### 什么是Service Mesh?

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

![](https://grstatic.oss-cn-shangh ... -1.png)

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

![](https://grstatic.oss-cn-shangh ... -2.png)

### 为什么需要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指定的策略。

![](https://grstatic.oss-cn-shangh ... -3.png)

Control plane定义服务发现、路由、流量控制等策略。这些策略可以是全局的,也可以是限定的。Data plane负责在通信时应用和执行这些策略。

### 最后

总结来说,Service Mesh是“时间的产物”,Docker、Kubernetes等容器技术直接推进了对于Service Mesh的需求,让复杂的系统可以被轻松部署和管理。

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

https://www.shantala.io/service-mesh-for-microservices/ 

-----

**相关阅读**

* `技术`[解读Rainbond ServiceMesh微服务架构_开源PaaS Rainbond](https://www.goodrain.com/2018/ ... 80515/) `2018/05/15`

**开源PaaS [Rainbond](https://www.rainbond.com)原生支持Service Mesh,在线体验请注册[公有云](https://www.goodrain.com)(新用户7天免费)**

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

ServiceMeshgoodrain 发表了文章 • 0 个评论 • 823 次浏览 • 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”并接受邀请入群
 
 

有没有一个可用的现成例子项目?

交流问答leo 回复了问题 • 8 人关注 • 6 个回复 • 1664 次浏览 • 2018-05-10 17:51 • 来自相关话题

如何用Istio做一个前后端分离的博客?

Istiosunshinexs 回复了问题 • 2 人关注 • 1 个回复 • 640 次浏览 • 2018-05-08 10:42 • 来自相关话题

纠错帖:Zuul & Spring Cloud Gateway & Linkerd性能对比

交流问答不战の约 回复了问题 • 4 人关注 • 3 个回复 • 1638 次浏览 • 2018-05-04 10:28 • 来自相关话题

istio 配置生效流程及源码简介

Istiofudali 发表了文章 • 0 个评论 • 543 次浏览 • 2018-04-24 13:13 • 来自相关话题

istio 配置生效流程及源码简介

使用Istio微服务框架,业务逻辑写在哪里?有规定用什么语言写吗?

IstioOnline 回复了问题 • 2 人关注 • 1 个回复 • 872 次浏览 • 2018-04-22 01:11 • 来自相关话题