微服务概述

目录

微服务概述

单体应用

学习微服务之前先看看看传统的单体应用

什么是单体应用

  • 所有的业务功能都在一个应用程序里面
  • 研发人员开发并维护同一个代码库
  • 架构简单,典型的三层架构

JHNAwd.png

随着业务的发展,访问量的不断增加,单体应用已经无法满足业务的需求,这个时候单体应用通常的解决方案是通过横向扩展来提高并发能力,如下:

JHU6bQ.png

单体应用的优缺点

优点:

  • 架构简单,容易上手
  • 部署简单,没有复杂的依赖
  • 测试方便,一旦部署,所有功能就可以测试

缺点:

  • 复杂度高,代码越来越庞大
  • 开发效率低,开发协作越来越麻烦
  • 牵一发动全身,任何一个功能出故障,可能系统就直接瘫痪了

微服应用

什么是微服务

  • 简单说就是微小的服务或应用,比如linux上的各种工具:ls,cat,awk等

  • 微服务就是让每个小的服务专注的做好一件事

  • 每个服务单独开发和部署,服务之间是完全隔离的

通过下面两个图来把微服和单体应用做对比

JH0ho4.png

相比于单体应用,微服务将单体应用的功能拆分未多个微小的服务,而服务与服务之间通过网络调用实现

微服务的优缺点

优点:

  • 迭代周期短,极大的提升开发效率
  • 独立部署,独立开发
  • 可伸缩性好,能够针对指定的服务进行伸缩
  • 故障隔离,不会相互影响

缺点:

  • 复杂度增加,一个请求往往要经过多个服务,请求链路比较长
  • 监控和定位问题困难
  • 服务管理比较复杂

落地微服务的关键因素

配套设施:

  • 微服务框架研发和维护
  • 打包,版本管理,上线平台支持
  • 硬件层支持,比如容易和容器调度
  • 服务治理平台支持,比如分布式链路追踪和监控
  • 测试自动化支持,比如上线前自动化case

组织架构

  • 微服务框架开发团队
  • 私有云研发团队
  • 测试平台研发团队

微服务生态

微服务层次换分:

  • 硬件层
  • 通信层
  • 应用平台层
  • 微服务层

硬件层

  • 物理服务器管理

  • 操作系统管理

  • 配置管理

  • 资源隔离和抽象

  • 主机监控和日志

硬件层架构:

JHhJAI.png

通信层

  • 网络传输
  • RPC(rpc客户端和rpc服务端)
  • 服务发现
  • 服务注册
  • 负载均衡
  • 消息传递

网络传输层

  • HTTP+RESTFUL:GET,POST,PUT,DELETE
  • TCP RPC 调用:Thrift,Dubbox, GRPC
  • 消息传递:JSON, Thrift, protobuf

服务注册与发现

分布式数据存储

  • Consul
  • Etcd
  • Zookeeper

CAP原理:

  • C: consistency, 一致性,每次总是能够读到最近写入的数据或者失败
  • A: available, 每次请求都能读到数据
  • P: partition tolerance 分区容忍,不管任意个消息由于网络原因失败,系统都能能够继续工作

CAP原理中,P是必须满足的,C,和A 可以根据业务需要选择,要么是CP系统,要么是AP系统

支撑平台

  • 私有云平台
  • 服务管理平台
  • 监控报警平台
  • 测试&构建&发布平台
  • 日志检索平台
  • 服务治理平台
  • Metrics平台