微服务概述

单体应用

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

什么是单体应用

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

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

单体应用的优缺点

优点：

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

缺点：

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

微服应用

什么是微服务

• 简单说就是微小的服务或应用，比如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平台