C# 微服务学习总结

目录

单体架构

是什么

优点

缺点

分布式

示意图

SOA

为什么使用SOA

示意图

微服务组件

Consul

能做什么

示意图

Ocelot

是什么

超时

熔断

限流

Polly

微服务术语

服务伸缩性

服务降级

服务治理

服务雪崩

微服务数据共享

常规方案

服务聚合

为什么要做服务聚合

示意图

微服务分布式锁

微服务分布式事务

单体架构

是什么

单体架构的项目就是一个应用程序，所有的功能和业务都是在一个项目里面去做的。

优点

项目做成单体架构，最大的好处就是开发简单，部署也方便，如果公司的业务没那么大，研发也没有那么多，那么做成单体架构是完全没有任何问题的。

缺点

1. 如果公司的业务比较大，研发也比较多，这个时候做成单体架构就不太合适，都是把一个大系统拆分 成很多个子系统，每个子系统对应一个项目组去做，而且每个子系统对应的有自己的数据库。
2. 这么做最大的好处就是分工明确，而且项目的迭代也比较快，也好维护。
3. 但是又会带来新的问题，就是各个服务之间的通信，服务的治理，服务的雪崩，还有各个服务之间需 要数据共享，不同的数据库之间还有可能要满足事物正确执行的四要素，而且服务的发布和部署也很 麻烦，所以想做好也是非常不容易的。

分布式

1. 像有些公司的这个业务确实也比较大，但是研发比较少，做成微服务架构就是在增加所有人的工作量， 而且即使做出来了，稳定性也没法保证。
2. 所以就把单体架构搞成了分布式，就是多买几台服务器，然后用Nginx做一个负载均衡，让多台服务 器来分担一台服务器的请求压力。

示意图

SOA

为什么使用SOA

1. 到了后面因为公司的业务越来越大，老板也开始对公司的研发部比较重视了，这个时候招了很多研发， 老系统也在维护，然后新的系统也在做，就是把老的系统拆分成了多个子系统，对应到每一个项目组 去做。
2. 做的时间久了，像各个服务之间的通信，服务的治理，服务的雪崩，服务之间的数据共享，还有不同 的数据库之间满足事物正确执行的四要素，都通过不断的尝试和摸索慢慢的都解决了。
3. 这个时候又会带来新的问题，A系统在完成某块业务的时候需要调用B系统和C系统提供的接口，B 系统也一样也在完成某块业务的时候需要调用A系统和C系统提供的接口，C系统也一样也在完成某 块业务的时候需要调用A系统和B系统提供的接口。
4. 各个子系统越多，调用的关系也就越复杂，到最后各个子系统之间的调用关系就会变得杂乱无章，而 且任何一个子系统只要把接口改一改，其它调用这个接口的系统都得跟着改。
5. 然后各个项目组就会出现甩锅，扯皮。测试在测试的时候，发现A组做的东西现在用不了，A组查了 一下，发现是B组的接口出了问题，要么就是接口的参数传的没有任何问题，但是就是没有返回的数 据结果，要么就是压根就用不了，因为人家把接口的名字都改了。
6. 这个时候就需要定义一个中立性的接口，来负责处理各个子系统之间的调用关系，这个中立性的接口 也就是SOA。

示意图

微服务组件

Consul

能做什么

1. Consul主要是用来做服务的注册与发现，而且也能做到负载均衡和动态伸缩。
2. 还能进行健康检查，也就是每隔一段时间向各个服务发送一次HTTP请求，如果发现某个服务一直没有 HTTP请求的响应。那么过一段时间，Consul会自动把该服务给剔除掉。

示意图

Ocelot

是什么

1. Ocelot是一个API网关。
2. 像负载均衡，熔断，限流，超时，缓存，通用性的鉴权授权都可以用它来做。

超时

1. 超时就是在调用某个API接口的时候在单位时间内没有返回数据的结果，就直接放弃了，就是为了保 证服务的可用性，
2. 比如当前的这个API接口都过了这么长时间了还没有返回数据的结果，那就不等了，继续调用其它的 API接口。

熔断

1. 熔断就是在单位时间内去调用某些API接口一直报错，错误超过了多少次之后就直接把这些API接口 暂时给停掉了，这种错误一般都是服务器的异常，而不是代码的异常。
2. 然后下次再进行HTTP请求的时候，就不会去调用这些一直报错的API接口，还是为了保证服务的可用 性。
3. 这些一直报错的API接口一般都会给它们一个恢复期，比如过了5分钟之后，它们就又可以被HTTP的 请求给调用了。

限流

1. 限流就是限制单位时间内HTTP的请求数量。
2. 有些接口用户调用的次数非常频繁，再加上用户的数量非常庞大，会导致消耗比较多的网络带宽，对 数据库也会造成不小的压力。
3. 所以可以对这些接口进行限流，限制这些接口单位时间内的访问量。

Polly

1. Polly就是.Net提供的一个针对服务的程序包，它也能提供超时，熔断这样的功能。
2. 但是它只是针对某个服务的内部提供这样的功能，并不是对整体的服务都提供这样的功能。
3. 如果想对整体的服务都提供像超时，熔断这样的功能，还是需要靠API网关来实现。

微服务术语

服务伸缩性

1. 服务伸缩性指的就是某个服务的API接口用户现在调用的次数非常频繁，对数据库也造成了不小的压 力。
2. 为了能够保证用户有比较良好的体验，这个时候就可以通过增加该服务的数量来进行缓解。
3. 每增加了一个服务就相当于增加了一台服务器，每一台服务器对应的就是一个数据库。
4. 本质上还是利用负载均衡让多台服务器来分担一台服务器的请求压力。
5. 但是某个服务的API接口用户调用的次数不是一直都很频繁，等到流量的高峰期过了，就可以缩减该 服务的数量，可以利用闲置下来的服务器去做其它的事情。
6. 对于大部分中小型公司来说，服务伸缩性基本上就不考虑，因为公司就一台服务器。

服务降级

1. 服务降级指的就是超时，熔断，限流。
2. 就是通过降低用户的体验，来保证整个系统的可用性。

服务治理

1. 服务治理指的就是对服务的调用过程进行管理。
2. 其实还是在做超时，熔断，限流，缓存，负载均衡这些东西。

服务雪崩

1. 服务雪崩指的就是某个API接口报错了，或者一直没有返回数据的结果。
2. 处理这类问题就可以用超时，熔断来解决。

微服务数据共享

常规方案

1. 服务之间的数据共享可以直接访问某个服务的数据库来获取数据。
2. 也可以调用某个服务提供的API接口来获取数据。
3. 还可以使用消息队列，比如Kafka，某个服务在处理完自己的业务逻辑之后把数据发送出去，其它服务 收到了通知，获取到数据以后在处理自己的业务逻辑。
4. 还可以使用Redis数据库进行数据共享。

服务聚合

为什么要做服务聚合

1. 还可以做服务聚合，比如A系统在完成某块业务的时候需要调用B系统和C系统提供的接口，B系统 也一样也在完成某块业务的时候需要调用A系统和C系统提供的接口，C系统也一样也在完成某块业 务的时候需要调用A系统和B系统提供的接口。
2. 各个子系统越多，调用的关系也就越复杂，到最后各个子系统之间的调用关系就会变得杂乱无章，而 且任何一个子系统只要把接口改一改，其它调用这个接口的系统都得跟着改。
3. 然后各个项目组就会出现甩锅，扯皮。测试在测试的时候，发现A组做的东西现在用不了，A组查了 一下，发现是B组的接口出了问题，要么就是接口的参数传的没有任何问题，但是就是没有返回的数 据结果，要么就是压根就用不了，因为人家把接口的名字都改了。
4. 这个时候就需要定义一个中立性的接口，来负责处理各个子系统之间的调用关系，这个中立性的接口 也就是SOA。

示意图

 

微服务分布式锁

1. 分布式锁是多个进程不在同一个系统中，用分布式锁来控制多个进程对资源的访问。
2. 在微服务中，每个服务都是单独的一个子系统，所以每个服务都是在自己单独的进程中，甚至各个服 务对应的都是自己的服务器，压根就没有在一个服务器中。
3. 这个时候就可以考虑使用Redis数据库来实现分布式锁。
4. 因为Redis数据库是单线程模型，它的命令操作都是原子性，利用Redis数据库的这个特性就可以很容 易的实现分布式锁。
5. 比如A用户在Redis数据库中利用SETNX指令写入了1个KEY，其它用户暂时无法写入这个KEY，从而 实现锁的效果。

微服务分布式事务

1. 分布式事务是指事务的参与者，支持事务的服务器，资源服务器以及事务管理器，分别位于分布式系 统的不同节点上。
2. 比如说大型的电商系统中，一些下单场景会涉及到库存，优惠促销计算，订单ID生成。
3. 通常情况下，库存，促销，主键生成策略，都位于不同的服务器和数据库表中，但是最终这些数据会 达成一致，这样的好处就是提升了系统的性能。
4. 在弱一致性方案中，常见的解决方案有，使用分布式消息队列来实现最终的一致性。
5. 基于TCC事务，通过演进版本的二阶段提交去实现最终的一致性。
6. 使用Seata事务框架，它提供了多种事务模型，比如说AT，XA，Saga，TCC等，不同的模型提供的是 一个强一致性或者弱一致性的一个支持。