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容器一次构建、多次交付的特性可以使微服务具备了更好的可移植性、可复用性。
很多人把容器化和微服务架构混为一谈,认为自己的服务部署到了容器后,系统就是一个微服务架构了。其实二者存在本质上的差异。可以说,一个巨石型单体架构即使部署到了容器上,依然无法改变它架构上的“拙劣”。
目前容器技术仍然是微服务架构最佳的运行时环境和平台,也很好地支撑了微服务架构去中心化、细粒度、容错、伸缩的特性。如下图所示,是虚拟机与容器不同的隔离机制。
虚拟机
容器
使用传统虚拟机的应用存在如下运维弊端:
● 部署非常慢、成本非常高、资源浪费。
● 难以迁移和扩展。
● 服务与硬件厂商提供的特性绑定。
使用容器对微服务架构进行自动化运维的优势:
● 容器的资源开销更小,Docker本身共享操作系统内核,容器可以节省更多物理机资源。
● 在开发和运维之间搭建了一座桥梁,是实现DevOps的最佳方案。
● 容器可以对软件和其依赖的标准镜像格式打包,保证应用在不同运行环境下的统一交付,解决环境差异问题和大规模的交付部署问题。
● 容器本质上相当于一个进程,每个容器都可以看作一个不同的微服务进程,因此可以独立升级,与底层共享操作系统,性能更加优良,系统负载更低,在同等硬件资源条件下可以运行更多的应用实例,更充分地利用系统资源。
● 在没有适合的工具和自动化运维的情况下,使用微服务架构会导致灾难。目前基于容器技术和Kubernetes技术的平台已经成为微服务交付和管理的最佳平台。
云原生12要素
=======
Gartner定期发布的技术成熟度曲线可以帮助我们方便地评估技术的成熟度,同时帮助我们制定战略,即采用怎样的技术工具。Gartner最新发布的技术影响力和普及模式与成熟度分析说明,微服务架构已经在中国全面进入成熟落地阶段,从全球来讲,很多知名IT企业和公司,像亚马逊、Netflix、阿里巴巴,已经采用微服务架构重塑了自己的核心业务系统。当前,很多公司为了节省成本、减少对基础硬件设施的投入,纷纷选择采用公有云或者私有云的方式管理公司的应用服务和基础设施。
云原生12要素(如下图所示)是基于云的架构设计和开发模式需要具备的一套全新的理念,也是云原生应用开发的最佳实践原则。
● 要素1:基准代码
基准代码和应用之间总是保持一一对应的关系:一旦有多个基准代码,就不能称为一个应用,而是一个分布式系统。分布式系统中的每一个组件都是一个应用,每一个应用都可以分别使用云原生12要素进行开发。
● 要素2:依赖显式声明依赖关系,应用程序不会隐式依赖系统级的类库。要通过依赖清单,确切地声明所有依赖项。此外,在运行过程中通过依赖隔离工具来确保程序不会调用系统中存在但清单中未声明的依赖项。这一做法会统一应用到生产和开发环境。像Java语言使用的Maven打包软件或者Cradle都可以显式声明依赖。
● 要素3:配置
通常应用的配置在不同部署环境(预发布、生产环境、开发环境等)中会有很大差异。Factor推荐将应用的配置存储于环境变量中。我们可以非常方便地在不同的部署环境中修改环境变量,却不动一行代码。
最后
针对最近很多人都在面试,我这边也整理了相当多的面试专题资料,也有其他大厂的面经。希望可以帮助到大家。
上述的面试题答案都整理成文档笔记。 也还整理了一些面试资料&最新2021收集的一些大厂的面试真题(都整理成文档,小部分截图)
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持。
专题资料,也有其他大厂的面经。希望可以帮助到大家。
[外链图片转存中…(img-Yecl7mPi-1714543398585)]
上述的面试题答案都整理成文档笔记。 也还整理了一些面试资料&最新2021收集的一些大厂的面试真题(都整理成文档,小部分截图)
[外链图片转存中…(img-TktDOoge-1714543398586)]
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持。