微服务概述
目录
目录
微服务概述
单体应用
学习微服务之前先看看看传统的单体应用
什么是单体应用
- 所有的业务功能都在一个应用程序里面
- 研发人员开发并维护同一个代码库
- 架构简单,典型的三层架构
随着业务的发展,访问量的不断增加,单体应用已经无法满足业务的需求,这个时候单体应用通常的解决方案是通过横向扩展来提高并发能力,如下:
单体应用的优缺点
优点:
- 架构简单,容易上手
- 部署简单,没有复杂的依赖
- 测试方便,一旦部署,所有功能就可以测试
缺点:
- 复杂度高,代码越来越庞大
- 开发效率低,开发协作越来越麻烦
- 牵一发动全身,任何一个功能出故障,可能系统就直接瘫痪了
微服应用
什么是微服务
-
简单说就是微小的服务或应用,比如linux上的各种工具:ls,cat,awk等
-
微服务就是让每个小的服务专注的做好一件事
-
每个服务单独开发和部署,服务之间是完全隔离的
通过下面两个图来把微服和单体应用做对比
相比于单体应用,微服务将单体应用的功能拆分未多个微小的服务,而服务与服务之间通过网络调用实现
微服务的优缺点
优点:
- 迭代周期短,极大的提升开发效率
- 独立部署,独立开发
- 可伸缩性好,能够针对指定的服务进行伸缩
- 故障隔离,不会相互影响
缺点:
- 复杂度增加,一个请求往往要经过多个服务,请求链路比较长
- 监控和定位问题困难
- 服务管理比较复杂
落地微服务的关键因素
配套设施:
- 微服务框架研发和维护
- 打包,版本管理,上线平台支持
- 硬件层支持,比如容易和容器调度
- 服务治理平台支持,比如分布式链路追踪和监控
- 测试自动化支持,比如上线前自动化case
组织架构
- 微服务框架开发团队
- 私有云研发团队
- 测试平台研发团队
微服务生态
微服务层次换分:
- 硬件层
- 通信层
- 应用平台层
- 微服务层
硬件层
-
物理服务器管理
-
操作系统管理
-
配置管理
-
资源隔离和抽象
-
主机监控和日志
硬件层架构:
通信层
- 网络传输
- 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平台