微服务总结

1、微服务是什么？

微服务是由Martin Fowler与James Lewis于2014年共同提出。微服务框架是由很多小服务组成，每个服务运行在单独进程中，并通过轻量级通信机制（如RPC），完成整个应用通信，然后是针对业务的垂直划分，进行自动化独立部署，来保证最低限度的集中式管理的一种服务。

2、使用微服务的好处（对比）？

微服务的好处主要体现在目前框架使用上的不足。首先看下Monoliths和SOA架构：

Moniliths架构

特点很明显：耦合性强，架构的整体性能最好，但是扩展性差，适用于几乎不用更新迭代的小型项目。

随着发展对架构中web容器的内容开始水平分层，降低了耦合性，提高了开发效率和扩展性，但是请求链路边长，并且业务耦合严重导致问题排查难度大。

水平分层架构

SOA架构，主要特点就是业务区分出来，通过总线串联起来，每个业务是Monoliths构架，业务越多架构中内容越多，导致SOA架构繁重。

SOA架构

因此结合前面两种架构的优点，出现了微服务架构。解决业务耦合性强和架构繁重的问题。

1、微服务的特点（框架）？

微服务架构从垂直和水平方向将应用进行拆分，垂直方向一般按业务进行拆分，然后对业务的每一层再进行水平拆分，最终的结构为：

主要有，网关层、业务逻辑层、数据访问层、存储层、配置中心、服务注册发现中心构成。网关层的任务有鉴权、安全、过滤、路由等功能；业务逻辑层对请求的业务进行计算；数据访问层主要做ORM；存储层包括DB、cache等信息的存储；配置中心对项目中的配置文件进行管理，方便多个小服务之间配置差异性的管理；服务注册发现中心因为每层之间的通信都需要用到RPC，因此需要注册中心对每层的服务进行管理，起到服务的注册和发现的作用。

微服务架构最大的特点：独立部署、快速迭代、持续交付

2、微服务的设计模式？

聚合设计模式、代理设计模式、分支设计模式、链式设计模式、数据共享设计模式、异步设计模式，主要使用聚合设计模式，其特点是所有服务通过网关层路由到各个业务逻辑层进行处理。

3、使用微服务需要考虑的地方？

（1）无状态，是指每个运行的服务都是无状态的，保证任何一个进程都是可用的，当其中一个挂掉另一个完全可以替换掉。每个服务就要做到服务的完全一致性，而不一致的主要原因就是数据的不一致导致，因此服务不要保存数据，只做业务逻辑处理。

（2）服务降级，当请求数据突然增加服务处理不过来，严重可能导致整个服务崩溃，此时需要对请求进行筛选，将一些请求过滤掉。因为请求是突然增加的，通常情况服务器是满足要求的，但是突然激增导致不可用的情况，不能为了满足一时的增量，而增加大量的服务器，资源浪费，得不偿失。因此需要服务降级，主要方式有三种：1、拒绝老请求；2、优先级请求；3、随机丢弃请求。拒绝老请求的主要方式是，在请求到来的时候，会经过网络IO的缓存队列，因此在请求进入队列的时候记录缓存的进入队列的时间和出队列的时间，当差值达到阈值是，丢弃该请求。这种方式会丢弃重要的请求（涉及钱的）因此需要结合优先级请求进行优化，当该请求的时间差值达到阈值的时候认为请求数量过多需要过滤请求，因此开始丢弃优先级低的请求，至于如何确定请求的优先级可以在协议中约定。第三种无差别的随机丢弃很少使用，就是任何请求都平等对待，随机丢弃。

（3）异步调用，请求的处理的不需要立即返回结果可以使用异步调用的方式，另外为了增加系统的吞吐量也是要使用异步调用的，其实异步调用同样也可以做同步调用的事情，因为同步调用的是等待调用的返回结果，异步调用是处理完以后通过回调的方式返回，效果是一样的，因此大部分请求都是可以使用异步调用的。异步调用可以增加系统吞吐量，是将请求放到队列中，然后该请求立即返回，下游处理完队列的请求后通过回调函数返回给上游。

（4）幂等设计，保证请求（参数一致）重复执行和执行一次的结果一样。为什么会重复执行，我们在发送一个请求的时候，可能会遇到各种请求，导致请求结果失败，系统中是有高可用的，需要相信系统的稳定性，第一次请求可能是一台服务器挂掉了，但是其他服务器是好使的，并不能直接返回给用户错误信息，这是不友好的，因此可以路由到其他服务器来执行。还有多线程执行相同的请求（参数一致），需要保证执行的结果是一致的。首先要知道哪些操作是幂等的哪些是不幂等的，从操作上来说，create、delete、query操作都是幂等的无论操作几次记过都是一样的，update操作部分是幂等的部分不是幂等的，当update的数据是相对值的时候，如age，每次操作age+1，那么每次请求都会时age增加不能保证其幂等性。因此需要对此类操作进行幂等设计。

（5）分布式事务，分布式系统中对于事务的保证也是十分重要的，尤其是订单处理问题中，一个请求交给多个服务处理，假设有三个其中A、B处理都通过了，但是处理到C的时候出问题了，但是此时A、B已经处理完了，那么就导致严重的不一致问题。因此为了保证事务的一致性，需要对该事务进行回滚，将A、B完成的任务回滚到执行任务之前的情况，该如何实现呢？因此需要额外的事务处理机制对分布式事务进行处理，首先确定该请求为一个事务的时候，在完成A的操作后，需要记录A的请求，参数，服务器信息，事务信息，保存到事务的数据库中，B完成后同样保存到数据库中，执行到C出现了问题，需要对B、A（注意顺序）进行一次回滚，首先在事务数据库中找到该事务和处理该事物的方法B以及相应的参数，对该请求进行补偿，同样找到A进行补偿。