一文带你搞懂微服务架构深度解析：微服务的采用前提，技术与理念

2401_84438893

于 2024-04-21 12:05:05 发布

阅读量841

点赞数 8

分类专栏： 2024年程序员学习文章标签：架构微服务服务器

本文链接：https://blog.csdn.net/2401_84438893/article/details/138029634

版权

2024年程序员学习专栏收录该内容

17 篇文章 0 订阅

订阅专栏

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注Java）

正文

面向服务

====

大部分企业选择微服务架构是业务驱动的。对于基于传统J2EE技术栈的Web项目而言，早期单体架构就是所谓的“一个War包打天下”，将应用程序的所有功能都打包成一个独立的War包，部署在Tomcat的指定目录下就可以顺利运行。然而，软件项目是一个不断迭代和变化的过程，业务模块的增加、功能的扩展、人员的更迭、需求的变动最终都需要修改代码来实现。于是代码跟随版本的不断升级而逐渐膨胀变得难以维护。单体架构的灵活性、可扩展性、可运维性都明显下降，开发人员效率降低、系统稳定性变差、局部小问题导致“牵一发而动全身”。

在这种情况下，单体架构为了保证程序内部的高内聚、低耦合，引入了分层的架构模式。分层架构在某种程度上解决了不同类型代码的逻辑耦合问题，模块之间有了更加清晰的职责划分，降低了单体架构的整体复杂度。而分层架构的问题是没有聚焦当前业务逻辑，以技术为导向的架构形态很难做到服务的复用，业务模块无法独立部署和演进。

微服务的理念与SOA服务架构是一脉相承的，微服务架构同样强调面向服务，将一个大的“问题空间”通过领域建模拆解分为实体之间的关系和行为，使用限界上下文（Bounded Context）将实现细节封装起来，让服务可以独立伸缩，每个服务都有明确的边界。

在面向业务构建微服务时，我们不应该把主要的关注点放在是采用 Tomcat 还是 Jetty 应用容器上，也不应该放在 Spring Cloud 、Docker、RPC这些技术概念或框架上。微服务架构首先要考虑的是解决业务的问题。在开始微服务架构转型之前，请先理解业务，洞察业务边界、职责划分，让团队专注于实现某个特定的应用服务。微服务需要根据一定的软件设计原则来实现面向服务的架构模式，本文在微服务构建章节会深入讲解领域驱动设计如何帮助我们对系统进行合理的服务划分，如何拆解、聚合以实现服务的开发和复用。另外，面向服务的系统的服务边界划分需要我们格外注意，因为错误的服务领域划分将会使服务陷入大量的远程调用和分布式事务中，在这种情况下，微服务给整个系统带来的不是便利而是麻烦。

底座技术

====

从效率的角度出发，微服务架构需要配套的技术栈和技术底座支撑。目前，很多一线互联网公司已经成功基于底座技术实现了微服务架构的落地和实践。

技术选型是落地微服务架构的关键环节，公司在落地微服务架构的过程中，不仅仅要关注技术本身，更重要的是结合自己公司的技术现状和人员技术背景，根据已有的技术栈来进行微服务架构的落地和实践。

从技术选型的角度出发，我们需要根据一定的优先级来考虑：需求满足度、社区活跃度、技术掌控能力。

● “需求满足度”是最重要的因素，因为技术和架构最根本的动机还是满足业务的需求，如果一项先进的技术没有满足用户的需求，则这项技术将失去发展的动力。

● “社区的活跃度”是非常重要的参考，因为社区的活跃度代表了这项技术被广大开发者接受的程度和这项技术的广泛度和生命力。对于技术薄弱的公司，最好采用在一线互联网公司落地并且在社区内拥有良好口碑的开源产品。因为这些技术已经在大企业中经过了生产环境的验证，并且有良好的社区生态，可以得到更多的技术支持。当然，有实力的公司会选择通过自研的方式落地微服务架构，而对于小规模团队，还是建议采用社区的技术框架落地微服务架构，一方面可以不用从头开始，另一方面，也会降低公司的整体学习成本。

● 同时，需要考虑公司人员的技术掌控能力。例如，如果一个框架使用C语言实现了微服务架构，虽然在性能上有优势，但整个团队没有懂C语言的开发者，那么就需要重新考虑是否有其他的替代技术方案。

基于Spring社区的影响力，目前可以认为Spring Boot是构建Java微服务架构的事实标准；另外，Dubbo是阿里多年的生产级分布式微服务实践的技术结晶，Dubbo本质上是一套基于Java的RPC框架，服务治理能力非常强，在国内技术社区中具有很大的影响力。还有ApacheServiceComb等国内外知名微服务框架，这里就不再赘述。

架构技术

====

单体架构被拆分为微服务后，需要解决众多服务的治理及复杂度管控问题。微服务存在领域模型建设、服务边界划分、服务与服务之间的依赖、服务交互集成、独立数据管理等问题，针对这些，我们需要优化我们的架构设计理念和设计方法。

领域驱动设计

Eric Evans在《领域驱动设计》一书中对不同公司的业务应用程序中遇到的复杂问题进行了总结，帮助我们在现实世界中进行建模。

他为领域驱动设计提出了大量的最佳实践和经验技巧：

● 领域驱动设计方法有利于软件开发团队与业务部门或领域专家密切合作，使开发人员与业务人员达成共识。

● 技术人员和业务专家应该首先进行领域建模，找到有界的上下文和相关的核心域，以及普遍存在的语言、子域、上下文映射，用于简化软件项目的复杂度，使得设计思路能够更加清晰、设计过程更加规范。

对于微服务架构而言，它和领域驱动设计同样关注业务。领域驱动设计理念聚焦于领域建模、实体、边界划分、界限上下文。领域驱动设计非常适合从业务上去划分微服务的边界，定义服务对外暴露的接口。每一个微服务都应该是一个可以独立开发、部署、运行的自治主体。可以说，领域驱动设计是指导微服务架构设计、解耦业务、服务拆分、服务构建的关键原则。

前后端分离技术

微服务倡导专业分工，每个组件都专注于各自的业务领域。而大部分软件，尤其是面向企业领域的系统基本都是由前端和后端服务组成的。将前后端分离作为切入点，我们可以轻松地开启微服务化改造之旅。下面是微服务架构进行前后端职责划分的主要规则：

● 技能分离，前后端可以使用不同的特定语言或框架来实现最佳的微服务实践。

● 职责分离，前端主要负责和用户的交互逻辑，后端主要负责业务逻辑和资源的管理。

● 部署分离，前端和后端可以做到独立发布，不存在发布过程的耦合，前端和后端可以根据约定的API进行版本迭代和独立演进。

前后端分离架构有利于将微服务在技术层面上解耦，后端微服务可以专注于实现对后端服务和资源的管理，而不用再关注与用户交互的逻辑验证等问题。

前后端分离有利于微服务中的各组件的演进和组合，微服务架构细粒度的服务可以让不同前端共享不同后端，通过“搭积木”的方式实现服务的复用和独立的演进，如下图所示。

一文带你搞懂微服务架构深度解析：微服务的采用前提，技术与理念

事件驱动技术

在单体架构下，系统的复杂性在于如何做好模块之间的解耦，因为模块依然存在于同一个进程中，实现进程内的并发处理和多线程模型的管理是单体架构的主要工作。所以单体架构的瓶颈往往是CPU，不适合网络I/O密集型的计算处理场景。而在微服务架构下，因为细粒度的服务之间的交互主要通过分布式网络进行，而事件驱动架构为微服务提供了更多的跨网络集成优势。

● 基于事件的体系结构是异步的，不存在网络阻塞。在提供服务之前，我们必须考虑网络的局限性。选择REST同步调用方式存在服务调用依赖问题，会产生级联消息雪崩效应，而选择事件机制我们不用担心同步调用的问题。

● 基于消息队列的异步消息处理机制。相比请求/响应模式的服务集成方式，采用Broker代理的服务集成方式可实现服务之间的解耦，同时可以提高服务的性能、可靠性、可扩展性。

然而，事件驱动框架也会在消息一致性、消息的监控和传输上给系统带来额外的技术复杂性。

● “协同”优先“编排”原则。事件编排机制会由“中心大脑”

来领导并驱动整个流程，这个大脑就像交响乐队中的指挥；事件协同机制会预先说明清楚系统中各个部件的职责，而把具体怎么实现留给各个部件。总的来说，事件编排机制的缺点是明显的，中心控制点承担了太多职责，它会成为网状结构的中心枢纽。而事件协同机制不仅可以降低系统的耦合性，还可以让我们以更加灵活的方式修改现有系统。

● CQRS（Command and Query Responsibly Separate，命令查询职责分离），是介于脚本驱动和领取驱动之间的一种服务建模与数据交互模式，是事件驱动领域中被广泛使用的一个概念，通过CQRS可以解决数据读写交叉问题，并能有效降低业务逻辑的复杂性。

服务监控与治理

=======

在单体架构时代，因为所有服务都集中在少数几个系统中，系统之间的相互调用关系相对简单，在出现故障时，可以将问题根源锁定在有限的系统范围内并定位问题。而在微服务架构下，众多微服务实例之间有频繁的分布式跨网络协作、相互远程调用，这时如果没有一整套服务治理方法，帮助我们保证SLA（Service-Level Agreement，服务等级协议）、增强服务治理水平、提升微服务的治理与运维效率，那么微服务的转型之路将举步维艰。

技术团队关注的焦点往往是架构的实现和业务建模，容易忽略微服务架构带来的一系列负面影响，通过微服务监控与治理可以全方位地掌控当前服务的运行状态和资源利用情况，可以说，服务治理与监控既是微服务架构在平台层面的核心工作，也是微服务应用“长治久安”的前提。通过微服务治理能力的提升，可以提供对业务应用的快速响应能力、保证业务的健康稳定及持续演进；在技术上，可以帮助微服务的开发和运维人员实时地掌握微服务的运行状态，以及进行问题定位和故障恢复。

在服务治理的技术选型上，Spring Cloud提供了服务治理的一站式解决方案。同时，微服务框架结合众多技术组件可以提供Metrics指标监控、日志监控、调用链等信息监控、健康检查和告警通知等功能。Metrics监控主要依赖于时间序列数据库，目前较成熟的产品有Prometheus 和 OpenTSDB；我们可以采用 ELK （ Elasticsearch 、Logstash、Kibana三个技术框架缩写）技术栈实现日志的归集、存储、搜索和可视化报表查看等；可以采用Spring Cloud Sleuth日志收集工具包，结合Zipkin和HTrace，作为Spring Cloud的一种分布式追踪解决方案。

容器和自动化技术

========

容器和自动化技术可以说是微服务规模化发展需要解决的首要问题。基于容器的部署和交付无论在软件开发领域，还是运维相关领域，都带来了巨大的技术颠覆。通过自动化交付部署可以将开发与运维环节打通。交付物的标准化使得我们可以“标准化”地交付应用及它所依赖的运行环境。Docker容器一次构建、多次交付的特性可以使微服务具备了更好的可移植性、可复用性。

很多人把容器化和微服务架构混为一谈，认为自己的服务部署到了容器后，系统就是一个微服务架构了。其实二者存在本质上的差异。可以说，一个巨石型单体架构即使部署到了容器上，依然无法改变它架构上的“拙劣”。

目前容器技术仍然是微服务架构最佳的运行时环境和平台，也很好地支撑了微服务架构去中心化、细粒度、容错、伸缩的特性。如下图所示，是虚拟机与容器不同的隔离机制。

一文带你搞懂微服务架构深度解析：微服务的采用前提，技术与理念

虚拟机

一文带你搞懂微服务架构深度解析：微服务的采用前提，技术与理念

容器

使用传统虚拟机的应用存在如下运维弊端：

● 部署非常慢、成本非常高、资源浪费。

学习分享，共勉

这里是小编拿到的学习资源，其中包括“中高级Java开发面试高频考点题笔记300道.pdf”和“Java核心知识体系笔记.pdf”文件分享，内容丰富，囊括了JVM、锁、并发、Java反射、Spring原理、微服务、Zookeeper、数据库、数据结构等大量知识点。同时还有Java进阶学习的知识笔记脑图（内含大量学习笔记）！