从0开始学微服务
胡忠想
微博技术专家
立即订阅
16266 人已学习
课程目录
已完结 42 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 微服务,从放弃到入门
免费
模块一 入门微服务 (10讲)
01 | 到底什么是微服务?
02 | 从单体应用走向服务化
03 | 初探微服务架构
04 | 如何发布和引用服务?
05 | 如何注册和发现服务?
06 | 如何实现RPC远程服务调用?
07 | 如何监控微服务调用?
08 | 如何追踪微服务调用?
09 | 微服务治理的手段有哪些?
10 | Dubbo框架里的微服务组件
模块二 落地微服务 (14讲)
11 | 服务发布和引用的实践
12 | 如何将注册中心落地?
13 | 开源服务注册中心如何选型?
14 | 开源RPC框架如何选型?
15 | 如何搭建一个可靠的监控系统?
16 | 如何搭建一套适合你的服务追踪系统?
17 | 如何识别服务节点是否存活?
18 | 如何使用负载均衡算法?
19 | 如何使用服务路由?
20 | 服务端出现故障时该如何应对?
21 | 服务调用失败时有哪些处理手段?
22 | 如何管理服务配置?
23 | 如何搭建微服务治理平台?
24 | 微服务架构该如何落地?
模块三 进阶微服务 (8讲)
25 | 微服务为什么要容器化?
26 | 微服务容器化运维:镜像仓库和资源调度
27 | 微服务容器化运维:容器调度和服务编排
28 | 微服务容器化运维:微博容器运维平台DCP
29 | 微服务如何实现DevOps?
30 | 如何做好微服务容量规划?
31 | 微服务多机房部署实践
32 | 微服务混合云部署实践
模块四 展望微服务 (4讲)
33 | 下一代微服务架构Service Mesh
34 | Istio:Service Mesh的代表产品
35 | 微博Service Mesh实践之路(上)
36 | 微博Service Mesh实践之路(下)
阿忠伯的特别放送 (4讲)
阿忠伯的特别放送 | 答疑解惑01
阿忠伯的特别放送 | 答疑解惑02
微博技术解密(上) | 微博信息流是如何实现的?
微博技术解密(下)| 微博存储的那些事儿
结束语 (1讲)
结束语 | 微服务,从入门到精通
从0开始学微服务
登录|注册

33 | 下一代微服务架构Service Mesh

胡忠想 2018-11-06
今天我们将进入专栏最后一个模块,我会和你聊聊下一代微服务架构 Service Mesh。说到 Service Mesh,在如今的微服务领域可谓是无人不知、无人不晓,被很多人定义为下一代的微服务架构。那么究竟什么是 Service Mesh?Service Mesh 是如何实现的?今天我就来给你解答这些疑问。

什么是 Service Mesh?

Service Mesh 的概念最早是由 Buoyant 公司的 CEO William Morgan 在一篇文章里提出,他给出的服务网格的定义是:
A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学微服务》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(18)

  • oddrock
    集中式的方式就类似esb模式了,缺点就是:
    1、本地调用变成了远程调用,开销变大。
    2、无法采用iptables这样的拦截技术实现对服务的透明无感知的调用和转发。
    3、集中后可能存在网络和性能瓶颈。

    但这样做也不是一无是处,在一些对微服务治理平台的资源占用要求不能太多,且需要对微服务集中管控的情况下,是不是也可以尝试啊。

    作者回复: 确实,对一些规模较小的服务调用可以尝试,这时候有点类似nginx和slb的角色

    2018-11-06
    4
  • Switch
    sidecar代理模式本身定义就是作为轻量级代理,其一般是不支持高可用特性的。
    部署方式也是和应用程序一起部署在父容器中,提供一些支撑性 服务。

    作者回复: 嗯

    2018-11-06
    3
  • Cain
    一个sidecar有单点故障问题。那一个cp还是有单点故障问题啊?这个作者是怎么考虑的?
    2019-03-11
    2
  • lujg
    在现有的Istio模型中,sidecar是与服务共享网络配置,每个服务有一个单独的sidecar。那是否可能将side car部署为一个单一的pod,但是与服务处于同一node上,这样是否可以多个service 共享一个sidecar(并且由于处于同一node上网络延迟不会有明显增加)?请问一下为什么没有选择这种方案?
    2019-02-26
    1
  • 亚林
    集中部署起来风险太高,集中部署也就回到原来都老路上面去了,无法解决可用性问题
    2019-06-18
  • 花生
    有点类似区块链的本地簿记功能。每个单体解决各自的问题。
    2019-01-16
  • 文敦复
    Control Plane的作用怎么和企业服务总线这么相似?企业服务总线多了一个流量流转,而Service Mesh中请求是先通过CP选择后,由Sidecar自己调用,这点不同?

    作者回复: ESB吗?两者的作用差别很大啊

    2018-11-12
  • 文敦复
    Control Plane是一个集中式的处理单元,所有side car 共享他?每次调用都需要cp来做决断?

    作者回复: 监控、配额控制、安全都需要经过cp

    2018-11-12
  • 每天晒白牙
    就像大家所说的,一个sidecar有单点问题。同时sidecar与服务一同部署可以减去网络开销,如果都调用同一个sidecar增加了网络开销。

    作者回复: 确实

    2018-11-07
  • 爱吃回锅肉的瘦子
    第一点,是单点故障,第二点是为了实现负载均衡(个人猜想)第三点多个实例可以用来定位每一个服务?第四点不同实例可以针对性为该服务定制请求,第五点让不同系统不同的标准统一,方便调用。

    作者回复: 主要是因为单点故障和单点可能成为瓶颈

    2018-11-06
  • gen_jin
    回答老师的问题:1.有单点问题 2.多一跳有性能开销 3.配置麻烦

    作者回复: 正确

    2018-11-06
  • 三木子
    老师你看了github的事故说明后,有什么感想呢?

    作者回复: 数据库自动切主是个非常高危的操作,在生产环境中使用要非常谨慎

    2018-11-06
  • 陈华应
    一个sidercar存在单点故障隐患
    有时候需要对服务提供者或服务提供者进行个性化配置,一个sidercar不如多个sidercar方便
    集中部署sidercar更有可能出现性能瓶颈,如单个服务流量或者访问量巨大时会不会拖慢整体
    暂时只能想到这些不知道对不对的点

    作者回复: 是要考虑的几个因素

    2018-11-06
  • 松花皮蛋me
    service mesh是长连接的吗

    作者回复: sidecar之间通信可以保持长链接

    2018-11-06
  • echo_陈
    集中起来不就成了网关了嘛……
    不对,网关只关心入请求不能对发出的请求加工

    作者回复: 也有混合功能的网关,比如现在的openresty

    2018-11-06
  • 拉欧
    Service mesh要求sidecar是轻量级的代理,这表示sidecar不具备高可用特性,如果一个sidecar代理多个实例,就会出现单点问题,尤其在流量高峰期,一旦sidecar挂了,一群服务都不能用了。

    作者回复: 这是很重要的一个原因

    2018-11-06
  • LEON
    老师想问下Service mesh做负载均衡具体是如何实现的?如何保证每个pod链接是均衡的。是不是需要通过部署ingress给每个pod里的sidecar做负载均衡?

    作者回复: 通过sidecar发出请求时使用负载均衡算法

    2018-11-06
  • 欧嘉权Felix
    唯品会的service mesh实践也很优秀

    作者回复: 前几天看了江南白衣写的文章,也很不错

    2018-11-06
收起评论
18
返回
顶部