【微服务系列笔记】微服务概述

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 本文对比了单体应用和微服务架构。单体应用中所有功能模块在一个工程中,而微服务则按领域模型拆分为独立服务,每个服务有明确边界,可独立开发、部署和扩展。微服务允许使用不同语言和技术栈,每个服务有自己的数据库。微服务架构的优点包括易于开发维护、技术栈开放和错误隔离,但缺点包括增加运维成本、调用链路复杂、分布式事务处理困难以及学习成本高。实现微服务通常涉及SpringCloud等开发框架和Docker等运行平台。

1.单体应用与微服务架构区别

如上图左侧为单体应用架构。在传统单体应用中,所有功能模块都在一个工程中编码、部署,即使是集群部署,也只是单体应用的水平复制。

如上图右侧为微服务架构。在微服务架构的项目中,每个应用会按照领域模型划分进行业务、功能聚合,由此拆分后聚合的应用往往:模型高度统一、职责清晰且收敛、应用与应用(领域与领域)之间边界清晰,并且提升了每个应用的独立性、扩展性。

除了应用拆分维度,微服务架构也保证了每个应用可以使用独立语言开发、独立数据存储技术,只要能保持对外统一交互语言即可,存储模型差异如下:

见上图,应用拆分之后对应每个应用会独立、或共享一个数据库,数据库的拆分维度除了要考虑领域边界,还要更多的考虑每个数据库的QPS、TPS,避免高频写操作集中在一个DB,由此起到给数据库减压的功效。

基于上述分析,单体架构存在的问题主要集中在:功能混淆、边界模糊、维护成本高、可靠性差等角度,对于后续应用的升级、扩展同样存在瓶颈。因此随着互联网的发展,我们必须解决上述问题,而微服务就是这样一种架构模式。

2.什么是微服务

自2014年起,微服务架构由Martin Fowler、Adrain Cockcroft、Neal Ford等人接力进行介绍、完善、演进、实践后,一直维持着较高的热度直到现在,内容如下:

微服务架构是一种架构模式,它提倡将原本独立的单体应用,拆分成多个小型服务。这些小型服务各自独立运行,服务与服务间的通信采用轻量级通信机制(一般是基于HTTP协议的RESTful API),达到互相协调、互相配合的目的。被拆分后的服务都围绕着具体的业务进行构建,每个服务都能独立地进行开发、部署、扩展。由于相互独立,且采用轻量级通信机制,各个小型服务也能够使用不同的语言开发,也可以使用不同的数据存储技术。

微服务是一套经过漫长的架构演进、良好架构设计的分布式架构方案。从传统单体应用到分布式独立应用,从应用数据服务到引入缓存优化性能,从反向代理和CDN加速网站响应等等,技术架构不断演进的过程中,逐步出现前后端分离,数据读写分离,云原生、DDD领域驱动,最终孵化出如SpringCloud、SpringCloud Alibaba等成熟稳定的微服务架构方案。

微服务其主要特征:

  • 服务自治:团队独立、技术独立、数据独立、部署独立
  • 面向服务:微服务对外暴露业务接口,如RESTful API调用
  • 单一职责:每个应用领域边界清晰,功能职责单一,无重复工作

3.微服务优缺点

3.1 优点

①易于开发维护

微服务基于领域模型拆分的应用,其内部模型高度统一,功能相对内聚,开发人员只需要对固定模型进行领域业务接口封装即可。

②技术栈开放

微服务因独立部署、独立开发,因此开发团队可以根据资深团队特点进行技术选型。如团队擅长关系型数据库则MySQL,擅长图形计算则Neo4j。

③升级错误隔离

A技术专项升级因单独部署,不再影响整个分布式架构中全部功能,只影响有接口交互的部分应用,而这种应用也可以通过灰度、服务降级、服务熔断的方式兼容和处理,不会因一个错误导致整个应用瘫痪。

3.2 缺点

①运维成本高

更多的服务意味着更多的运维投入,传统应用中只有一个应用,而为服务中,需要保障几十、上百个服务的正常运行和协作。

②调用链路复杂

微服务架构中,不可避免的会出现A服务依赖B服务,B服务依赖C服务,C继续依赖D服务的场景,一旦A调用异常,排查链路可能会从A->B->C->D,才能最终发现服务报错具体信息(后续skywalking可解决)。

③分布式事务问题

同上例A->B->C->D的长链路调用过程中,如果A先修改自己数据,但下游C却异常,此时预期是A回滚自己事务,这一点在单体应用因都是本地事务可以很好做到,但是分布式场景下却提升了复杂度(后续Seata可解决)。

④学习成本高

微服务学习除了需要一定基础之外:Spring、SpringMvc、MyBatis、SpringBoot、Maven、MySQL等,还需学习SpringCloud,中间件、缓存、Docker、文件服务器等多种技术,每一门学习都有很多难点需要克服。

4.如何实现微服务架构

至此我们了解了微服务的定义、优缺点,还总结了一些指导性的原则,下面我们进一步探讨下,如何实现微服务架构。

4.1 技术选型

1.开发框架

可使用SpringCloud作为微服务开发框架,因为SpringCloud为微服务架构提供了完整的解决方案,同时文档丰富,社区活跃

当然借助于SpringBoot+Nacos+Dubbo等其他技术架构也可以实现微服务架构,但因SpringCloud丰富且完整的解决方案体系,作为新手学习笔者在此更推荐依此学习,此学习过程中涉及的理论在今后的工作中也一定大有帮助。

2.运行平台

微服务并不绑定运行平台,将微服务部署在PC server、阿里云、AWS等云计算平台都是可以的。出于轻量、灵活、应用支撑及现在市场主流部署模式,笔者选择Docker作为部署容器。

4.2 通用微服务技术架构图

5.总结

本文介绍了微服务基本概念、演变过程,主要的原则及优缺点,最后谈到了微服务的实现方案之一,作为引文此章节偏理论知识一些。后续笔者将借助具体技术实现带领读者一起逐步实现微服务架构体系。

目录
相关文章
|
1月前
|
SQL 关系型数据库 数据库
【微服务系列笔记】Seata
Seata是一种开源的分布式事务解决方案,旨在解决分布式事务管理的挑战。它提供了高性能和高可靠性的分布式事务服务,支持XA、TCC、AT等多种事务模式,并提供了全局唯一的事务ID,以确保事务的一致性和隔离性。Seata还提供了分布式事务的协调、事务日志、事务恢复等功能,帮助开发人员简化分布式事务的管理和实现。
52 1
|
1月前
|
负载均衡 安全 Java
【微服务系列笔记】Gateway
Gateway是Spring Cloud生态系统中的网关服务,作为微服务架构的入口,提供路由、负载均衡、限流、鉴权等功能。借助于过滤器和路由器,Gateway能够动态地管理请求流量,保障系统的安全和性能。
45 7
|
1月前
|
Linux Docker 容器
【微服务系列笔记】Docker
docker是一种容器技术,它主要是用来解决软件跨环境迁移的问题和同一环境下依赖冲突问题。 Docker可以运行在Mac, Windows, linux等操作系统上,常用于适用于构建和部署分布式应用、微服务架构。
49 0
【微服务系列笔记】Docker
|
1月前
|
监控 Java 应用服务中间件
【微服务系列笔记】Sentinel入门-微服务保护
Sentinel是一个开源的分布式系统和应用程序的运维监控平台。它提供了实时数据收集、可视化、告警和自动化响应等功能,帮助用户监控和管理复杂的IT环境。本文简单介绍了微服务保护以及常见雪崩问题,解决方案。以及利用sentinel进行入门案例。
48 3
|
1月前
|
负载均衡 Java Apache
【微服务系列笔记】Feign
Feign是一个声明式的伪HTTP客户端,它使得HTTP请求变得更简单。使用Feign,只需要创建一个接口并注解。Feign默认集成了Ribbon,并和Eureka结合,默认实现了负载均衡的效果。 OpenFeign 是SpringCloud在Feign的基础上支持了SpringMVC的注解。
57 8
|
1月前
|
存储 负载均衡 Cloud Native
【微服务系列笔记】Nacos
Nacos 是阿里巴巴开源的项目,用于构建云原生应用的动态服务发现、配置管理和服务管理平台。它支持动态服务发现、服务配置、服务元数据和流量管理,旨在更敏捷和方便地构建、交付和管理微服务平台。可作为注册中心与配置中心。
67 5
|
1月前
|
Nacos 微服务
【微服务系列笔记】Eureka
该文档介绍了微服务注册中心的重要性和流行选项,如Eureka、Nacos、Consul和Zookeeper,强调Eureka是唯一支持跨区域调用的AP系统。接着,它提供了一个Eureka入门案例,包括设置Eureka服务器和客户端的步骤,并展示了多实例部署的效果。最后,简要总结了学习Eureka的意义,并提出了几个思考问题,如Eureka的功能、工作原理以及其他服务发现技术。
47 5
|
1月前
|
负载均衡 算法 应用服务中间件
【微服务系列笔记】负载均衡
本文介绍了负载均衡的概念和重要性,指出随着流量增长,通过垂直扩展和水平扩展来提升系统性能,其中水平扩展引入了负载均衡的需求。负载均衡的目标是将流量分布到多台服务器以提高响应速度和可用性,常见的硬件和软件负载均衡器包括F5、A10、Nginx、HAProxy和LVS等。 文章接着提到了Ribbon,这是一个客户端实现的负载均衡器,用于Spring Cloud中。Ribbon在发起REST请求时进行拦截,根据预设的负载均衡算法(如随机算法)选择服务器,并重构请求URI。文中还介绍了如何通过代码和配置文件两种方式自定义Ribbon的负载均衡策略。
69 3
|
1月前
|
消息中间件 Java API
【微服务系列笔记】MQ消息可靠性
消息可靠性涉及防止丢失,包括生产者发送时丢失、未到达队列以及消费者消费失败处理后丢失。 确保RabbitMQ消息可靠性的方法有:开启生产者确认机制,确保消息到达队列;启用消息持久化以防止未消费时丢失;使用消费者确认机制,如设置为auto,由Spring确认处理成功后ack。此外,可开启消费者失败重试机制,多次失败后将消息投递到异常交换机。
48 1
|
1月前
|
负载均衡 监控 Java
微服务课程之SpringCloud 概述及微服务搭建
微服务课程之SpringCloud 概述及微服务搭建
51 0