从0开始学微服务
胡忠想
微博技术专家
立即订阅
16289 人已学习
课程目录
已完结 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开始学微服务
登录|注册

03 | 初探微服务架构

胡忠想 2018-08-28
上一期我给你讲了什么时候应该进行服务化,以及服务化拆分的两种方式即横向拆分和纵向拆分,最后还提到了引入微服务架构需要解决的问题。
我想你一定很好奇微服务架构到底是什么样子的,接下来我们一起走进微服务架构,来看看它的各个组成部分
下面这张图是我根据自己的经验,绘制的微服务架构的模块图,在具体介绍之前先来看下一次正常的服务调用的流程。
首先服务提供者(就是提供服务的一方)按照一定格式的服务描述,向注册中心注册服务,声明自己能够提供哪些服务以及服务的地址是什么,完成服务发布。
接下来服务消费者(就是调用服务的一方)请求注册中心,查询所需要调用服务的地址,然后以约定的通信协议向服务提供者发起请求,得到请求结果后再按照约定的协议解析结果。
而且在服务的调用过程中,服务的请求耗时、调用量以及成功率等指标都会被记录下来用作监控,调用经过的链路信息会被记录下来,用于故障定位和问题追踪。在这期间,如果调用失败,可以通过重试等服务治理手段来保证成功率。
总结一下,微服务架构下,服务调用主要依赖下面几个基本组件:
服务描述
注册中心
服务框架
服务监控
服务追踪
服务治理
接下来,我来为你一一介绍这些组件。

服务描述

服务调用首先要解决的问题就是服务如何对外描述。比如,你对外提供了一个服务,那么这个服务的服务名叫什么?调用这个服务需要提供哪些信息?调用这个服务返回的结果是什么格式的?该如何解析?这些就是服务描述要解决的问题。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学微服务》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(36)

  • michael
    老师,服务追踪中,为什么各服务层需要生产自己的requestid,只使用客户端生成的requestid在各层传递不行吗?
    2018-08-28
    4
    46
  • oddrock
    微服务架构下要解决的服务描述、服务注册与发现、服务框架、服务监控、服务跟踪、服务治理其实在soa下基本都同样存在。
    soa下服务描述用wsdl,服务注册与发现用uddl,服务框架、服务监控和服务跟踪、治理基本都依赖esb,治理还要部分依赖负载均衡。
    同样情况在单体简单的多,服务描述就是api,服务注册与发现就是引用jar,监控、跟踪、治理在单体情况下基本不存在,最多用jvm监控工具来监控

    我的理解如上,还请老师指正

    作者回复: 看来对soa很了解

    2018-08-28
    45
  • 王宏达达达
    老师,微服务和分布式的区别到底在哪里呢?
    2018-08-29
    18
  • zhihai.tu
    微服务架构6大组件:
    1、服务描述:RestfulApi (http)、xml (rpc)、IDL (grpc)
    2、注册中心:注册(服务提供者->注册中心)、订阅(服务消费者->注册中心)、返回(注册中心->服务消费者)、通知(注册中心->服务消费者)
    3、服务框架
    4、服务监控(发现问题):指标收集、数据处理、数据展现
    5、服务追踪(定位问题):RequestId传递
    6、服务治理(解决问题):单机故障——自动摘除、单IDC故障——自动切换、依赖服务不可用——熔断
    2019-04-26
    13
  • 5ispy
    阿忠老师终于提到自动扩容,后面会细讲吗?这是不是支持8对明星并发出轨的关键🤪

    作者回复: 后面有一节会讲混合云下的微服务架构

    2018-08-28
    13
  • XuToTo
    看到一位同学讨论到 http 和 rpc,我的理解是,其实 http 服务从某种程度上来说也算 rpc,之所以不使用 http 来做内部 rpc,我想有一部分原因是 http 包含了冗余的信息,并不适用于内部高效的 rpc,像是 gRPC 这样的都会利用 protocol buffer 来最大限度减少序列化后传输信息的大小。
    2018-08-28
    10
  • 努力的小斌
    问requestID,大家可以看一下Google Dapper那篇论文
    2018-08-30
    6
  • vick
    服务故障问题在传统架构中的解决方式,一般是远程调用时要做超时处理,很多http client的第三方包都提供timeout的处理。同理微服务架构下的熔断机制相比之下有哪些优势,期待后面教程的分析。
    2018-09-01
    5
  • godtrue
    阅后感
    个人感觉理解微服务的关键环节在于理解网络通信,最简单的微服务,比如:只有一个服务提供者也只有一个服务消费者,只要他们能通信相互理解就行。
    深入了理解他们通信的原理,其他的都是在机器增多,考虑网络环境的复杂多变,提供负载均衡、高可用、高性能、易维护、易定位问题、支持水平扩展的外围服务,是分布式系统都需要考虑的问题啦。

    希望后面能看的老师讲解这些,否则感觉就不是由浅入深层层推进的讲解方式了,理解起来令人费解。

    一个东西从无到有基本是有一个变化和积累的过程的,如果能清楚他不存在前会有什么痛点,他出现后解决了那几点痛点,那是很爽快的。当然一个技术方案在解决一些问题的同时总会带来另外的一些更加复杂的问题,希望后面老师能有所讲解。

    我觉得微服务的组成从核心一层层往外应该有以下组件组成:
    1:网络通信框架,什么协议?如何序列化和反序列化?
    2:服务协议,使用通用的?还是开源?还是自研?
    3:服务注册中心,订阅和发布服务信息
    4:服务治理平台,监控服务信息,管理服务信息,上下线服务,查看服务所属,查看服务调用链

    感谢老师的讲解,期待下文!
    2019-05-17
    4
  • Final不基
    我们用spring cloud微服务框架。zipkin做链路监控,有办法链路到jdbc 数据库层么?

    作者回复: zipkin不支持,skywalking可以

    2018-11-13
    4
  • 大光头
    微服务下的问题在单体应用会有,但不是问题,因为天生满足。分布式之后,
    接口调用,就需要服务发现,服务注册和服务间调用。
    接口错误需要容错处理和熔断处理。
    接口性能,需要靠扩容。
    接口调用情况需要监控。
    问题排查需要全链路跟踪。
    2018-08-30
    3
  • Halo_浅色调
    为啥要两个requestId,我们以前就只用了一个来进行链路追踪,只用一个有啥缺陷吗

    作者回复: 一个requestid,一个是spanid,这里是为了描述原理抽象表达这个意思

    2018-08-29
    3
  • 猿一代
    c502和1999992,老师,今天微博热搜赵丽颖和冯绍峰结婚的消息报出来的分别是什么原因呀?
    2018-10-16
    2
  • greatcl
    如果服务提供者继续请求其他服务,会在本地再生成一个自己的requestid,然后把这两个requestid都当作请求参数继续往下传递。
    =========
    老师你好,想问下为什么要两个requestid都往下传递呢,只用第一个requestid不是就可以追踪到了吗?

    作者回复: 这里没有详细描述 其实是spanid 这里是抽象描述原理

    2018-08-28
    2
  • 贾洵
    既然设置一个跟踪ID,为什么不设置一个uuid做为调用唯一ID。这样既可以全程跟踪,又节省寻找串联请求ID的时间?

    作者回复: uuid没法区分调用的层级关系

    2018-11-05
    1
  • 70
    服务描述,注册中心,服务框架,服务监控,服务追踪,服务治理。这些在单体服务中也存在,服务描述在任何时候都需要。注册中心和服务框架在单体服务中可能没有那么明显,单体服务中多数采用人为沟通和文档进行维护。服务监控和服务追踪,服务治理,这些部分的存在,可以让我们实时监控服务的运行状态,及时发现并解决问题,单体和微服务都是无法缺失的。在面对服务容量问题时,单体服务解决起来更加麻烦,由于没有服务拆分,所以需要根据所有业务中最小容量业务来进行计算扩容。哈哈,个人拙见,阿忠叔别生气
    2018-08-28
    1
  • eason2017
    在复杂调用中,应该还有熔断,这样避免底层服务拖死自身服务,对吧~

    作者回复: 嗯,熔断是一种非常有效的服务治理手段

    2018-08-28
    1
  • eason2017
    看到dubbo的影子了,嘎嘎
    2018-08-28
    1
  • feimeng0532
    单体应用的集群方式和微服务的治理,单体故障转移,
    2018-08-28
    1
  • 钟杰
    服务聚合和服务网关呢?
    2019-10-23
收起评论
36
返回
顶部