从0开始学微服务（二） --- 2020年04月
各种框架的选型
1、注册中心选型
注册与发现有解决方案有两种：
1）、应用内注册与发现的方式，最典型的是 Eureka 注册中心。
Eureka 主要三个组件：Eureka Server 实现服务信息注册、存储、查询，Eureka Client 集成在服务端的注册中心 SDK，实现服务注册、反注册，以及服务订阅、服务更新等功能。
2）、应用外注册与发现的方式，有 Consul、Nacos。
Nacos 有一个简单 UI 的客户端，实现服务注册信息的存储，以及各种参数的配置。
Nacos 支持基于 DNS 和基于 RPC 的服务发现。
Nacos 对服务进行实时的健康检查，阻止向不健康的主机或服务实例发送请求。支持传输层(TCP)和应用层(HTTP、MySQL)的健康检查。
提供了 agent 主动上报和服务端主动检测两种健康检查模式。
可以在配置变更时，不需要重新部署应用和服务，让配置的管理变的更加高效和敏捷。
动态 DNS 服务支持权重路由，可以实现中间层负载均衡、更灵活的路由策略、流量控制以及数据中心你给我的简单 DNS 解析服务。
容器化的云应用更适合应用外的注册中心，避免侵入业务。
注册中心需要考虑 高可用性(集群部署、多 IDC 部署)、一致性。
2、开源 RPC 框架选型
RPC 框架主要的三部分：通讯框架、通信协议、序列化和反序列化格式。
跟语言平台帮顶的开源 RPC 框架，Dubbo 支持 Java 语言，SpringCloud 也是。
1）、Dubbo
Dubbo 的服务消费和服务提供者都需要引入 Dubbo 的 SDK 才能完成 RPC 调用。
Dubbo 默认采用 Netty 作为通信框架，支持 Dubbo、RMI、HTTP、Hession 等协议，支持 Json .Dubbo、Hession 等序列化格式。
2）、SpringCloud
已学。
3、搭建监控系统
监控涉及到 数据收集、数据传输、数据处理、数据展示。
ELK (Elasticsearch、Logstash、Kibana)
分别是数据处理，数据收集、传输，数据展示的是三个工具。因为 Logstash 要在各个服务器上部署，比较消耗 CPU 和内存，所以引入了 Beats 来作为数据收集器，把数据收集到后发送到 Logstash。
4、服务跟踪系统 (后期学习后补上)
OpenZipkin
Pinpoint
5、识别服务节点的存活 (服务治理)
1）、心跳开关保护机制
在网络频繁抖动的时候，服务消费者不至于一直因为得知服务提供者的变动，而一直去请求注册中心获取最新的服务节点信息。
2）、服务节点保护机制
服务提供者会每隔一段时间像注册中心汇报心跳。如果超出时间没有汇报，则注册中心摘除该节点。(SpringCloud 中的默认心跳时间是30s )
但是服务频繁抖动时，可能摘除的节点过多，则剩下的节点难以承受所有的调用，引起 雪崩。
可以设置一个阈值比例，超过阈值，则注册中心不能摘除节点。
3）、静态注册中心
可以服务消费者直接调用服务提供者是否成功，如果连续失败超过一定次数，就在本地内存中标记该节点为不可用。每隔一段时间，消费者都像不可用的节点发起保活探测。（这样就不需要心跳机制与摘除机制）（有点去中心化）
6、负载均衡算法
1）、随机算法
服务节点的性能差异不大的情况下。
2）、轮询算法
同随机算法的应用场景差不多。
3）、加权轮询算法
不同的节点的权重不同，则访问的权重也不同。应用于性能节点不同的服务器的场景。
4）、最少活跃连接算法
服务端节点性能差异较大时。
5）、一致性 hash 算法
同一个来源的请求，只会
映射到一个节点上。相当于记忆功能。
6）、自适应最优选择算法
复杂的情况。
7、如何使用服务路由 (以后再学习加深理解)
服务消费者在发起服务调用时，必须根据特定的规则来选择服务节点，从而满足某些特定的需求。
应用场景：
分组调用，多个数据中心，部署在不同的机房或云上。
灰度发布，先小范围部署，再大范围部署。
流量切换，将调用该机房服务的流量切换到其他正常的机房。
读写分离，读接口部署在一起，写接口部署在其他节点。
8、服务端出现故障怎么办
集群故障、单 IDC 故障、单机故障。
集群故障：限流降级。
限流：限制流量，给系统设置一个阈值，超过阈值的请求自动放弃。
降级：停止系统中的某些功能，来保证系统整体的可用性。
单 IDC 故障：脱网，流量切换。基于 DNS 解析的流量切换，还有基于 RPC 分组的流量切换。
单机故障：自动重启，设置一个阈值，当某个接口的平均耗时超过一定阈值，就重启。
9、服务调用失败的处理手段
超时：避免依赖的服务迟迟没有返回调用结果，把服务消费者拖死。
重试：再一次发起请求，主要注意到幂等性。
双发：同时2次请求。
熔断：短时间关闭服务提供，给故障时间恢复，再重新请求。三种状态，关闭、打开、半打开。一段时间的服务调用的失败率高于设定的阈值后，断路器进入打开。过一段时间后，断路器半打开。当请求能成功时，就打开。不成功，就再过一个周期重新请求。
10、管理服务配置
1）、可以把配置当做代码等同看待，岁应用程序一起发布。
2）、抽离到单独的配置文件中，与代码分离。
但是还有更好的方案，配置中心。
配置中心：配置注册功能、反注册功能、查看功能、变更订阅功能。
11、容器化
镜像仓库：有一个集中存储的地方，把镜像存储在这里，服务发布的时候，各个服务器都访问这个集中存储来拉取镜像，然后启动容器。
1）、权限控制
哪些用户可以拉取镜像，哪些用户可以修改镜像。
2）、镜像同步
当镜像同时发布到几十几百台集群节点上，就需要多个镜像仓库实例来做负载均衡。
一个方案是一主多从，主从复制。
3）、高可用性
多 IDC 部署。
容器调度：
1）主机过滤：存活过滤、硬件过滤。
2）调度策略：解决容器创建时选择哪些主机最合适。
服务编排：
服务依赖、服务注册、自动扩缩容。
12、微服务实现 Devops
1）持续集成阶段：代码检查、单元测试、集成测试。
2）持续交付阶段：类生产环境线上拆除节点，接入新版本后，观察服务是否正常。
3）持续部署阶段：代码自动发布到线上的所有节点中去。
13、微服务容量如何规划
一是评估集群的最大容量和线上实际运行的负荷（如何做好容量评估）；
二是如何确定弹性扩缩容的时机以及机器数（如何做好调度决策）；
多机房部署：
负载均衡、数据同步、一致性。
1）、一个主机房用来写，将该写同步写到其他机房的缓存中。数据库通过 binlog 机制同步数据。但是如果主机房 down 掉，则会影响整体业务。
2）、独立机房架构，用 WMB 消息同步机制同步缓存，数据库还是用 binlog 同步数据。
WMB 机制是将一个机房的写请求发送给另一个机房。reship 负责把本机房的写请求分发一份给别的机房。collector 负责从别的机房读取写请求，然后把请求转发给本机房的处理机。
WMB 一是通过 MCQ 消息队列，一种是通过 RPC 调用。
混合云部署：
1）、需要打通私有云和阿里云之间的网络连接，用跨云专线。
2）、只是将缓存部署在公有云上，并没有将隐私数据库部署在公有云。
14、一些疑问点
1）、微服务的拆分粒度、拆分方式。
结合开发人员的多少，以及服务的依赖性，可以拆分为多个独立的微服务，实现开发的解耦。
可以根据服务的关联度，或者数据库隔离维度进行拆分。（一般是两种方式进行结合）
但是首先先进行稍微大粒度的拆分，业务验证稳定后，再逐步进行细化的服务拆分。（互联网项目）
2）、数据处理的实时操作，服务追踪
第一个场景是快读定位线上服务问题。经过链路上的多个环节，如果请求过慢，就需要将服务追踪收集到的每个环节的调用数据，进行实时聚合，计算每个环节的平均耗时和接口成功率。这样一览监控就可以快速定位问题。
第二个场景是定位某一次用户请求失败的原因。需要根据用户的 traceId 和 spanId，把一次用户经过的各个环节的服务调用串联起来，找出调用的上下文，最终可以找到在哪一层发生了错误。
3）、清除僵尸节点、优化反注册
服务缩容，第一步调用注册中心的反注册接口把节点从服务节点列表删除，第二步是回收服务器，把节点从服务池列表中删除。第一步失败第二步成功，就存在僵尸节点。可以对比服务池的节点列表与注册中心的节点列表，然后删除僵尸节点。
