Java微服务学习笔记(一)：微服务架构的概念理解

最新推荐文章于 2024-05-30 10:27:35 发布

Cute_LuoBo

最新推荐文章于 2024-05-30 10:27:35 发布

阅读量399

点赞数 1

分类专栏：微服务文章标签： java 微服务架构

本文链接：https://blog.csdn.net/qq_41046428/article/details/124980587

版权

微服务专栏收录该内容

1 篇文章 0 订阅

订阅专栏

Java微服务学习笔记

Tips:入门学习时粗略整理，仅供参考
(一)：架构的基础理解

前言

在项目伊始时，常见的SpringBoot单体项目就可以满足需求，但随着业务功能迭代和用户数量的增加，项目也不可避免地遇到以下的一些问题：
一、更新波及范围过大：某个服务更新时，需要将完整项目重新打包，停止所有服务后再次部署
二、服务性能拓展受限：单体项目只能集成在一个应用程序包中，拓展时必须要在新的计算机资源中，完整部署一个新的单体项目，无法针对某个特别需求性能的服务进行单独拓展

对于这些问题，可以使用微服务的部署结构来解决

一、微服务是什么？

微服务是一种软件部署架构，将每个业务功能都单独拆分成一个服务模块，每个服务模块都有属于自己的数据资源，可以自主实现个体功能而不会干扰到其他服务，需要协助完成的，通过约定的协议（HTTP/RPC）来进行通信，通过这些服务模块来组合成一个复杂的大型应用程序。

二、常用开源微服务框架演化

1. Dubbo

由阿里巴巴公司开发，于2011年底进行开源，后续捐赠给Apache基金会，成为Apache孵化器项目
在Spring Cloud出现之前，Dubbo是国内微服务部署的主流框架。

作为初代探索者，很好解决了当时微服务开发的问题，但开发相对繁琐

服务注册中心：zookeeper
服务交流协议：自订的RPC协议（Dubbo协议）
服务网关：无
配置中心：无
服务监控/安全维护：Dubbo-admin

2. Spring Cloud (NetFlix)

由Spring开源基金会维护，在SpringBoot项目的基础上，约定了一个微服务开发规范，整合和开发了微服务架构所需各种应用服务模块，例如注册中心、网关、负载均衡等。
在开始时，服务模块实现主要使用了NetFlix公司开源的组件，例如Eureka、Ribbon、Zuul等，这阶段也被称为Spring Cloud NetFlix，但随着这些模块原开源项目的关闭，基本都替换为了Spring自行维护的新模块，"Spring Cloud NetFlix"这一称呼也不再使用。

主要提供了新的微服务“体系”，抽象了微服务的开发模式，底层的实现模块可以更方便的替换，同时结合SpringBoot的快捷配置（start）功能，使单个微服务模块的配置效率大大提升。

服务注册中心：NetFlix Eureka /HashiCorp Consul
服务交流协议：HTTP协议(Rest API)
服务网关：Spring Cloud Gateway / NetFlix Zuul
配置中心：Spring Cloud Config
服务监控/安全维护：Hystrix

拓展阅读：4 年 46 个版本，一文读懂 Spring Cloud 发展历史-2020

3. Spring Cloud Alibaba

阿里巴巴公司在SpringCloud架构基础上，开发的一系列新的微服务套件实现，被称为Spring Cloud Alibaba。
提供了一些更加方便的服务组件，例如Nacos，整合了注册中心和配置中心，服务交流协议中拓展支持了Dubbo协议，可以使原Dubbo开发项目更方便地迁移，目前国内主流微服务框架学习都以此项目为准

服务注册中心：Alibaba Nacos
服务交流协议：HTTP协议(Rest API) / RPC协议（Dubbo协议）
服务网关：Spring Cloud Gateway / NetFlix Zuul
配置中心：Alibaba Nacos
服务监控/安全维护：Alibaba Sentinel

三、微服务架构与技术栈组成

Tips：未深入理解，仅作当前阶段总结

1.微服务本体

将单个业务功能拆分成的单独的微服务，本质是个功能更加纯粹的SpringBoot应用，拥有独立的数据库，避免各服务之间干扰。服务间通过约定的协议进行通讯，例如Dubbo/Http等

2.服务间通讯工具

1. RestTemplate：

Spring提供的带有基础封装的HTTP客户端，可以快速地将返回的json数据转成指定对象后再利用。没有负载均衡功能，需要使用其他框架，例如Ribbon等

2. Feign：

声明式编程请求客户端，使用类springmvc的controller模型，定义访问客户端接口，通过调用接口来传递数据，内部封装了Ribbon来实现负载均衡功能

3. Dubbo?:

(暂未用到，略)

3.负载均衡

负载均衡即对请求进行分流，以使各微服务的性能充分利用

Ribbon:

对于RestTemplate，需要在Bean声明方法中使用@AutoBanlance注解启用负载均衡

工作原理：对HTTP客户端访问的URI进行拦截，获取URI中的host（服务名），从注册中心中获取服务列表，根据负载均衡策略，替换为服务列表中的连接地址来访问

4.注册中心&配置中心

对于微服务来说，不能由业务服务本身来维护其他关联服务实例通讯地址，于是有了注册中心的概念。
业务服务运行时，在注册中心进行注册，然后由注册中心维护具体的服务列表。

1.Eureka：

基础的配置中心，Server基于服务本身维护，通过Client的心跳维护服务列表

服务端组成：由微服务本身构成，引入Eureka-Server依赖后，成为服务端
服务列表维护机制：通过Client对Server发送的心跳判断存活
获取服务列表的方法：Client主动请求(Pull)

2.Nacos：

更加先进的注册中心模块，同时引入了配置中心功能，可由Web UI控制

服务端组成：独立的执行程序，可选独立模式/集群模式
服务列表维护机制：
- A.通过Client对Server发送的心跳判断存活
- B.对于非临时实例，Server将会主动调用Client来判断存活，失联时仅标记而不移除出服务列表
获取服务列表的方法：
- Client主动请求(Pull)，定时从注册中心获取，缓存至本地，消息可能不及时
- Server主动推送（Push），服务列表变动（服务失效）时主动推送，避免消息延时导致的服务通讯错误

对比Eureka提供的新功能：

引入服务集群和新的负载均衡策略：对服务的地域/可用区进行区分，Client使用NacosRule负载均衡策略时，对于同一个集群的服务，将优先内部调用，失效时才进行跨集群调用，并打印WARN日志
增加权重机制：
- 对于部署主机性能不同的服务，可以用于调整流量分布
- 可以通过权重分配，实现服务的阶段式替换更新上线，或小范围实验性运行测试
增加命名空间(namespace)，可以用于服务之间的隔离
增加了配置中心功能，可以用于服务配置的统一管理和配置的热更新

5.网关

对于用户侧发过来的请求，一般不允许直接与微服务实例进行通讯，需要由网关来进行先行处理。

主要职责：

路由(route)：由网关识别请求，来指向具体的微服务
过滤器(filter)：在此模块中可以通过过滤器，对请求进行验证或加工等

1.Gateway：

基于Spring5的WebFlux响应式编程，性能效率更高。

部署：引入gateway依赖包，与其他微服务一样在注册中心中注册，用户侧的请求都指向网关地址
路由：可以在配置文件中，定义一个路由表(routers)列表，在其中定义(id)路由ID、(url)服务指向URL（直接指向/lb动态均衡）、(predicates)路由断言匹配规则
过滤器：
- A.使用内置过滤器工厂规则，可以在路由表配置中为每个路由都定义过滤器(router-filters)，或直接定义默认过滤器(default-filters)
- B.对于更高级的过滤器，可以实现GlobalFilter接口，按需求自定义实现全局过滤器(global-filter)
跨域配置：配置文件中通过跨域配置项（globalcors）来对指定请求类型、来源、携带请求头、携带Cookies、跨域检测有效期等进行配置