1.什么是微服务？
这里引用一下知乎老刘的图片和相关理解 https://www.zhihu.com/question/65502802/answer/802678798
网上超市：
引入了微信和APP端，进一步扩大
再次升级，把冗余的模块拿出来独立成为一个系统
细心的朋友可以发现，这时系统的瓶颈是数据库，所以再次升级改造，把数据库拆分并加入消息队列机制，商品服务和促销服务访问频率大因此加入了缓存机制
mq的作用
服务监控 ：
微服务架构虽然逻辑上看似完美，但也存在问题：
- 定点故障点非常困难
- 一个服务器故障可能导致其他服务器一起挂掉
- 部署和管理的工作量大
- 测试不便
所以为了解决问题：1.减少故障发生的概率 2.降低故障造成的影响，所以监控体系应运而生，系统实现思路是让各个组件报告自己当前状态，然后用一个指标采集器组件定时获取和保存各组件状态，同时可指定查询某组件当前的状态，最后这些数据用UI显示。这里拿商品服务的举例
链路跟踪：
一个用户的请求往往涉及多个内部服务调用。为了方便定位问题，需要能够记录每个用户请求时，微服务内部产生了多少服务调用，及其调用关系。这个叫做链路跟踪。我们用一个Istio文档里的链路跟踪例子来看看效果：
从图中可以看到，这是一个用户访问productpage页面的请求。在请求过程中，productpage服务顺序调用了details和reviews服务的接口。而reviews服务在响应过程中又调用了ratings的接口。整个链路跟踪的记录是一棵树及一个实现方案
日志监控：
当访问数变大、或服务器规模增多时，日志文件的大小会膨胀到难以用文本编辑器进行访问，更糟的是它们分散在多台服务器上面。排查一个问题，需要登录到各台服务器去获取日志文件，一个一个地查找（而且打开、查找都很慢）想要的日志信息。因此，在应用规模变大时，我们需要一个日志的“搜索引擎”。以便于能准确的找到想要的日志。常用日志分析组件：ELK（Elasticsearch、Logstash、Kibana）
- Elasticsearch：搜索引擎，日志存储
- Logstash：日志采集器，它接收日志输入，对日志进行一些预处理，然后输出到Elasticsearch
- Kibana：UI组件，通过Elasticsearch的API查找数据并展示给用户
EFK（Elasticsearch、Filbeat/Fluent、Kibana）：采用Fibeat或Fluent其中一种即可，俩中功能类似
- Filbeat：日志采集工具，是Logstash的优化版
- Fluent：日志采集工具
网关路由：
大量的服务，大量的接口，使得整个调用关系乱糟糟的。经常在开发过程中，写着写着，忽然想不起某个数据应该调用哪个服务。或者写歪了，调用了不该调用的服务，本来一个只读的功能结果修改了数据……为了应对这些情况，微服务的调用需要一个把关的东西，也就是网关，每次调用时进行权限校验。
熔断：
当一个服务因为各种原因停止响应时，调用方通常会等待一段时间，然后超时或者收到错误返回。如果调用链路比较长，可能会导致请求堆积，整条链路占用大量资源一直在等待下游响应。所以当多次访问一个服务失败时，应熔断，标记该服务已停止工作，直接返回错误。直至该服务恢复正常后再重新建立连接。
服务降级：
当下游服务停止工作后，如果该服务并非核心业务，则上游服务应该降级，以保证核心业务不中断。比如网上超市下单界面有一个推荐商品凑单的功能，当推荐模块挂了后，下单功能不能一起挂掉，只需要暂时关闭推荐功能即可。
限流：
一个服务挂掉后，上游服务或者用户一般会习惯性地重试访问。这导致一旦服务恢复正常，很可能因为瞬间网络流量过大又立刻挂掉，在棺材里重复着仰卧起坐。因此服务需要能够自我保护——限流。限流策略有很多，最简单的比如当单位时间内请求数过多时，丢弃多余的请求。另外，也可以考虑分区限流。仅拒绝来自产生大量请求的服务的请求。例如商品服务和订单服务都需要访问促销服务，商品服务由于代码问题发起了大量请求，促销服务则只限制来自商品服务的请求，来自订单服务的请求则正常响应。
新内容补充 ，引自：https://www.jianshu.com/p/7293b148028f
什么样的服务才算微服务呢？
- 单一职责的。一个微服务应该都是单一职责的，这才是“微”的体现，一个微服务解决一个业务问题（注意是一个业务问题而不是一个接口）。
- 面向服务的。将自己的业务能力封装并对外提供服务，这是继承SOA的核心思想，一个微服务本身也可能使用到其它微服务的能力
目前国内企业使用的微服务框架主要是Spring Cloud和Dubbo（或者DubboX），但是Dubbo那两年的停更严重打击了开发人员对它的信心，Spring Cloud已经逐渐成为主流
服务注册与发现：
应用微服务化之后，首先遇到的第一个问题就是服务发现问题，一个微服务如何发现其他微服务呢？最简单的方式就是每个微服务里面配置其他微服务的地址，但是当微服务数量众多的时候，这样做明显不现实。所以需要使用到微服务架构中的一个最重要的组件：服务注册中心，所有服务都注册到服务注册中心，同时也可以从服务注册中心获取当前可用的服务清单：
服务注册与发现可选择组件：Zookeeper、Eureka、Consul等
配置服务：
当服务数量超过一定程度之后，如果需要在每个服务里面分别维护每一个服务的配置文件，运维人员估计要哭了，那么就需要用有一个配置中心来管理服务的配置问题
3.SpringCloud