一、微服务
了解基本概念：分布式、集群、微服务…
分布式：把一个应用拆成几个应用部署到不同的机器上
集群：同一个应用部署到不同的机器上
微服务：比分布式拆分应用的颗粒度更细，拆分为单个的服务，比如用户服务、短信服务…
1.微服务架构
2.微服务组件
SpringCloud 核心组件：Netflix Eureka、Spring Zuul/Gateway、Feign、Ribbon、Hystrix、Stream、Config、Sleuth
2.1 配置中心
常用做配置中心的组件：db、file、git、apolloconfig、consul、etcd3、nacos、zk
| 名称 | 核心 | 优劣 |
|---|---|---|
| db | 将配置信息存于数据库中 | 多连接，共享，受限于数据库 |
| file | 存于本地文件中 | 多服务需要多拷贝，修改麻烦 |
| git | 共同维护配置仓库 | 通过分支区分各环境（SpringCloud官网） |
| apolloconfig | 数据库、本地文件 单独部署服务、依赖Eureka 、Java |
设计 Namespace 与SpringCloud 很好衔接，支持事件驱动 可通过UI页面配置 |
| consul | go语言开发的服务注册、配置组件 支持http和dns协议， 采用http api 注册、配置 |
支持Service Mesh 桥接服务网格与传统网络 … |
| etcd3 | 高可用KV存储系统， 用于分享配置,服务发现 |
k8s 中来维护服务状态信息， 支持curl 等方式，写速度快 使用 Raft 实现分布[式 |
| nacos | ali开源发现、配置、管理服务 | 架构 有UI界面，可通过UI页面配置 |
| zk | 对元数据管理、leader选举 | 大数据中协助服务（选举）、 kafka中选举leader 无UI配置页面 |
Seata config 分析 github、Seata config 分析 gitee
2.2 注册中心
常用的服务发现：file、zk、redis、nacos、eureka、consul、etcd3、sofa
| 名称 | 核心 | 优劣 |
|---|---|---|
| file | 存储、读取、比较 | 共享文件 |
| zk | Znode的引用方式是路径引用、CA | 无UI |
| redis | 基于订阅与发布 | |
| nacos | ConcurrentHashMap、 file、事件 支持AP/CP模式 |
社区活跃 |
| eureka | 3级缓存、instanceId、 applicationName、ip+port、 ConcurrentHashMap<String, Map<String, Lease appName，也就是服务名， 内层map的key是instanceId、AP模式（最终一致性） |
SpringCloud官网、停止维护 |
| consul | go语言开发、CA 强一致性 | |
| etcd3 | 高可用KV存储系统， 用于分享配置,服务发现 Raft强一致性算法的具体实现 |
CoreOS、Kubernetes和CloudFoundry 等知名项目均在生产环境中使用了etcd |
| sofa | https://github.com/sofastack | 金融级云原生架构的中间件 |
2.3 网关
| 名称 | 核心 | 优劣 |
|---|---|---|
| SpringCloud Zuul | Filter | 同步/受线程数限制（Tomcat) |
| SpringCloud GateWay | Reactor/Netty | 异步 |
| Kong |
2.4 服务间调用
| 名称 | 核心 | 优劣 |
|---|---|---|
| Feign | Netflix、声明式伪Http 基于Feign注解 和 JAX-RS注解 整合了ribbon，具有负载均的能力 整合了Hystrix，具有快速熔断的能力 通过服务名调用 |
轮询、客户端做负载算法 spring-cloud-provider.ribbon. NFLoadBalancerRuleClassName =com.netflix.loadbalancer. RandomRule 可配置 |
| Http | 1.http调用 具有标准语意的通用接口定向资源， 2.基于http协议;如果基于http1.0 协议，包含很 多无用内容;如果基于http2.0,则报文体积小很多 3.一般用json传输，字节大小、序列化耗时比thrift高 4.需要配置nginx、HAProxy来实现负载 5.需要事先通知，修改nginx、 HAProxy配置(异常页面） |
浏览器接口调用 APP接口调用 第三方接口调用 主要用于对外异构环境 |
| Rpc | 1.一般远程过程调用,基于tcp或http协议， 2.可自定义tcp协议，可以让报文体积更小. 标准的RPC框架更多的是服务治理 3.基于thrift实现高效二进制传输 4.一般自带负载均策略，可基于客户端重写 5.能够自动通知，不影响上游，达到服务治理效果 |
主要用于公司内部服务调用 性能消耗低，传输效率高 服务治理方便 |
| gRpc | google RPC调用，Protobuf+gRPC | 降低耦合度 |
| Ribbon | RestTmeplate实现 | @LoadBalanced |
2.5 负载均衡算法
| 名称 | 核心 | 优劣 |
|---|---|---|
| 轮询 | 交替访问 | 正常情况 |
| hash | 基于ip、url等只设置hash值 引流到不同的服务 |
服务比较多 |
| weigh | 针对服务设置权重 比如引流到访问量少的服务， 提高服务访问量 |
最好能手动设置 即时生效 |
| 最少时间 | 引流到响应特别快的服务 | 缓存各个信息 |
可参考Nginx负载均衡
2.6 限流
| 名称 | 核心 | 优劣 |
|---|---|---|
| 计数器 | 在一段时间间隔内（时间窗/时间区间）， 处理请求的最大数量固定，超过部分不做处理 |
量大时会忽略很多请求 指定线程池大小，指定数据库连接池大小、 nginx连接数等,这都属于计数器算法 |
| 漏桶 | 漏桶大小固定，处理速度固定， 但请求进入速度不固定 |
在突发情况请求过多时， 会丢弃过多的请求 |
| 令牌桶 | 令牌桶的大小固定，令牌的产生速度固定， 但是消耗令牌（即请求）速度不固定 |
RateLimiter |
| Sentinel | 流量卫兵（信号量） | 开箱即用、社区活跃、控制台管理等等 |
| Hystrix | 线程池隔离/信号量隔离 | 不完善 |
限流：计数器、漏桶、令牌桶 三大算法的原理与实战（史上最全）
2.7 消息中间件
一种接收数据、存储数据、转发数据的网络应用。
协议、持久化机制、消息分发机制、高可用设计、高可靠设计
消息中间件常用协议： OpenWire、AMQP、MQTT、Kafka、OpenMessage
| 名称 | 核心 | 优劣 |
|---|---|---|
| Kafka | TCP二进制协议、无事务设计 | 生产者端的负责，需要人工 依赖zookeeper |
| RabbitMQ | AMQP(OpenWire、AMQP、MQTT、Kafka、OpenMessage) 协议、支持事务、持久化、 多用于金融行业、可靠性高 |
|
| ActiveMQ | MQTT（Message Queuing Telemetry Transport）协议 IBM开发的即时通讯协议，多用于物联网 |
|
| RocketMQ | OpenMessage，阿里发起，分布式消息国际标准 结构简单、解析快、有事务设计、有持久化设计 |
2.8 服务治理
| 名称 | 核心 | 优劣 |
|---|---|---|
| Eureka 相关 | ||
| SpringBootAdmin+ZipKin | ||
| skywalking 链路追踪 | ||
| 普罗米修斯 | ||
| Istio | 与k8s/虚拟机,结合紧密 适用于异构服务(不同开发) 服务网关化（Server Mesh) 采用sidecar模式 （对业务无侵入,切面） 与各个组件能很好切合 |
3.微服务应用
| 名称 | 核心 | 优劣 |
|---|---|---|
| 优悦家居 | Doccker Swarm SpringCloud Zuul/Eureka/Config/ |
|
| XC | K8s 、SpringCloud Gateway Eureak、Apollo/Nacos |