微服务架构

1 基本概念

1.1 高可用

负载均衡、限流、熔断、降级、高并发控制、回滚、隔离、压力测试

1.2 高并发

缓存、异步操作、池化技术、扩容、队列

2 负载均衡

1. 外网(广域网)通过DNS全局负载均衡解析到不同的局域网集群进行分流
2. 内网(局域网)通过搭建API网关，比如LVS（软件负载均衡器）、NginX、F5多层次进行负载均衡
3. NginX将解析结果分配给服务器

2.1 LVS

LVS在数据链路层工作、通过改写MAC地址将请求路由到相应的服务器上

2.2 NginX负载均衡算法

2.2.1 轮询算法

不进行额外的配置，直接配置机器、端口和权重。会按照权重自动分配请求

2.2.2 根据IP负载均衡

根据IP进行负载均衡，相同的IP请求打到同一个服务器上。如果同一个IP恶意攻击，需要使用额外的技术来进行应对

2.2.3 哈希法

通过一个算法进行请求的哈希，类似hashmap，将请求分布在不同的服务器（桶）上。问题在于当添加服务器或者删除的时候，可能导致rehash，低效

2.2.4 一致性哈希

一致性哈希法进行负载均衡，当服务器较多的时候比较均匀，如果一个服务器挂掉会使得很少的数据需要重新重新路由，效率较好

2.3 NginX的降级与重试

2.3.1 通过失败次数进行降级

在配置文件中进行配置，统计发送请求后在一段时间内失败的次数，如果在这段时间内超过了这个次数，则在这段时间内这台服务被认为是不可用的

2.3.2 心跳检测

通过TCP或HTTP的方法进行心跳检测，每隔多少秒进行测试，如果检测失败给定次数后，会标记为不可用，继续检测，如果检测成功给定次数后，标记为可用

2.4 NginX长链接

因为使用的是HTTP，所以配置方式类似于HTTP1.1中的长连接概念

2.5 动态负载均衡

使用插件Consul进行动态负载均衡。Consul能够实现在服务注册后，NginX动态发现服务。

1. 启动服务器
2. 通过Consul管理后台向Consul的service中注册刚启动的服务
3. 在NginX中的Consul插件会有一个长连接轮询访问service，看是否有新服务注册
4. 如果发现了有新服务，则向NginX中注册

3 隔离

3.1 线程隔离

在业务处理中，将传过来的消息进行分类，交给不同的线程池进行处理，实现线程隔离。其中一个业务发生故障，不会影响到另一个线程池

3.2 集群隔离/热点隔离

比如新增一个秒杀系统，对服务的要求比较高。如果还是按照常规逻辑接入服务，那么一旦秒杀系统发生问题可能导致其他服务跟着宕掉，这个时候可以使用集群隔离，在每个服务的集群中进行分组，分出一些机器专门用于秒杀服务，打到集群隔离

3.3 机房隔离

多个机房之间隔离，beta环境使用的机房和线上环境使用的不同，线上环境使用的机房也各不相同，多个服务的调用只在同一个机房的机器上调用。第一个，这样做使得服务间的调用网络延迟低。第二个，如果有自然灾害，一片机房所有的服务器全部挂了，线上也有其他的服务器能够运行。

3.4 动静隔离

静态文件可以存放在CDN上，防止占用了太多的带宽，使得带宽被打满。

3.5 读写隔离

一般的数据库也会采用主从分离的方式，从表读，主表写。在服务中也通过这样的方式进行读写隔离。这样可以有效的防止写占用时间太长了，导致读的效率低下。

4 限流

4.1 限流算法

原子计数器、令牌桶、漏桶

4.2 接口级限流

通过时间片限流，或者算法限流，对某个接口的RPC调用进行限流。

4.3 容器限流

Tomcat、netty都有自己的限流方式，基本都是池化技术的限流。

4.4 分布式限流

采用NginX和Lua进行限流，分布式限流最重要的就是让限流服务变得原子化

5 降级

5.1 降级的判定方法

1. 超时降级
2. 失败次数降级
3. 故障降级
4. 限流降级
5. 开关降级

5.2 降级措施

1. 服务功能降级
2. 读降级：降级为只读缓存，减小压力，对一致性要求不高的时候可用
3. 写降级：降级为只更新缓存，打日志，不写数据库

6 缓存

降级和缓存都是越靠近用户效果越好

6.1 缓存算法

FIFO： 先缓存的数据先删除

LRU：最近最少使用的缓存删除

LFU：最近使用次数最少的缓存删除

6.2 缓存回收策略

1. 基于容量的回收
2. 基于过期时间的回收策略
3. 基于引用形式的回收策略（软引用、弱引用）

6.3 缓存类型

1. 堆缓存
2. 堆外缓存
3. 磁盘缓存
4. 分布式多级缓存

分布式多级缓存：

1. nginx服务器的本地缓存
2. 从redis集群缓存
3. tomcat集群，堆缓存 -> 堆外缓存 -> 磁盘缓存
4. DB服务，更新主redis集群
5. 主redis集群更新从redis集群

7 RPC

7.1 传统单服务问题

传统服务使用一个服务，可能利用MVC或者一些模式来做分层，但实际上还是单服务。这样存在一些问题：

1. 开发效率低，提交代码，测试环境都很麻烦
2. 代码维护难，修改起来耦合度高
3. 扩展性很低，耦合度高，扩展很难做

将大的应用分解为小的互相连接的微服务。一个微服务完成一些相关的功能呢。不同的微服务之间通过REST或者RPC进行连接。

7.2 PRC优缺点

优点：

1. 自由选择技术栈
2. 强化了模块化，降低了耦合性
3. 项目能够独立部署，CI成为可能
4. 使得每个服务都可以独立扩展

微服务也不是一个银弹方法，他是达成一种高效开发和服务的手段，不是目的。它自身也存在很多缺点。为了部署分布式的服务，同样带来了很多问题。

缺点：

1. RPC
2. 数据库体系，我们有的时候没有办法保持强一致性，只能保持最终一致性
3. 测试复杂，需要测试所有的相关业务方
4. 跨服务修改，可能多个服务之间有依赖关系，这个时候需要大量的精力修改

7.3 常用RPC框架

Dubbo

• 远程通讯：提供对多种长连接的NIO框架抽象封装，以及序列化
• 集群容错：提供基于接口方法的透明远程过程调用，软负载均衡，失败容错，地址路由，动态配置等集群支持。
• 自动发现：基于注册中心目录服务，消费方能动态查找服务提供

API网关，是一个服务器，对外面想要调用方法的服务屏蔽了被调用方。通过API网关暴露给外部统一的调用接口，而且它还对身份验证，监控，负载均衡，缓存，分组调用等进行了处理。在这个环节处理所有的非业务功能。

Mesh

• 是一种应用服务间的中间层，是一种轻量级网络代理，服务间对其没有感知。这一层负责了服务间负载均衡、熔断、监控、限流等一系列问题。

RPC的传输：java RMI 、 Thrift 、 protocol buffers

RPC并不是封装的越完整越好，有的时候通过一些配置，需要让使用者知道这是一个远程的方法调用

响应时间/延迟：首先多久的延迟算长，看看99线，95线，是不是基本都是在这水平上，如果有几个效率特别差，可以考虑先优化差的。

8 概念

1. 在Lion中进行文件配置，确保应用是无状态的，这样有利于水平扩展。
2. 基础服务访问量过大，可以进行分组，让不同的调用方调用不同的机器，限流，注意超时时间进行熔断。
3. 消息队列：流量削峰。MQ-client提供拉模式，定时或者批量拉取，可以起到削平流量，下游自我保护的作用。要想提升整体吞吐量，需要下游优化，例如批量处理等方式。
4. 在大流量的处理中，保证最终一致性即可，在redis中扣减并通过AOF打日志，通过同步work在DB中打表。
5. 降级：熔断（RPC降级为不调用）、人工开关降级（配置文件打开降级）、动态化降级为静态化、读服务降级（降级为读缓存或静态化）
6. 缓存：1）JAVA堆缓存，用软引用或弱引用，缓存热点数据，但GC时间变长；2）堆外缓存，空间更大，不受GC影响，但需要序列化，NIO；3）redis服务器分布式缓存，速度快，需要持久化，效果没有前两个好，一致性更好，但缓存并不考虑一致性问题。如果不行就回源。
7. 缓存工具：Guava Cache、Ehcache 3.x、MapDB等
8. Nginx反向代理：正向代理是访问不到指定的东西去访问代理，反向代理是用户访问代理好像是访问了需要访问的东西，而代理做负载均衡和正则等一些分配。
9. 一致性hash：在一个圆环上放置服务器，将key同样计算后放到顺时针的第一台服务器上。一致性哈希算法对于节点的增减都只需重定位环空间中的一小部分数据，具有较好的容错性和可扩展性。
10. 简单扩容、水平拆分数据/应用、重构系统。