遇到面试官问微服务架构设计到底该如何回答?
👉 这是一个或许对你有用的社群
🐱 一对一交流/面试小册/简历优化/求职解惑,欢迎加入「芋道快速开发平台」知识星球。下面是星球提供的部分资料:
《项目实战(视频)》:从书中学,往事上“练” 《互联网高频面试题》:面朝简历学习,春暖花开 《架构 x 系统设计》:摧枯拉朽,掌控面试高频场景题 《精进 Java 学习指南》:系统学习,互联网主流技术栈 《必读 Java 源码专栏》:知其然,知其所以然
👉这是一个或许对你有用的开源项目
国产 Star 破 10w+ 的开源项目,前端包括管理后台 + 微信小程序,后端支持单体和微服务架构。
功能涵盖 RBAC 权限、SaaS 多租户、数据权限、商城、支付、工作流、大屏报表、微信公众号、CRM 等等功能:
Boot 仓库:https://gitee.com/zhijiantianya/ruoyi-vue-pro Cloud 仓库:https://gitee.com/zhijiantianya/yudao-cloud 视频教程:https://doc.iocoder.cn 【国内首批】支持 JDK 21 + SpringBoot 3.2.2、JDK 8 + Spring Boot 2.7.18 双版本
为什么要做微服务?
微服务一直是近几年的技术热点,凡是谈到架构设计,毫无疑问都离不开微服务这个话题。无论是做架构设计,还是只是做业务开发,几乎在所有的面试中,微服务设计几乎是必问的一道面试题。另外,在我们的实际工作中,几乎百分之80的公司,微服务也都是架构演变升级的方向。那么,为什么要做微服务呢?微服务的出发点是什么呢?
单体架构达到瓶颈
业务复杂度上升,扩展困难,维护费力度上升,牵一发动全身 团队规模扩大,开发冲突增多,开发效率降低,无法兼容多种编程语言 性能受到制约,在服务可靠性、吞吐能力、服务部署等方面达到瓶颈
优化架构,更新换代
保证技术架构的鲜活度,不与主流脱轨 不断的调整技术建设,支撑内部技术发展 更好的架构体系,更有力的支撑业务需求
跟随潮流,为了微服务而微服务
为了紧跟潮流,别人搞我们也要搞 为了体验下微服务架构的魅力 为了自己实操一把,掌握微服务技术
微服务的出发点必定是为了解决架构层面遇到的问题,微服务是分而治之的思想。它通过引入更分散的架构思想,从而来解决更复杂的系统问题。所以,微服务并不是所有系统都适用的。在考虑微服务架构的时候,我们得先评估下是否真的需要?从单体到微服务是一个复杂化的过程,如果非必要不微服务。最近,大有微服务合并转向单体的趋势。只有我们的系统在业务复杂度层面、系统性能层面、团队开发协作层面等有了确切的需求,那么微服务确实是不二之选。
基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
项目地址:https://github.com/YunaiV/ruoyi-vue-pro 视频教程:https://doc.iocoder.cn/video/
微服务到底是什么?
微服务(Microservices)是一种软件开发架构风格,它将一个复杂的应用程序构建为一系列小型服务的集合,每个服务运行在其独立的进程中,并通常围绕特定的业务能力进行构建。这些服务可以通过定义良好的API进行通信,通常是HTTP RESTful API或轻量级的消息传递系统。
微服务的核心特点包括:
小型化和轻量级:每个服务都相对较小,只关注特定的业务功能。 独立部署:各个微服务可以独立部署,不需要依赖其他服务。 独立扩展:可以根据需求独立扩展或收缩特定的服务。 技术多样性:团队可以根据服务的特定需求选择最适合的技术栈,包括编程语言和数据存储等。 业务中心化:每个服务都围绕一项业务能力构建,易于理解和维护。 敏捷性:微服务架构提高了开发和部署的速度,使得快速迭代和持续交付成为可能。 容错性:系统中某个服务的故障不会导致整个系统的崩溃,提高了系统的稳定性。 去中心化治理:没有统一的控制中心,服务之间的调用和数据流是去中心化的。 去中心化数据管理:每个服务可以有自己的数据库,实现数据的封装和隔离。 基础设施自动化:自动化的部署、扩展、监控和故障恢复是微服务架构的关键。
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
项目地址:https://github.com/YunaiV/yudao-cloud 视频教程:https://doc.iocoder.cn/video/
我们到底如何进行微服务拆分?
拆分是没有完全标准的答案和方式,每家公司或者每个团队拆分的微服务方式可以说是各不相同。但拆分必然有相同的部分,有一些必然需要参考的准则和拆分方式。这些就是我们所需要掌握的,包括面试时候所需要回答出来的点。
微服务拆分原则
单一职责原则:每个服务应该有一个清晰定义的职责,并且只负责一个特定的业务功能。 业务能力对齐:服务应该围绕业务能力构建,确保每个服务都是一个可独立部署和扩展的业务单元。 独立性:每个服务应该是独立的,拥有自己的代码库、数据库和部署流程。 轻量级通信:服务之间的通信应该是轻量级的,避免使用重量级的通信协议。 数据隔离:每个服务应该有自己的数据存储,避免服务之间的数据依赖。 去中心化治理:允许每个服务独立选择技术栈和框架。 容错性:服务应该能够容忍其他服务的故障,通常通过断路器模式实现。 敏捷性:服务应该能够快速迭代和部署,以适应快速变化的业务需求。 智能端点和哑管道:服务之间通过简单的管道通信,而业务逻辑应该封装在端点中。 API 网关:使用API网关来提供统一的入口,处理跨服务的请求路由、负载均衡和安全控制。 持续集成和持续部署(CI/CD) :自动化的构建和部署流程对于微服务架构至关重要。 监控和日志:实现集中的监控和日志管理,以便于跟踪和诊断跨服务的问题。 团队自治:每个服务的开发团队应该有足够的自治权,以快速响应业务需求。 服务发现:实现服务发现机制,以便服务实例可以相互发现并进行通信。 断路器模式:使用断路器模式来防止级联故障,并提高系统的稳定性。 异步消息传递:在可能的情况下,使用异步消息传递来解耦服务。 版本控制:为服务和API实现版本控制,以支持向后兼容性。 安全性:确保每个服务都有适当的安全措施,包括认证和授权。 文档和API管理:为API提供详细的文档,并管理API的变更。 避免远程调用:尽量避免远程服务调用,优先考虑本地服务调用。 服务边界清晰:服务之间的边界应该清晰定义,避免功能重叠。 避免共享服务:避免创建共享服务,因为它们可能导致服务间的耦合。 可替换性:设计服务时,应考虑到将来可能的替换或升级。 环境一致性:确保开发、测试和生产环境尽可能一致,以减少环境差异导致的问题。 配置管理:实现集中的配置管理,以便于跨服务的配置变更。 服务契约:定义清晰的服务契约,包括API和数据格式。 性能和可伸缩性:在设计服务时,考虑性能和可伸缩性需求。 避免过度拆分:避免过度拆分服务,导致过多的服务管理和通信开销。
微服务拆分方式
按业务拆分
这是最常见的拆分方式,根据业务功能的不同将应用程序划分为不同的服务。每个服务对应一个特定的业务领域,例如用户管理、订单处理、库存管理等。
优点:
服务之间界限清晰,易于管理和维护。 每个服务可以独立部署和扩展。
缺点:
需要良好的业务领域分析和规划。
按复用度拆分
根据服务的复用程度进行拆分,将那些在多个地方被使用的通用功能(如认证、日志记录、配置管理)划分为独立的服务。
优点:
提高代码复用性。 便于统一管理和更新通用功能。
缺点:
过度拆分可能导致服务之间的依赖性增加。
按冷热拆分
根据服务的使用频率以及业务复杂度、需求频率,将高频率(热)服务和低频率(冷)服务分开部署。热服务可能需要更多的资源和优化、以及更频繁的服务发布。
优点:
可以根据服务的实际使用情况优化资源分配。 冷热分离有助于提高系统整体性能。 有助于保持系统稳定性。
缺点:
需要准确评估服务的使用频率。
按吞吐量拆分
根据服务的吞吐量需求进行拆分,将那些需要高吞吐量处理的服务单独拆分出来,以便进行专门的优化和扩展。
优点:
可以根据服务的性能需求进行资源分配和优化。 有助于确保关键服务的性能。
缺点:
需要对服务的性能特性有深入的了解。
按团队架构拆分
根据团队的组织结构和开发能力进行服务拆分,每个团队负责一个或多个服务的开发和维护。
优点:
提高团队的责任感和开发效率。 便于团队内部协作和知识共享。
缺点:
可能导致团队间的沟通和协调成本增加。
微服务与DDD领域驱动设计
微服务与DDD的关系
业务边界的确定:DDD通过战略设计帮助确定业务边界,这些边界可以直接映射到微服务的划分上。每个限界上下文(Bounded Context)通常对应一个微服务。 高内聚低耦合:DDD提倡高内聚的领域模型,这与微服务追求的高内聚、低耦合的服务设计原则相吻合。 持续演进:DDD鼓励通过不断的迭代来演进领域模型,这与微服务架构中服务的持续集成和持续部署(CI/CD)的理念相符。 技术与业务的对齐:DDD通过统一语言(Ubiquitous Language)促进业务专家与开发人员之间的沟通,而微服务架构则通过服务的独立性支持快速响应业务变化。 独立部署和扩展:DDD中的每个限界上下文都可以独立部署和扩展,这与微服务的独立部署和扩展原则一致。 领域事件:DDD中的领域事件可以用来触发微服务间的通信,实现服务间的松耦合。 抗腐层:在微服务架构中,DDD的反腐层概念可以帮助维护服务间的清晰界限,确保服务的独立性和稳定性。
在实践中,DDD可以帮助团队更好地理解和建模业务领域,而微服务架构提供了实现这些模型的技术手段。通过DDD的领域模型,可以更容易地识别出微服务的职责和边界,从而设计出更灵活、可维护和可扩展的系统。
说白了,DDD诞生了20多年了,之前一直不温不火是因为DDD很难落地。但随着微服务的出现,DDD思想与微服务非常契合,2者相辅相成,DDD成为了微服务拆分的指导思想,而微服务有着完善的落地技术方案。DDD通过聚焦业务模型,强调明确清晰的业务边界,划分出多个限界下上文,通过定义具体的实体、值对象、聚合根把业务模型分的明明白白,这不就是微服务划分业务服务最好的军师吗?
微服务与其他架构模式的区别
微服务架构与传统的单体架构、分布式架构和Serverless架构有显著的不同。以下是微服务架构与其他架构的区别:
微服务架构 vs 单体架构
单体架构:
应用程序的所有功能模块都打包在一起,作为一个单一的单元运行。 通常难以维护和更新,因为任何更改都需要重新部署整个应用。 技术栈统一,整个应用通常使用相同的编程语言和技术。
微服务架构:
应用程序被分解为一系列小型服务,每个服务运行在自己的进程中,并通常围绕特定的业务功能构建。 易于开发和维护,因为每个服务都是独立的,可以单独部署、升级和扩展。 技术多样性,不同的服务可以使用不同的编程语言和技术栈。
微服务架构 vs 分布式架构
分布式架构:
应用程序被拆分成多个模块,这些模块运行在不同的服务器上,并通过网络通信。是一个更广泛的概念,已经存在了很长时间,涉及多个计算机或节点协同工作完成复杂任务。 指的是系统的组件分布在不同的物理位置,但作为一个整体协同工作。分布式系统不一定涉及服务的拆分,它更侧重于组件之间的通信和协作。
微服务架构:
虽然微服务架构也是分布式的,但它更侧重于服务的独立性、灵活性和敏捷性。 微服务架构是分布式系统架构的一种特殊形式,它专注于更细粒度的服务拆分和独立部署
微服务架构 vs Serverless架构
Serverless架构:
在Serverless架构中,开发者不需要管理服务器,而是将代码部署到云平台上,由云平台负责运行和扩展。 通常以函数为单位,按需运行,按实际使用量计费。
微服务架构:
微服务通常长期运行,提供持续的服务,而Serverless架构中的函数是事件驱动和短暂运行的。 微服务架构可能需要更多的运维工作,因为每个服务都需要独立管理和部署。
微服务架构 vs Soa架构
微服务架构和SOA(面向服务的架构)都是设计软件系统的方法,它们在多个方面有相似之处,但也存在一些关键的区别:
服务粒度:
微服务:通常具有更细的粒度,每个服务都非常专注,以至于可能只有一个单一的职责或功能23。 SOA:服务粒度较粗,可以包含多个功能,服务组件的大小可以从小型应用程序服务到非常大型的企业服务23。
通信方式:
微服务:倾向于使用轻量级的通信机制,如HTTP RESTful API或轻量级的消息传递系统12。 SOA:可能使用更复杂的协议,如WebService BPEL(业务流程执行语言),并且常通过ESB(企业服务总线)进行服务间的通信和集成12。
架构划分方式:
微服务:强调按垂直架构划分,按照业务能力将系统拆分成独立的服务,每个服务完成一种特定的功能,服务即产品3。 SOA:更注重按水平架构划分,将系统划分为前端、后端、数据库和测试等不同的层次
微服务架构 vs Service Mesh
微服务和Service Mesh是云原生架构中的两个重要概念,它们在软件架构和部署上有不同的关注点和作用:
微服务(Microservices):
微服务是一种架构风格,它将一个大型复杂软件应用分解为一组小型、独立的服务,每个服务运行在自己的进程中,并通常围绕特定的业务功能构建。 微服务之间通过定义良好的API进行通信,通常是HTTP RESTful API或轻量级的消息传递系统。 微服务架构的优点包括降低系统复杂度、松耦合、跨语言开发、独立部署等。
Service Mesh(服务网格):
Service Mesh是微服务架构中的一个基础设施层,专门用于处理服务间的通信。它通过使用“sidecar”代理模式,使得服务通信的细节(如发现、负载均衡、故障恢复、度量和监控、安全性等)对应用层透明。 Service Mesh的典型实现包括Istio、Linkerd、Consul等,它们通常以轻量级代理的形式与应用服务一起部署,而不需要应用代码的更改。 Service Mesh解决了微服务架构中的一些挑战,如服务发现、配置管理、流量控制和故障处理等。
主要区别:
关注点:微服务关注的是将应用拆分成独立部署的小型服务,而Service Mesh关注的是这些服务间的通信和治理。 实现:微服务可以通过各种技术栈实现,而Service Mesh通常需要特定的基础设施支持,如Istio或Linkerd。 透明性:Service Mesh通过代理抽象了服务通信的复杂性,对应用层是透明的,而微服务架构中,服务通信的实现细节通常需要开发者自行处理。 治理:Service Mesh提供了一套完整的服务治理功能,如流量控制、安全认证、监控等,这些在微服务架构中可能需要额外的工作来实现。
微服务架构是一种将应用分解为独立服务的方法,而Service Mesh是支持微服务的通信和治理的基础设施层。Service Mesh可以视为微服务架构的进化,它解决了微服务架构中的一些复杂问题,使得开发者可以更专注于业务逻辑的实现。微服务架构适合于需要高扩展性和灵活性的复杂应用,而Serverless架构适合于无状态的、事件驱动的应用场景。选择哪种架构取决于项目的具体需求、团队的技术能力以及期望的运维复杂度。
微服务中的常见技术实现方案
服务间通信:
RESTful API:使用HTTP协议和JSON或XML格式进行服务间通信。 gRPC:一个高性能的RPC框架,使用Protocol Buffers作为接口定义语言。 Apache Thrift:Facebook开发的一套RPC通信框架,支持多种语言。 Apache Avro:Apache的一个项目,提供了RPC和数据序列化的功能。 Apache Dubbo:Alibaba开源的高性能Java RPC框架。
消息队列:
Kafka:一个分布式流处理平台,广泛用于构建实时数据管道和流式应用。 RabbitMQ:一个开源的消息代理,也称为消息队列。 Amazon SQS:Amazon提供的一个完全托管的消息队列服务。 Google Pub/Sub:Google Cloud提供的事件驱动的异步服务到服务通信。 Apache Pulsar:一个云原生分布式消息流平台。
服务注册与发现:
Eureka:Netflix开源的服务注册与发现组件。 Consul:提供服务发现和配置共享。 Apache Zookeeper:一个分布式协调服务,可用于服务注册与发现。 etcd:一个分布式键值存储,用于配置共享和服务发现。 Nacos:Alibaba开源的更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
配置管理:
Spring Cloud Config:Spring Cloud的配置管理工具。 Consul K/V:Consul的键值存储,可用于存储配置信息。 Apache ZooKeeper:可以用作分布式配置存储。 etcd:除了服务发现,也常用于配置管理。 Config Server:Spring Cloud Netflix的配置中心组件。
API网关:
Zuul:Netflix开源的API网关服务。 Kong:一个云原生API网关,提供API管理、开发平台和DevOps解决方案。 Amazon API Gateway:AWS提供的一个完全托管的服务,用于创建、发布、维护、监控和保护API。 Nginx:一个高性能的HTTP服务器和反向代理,也可以作为API网关使用。 Traefik:一个开源的边缘路由器,支持API网关功能。
认证鉴权:
OAuth 2.0:一个行业标准的协议,用于授权。 OpenID Connect:基于OAuth 2.0的认证层。 Apache Shiro:一个强大且易于使用的Java安全框架。 Spring Security:为Java应用程序提供认证和访问控制。 JWT (JSON Web Tokens):用于在双方之间安全地传输信息。
日志监控:
ELK Stack(Elasticsearch, Logstash, Kibana):用于集中日志收集和可视化。 Prometheus:开源监控和警报工具。 Grafana:一个跨平台的开源分析和监控解决方案。 Fluentd:一个开源的数据收集器,用于统一日志数据收集和消费。 Graylog:提供数据收集、索引和实时搜索的日志管理平台。
持续集成与部署:
Jenkins:一个开源的持续集成工具。 GitLab CI/CD:GitLab内置的持续集成和持续部署工具。 CircleCI:提供自动化的持续集成和持续部署服务。 Travis CI:一个持续集成服务,支持GitHub。 Spinnaker:一个开源的、多功能的持续交付平台。
断路器:
Hystrix:Netflix开源的断路器库,用于容错。 Resilience4j:轻量级的容错库,灵感来自Hystrix。 Sentinel:Alibaba开源的轻量级流量控制、熔断和系统保护开源库。 Spring Retry:Spring提供的一个简单的自动重试机制。 Polly:一个提供断路器功能的库,支持多种语言。
分布式追踪:
Zipkin:一个分布式追踪系统。 Jaeger:由Uber开发的分布式追踪系统。 SkyWalking:一个开源的APM系统,用于分布式系统的追踪、监控和诊断。 OpenTelemetry:一个用于观测分布式系统的工具,提供追踪、度量和日志。 AWS X-Ray:AWS提供的一个服务,用于分析和调试分布式Web应用程序。
容器化和编排:
Docker:用于开发、发布和运行应用程序的容器化平台。 Kubernetes:一个开源平台,用于自动部署、扩展和管理容器化应用程序。 Apache Mesos:一个集群管理器,提供有效的资源隔离和共享。 Amazon ECS:AWS提供的容器管理服务。 Nomad:HashiCorp开发的一个容器编排工具,用于管理容器化和非容器化应用程序的部署。
总结
微服务架构现在依旧是架构设计的主流,微服务分而治之的思想永不过时。 架构是从简单到复杂的一个过程,架构设计是为了把复杂变得尽量简单,所以能用单体就单体,不要盲目微服务,随之带来的可能不是微服务的好处,而是成本。 DDD是微服务拆分的指导思想,它以业务为王,只关心于业务模型本身。 微服务拆分按业务是基础,在业务之上还可以按照业务复杂度、变动频率、吞吐量、以及团队情况等进行多维度的拆分。服务的人员分配可参考3个火枪手原则。 好的架构一定是边界清晰、职责明确、规范统一、修少扩多(原先代码需要修改的少、扩展新增的多)、链路明朗、适配灵活、伸缩自如、高内聚低耦合。
欢迎加入我的知识星球,全面提升技术能力。
👉 加入方式,“长按”或“扫描”下方二维码噢:
星球的内容包括:项目实战、面试招聘、源码解析、学习路线。
文章有帮助的话,在看,转发吧。
谢谢支持哟 (*^__^*)
微信扫码关注该文公众号作者