springCloud微服务

最新推荐文章于 2024-09-04 07:00:00 发布

骑马看象

最新推荐文章于 2024-09-04 07:00:00 发布

阅读量484

点赞数 1

分类专栏： spring springCloud 文章标签： java springCloud

本文链接：https://blog.csdn.net/qq_15592789/article/details/117032715

版权

spring 同时被 2 个专栏收录

20 篇文章 0 订阅

订阅专栏

springCloud

12 篇文章 0 订阅

订阅专栏

springCloud微服务

springColud
服务
SpringCloud技术

springColud

概念

Spring Cloud是实现微服务架构的一系列框架的有机集合。是在Spring Boot基础上构建的，用于简化分布式系统构建的工具集。是拥有众多子项目的项目集合。利用Spring Boot的开发便利性，巧妙地简化了分布式系统基础设施（服务注册与发现、熔断机制、网关路由、配置中心、消息总线、负载均衡、链路追踪等）的开发。

组成

服务注册与发现组件：Eureka，Zookeeper，Consul,Nacos等。Eureka基于REST风格的。
服务调用组件：Hystrix(熔断降级，在出现依赖服务失效的情况下，通过隔离系统依赖服务的方式，防止服务级联失败，同时提供失败回滚机制，使系统能够更快地从异常中恢复)，Ribbon（客户端负载均衡，用于提供客户端的软件负载均衡算法，提供了一系列完善的配置项：连接超时、重试等），OpenFeign（优雅的封装Ribbon，是一个声明式RESTful网络请求客户端，它使编写Web服务客户端变得更加方便和快捷）。
网关：路由和过滤。Zuul，Gateway。
配置中心：提供了配置集中管理，动态刷新配置的功能；配置通过Git或者其他方式来存储。
消息组件：Spring Cloud Stream（对分布式消息进行抽象，包括发布订阅、分组消费等功能，实现了微服务之间的异步通信）和Spring Cloud Bus（主要提供服务间的事件通信，如刷新配置）
安全控制组件：Spring Cloud Security 基于OAuth2.0开放网络的安全标准，提供了单点登录、资源授权和令牌管理等功能。
链路追踪组件：Spring Cloud Sleuth（收集调用链路上的数据），Zipkin（对Sleuth收集的信息，进行存储，统计，展示）。

版本信息

springCloud版本信息官网
在这里插入图片描述
最新使用的版本为2020.0.x我下面演示的项目版本是2020.0.2这个是2021-03-17的最新版本。这个版本中spring-cloud-netflix已经删除一些支持。

为什么使用最新的，学习吗不用最新的用什么。版本信息参考官网Spring-Cloud-2020.0-Release-Notes.
Spring Cloud 自 2016 年 1 月发布第一个 Angel.SR5 版本，到目前 2021 年 4 月21发布 Hoxton.SR11版本，已经历经了 5 年时间。

服务

单体应用

1、概念：所有功能全部打包在一起。应用大部分是一个war包或jar包。随着业务发展，功能增多，这个项目会越来越臃肿。
2、好处：容易开发、测试、部署，适合项目初期试错。
3、坏处：
随着项目越来越复杂，团队不断扩大。坏处就显现出来了。
a) 复杂性高：代码多，十万行，百万行级别。加一个小功能，会带来其他功能的隐患，因为它们在一起。
b) 技术债务：人员流动，不坏不修，因为不敢修。
c) 持续部署困难：由于是全量应用，改一个小功能，全部部署，会导致无关的功能暂停使用。编译部署上线耗时长，不敢随便部署，导致部署频率低，进而又导致两次部署之间功能修改多，越不敢部署，恶性循环。
d) 可靠性差：某个小问题，会导致整个应用崩溃。
e) 扩展受限：只能整体扩展,无法按照需要进行扩展,不能根据计算密集型和IO密集型进行合适的区分。
f) 阻碍创新：单体应用是以一种技术解决所有问题，不容易引入新技术。但在高速的互联网发展过程中，适应的潮流是：用合适的语言做合适的事情。比如在单体应用中，一个项目用spring MVC，想换成spring boot，切换成本很高，因为有可能10万，百万行代码都要改，而微服务可以轻松切换，因为每个服务，功能简单，代码少。

微服务应用

概况

微服务是一种架构风格，将单体应用划分为小型的服务单元。
微服务架构是一种使用一系列粒度较小的服务来开发单个应用的方式；每个服务运行在自己的进程中；服务间采用轻量级的方式进行通信(通常是HTTP API)；这些服务是基于业务逻辑和范围，通过自动化部署的机制来独立部署的，并且服务的集中管理应该是最低限度的，即每个服务可以采用不同的编程语言编写，使用不同的数据存储技术。

特点

独立运行在自己进程中。
一系列独立服务共同构建起整个系统。
一个服务只关注自己的独立业务。
轻量的通信机制RESTful API
使用不同语言开发
全自动部署机制

组件信息

服务注册与发现：服务提供方将己方调用地址注册到服务注册中心，让服务调用方能够方便地找到自己；服务调用方从服务注册中心找到自己需要调用的服务的地址。
负载均衡：服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。并且，服务节点选择的过程对服务调用方来说是透明的。
服务网关：服务网关是服务调用的唯一入口，可以在这个组件中实现用户鉴权、动态路由、灰度发布、A/B测试、负载限流等功能。
配置中心：将本地化的配置信息(Properties、XML、YAML等形式)注册到配置中心，实现程序包在开发、测试、生产环境中的无差别性，方便程序包的迁移，也是无状态特性。
集成框架：微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组件(特别是管理端组件)集成到统一的界面框架下，让用户能够在统一的界面中使用系统。Spring Cloud就是一个集成框架。
调用链监控：记录完成一次请求的先后衔接和调用关系，并将这种串行或并行的调用关系展示出来。在系统出错时，可以方便地找到出错点。
支撑平台：系统微服务化后，各个业务模块经过拆分变得更加细化，系统的部署、运维、监控等都比单体应用架构更加复杂，这就需要将大部分的工作自动化。现在，Docker等工具可以给微服务架构的部署带来较多的便利，例如持续集成、蓝绿发布、健康检查、性能监控等等。如果没有合适的支撑平台或工具，微服务架构就无法发挥它最大的功效。

优点

独立部署。不依赖其他服务，耦合性低，不用管其他服务的部署对自己的影响。
易于开发和维护：关注特定业务，所以业务清晰，代码量少，模块变的易开发、易理解、易维护。
启动块：功能少，代码少，所以启动快，有需要停机维护的服务，不会长时间暂停服务。
局部修改容易：只需要部署相应的服务即可，适合敏捷开发。
技术栈不受限：java，node.js等
按需伸缩：某个服务受限，可以按需增加内存，cpu等。
职责专一。专门团队负责专门业务，有利于团队分工。
代码复用。不需要重复写。底层实现通过接口方式提供。
便于团队协作：每个团队只需要提供API就行，定义好API后，可以并行开发。

缺点

分布式固有的复杂性：容错（某个服务宕机），网络延时，调用关系、分布式事务等，都会带来复杂。
分布式事务的挑战：每个服务有自己的数据库，有点在于不同服务可以选择适合自身业务的数据库。订单用MySQL，评论用Mongodb等。目前最理想解决方案是：柔性事务的最终一致性。(刚性事务：遵循ACID原则，强一致性。柔性事务：遵循BASE理论，最终一致性；与刚性事务不同，柔性事务允许一定时间内，不同节点的数据不一致，但要求最终一致。)
接口调整成本高：改一个接口，调用方都要改。
测试难度提升：一个接口改变，所有调用方都得测。自动化测试就变的重要了。API文档的管理也尤为重要。推荐：yapi。
运维要求高：需要维护几十上百个服务。监控变的复杂。并且还要关注多个集群，不像原来单体，一个应用正常运行即可。
重复工作：比如java的工具类可以在共享common.jar中，但在多语言下行不通，C++无法直接用java的jar包。