Java微服务【1.1】：微服务概述

八戒，你又涨价了哎

已于 2024-09-10 22:04:06 修改

阅读量558

点赞数 2

分类专栏：微服务文章标签：微服务 eureka ribbon

于 2023-07-29 23:40:31 首次发布

本文链接：https://blog.csdn.net/hkzuz/article/details/131990403

版权

微服务专栏收录该内容

6 篇文章 0 订阅

订阅专栏

文章介绍了微服务架构与传统单体架构的区别，强调了微服务的低耦合和高扩展性。常见的微服务组件如注册中心、配置中心、网关等的作用被详细阐述，并提到了SpringCloud等微服务框架。服务拆分原则包括单一责任原则、高内聚低耦合等，通过实例展示了如何进行服务拆分。

摘要由CSDN通过智能技术生成

与传统单体架构比较

单体架构

传统的单体架构，将业务的所有功能集中在一个项目中开发，打成一个包部署。单体架构具有结构简单，部署成本低等优点，适合小型项目，单体架构的优点让其可不避免的产生了代码耦合度高，维护升级困难等缺点。

分布式架构

分布式架构的出现，解决了单体架构的缺点，每个业务功能模块作为独立项目开发，称为一个服务。

微服务架构作为分布式架构的一种，具有着服务低耦合，有利于服务升级和拓展的优点，是一种经过良好架构设计的分布式架构方案，适合大型互联网项目。但微服务架构关系调用复杂，维护，管理的成本较高

常见的微服务组件

注册中心：用于记录和管理各个微服务的信息，包括服务名称、IP地址、端口等，提供服务发现功能，常见的注册中心有Eureka、Consul和Zookeeper等。

配置中心：用于集中管理微服务的配置信息，如数据库连接、缓存配置等，常见的配置中心有Spring Cloud Config和Apollo等。

网关：作为整个微服务架构的入口，接收用户请求并进行路由、鉴权、负载均衡等操作，常见的网关有Spring Cloud Gateway和Netflix Zuul等。

分布式缓存：用于提高系统的性能和并发能力，常见的分布式缓存有Redis和Memcached等。

分布式数据库：用于存储和访问微服务的数据，常见的分布式数据库有MySQL集群、MongoDB和Cassandra等。

消息队列：用于实现微服务之间的异步通信，解耦服务间的耦合关系，常见的消息队列有Kafka和RabbitMQ等。

日志服务和监控链路追踪：用于记录和分析微服务的运行日志和性能指标，帮助进行故障定位和系统监控，常见的工具有ELK Stack（Elasticsearch、Logstash、Kibana）和Zipkin等。

分布式搜索：用于实现复杂的搜索需求，支持高并发和大规模数据索引，常见的分布式搜索引擎有Elasticsearch和Solr等。

微服务架构各组件作用介绍

微服务架构由许多服务模块组成，这些模块之间的调用关系变得错综复杂。为了解决服务模块之间关系难以记录的问题，引入了注册中心。注册中心用于标准化记录每个微服务的IP地址和端口，并提供服务发现功能。
每个服务模块都有自己的配置文件，通过配置中心进行统一管理。
用户通过网关来访问服务并进行身份验证，网关将用户的请求路由到相应的服务模模块
为了支持庞大的服务架构并发访问，引入了分布式缓存。
复杂的搜索需求由分布式搜索组件来实现。
服务模块之间的异步通信依赖消息队列，提高了服务的并发能力。
引入分布式日志服务和系统监控链路追踪功能，用于记录微服务运行过程中的日志和异常情况，帮助进行故障定位等。

分布式架构各组件关系图

微服务的架构特征

单一责任原则：每个微服务只负责一个具体的业务功能，通过拆分成多个小型服务来实现解耦和模块化。

松耦合：微服务之间通过明确定义的接口进行通信，彼此独立部署和扩展，使得系统更加灵活和可维护。

分布式管理：各个微服务可以独立地开发、部署、维护和扩展，使团队能够更好地并行开发，快速迭代更新。

弹性和容错：微服务架构通过使用断路器、负载均衡、容错机制等，可以实现高可用性和容错能力，提供稳定的服务。

自治性：每个微服务都是自治的，可以使用不同的编程语言、数据库、技术栈等，充分发挥团队的自主权和创造力。

服务发现和治理：微服务通过注册中心来实现服务的发现和注册，监控和管理微服务的状态、版本、依赖关系等。

事件驱动和异步通信：微服务架构可以通过事件驱动的方式实现不同服务之间的异步通信，提高系统的灵活性和性能。

容易扩展：由于微服务是独立部署和扩展的，可以根据具体需求对某些服务进行水平或垂直扩展，以满足业务需求或处理高并发。

常用微服务框架

Spring Cloud：基于Spring框架的微服务框架，提供了丰富的功能和组件，如服务发现、负载均衡、断路器等，包括Eureka、Ribbon、Feign、Hystrix等子项目。
Netflix OSS：由Netflix开源的一系列微服务框架和工具组成，包括Eureka（服务注册与发现）、Ribbon（客户端负载均衡）、Hystrix（容错和断路器）等。
Dubbo：阿里巴巴开源的分布式服务框架，具备高性能和轻量级的特点，支持服务注册与发现、负载均衡、远程调用等功能。
gRPC：由Google开发的跨语言的高性能RPC框架，使用Protocol Buffers作为接口定义语言，支持多种编程语言和平台。
ServiceComb：华为开源的微服务框架，提供了服务注册与发现、负载均衡、熔断器等功能，同时集成了一些监控和治理特性。
Istio：一个用于连接、管理和保护微服务的开源平台，提供流量管理、策略和安全性，基于Envoy代理。

服务拆分原则

了解了微服务后可以知道，微服务就是将大的项目拆分成无数个小项目模块，那么要怎么拆分呢？原则如下：

单一责任原则：每个微服务应该只负责一个具体的业务功能。拆分后的微服务应该聚焦于解决特定的问题，避免功能耦合。

高内聚低耦合：微服务内部的模块和组件之间应该高度内聚，模块之间的依赖关系应该尽可能的松散，减少相互影响。

能独立开发与部署：每个微服务应该能够独立地开发、测试、部署和扩展。这样可以实现团队的自治性，并且减少了对整体系统的影响。

界限上下文：根据领域驱动设计（DDD）的原则，将领域模型和业务逻辑划分为不同的界限上下文。每个上下文可以作为一个微服务的边界，实现高内聚的业务功能。

可独立扩展和替换：微服务架构应该支持水平扩展和垂直扩展，每个服务可以根据需要独立地进行扩展。此外，微服务的技术栈和实现可以随时替换，以适应新的需求和技术发展。

按业务价值优先：在拆分微服务时，应该优先考虑对业务价值的贡献。将核心的、高频使用的功能拆分为微服务，以提供更快的迭代和响应能力。

避免过度拆分与服务过多化：避免将功能过度拆分为过多的微服务，这样会增加系统的复杂性和维护成本。需要权衡业务需求和系统规模，找到合适的拆分粒度。

服务拆分举例：

一个音乐平台项目，就可以将服务拆分成用户服务，音乐服务，支付服务等，负责相关业务，都有自己的独立数据库。

当用户在客户端注册并创建一个新账户时，用户服务会将用户的账户信息保存到用户数据库中。

当用户登录到音乐平台时，用户服务会验证用户的身份并返回个人信息，例如用户名、头像等。

当用户搜索音乐时，客户端会发送请求给音乐服务，并从音乐数据库中查询相应的音乐信息。

当用户选择购买一首音乐，客户端会向支付服务发送支付请求，支付服务会处理相应的支付流程，并将购买记录保存到支付数据库中。