分布式和微服务

SOA 面向服务的架构（Service Oriented Architecture），也就是把我们的项目按照业务逻辑拆分成服务层、表现层两个工程。服务层中包含业务逻辑，只需要对外提供服务即可。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。SOA架构中有两个主要角色：服务提供者（Provider）和服务使用者（Consumer）。

分布式id的生成方式

全局唯一id必须具备什么特点？
1. 全局唯一性：不能出现重复的ID，最基本的要求。
2. 递增：保证下一个ID一定大于上一个ID。
3. 信息安全：如果ID是连续递增的，恶意用户就可以很容易的窥见订单号的规则，从而猜出下一个订单号，如果是竞争对手，就可以直接知道我们一天的订单量。所以在某些场景下，需要ID无规则。

方案：

UUID 几千万的数据基本没有重复的可能，但是是无序的，字符串，占用较大，不适合排序
数据库自增iD：于可以暴露的id来讲没问题
Mongodb自己生成的_id：这个是适合分布式系统的，而且自带排序，很好
Redis生成全局唯一自增ID:可行
雪花算法ID： long类型的，绝对不会重复，自增排序，但占用还是比较大

基于Redis INCR 命令生成分布式全局唯一id
INCR 命令主要有以下2个特征：
1. Redis的INCR命令具备了“INCR AND GET”的原子操作，即增加并返回结果的原子操作。这个原子性很方便我们实现获取ID.
2. Redis是单进程单线程架构，INCR命令不会出现id重复.
基于以上2个特性，我们可以采用INCR命令来实现分布式全局ID生成。

public class Test {
 
    @Autowired
    private StringRedisTemplate stringRedisTemplate;
 
    private static final String ID_KEY = "id:generator:user";

    @Test
    public void incrementId() {
        for (int i = 0; i <100 ; i++) {
            //步骤1：生成分布式id,该命令会自动返回生成的id
            long id=this.stringRedisTemplate.opsForValue().increment(ID_KEY);
 
            //全局id，代替数据库的自增id
            Order order = new Order();
            order.setId(id);
        }
    }
}

什么是微服务?

特性

每个微服务可独立运行在自己的进程里；
一系列独立运行的微服务共同构建起了整个系统；
每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，比如：订单管理，用户管理等；
微服务之间通过一些轻量级的通信机制进行通信，例如通过REST API或者RPC的方式进行调用。

为什么要有微服务架构?单体架构的问题

单体架构在规模比较小的情况下工作情况良好，但是随着系统规模的扩大，它暴露出来的问题也越来越多，主要有以下几点：

1.复杂性逐渐变高

比如有的项目有几十万行代码，各个模块之间区别比较模糊，逻辑比较混乱，代码越多复杂性越高，越难解决遇到的问题。

2.技术债务逐渐上升

公司的人员流动是再正常不过的事情，有的员工在离职之前，疏于代码质量的自我管束，导致留下来很多坑，由于单体项目代码量庞大的惊人，留下的坑很难被发觉，这就给新来的员工带来很大的烦恼，人员流动越大所留下的坑越多，也就是所谓的技术债务越来越多。

3.部署速度逐渐变慢

这个就很好理解了，单体架构模块非常多，代码量非常庞大，导致部署项目所花费的时间越来越多，曾经有的项目启动就要一二十分钟，这是多么恐怖的事情啊，启动几次项目一天的时间就过去了，留给开发者开发的时间就非常少了。

4.阻碍技术创新

比如以前的某个项目使用struts2写的，由于各个模块之间有着千丝万缕的联系，代码量大，逻辑不够清楚，如果现在想用spring mvc来重构这个项目将是非常困难的，付出的成本将非常大，所以更多的时候公司不得不硬着头皮继续使用老的struts架构，这就阻碍了技术的创新。

5.无法按需伸缩

比如说电影模块是CPU密集型的模块，而订单模块是IO密集型的模块，假如我们要提升订单模块的性能，比如加大内存、增加硬盘，但是由于所有的模块都在一个架构下，因此我们在扩展订单模块的性能时不得不考虑其它模块的因素，因为我们不能因为扩展某个模块的性能而损害其它模块的性能，从而无法按需进行伸缩。

微服务架构优点

易于开发和维护

由于微服务单个模块就相当于一个项目，开发这个模块我们就只需关心这个模块的逻辑即可，代码量和逻辑复杂度都会降低，从而易于开发和维护。

启动较快

这是相对单个微服务来讲的，相比于启动单体架构的整个项目，启动某个模块的服务速度明显是要快很多的。

局部修改容易部署

在开发中发现了一个问题，如果是单体架构的话，我们就需要重新发布并启动整个项目，非常耗时间，但是微服务则不同，哪个模块出现了bug我们只需要解决那个模块的bug就可以了，解决完bug之后，我们只需要重启这个模块的服务即可，部署相对简单，不必重启整个项目从而大大节约时间。

技术栈不受限

比如订单微服务和电影微服务原来都是用java写的，现在我们想把电影微服务改成nodeJs技术，这是完全可以的，而且由于所关注的只是电影的逻辑而已，因此技术更换的成本也就会少很多。

按需伸缩

我们上面说了单体架构在想扩展某个模块的性能时不得不考虑到其它模块的性能会不会受影响，对于我们微服务来讲，完全不是问题，电影模块通过什么方式来提升性能不必考虑其它模块的情况。

微服务架构缺点

运维要求较高

对于单体架构来讲，我们只需要维护好这一个项目就可以了，但是对于微服务架构来讲，由于项目是由多个微服务构成的，每个模块出现问题都会造成整个项目运行出现异常，想要知道是哪个模块造成的问题往往是不容易的，因为我们无法一步一步通过debug的方式来跟踪，这就对运维人员提出了很高的要求。

分布式的复杂性

对于单体架构来讲，我们可以不使用分布式，但是对于微服务架构来说，分布式几乎是必会用的技术，由于分布式本身的复杂性，导致微服务架构也变得复杂起来。

接口调整成本高

比如，用户微服务是要被订单微服务和电影微服务所调用的，一旦用户微服务的接口发生大的变动，那么所有依赖它的微服务都要做相应的调整，由于微服务可能非常多，那么调整接口所造成的成本将会明显提高。

重复劳动

对于单体架构来讲，如果某段业务被多个模块所共同使用，我们便可以抽象成一个工具类，被所有模块直接调用，但是微服务却无法这样做，因为这个微服务的工具类是不能被其它微服务所直接调用的，从而我们便不得不在每个微服务上都建这么一个工具类，从而导致代码的重复。

分布式事务问题

问题：如何实现两个分布式服务（订单服务、库存服务）共同完成一件事即订单支付成功自动减库存，这里的关键是如何保证两个分布式服务的事务的一致性。

理解CAP理论

CAP理论是分布式事务处理的理论基础：分布式系统在设计时只能在一致性(Consistency)、可用性(Availability)、分区容忍性(PartitionTolerance)中满足两种，无法兼顾三种。

C：一致性>Consistency;

一致性就是说，我们读写数据必须是一摸一样的。

比如一条数据，分别存在两个服务器中，server1和server2。
我们此时将数据a通过server1修改为数据b。此时如果我们访问server1访问的应该是b。
当我们访问server2的时候，如果返回的还是未修改的a，那么则不符合一致性，如果返回的是b，则符合数据的一致性。

A：可用性>Availability;

只要我对服务器，发送请求，服务器必须对我进行相应，保证服务器一直是可用的。

P：分区容错性>Partition tolerance;

一般来说，分布式系统是分布在多个位置的。比如我们的一台服务器在北京，一台在上海。可能由于天气等原因的影响。造成了两条服务器直接不能互相通信，数据不能进行同步。这就是分区容错。我们认为，分区容错是不可避免的。也就是说 P 是必然存在的。

分布式系统不可避免的出现了多个系统通过网络协同工作的场景，结点之间难免会出现网络中断、网延延迟等现象，这种现象一旦出现就导致数据被分散在不同的结点上，这就是网络分区。

分布式系统如何兼顾CAP：

在保证分区容忍性的前提下一致性和可用性无法兼顾，如果要提高系统的可用性就要增加多个结点，如果要保证数据的一致性就要实现每个结点的数据一致，结点越多可用性越好，但是数据一致性越差。
所以，在进行分布式系统设计时，同时满足“一致性”、“可用性”和“分区容忍性”三者是几乎不可能的。

分布式事务一致性解决方案

两阶段提交协议(2PC)

两阶段提交协议，两阶段提交由协调者和参与者组成，共经过两个阶段和三个操作，MySQL支持两阶段提交协议。

1）第一阶段：准备阶段（prepare）
协调者通知参与者准备提交，各参与者反馈事务执行结果，但参与者先不提交事务。
2）第二阶段：提交 (commit) / 回滚 (rollback) 阶段
协调者通知参与者开始提交，各参与者反馈事务提交结果。只要在这两个阶段中执行结果和提交结果有失败回复，整个事务回滚。

一个下单减库存的例子：

1、应用程序连接两个数据源。
2、应用程序通过事务协调器向两个库发起prepare，两个数据库收到消息分别执行本地事务（记录日志），但不提交，如果执行成功则回复yes，否则回复no。
3、事务协调器收到回复，只要有一方回复no则分别向参与者发起回滚事务，参与者开始回滚事务。
4、事务协调器收到回复，全部回复yes，此时向参与者发起提交事务。如果参与者有一方提交事务失败则由事务协调器发起回滚事务。

2PC的优点：实现强一致性，部分关系数据库支持（Oracle、MySQL等）。
缺点：整个事务的执行需要由协调者在多个节点之间去协调，增加了事务的执行时间，性能低下。

消息队列实现最终一致性

消息事务其实就是基于消息中间件的两阶段提交，将本地事务和发消息放在同一个事务里，保证本地操作和发送消息同时成功

本方案是将分布式事务拆分成多个本地事务来完成，并且由消息队列异步协调完成，如下图

下边以下单减少库存为例来说明：

1、订单服务和库存服务完成检查和预留资源。

2、订单服务在本地事务中完成添加订单表记录和添加“减少库存任务消息”。

3、由定时任务根据消息表的记录发送给MQ通知库存服务执行减库存操作。

4、库存服务执行减少库存，并且记录执行消息状态（为避免重复执行消息，在执行减库存之前查询是否执行过此消息）。

5、库存服务向MQ发送完成减少库存的消息。

6、订单服务接收到完成库存减少的消息后删除原来添加的“减少库存任务消息”。

实现最终事务一致要求：预留资源成功理论上要求正式执行成功，如果执行失败会进行重试，要求业务执行方法实现幂等。

优点：由MQ按异步的方式协调完成事务，性能较高。
缺点：此方式基于关系数据库本地事务来实现，会出现频繁读写数据库记录，浪费数据库资源，另外对于高并发操作不是最佳方案。

Spring Cloud、Dubbo 有什么区别？

dubbo注册中心时zookeeper springcloud注册中心时Eureka；

dubbo服务调用方式是RPC，springcloud是REST API；

dubbo轻量级。快，springcloud功能强大，没有dubbo快

springcloud有网关gateway，分布式配置config，消息总线bus

dubbo 服务开发流程，运行流程？

dubbo 服务开发流程:

maven 工程中 pom 文件先导入 dubbo 依赖 jar 包
搭建 zookeeper 注册中心
写好服务端工程并配置 dubbo 服务端配置，并关联上 zookeeper 注册中心
写好客户端工程并配置 dubbo 客户端配置，并关联上 zookeeper 注册中心
客户端工程依赖注入服务端实习类，即可调用相关暴露的接口

dubbo 运行流程：

服务容器负责启动，加载，运行服务提供者。
服务提供者在启动时，向注册中心注册自己提供的服务。
服务消费者在启动时，向注册中心订阅自己所需的服务。
注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

Dubbo 的容错机制有哪些

建议在服务提供方设置，@DubboService注解中配置超时时间，和重试次数。

超时时间默认3s，3s服务提供方没有返回结果，就算失败一次。默认重试2次

1. 失败重试(默认)

当服务消费方调用服务提供者失败后自动切换到其他服务提供者服务器进行重试。这通常用于读操作或者具有幂等的写操作，需要注意的是重试会带来更长延迟。可通过 retries="2" 来设置重试次数（不含第一次）。

<dubbo:reference>

<dubbo:method name="sayHello" retries="2" /></dubbo:reference>

2. 快速失败

当服务消费方调用服务提供者失败后，立即报错，也就是只调用一次。通常这种模式用于非幂等性的写操作。

3. 失败安全

当服务消费者调用服务出现异常时，直接忽略异常。这种模式通常用于写入审计日志等操作。

4. 失败自动恢复

当服务消费端用服务出现异常后，在后台记录失败的请求，并按照一定的策略后期再进行重试。这种模式通常用于消息通知操作。

5. 并行调用

当消费方调用一个接口方法后，Dubbo Client 会并行调用多个服务提供者的服务，只要一个成功即返回。这种模式通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数。

6. 广播调用

当消费者调用一个接口方法后，Dubbo Client 会逐个调用所有服务提供者，任意一台调用异常则这次调用就标志失败。这种模式通常用于通知所有提供者更新缓存或日志等本地资源信息。

如果您有定制化需求，也可以根据 Dubbo提供的扩展接口 Cluster 进行定制。

Dubbo负载均衡策略

按权重随机（默认）
按权重轮询
最少活跃调用数，相同的活跃数随机
一致性Hash，相同的请求总是发到同一提供者

如何改变dubbo的负载均衡策略？

在项目中，直接在注解@Reference中引用，然后注明loadblance="xxx".

xxx就是具体的策略名称，必须全部小写。

@Reference(loadblance = "random")
@Reference(loadblance = "RoundRobin")
@Reference(loadblance = "leastactive")
@Reference(loadblance = "consistenthash")
privite UserService userService;

如何改变权重值？

在Dubbo提供的@Service注解中配置

@Service(weight = 200)

Zookeeper

Zookeeper 的读写机制

Zookeeper 是一个由多个 server 组成的集群，一个 leader，多个 follower，每个 server保存一份数据副本，全局数据一致，分布式读写，更新请求转发，由 leader 实施

zookeeper 的工作原理

Zookeeper 的核心是原子广播，这个机制保证了各个 Server 之间的同步。

Zookeeper 节点宕机如何处理？

Zookeeper 本身也是集群，推荐配置不少于 3 个服务器。Zookeeper 自身也要保证当一个节点宕机时，其他节点会继续提供服务。如果是一个 Follower 宕机，还有 2 台服务器提供访问，因为 Zookeeper 上的数据是有多个副本的，数据并不会丢失；如果是一个 Leader 宕机，Zookeeper 会选举出新的 Leader。 Zookeeper 集群的机制是只要超过半数的节点正常，集群就能正常提供服务。只有在 Zookeeper 节点挂得太多，只剩一半或不到一半节点能工作，集群才失效。如果 zookeeper 注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯，但是无法从注册中心去同步最新的服务列表。

什么是Eureka?

注册中心 Eureka Server：就是服务注册中心（可以是一个集群），对外暴露自己的地址
提供端 Eureka Provider：启动后向 Eureka 注册自己信息（地址，提供什么服务）
消费端 Eureka Consumer：向 Eureka 订阅服务，Eureka 会将对应服务的所有提供者地址列表发送给消费者，并且定期更新
心跳(续约)：提供者定期通过 http 方式向 Eureka 刷新自己的状态

Eureka分为Servier和Client

provider和consumer都属于Client

Eureka如何实现高可用

准备多个Eureka Server 进行配置；
多个Server之间分别相互注册；
把其他Eureka Client 分别注册到所有 Eureka Server中
Eureka默认轮询的方式分别访问不同的Server 可以配置Ribbon来改变

Eureka的自我保护模式

默认情况下，如果Eureka Service在一定时间内没有接收到某个微服务的心跳，Eureka Service会进入自我保护模式，在该模式下Eureka Service会保护服务注册表中的信息，不在删除注册表中的数据，当网络故障恢复后，Eureka Servic 节点会自动退出自我保护模式。

Eureka和ZooKeeper都的区别

ZooKeeper中的节点服务挂了就要选举。在选举期间注册服务瘫痪,虽然服务最终会恢复,但是选举期间不可用的，选举就是该微服务做了集群，必须有一台主其他的都是从。
Eureka各个节点是平等关系,服务器挂了没关系，只要有一台Eureka就可以保证服务可用，数据都是最新的。如果查询到的数据并不是最新的，就是因为Eureka的自我保护模式导致的。
Eureka本质上是一个工程,而ZooKeeper只是一个进程。
Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像ZooKeeper 一样使得整个注册系统瘫痪。
ZooKeeper保证的是CP，Eureka保证的是AP