从0开始学微服务学习笔记

本文详细介绍了微服务的概念,从单体应用的局限性出发,阐述了服务化、微服务的优势。深入探讨了从单体迁移到微服务过程中遇到的问题,包括服务定义、发布、监控、治理等方面。讲解了微服务架构的基本组件,如服务描述、注册中心、服务框架和服务监控。此外,还涵盖了服务注册与发现、RPC远程调用、服务追踪、服务治理手段、负载均衡算法、服务路由实践、服务故障应对策略等内容,以及如何通过容器化和DevOps实现微服务的落地。最后,文章讨论了Service Mesh,特别是Istio的实现与微博的Service Mesh实践。
摘要由CSDN通过智能技术生成

1到底什么是微服务

  • 单体应用
    • 部署效率低
    • 团队协作开发成本高
    • 系统高可用性差
    • 线上发布变慢
  • 什么是服务化
    • 单体应用中通过jar包依赖产生的本地方法调用,改成通过RPC远程方法调用
  • 什么是微服务
    • 服务拆分力度更细
    • 服务独立部署
    • 服务独立维护
    • 服务治理能力要求高
      #2单体走向微服务#
  • 单体迁移到微服务遇到的问题?
    • 服务如何定义
    • 服务如何发布与订阅
    • 服务如何监控
    • 服务如何治理
    • 故障如何定位
      #3微服务架构#
  • 基本组件
    • 服务描述
      • 服务如何对外描述?
      • 服务名叫什么?
      • 调用这个服务需要提供哪些信息?
      • 调用这个服务返回的结果是什么格式的?
      • 该如何解析?
    • 注册中心
      • 解决服务的发布与订阅
        • 提供者登记
        • 消费者获取地址 发请求
    • 服务框架
      • 服务通信采用什么协议?
      • 数据传输采用什么方式?
      • 数据压缩采用什么格式?
    • 服务监控
      • 指标收集
      • 数据处理
      • 数据展示
    • 服务追踪
      • 服务调用情况
    • 服务治理
      • 单机故障
      • 单IDC(互联网数据中心)故障
      • 依赖服务不可用
        #4如何发布与引用服务#
  • 方式
    • restful api
      • 跨语言
    • xml
    • idl文件
      • 跨语言平台调用
      • Thrift协议
      • gRPC协议
        #5如何注册与发现服务#
  • 注册中心原理
    • 服务提供者RPC server
    • 服务消费者 RPC Client
    • 服务注册中心 Registry
  • 注册中心实现方式
    • 注册中心API
      • 服务注册接口
      • 服务反注册接口
      • 心跳汇报接口
      • 服务订阅接口
      • 服务变更查询接口
    • 集群部署
      • 集群部署保证高可用性
      • 分布式一致性保证数据一致性
    • 目录存储
    • 服务健康状态监测
    • 服务状态变更通知
    • 白名单机制
      #6如何实现RPC远程服务调用#
  • 服务消费者
    • 客户端
  • 服务提供者
    • 服务端
  • 调用过程
    • 成一次 RPC 调用,就必须先建立网络连接。建立连接后,双方还必须按照某种约定的协议进行网络通信,这个协议就是通信协议。双方能够正常通信后,服务端接收到请求时,需要以某种方式进行处理,处理成功后,把请求结果返回给客户端。为了减少传输的数据大小,还要对数据进行压缩,也就是对数据进行序列化
  • 客户端和服务端如何建立网络连接?
    • HTTP通信
      • 基于TCP/IP协议
    • Socket通信
      • 运行于客户端 clientSocket
      • 运行于服务端 serverSocket
      • 步骤
        • 服务器监听
          • serverSocket bind()绑定端口,调用listen()实时监控网络状况,等待客户端的连接请求
        • 客户端请求
          • clientSocket connect()函数 向serverSocket绑定的地址端口发起请求
        • 连接确认
          • 服务端监听或收到客户端的连接请求时,调用accept()响应客户端请求,并建立连接
        • 数据传输
          • 建立连接后,客户端调用send() 服务端调用receive()函数,服务端处理完请求后,服务端调用send()客户端调用recevice()得到返回结果。
      • 异常情况
        • 链路存活检测
          • 客户端定时发送心跳检测给服务端,连续N次或者超出规定时间没有回复则认为链路已经失效
        • 断连重试
          • 等待固定时间发起重连
  • 服务端如何处理请求?
    • 同步阻塞BIO
    • 同步非阻塞NIO
    • 异步非阻塞AIO
    • 建议采取业界开源框架 Netty Mina
  • 数据传输采用什么协议?
    • Http协议
    • Dubbo协议
  • 数据该如何序列化和反序列化?
    • 编码与解码就是序列化与反序列化
    • 常见序列化方式
      • 文本类
        • xml
        • json
      • 二进制
        • PB
        • Thrift
    • 使用考虑因素
      • 支持数据结构的丰富程度
      • 跨语言支持
      • 性能{压缩比与序列化速度}
        #7如何监控微服务调用#
  • 监控的对象是什么?
    • 用户端监控
    • 接口监控
    • 资源监控
    • 基础监控
  • 具体监控哪些指标?
    • 请求量
      • 实时请求量QPS 每秒查询次数
      • 统计请求量PV 一段时间内用户访问量
    • 响应时间
      • P99=500ms 意思是 99% 的请求响应时间在500ms以内,它代表了请求的服务质量,即 SLA。
    • 错误率
      • 一段时间内调用失败的次数占调用总次数的比率来衡量
  • 从哪些维度进行监控?
    • 全局维度
    • 分机房维度
    • 单机维度
    • 时间维度
    • 核心维度
      • 核心与非核心部署隔离,分开监控
  • 监控系统原理
    • 数据采集
      • 分类
        • 服务主动上报(代码中加入收集逻辑)
        • 代理收集(日志文件–>解析–>上报)
      • 考虑点
        • 采样率 采集数据的频率
        • 动态采集
    • 数据传输
      • 传输方式
        • UDP
        • Kafka
      • 数据格式十分重要
        • 二进制协议
          • 最常用的就是 PB 对象,它的优点是高压缩比和高性能,可以减少传输带宽并
            且序列化和反序列化效率特别高
        • 文本协议
          • 最常用的就是 JSON 字符串,它的优点是可读性好,但相比于 PB 对
  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
序言 自从Martin Fowler对微服务作出定义之后,微服务便火遍大江南北, 网上出现很多文章来描述它的好处,也有很多文章来说明它的弊端。这便 让很多小伙伴无所适从,微服务究竟是什么,要不要使用微服务架构,怎 么实施微服务架构?我一直认为,微服务架构只是新瓶装老酒,这老酒就 是模块化。如果在做系统设计时,已经把模块化做得很好,转型微服务只 是顺理成章的事。如果模块化都做不好,转型微服务只会带来灾难。 2014 年底,我们团队意识到 Docker 技术可以帮我们大幅度提高软 件产品的性能,降低硬件的投入,提高运维效率,便开始着手研发基于 Docker 的 PaaS 平台。随后,很快发现,PaaS 平台只是解决了软件生命周 期后半部分(运维)的问题,就思考能否通过 Docker 技术来提高开发团 队的效率。例如,降低团队成员流动带来的风险,提高多团队协作的效率, 找到组件或知识积累的方法,让同一个软件产品能够适应不同客户的定制 化需求,等等。从此,就与微服务结下了不解之缘。这些目标确定后,通 用的PaaS平台的研发目标也就变成了解决以上问题的微服务平台的研发, 以及后来的青柳云平台本身的微服务化的实践。 在做微服务架构技术选型的时候,我们以“无侵入”和“社区活跃” 为最主要的考量点,也只有这样,将来在升级为原子服务架构、量子服务 架构的时候,甚至是恢复成单体架构的时候,代价才是最小的。所以,在 3 InfoQ 中文站 为数不多的可选项中,我们拥抱了 Spring Cloud。最后的结果就是使用 基于 Docker 的微服务平台进行开发和运行运维支撑,使用 Spring Cloud 进行业务系统开发,两者相互独立,并可被独立替换。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值