目录：
Service Mesh入门—1、微服务架构的痛点
Service Mesh入门—2、服务网格架构

基于第一章微服务架构痛点，以及应用架构发展方向，服务网格思想提出了。

服务网格思想提出

历程

在这里插入图片描述

  • 最早开发的Linkerd的Buoyant公司提出，并在内部使用
  • 2016年09月29日第一次公开使用
  • 2017年初，Service Mesh进入国内技术社区视野

定义

在这里插入图片描述
在这里插入图片描述

服务网格架构

在这里插入图片描述

  • 治理能力独立（Sidecar）
  • 应用程序无感知
  • 服务通信的基础设施层

特点

  • Service Mesh独立进程，独立升级
  • 业务团队专注于业务逻辑本身
  • 一套基础设施支持多语言开发
  • 业务团队与基础设施团队物理解耦

业界实践

Sofa Mesh（蚂蚁金服）

在这里插入图片描述

Weibo Mesh（新浪微博）

在这里插入图片描述

Istio

在这里插入图片描述

关键能力

  • 流量管理
  • 策略执行
  • 服务安全
  • 服务观察
  • 多平台支持
    在这里插入图片描述

核心组件

Pilot：
在这里插入图片描述

  • 流量治理的核心组件
  • 支持从Kubernetes、Consul等多种平台获取服务发现功能

Mixer：
在这里插入图片描述

  • 实施访问控制和使用策略组件
  • 从Proxy代代理收集遥测数据

Citadel：
在这里插入图片描述

  • 负责管理密钥和证书
  • 保证数据平面各服务的通信安全

Istio + Kubernetes

  • 云原生应用治理
  • 云原生应用设施
    在这里插入图片描述

Istio+K8S

  • 通信与业务解耦
  • 服务注册与K8S通道相同
    在这里插入图片描述
    以上就是Service Mesh的入门，后续会更新Service Mesh实战。
# istio
Logo
向您推荐>>Eolink开发者社区

权威｜前沿｜技术｜干货｜国内首个API全生命周期开发者社区

更多推荐

ELK实现containerd的容器日志采集展示【基于logging的全栈监测】

企业级ELK Stack构建介绍

avatar 云原生

深入理解 Mocha 测试框架：从零实现一个 Mocha

前言什么是自动化测试自动化测试在很多团队中都是Devops环节中很难执行起来的一个环节，主要原因在于测试代码的编写工作很难抽象，99%的场景都需要和业务强绑定，而且写测试代码的编写工作量往往比编写实际业务代码的工作量更多。在一些很多业务场景中投入产出比很低，适合写自动化测试的应该是那些中长期业务以及一些诸如组件一样的基础库。自动化测试是个比较大的概念，其中分类也比较多，比如单元测试，端对端测试，集

avatar 云原生

(20200916 Solved)docker-compose up创建容器自动退出

问题描述如题，创建容器后自动退出了。并且docker start container无效解决方案原因是缺失了控制终端的配置，需要在docker-compose.yml中增加tty:true ，有时候这样也不行，需要再增加一个command:/bin/bash，命令不一定是这个，需要是一个不会退出的命令，然后用-d后台启动容器。Referencesdocker-compose启动容器后自动退出...

avatar 云原生