了解什么是微服务
参考：https://www.cnblogs.com/skabyy/p/11396571.html
一）、原有单体服务的弊端
场景演示：
需求：小明和小皮一起创业做网上超市 的故事
功能：
网站
- 用户注册、登录功能
- 商品展示
- 下单
管理后台
- 用户管理
- 商品管理
- 订单管理
二）、业务拓展：
- 网站系统增加促销活动功能
- 增加移动设备：微信小程序，移动App(移动设备的功能和网站的功能相同)，
- 在后台系统添加促销管理和数据分析
- 四个系统共用一个数据库
业务扩展后架构出现的弊端;
1.网站和移动端应用有很多相同业务逻辑的重复代码
2.数据有时候通过数据库共享，有时候通过接口调用传输。接口调用关系杂乱
3.数据库表结构被多个应用依赖，无法重构和优化
4.所有应用都在一个数据库上操作,数据库性能急剧下降
5.开发、测试、部署、维护愈发困难, 即使只改动一个小功能，也需要整个应用一起发布 ,
三）、微服务的特点：
抽象：抽象出公用的业务能力，做成几个公共服务
解决了各应用间数据库的共用问题：一个服务对应一个数据库
数据库拆分产生的问题和挑战 ：跨库级联的需求
四）、日志排查
原有单体系统的日志排查：查看日志，研究错误信息和调用堆栈
在微服务架构中，一个服务故障可能会产生雪崩效用，导致整个系统故障
五）、微服务的弊端
1.微服务架构整个应用分散成多个服务，定位故障点非常困难
2.稳定性下降，一个服务出现故障 ，可能导致整个系统挂掉
3.服务数量非常多，部署、管理的工作量很大
4.如何保证各个服务在持续开发的情况下仍然保持协同合作
5.原本单个程序的测试变为服务间调用的测试。测试变得更加复杂
六）、如何进行故障处理：
减少错误：事前监控，事后分析
降低影响：容错，服务降级
建立完善的监控体系
微服务架构中组件繁多 ,各个组件所需要监控的指标不同 ,做一个大而全的监控系统来监控各个组件是不大现实的
例如：Redis缓存监控的指标有占用内存值 ，网络流量 ，数据库监控连接数 ，磁盘空间 ，业务服务监控并发数，响应延迟、错误率等
如何实现监控：
1.各个组件提供报告自己当前状态的接口（metrics接口）
2.接口输出的数据格式一致
3.部署一个指标采集器组件，定时从这些接口获取并保持组件状态，提供查询服务
4.需要一个UI ，从指标采集器查询各项指标 ，绘制监控界面 或 根据阈值发出告警。
例如：Redis缓存和MySQL数据库的指标接口：RedisExporter和MySQLExporter （网上有开源组件）
使用采用Prometheus作为指标采集器
六）、链路跟踪
什么叫链路跟踪？
一个用户的请求往往涉及多个内部服务调用
链路跟踪 ：记录每个用户请求 ，记录微服务内部产生了多少服务调用，及其调用关系
实现链路跟踪：
1）、服务调用要在HTTP的HEADERS中记录至少四项数据
1.traceId ：标识一个用户请求的调用链路，具有相同traceId的调用属于同一条链路
2.spanId ：标识一次服务调用的id
3.parentId : 父节点的spanId
4.requestTime & responseTime : 请求时间和响应时间
2）、调用日志收集与存储的组件，以及展示链路调用的UI组件
链路跟踪的实现过程：
使用HTTP请求的拦截器，在每次HTTP请求时生成这些数据注入到HEADERS，同时异步发送调用日志到Zipkin的日志收集器中
链路跟踪只能定位到哪个服务出现问题 ，查找具体的错误信息的能力则需要由日志分析组件来提供
日志分析
ELK（Elasticsearch、Logstash和Kibana ）日志分析组件：
Elasticsearch：搜索引擎，同时也是日志的存储
Logstash：日志采集器，它接收日志输入，对日志进行一些预处理，然后输出到Elasticsearch
Kibana：UI组件，通过Elasticsearch的API查找数据并展示给用户
日志分析过程：
日志输出到文件------》每个服务里再部署个Agent，扫描日志文件 -------》输出给logstash