微服务架构SpringCloud_服务网关、认证中心、注册中心、服务容错、服务调用-CSDN博客

本文链接：https://blog.csdn.net/qq_52681418/article/details/113247805

阅读此博客，你需要了解springboot，springboot教程

boot和cloud版本注意对应，可以查看spring官网：https://spring.io/projects/spring-cloud#learn

微服务架构SpringCloud

随着互联网应用的发展，传统的单体应用架构和垂直应用架构已经不能满足大型互联网应用的需要，于是分布式架构（面向服务）便应运而生。分布式将传统的单体应用拆分为多个功能单一的服务，使应用的开发与维护变得简单多了。而springcloud则是其中的一个解决方案。

服务架构的演变：https://blog.csdn.net/qq_52681418/article/details/113448579

springcloud讲一个大型应用拆分为粒度很小的多个服务，这些服务通过相互协作来支撑整个应用对外提供的服务。这些服务被部署在不同的主机上，组成一个集群。

使用IDEA来开始一个SpringCloud项目：https://blog.csdn.net/qq_52681418/article/details/113547629

1.服务注册

服务之间的协作，即服务之间的相互调用，一个服务通过调用另一个服务，来使用其功能，于是这个过程就产生了2个角色：服务调用者(或服务消费者)、服务提供者（或服务生产者）。

服务调用者：调用其他服务的服务。
服务提供者：被调用的服务。

实现服务调用是比较容易的，使用 RestTemplate 对象即可实现服务调用，为调用者注入该对象，并使用该对象的 getForObject ( 接口地址 , 映射类 ) 来获取生产者返回的数据。

硬编码模式：

由于其接口地址为：http://ip:port/api 形式，在调用过程中将其直接编写在消费者代码中，因此这种模式也称为硬编码模式。

这种模式比较简单，但存在问题：springcloud是为了解决大型项目而生，既然是大型项目，自然有很多服务，这些服务部署到不同主机，消费者在调用生产者时就需要维护大量的IP+port，而且当这些地址发生变化时，就需要修改消费者代码，这无疑是增加了服务间的耦合性。

注册中心：

如何解决上面出现的问题呢，这就需要一个中介来处理了，生产者将自己的IP+端口提供给中介(服务注册)，消费者直接从中介获取服务信息（服务发现），通过该信息来调用服务（服务调用）。

这里的中介就叫做服务注册中心：

常见的服务注册中心有：

eureka
consul
nacos
zookeeper

都集成了Ribbon来实现服务调用。
参考：https://blog.csdn.net/qq_52681418/article/details/113251734

2.服务调用

通过上面，可以了解服务的注册与调用。服务调用即一个服务调用另一个服务，可以直接调用，也可以间接调用，常见的调用方式有以下几种：

硬编码调用
Ribbon
OpenFeign
Dubbo

参考：https://blog.csdn.net/qq_52681418/article/details/113336593

3.服务容错

服务容错包括：服务降级、服务限流、服务隔离。

服务容错是为了，因为服务宕机、网络中断、请求阻塞是无法完全杜绝的常见问题，为了保证整个应用的可以持续处理外部请求，因此需要对应用进行容错处理。

服务容错：

服务熔断：某个服务出现问题，就切断该服务的联系，防止影响其它服务正常运行。
服务降级：某个服务不可用时，用一个比较低级的服务来代替原服务处理请求。
服务限流：为服务设置请求阀值，使服务在一段时间内只接收指定数量的请求。
服务隔离：使服务之间相互隔离，防止出现雪崩效应。

雪崩效应：服务多级调用时，一个服务拥堵，从而导致多级服务都拥堵。

服务容错组件：

hystrix
sentinel
admin

服务容错参考：https://blog.csdn.net/qq_52681418/article/details/113351447

4.服务网关

在上面的集群之中，通过注册中心可实现服务之间的注册、调用，这种调用是集群内部的服务对服务的调用。但作为一个网络应用，除了内部调用，更需要将服务提供给外部，外部请求通过调用服务接口来进行服务访问。

因此当集群对外提供的服务较多时，由于对外提供的服务接口处于不同的主机上，对外提供的接口IP+端口也显得混乱不堪，前端开发者想使用、维护这些接口，无疑是困难的。

除此之外，对于请求的权限认证也将变得困难，因为接口在不同主机，而这些主机都存储用户信息显然是比较麻烦且浪费资源的。

如何解决这个问题呢？通过注册中心我们可以发现，通过注册中心这个中介可用将众多被调用的服务提供给服务调用者，因此调用者不用再维护调用的服务的IP+端口。

所以在对外提供的接口我们也可使用这种模式，将所有服务交给一个中介，外部获取接口，只需通过中介获取即可，而这个中介就叫做服务网关。

服务网关也是一个服务，部署在一台主机上，它可使用路由功能将众多接口的IP+端口替换为自身的IP+端口，外部请求只需知道网关的IP+端口就行了，当然它的好处不止如此。

使用网关的好处：

路由IP代理：将众多服务接口的IP、端口代理为自身的IP+端口。
保存权限认证信息：身份认证时，只需要再网关存储用户信息，网关通过，即可对用户开放被代理的接口。
网关限流：可以在网关外部，阻隔一些无用请求，可以降低服务接口的无用流量。
隐藏服务接口：外部访问的接口为网关接口，时间服务接口不会被外部请求获取。
网关高可用：网关也可以实现高可用，允许多个网关相互协作，保证服务可用。

以下是几个常见的服务网关：

nginx
zuul
gateway

服务网关请参考：https://blog.csdn.net/qq_52681418/article/details/113402988

5.链路追踪

通过之前的学习我们知道，微服务架构中，服务分布在不同的主机上，通过注册中心来实现服务的注册和调用，然后进行容错处理，最终将对外的服务接口交给网关进行代理。

在正常的系统中，日志是必不可少的，而在分布式系统中，该如何获取日志呢？而且当一个请求进入之后，又该如何检测为了处理这个请求调用了哪些服务呢？这就需要使用链路追踪技术。

分布式链路追踪：将一次分布式请求还原成调用链路，进行日志记录、性能监控、并集中展示请求调用情况。

较流行的链路追踪系统（大部分基于google：Dapper）：

Twitter：Zipkin
阿里：鹰眼
美团：Mtrace
大众点评：cat

常用的链路追踪组件有：

sleuth+zipkin
skywalking

参考：https://blog.csdn.net/qq_52681418/article/details/113505367

6.消息中间件

分布式系统的服务间传递的消息不应该只是日志和调用链路数据，也可以传递其他数据。

消息中间件是基于队列与消息传递技术，在网络环境中为应用系统提供同步或异步、可靠的消息传输的支撑性软件系统。

消息即服务产生的数据，服务可以将数据发送给其他主机，以此来实现服务间的通信。

大型应用中，服务往往有很多，如果每个服务之间直接进行通信，通信是十分复杂的，与服务调用一样，可以使用中间件来接收服务的消息、发送消息给目标服务。

消息的处理往往有先后顺序，因此在消息中间件中使用队列来确定优先级，即消息队列。
springcloud中使用事件驱动stream来整合消息中间件，常见的消息中间件有：

ActiveMQ
RabbitMQ
Kafka
RocketMQ

参考：https://blog.csdn.net/qq_52681418/article/details/113522897

7.配置中心

微服务架构中存在很多服务，每个服务都有自己的配置文件，这些配置文件如果集成在服务中，也是难以维护的，于是便可以使用配置中心来管理这些配置文件。
配置中心的使用是简单的，常见的配置中心有：

config
apollo

参考：https://blog.csdn.net/qq_52681418/article/details/113547302

小结

分布式系统即面向服务的系统，将一个大型应用拆分为多个服务，服务通过协调组成应用。微服务则是其中一个解决方案，将服务的粒度划分更小。

核心内容如下：

服务注册、服务调用：解决集群内部服务调用IP+端口较多问题。
服务容错：保证服务可用性。
服务网关：防止对外接口IP+端口太多。
链路追踪：采集服务日志、调用链路等数据。
消息中间件：集群中服务数据传递（优化链路追踪）。
配置中心：统一管理配置文件。

SpringCloud组件：

SOA注重复用，微服务注重拓展，但并非所有场景都要使用微服务，使用微服务有时候会将简单的问题放大：

分布式的代价：原本在单体应用中，很多简单的问题都会在分布式环境下被几何级的放大。例如分布式事务、分布式锁、远程调用等，不光要考虑如何实现他们，相关场景的异常处理也是必须要考虑到的问题。
协同代价：如果你经历过一个项目上线需要发布十几个应用，而这些应用又分别由多个团队在维护。你就能深刻的体会到协同是一件多么痛苦的事情了。
服务拆分需要很强的设计功力：微服务的各种优势，其中一个重要的基础是对服务领域的正确切分。如果使用了不合适的切分粒度，或者是错误的切分方法，都会让服务不能很好的实现高内聚低耦合的要求。