隔离太痛苦了决定学点感兴趣的东西。最近在看一些关于微服务的东西。
这几天在看一个极客时间上的老课，记一点看不懂+看得懂的笔记，基本是拿来当关键词搜索用的。课的地址课程目录。
1.数据库
- 微服务会拆分数据库，每个微服务对自己的数据库的数据做增删改操作。对于有关联关系的查询操作：一是可以冗余一些数据，或者建宽表，或通过es来进行；二是服务要提供粗粒度的查询接口（批量查询），而不是循环调用rpc。
2.服务的定义、服务的发布和订阅、服务的监控、服务的治理、故障的定位
3.拆分
- 建议的标准是按照每个开发人员负责不超过 3 个大的服务为标准，毕竟每个人的精力是有限的，所以在拆分微服务时，可以按照开发人员的总人数来决定。
- 性能聚类，性能要求高的并发大的和性能要求低的并发小的，要分开为不同的服务，这样部署和运行都独立，好维护。
4.跨服务事务的一致性问题(分布式事务)
- 简单的跨微服务间调用，TCC模式就可以了，如果是异步或长时间执行的调用事务，用SAGA模式。
TCC模式： TCC模式需要用户根据自己的业务场景实现 Try、Confirm 和 Cancel 三个操作；事务发起方在一阶段执行 Try 方式，在二阶段提交执行 Confirm 方法，二阶段回滚执行 Cancel 方法。（两阶段）
SAGA模式： 长事务解决方案。冲正。
1）Choreography（分布式的实现方式）：通过事件机制实现的，每个服务都监听自己所关心的事件，每个服务执行后会发送相应的事件，监听此事件的服务执行相应的处理逻辑。
2）Orchestration（集中式的实现方式）：是通过状态机来实现的整体控制，定义整体的处理流程，不同状态下需要触发的动作。
5.用户端监控（功能业务）、接口监控、资源监控（api依赖的资源，如redis）、基础监控（机器资源）。Prometheus、Dubbo、Flower。
6.服务发布和引用的那些坑
- 在一个服务被多个服务消费者引用的情况下，由于业务经验的参差不齐，可能不同的服务消费者对服务的认知水平不一，比如某个服务可能调用超时了，最好可以重试来提供调用成功率。但可能有的服务消费者会忽视这一点，并没有在服务引用配置文件中配置接口调用超时重试的次数，因此最好是可以在服务发布的配置文件中预定义好类似超时重试次数，即使服务消费者没有在服务引用配置文件中定义，也能继承服务提供者的定义。
7.K8S的服务注册
8.监控系统实现方案
- 日志监控推荐用ELK
- Metrics参数监控推荐用promethus+gafana
- 调用链监控推荐用skywalking
- 业务监控推荐用业务开发+gafana
9.服务调用失败都有哪些处理手段
超时：以 99.9% 或者 99.99% 的调用都在多少毫秒内返回为准。
重试
双发：P90，备份请求要设置一个最大重试比例，最大重试比例可以设置成15%。
熔断：服务调用失败的次数达到一定阈值，那么断路器就会被触发，后续的服务调用就直接返回，也就不会再向服务提供者发起请求了。
- （1）线程池隔离模式：使用一个线程池来存储当前的请求，线程池对请求作处理，设置任务返回处理超时时间，堆积的请求堆积入线程池队列。这种方式需要为每个依赖的服务申请线程池，有一定的资源消耗，好处是可以应对突发流量（流量洪峰来临时，处理不完可将数据存储到线程池队里慢慢处理）
- （2）信号量隔离模式：使用一个原子计数器（或信号量）来记录当前有多少个线程在运行，请求来先判断计数器的数值，若超过设置的最大线程个数则丢弃改类型的新请求，若不超过则执行计数操作请求来计数器+1，请求返回计数器-1。这种方式是严格的控制线程且立即返回模式，无法应对突发流量（流量洪峰来临时，处理的线程超过数量，其他的请求会直接返回，不继续去请求依赖的服务）
10.微服务容量规划（扩容计算）
多加一个冗余字段，标识这是压测数据，压测结束后清理就行了，或者数据本来就有标识。
数据库方面因为实现自动扩缩容的难度太大，我们目前是留有足够的冗余度，核心数据库都是4倍冗余
11.多机房部署
主从机房架构: 把所有的写请求都发给主机房，由主机房来负责写所有机房的缓存和本机房的数据库，而其他机房的数据库则通过 MySQL 的 binlog 同步机制实现数据同步。
独立机房架构: 联通和电信机房都有写请求，并通过一个叫 WMB 的消息同步组件把各自机房的写请求同步一份给对方机房，这样的话相当于每个机房都有全量的写请求。每个机房的处理机接收到写请求后更新各自机房的缓存，只有一个机房会更新数据库，其他机房的数据库通过 MySQL 的 binlog 同步机制实现数据同步。
数据一致性： 通过定时任务扫描es，通过比较不同机房相同requestid对应的处理状态，如果相同数据一致不做处理。如果不一致，进行重拾操作，达到一致。