微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务于服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。
————摘自 马丁·福勒先生的博客
课程目录
微服务的te dian
微服务优点
转转交易平台的特点
整个项目的设计概要
整体架构
1.微服务网关层（HTTP）
维护海量链接，对身份进行校验，session管理，转发请求
2.微服务聚合层（RPC）
业务逻辑处理层， 将请求拆分成原子请求，并将原子请求回来的数据转化成用户需要的数据
3.微服务原子层（RPC）
提供某个微服务的增删改查，进行原子性操作
4.微服务数据层
对每个微服务进行数据持久化
5.轻量级通信
HTTP
RPC
6.去中心化管理
7.微服务注册
8.微服务发现
9.微服务配置中心
聚合层面里的问题
聚合层拆分原理
微服务聚合层再次拆分
再次拆分聚合层之后优点
轻量级通信协议
1、HTTP/HTTPS
2、RPC（Thrif, gRpc,dubbo）
SCF
私有协议
3、消息队列
4、HAL
转转的轻量级通信选择
微服务的发现和注册
spring cloud 对于zookeeper的支持不如对Eureka，Eureka更为完善
踢出bug服务器
因为微服务和注册中心是应用心跳来链接的，在某个心跳间隙的请求需要重制到其他服务器上 ，一般设置timeout，超时后直接重连另外的服务器
柔性可用的必要性
柔性可用的要求
防止系统崩溃的二种策略
数据库降级
系统降级
服务治理
微服务监控框架
监控手段
监控项