微服务架构与领域驱动设计应用实践
发布时间:2023-06-06 00:08
本文摘要:本篇文章一共分为三个部门,划分是微服务架构的演进历程、详细实践微服务的应用技术和领域驱动设计的意识转变。微服务架构已经渗透到互联网应用的方方面面,而领域驱动设计也逐渐被业界所吸收。 微服务架构险些都是从 ALL IN ONE 的单体架构演进而来,中间又履历了漫衍式架构、面向服务架构的演进历程。单体架构往往以烟筒式方式生长,往往存在两个主要问题:中心化和耦合度高。

ag真人官网平台

本篇文章一共分为三个部门,划分是微服务架构的演进历程、详细实践微服务的应用技术和领域驱动设计的意识转变。微服务架构已经渗透到互联网应用的方方面面,而领域驱动设计也逐渐被业界所吸收。

微服务架构险些都是从 ALL IN ONE 的单体架构演进而来,中间又履历了漫衍式架构、面向服务架构的演进历程。单体架构往往以烟筒式方式生长,往往存在两个主要问题:中心化和耦合度高。所谓中心化,就是数据集中存储在单个数据库中,业务系统集中部署在单台服务器上,通过集群部署方式提供服务能力,然而中心化的问题,也就是单点问题。

而耦合度高,主要是指其中一个功效模块升级,其它的模块都得一起升级。这里要说明下,模块依赖度高不是单体架构的错,是因为原来架构可能就没有设计好,可是,在实际场景中,随着快速迭代开发,研发换了一波又一波,产物走了一茬又一茬,难免系统架构腐蚀严重。看到了单体架构的诸多问题,系统开始通过按功效或模块举行拆分,拆分成多个独立的子系统,系统间通过 RPC、MQ 方式挪用,由此逐渐演变为漫衍式的服务架构。漫衍式服务架构主要通过服务化和条理化举行解耦拆分,《架构整洁之道》书中提到一点,系统可以降解为计谋和条理,而架构设计就是把相同的计谋分到同一个组件中,反之,分属于差别的组件。

所以,架构设计可以通太过层设计,由高条理服务挪用低条理服务,低条理服务通过接口向上提供服务,以实现系统之间的解耦。也正是在这一阶段,单体架构一下子被拆分成几个或几十个系统。可是随着架构的生长,问题又接踵而来,在没有做好界限的划分之前,系统拆分的服务往往是松散的。

正如《架构整洁之道》所讲:软件架构设计自己就是一门划分界限的艺术。所以,许多系统在这一阶段,又往往举行了服务内聚和去条理化的演变历程。所谓服务内聚,就是以领域驱动设计为原则,重新界定领域界限,对模块举行服务整合,对系统举行合并。

而去条理化,则是去除服务条理崎岖之分,按服务挪用最优链路提供服务请求,降低深度,以此保证系统的稳定性能。系统如何从 0 到 1,从 1 到 2,从 2 到 100,在详细实践微服务的历程并不容易。首先,思量的第一个问题是:微服务是什么?其实,微服务是一个行动:拆。

说到拆,就涉及到两个问题,第一,怎么拆?第二,拆到什么水平。第一个问题,关于怎么拆,需要关注两个层面,一是发版速度,如商品、生意业务、促销等差别领域的迭代速度和开发速度是纷歧致的,所以,应该拆分到差别的领域,否则,就可能耦合在一起,A 上线 B 必须随着一起上,这可能就应该合并到一起。另一个是能源协同,每个系统后面临应差别的研发团队,一个项目往往需要几个团队分工协作,那么系统拆分一定导致团队协作的成本,所以拆分系统同样也是拆分团队,要思量协作相同所带来的成本。

第二个问题,拆到什么水平。其实,已经有许多人对微服务举行了界说,其中我认为最重要的两点:一是微服务或一组微服务,应该是一套独立部署运行的服务,二是微服务所依赖的数据资源应该是相互间相互独立隔离部署的。其实,拆只是实践微服务的开始,要搭建整体的微服务框架还要举行四部曲:拆、服务化、高可用、隔离。1,服务拆分微服务讲求拆分,那么多微才是微,以及,怎么才是比力合理的拆分。

在架构设计领域,有一个大家都在讲的著名定律:康为定律,可以明白为:一个系统架构的组织关系是和团队的组织关系相匹配的。如生意业务系统会对应一个生意业务系统的研发团队,商品系统会对应一个商品系统的研发团队,这种职责明确的组织结构会使得系统开发更高效。(图片来自网络)《未来架构》一书中讲过一个 AKF 立方体模型,从三个纬度讲述功效拆分、水平扩展、数据分区所发生的庞大度,如果只有一个系统,单台部署,单点存储,那么它就应该只是一个点,因为随着量级的增大,系统在每个纬度不停延长,逐渐成为一个庞大的立方体。

(图片来自网络)拆分可以分为系统拆分、功效拆分和读写拆分。如一个单体系统中,根据用户的交互场景看,门户首页可以拆分为前台系统,类目、商品、搜索等功效可以拆分到商品中心,订单、结算、发票等功效则可以拆分到生意业务中心,这就是简朴的系统拆分和功效拆分。而有些功效较为特殊,如商详页,在读取时需要聚合读取,所以又可以举行读写拆分。

2,服务化微服务首先需要有微服务基础设施,没有微服务基础设施,实践微服务就是一场灾难。以 SOA 落地方式为例,SOA 落地方式主要有:漫衍式服务化和集中式治理(ESB),漫衍式服务化的技术手段有 dubbo 或 spring cloud 等等,必须有整套的如服务发现、服务订阅、服务监控、服务追踪、服务日志等微服务基础设置,才气举行微服务架构。不能简朴只有 p2p 的服务挪用就开始服务化,那是不现实的。

3,服务治理当服务拆分的设计方案确认完毕,而服务化的基础设施也部署到位,那么系统往往一下子就会突然公布出成百上千个服务接口,就像一个网络一样,每个服务或微服务就像网中的一个节点,相互之间关联和联系。可是,服务网络应该被设计成为一个有向无环图,否则,就是一团麻。如开始的时候,只是 A 挪用 B,但随着业务生长,需要修改,可是因为对 A 不相识,就加个环节 B 挪用 A,如此形成了环形挪用,不仅逻辑庞大了,还降低了稳定和性能。这里的服务治理不是讲中间件团队的服务治理,如超时优化、启动优化等等,而是作为应用平台对服务的治理。

服务治理又分为三个阶段:服务梳理、服务界定和服务编排。所谓服务梳理就是梳理系统对外开放的服务化接口,包罗服务的 provider 和 consumer,以及服务分组、动态路由等依赖的梳理,然后对拆散的服务举行归类、界定,确定服务领域附属性,依据领域模型重新界定服务界限,最后通过服务迁移、切换,对同一领域的服务接口举行服务整合,提供统一的服务出口,实现服务编排。为什么要举行服务治理?那先来看看不举行服务治理的坏处。

微服务化拆分一定会在初期发生代码随处拷贝,没有一套代码,一定会造成庞大的扩散,如同样语意的 A、B 两个接口,如果 A 接口存在性能问题需要加缓存,那么 B 接口也会存在同样的问题,并需要同样的革新,这样庞大度就会随处伸张,同时也无法实现统一的服务层架构,另有,如果同样语意或相似语意的接口太多,那么接口就是杂乱的,无法实现有限接口的治理,如果系统出了问题,可能很难定位问题。业务逻辑是依赖于数据的,如果接口是杂乱的,那么慢 SQL 等质量差的 SQL 就无法举行有效收口革新,同样就越发难以实现数据库拆分息争耦。

综上,服务治理的历程就是从无序到有序的历程。总结一下看从拆分到服务化的历程,就是将原来一个整体的服务打碎,碎成一块一块的琐屑服务,然后再对服务重新归类、整合,形成一个一个新领域的、独立的服务。如单体架构就像一个雄伟的城堡,如果相对其中一个点举行调整和革新,那么可能面临着牵一发而动全身的风险。微服务化就是以一系列小的服务去支撑一个应用的方法论。

简明简要的说,就是:分而治之。4,服务高可用服务拆分并服务化之后,是不是就完事了,不!真正的微服务实践才刚刚开始,简朴提供了一个接口,是没有意义的,它必须具备高可用、高性能、高并发的三高特性,尤以高可用最为重要。保障服务高可用的方法有许多,如数据异构、多级缓存、超时与重试、熔断、异步并发、降级、限流、消息行列、压测与预案等。重点说下数据异构,所谓数据异构,就是将通过顺序消费或并发消费的方式,订阅 MySQL 数据库的 binlog,然后通过消息,如 Kafka 等 MQ 方式,异地存储到缓存或其它数据源中,如 Redis、Elasticsearch 等。

数据异构现在被普通使用,实现数据聚合,形成数据闭环。在举行数据异构的历程中,需要关注几个关键点,一是 CAP 原则,即强一致性往往被舍弃,而接纳最终一致性的设计。二是缓存,缓存在微服务架构中,不能被当成银弹来使用,使用缓存必须正视的问题有:热点缓存 & 大 Value 缓存、缓存穿透等问题。三是消息,消息现在还存在的问题有:延迟问题、消息的不稳定性(如丢消息)、消息的不确定性(如 timeout)、消息赔偿、柔性事务等问题。

而这些是微服务高可用架构实践中,不能不面临的问题。5,服务隔离隔离也是服务拆分的一种,为什么单独讲?因为服务拆分、服务化、服务治理和服务高可用都是在事前或事中可以做的,然而,有些系统已经成了某个样子,那么我们吸收时,首先能做到的就是迅速对系统举行隔离,保证业务之间不相互影响,详细实践包罗:历程线程隔离、集群/机房隔离、读写隔离、消息隔离、爬虫/热点隔离等。从单体架构开始,到漫衍式架构设计、微服务架构,再到现在领域驱动设计,作为实践微服务的架构师,思想上又有什么变化?我以为,法式员都是很闷骚的,但每个法式员心里都住一个大侠,金庸《笑傲江湖》里有气宗和剑宗之分,什么是剑宗,我明白就像是剑招、招数,如 spring、spring boot、spring cloud,另有 tomcat、netty、serviceless 等,这些技术、中间件、框架等就像脚手架一样可以资助我们提高效率,可是,我们是否需要泛起一个新技术就学习一个技术呢?而这就让我想到了气宗,它就像是通过对内在纪律的掌握,买通任督二脉,实现融会领悟,正如《九阳神功》所说:他强任他强,清风拂山岗,我自一口真气足。

如 Kakfa、Flink、Hbase 平分区可用性保障的设计思想都是基于 BigTable 的分区复制计谋。正是重心由外到内的转变,让我认知到,现在系统架构的生长,许多系统架构的庞大度,已经不是简简朴单通过引入一些新技术或框架,就能降低系统庞大的。它需要大大的提前对风险、问题、隐患的预知,做到未雨绸缪。《从零开始学架构》书中提到:架构设计的生长历程就是在于降低软件系统庞大的历程。

《架构整洁之道》书中提到:一个软件系统存在的意义,是系统用来赚钱或省钱的那部门代码,那才是整个系统的皇冠明珠。所以,当拿到一个需求的时候,首先思量的是要解决什么问题,它的问题域是什么,而不是先思量用哪种技术去实现或解决这个问题,这是舍本逐末的处置惩罚方法。

从领域驱动设计的角度来看,需求首先是问题域,属于业务界限的事情,梳理相识要实现什么功效和需求,然后在外延到事情界限,确认团队互助的方式,因为许多需求都可能需要跨团队互助的,最后才会到应用界限,即技术实现的解决问题领域。上图是一个典型的洋葱头模型,它的思想就是论述了从内到外的思考历程。然后,现实事情中,经常有人从外往内去思量问题,从我过往的履历举例,一次是数据异构的方案,之前是接纳 Storm,厥后 flink 开始盛行,我就将业务切换到了 flink,可是对于 flink 的调优不到位,从而影响了系统稳定性,另有一次是之前搜索用 solr,厥后 es 开始盛行,就像切到 es,可是 es 和 solr 两套搜索引擎的搜索排序效果是纷歧样的,最后,我们只能强奸了业务。其实,这都是不太对的。

《架构整洁之道》也提到:良好的架构设计应该尽可能地允许用户推迟和延后决议接纳什么框架、数据库、Web 服务以及其他与情况相关的工具。明白领域驱动设计,需求或问题它开始于一个领域意愿,由领域专家和交付团队一起,输出统一语言和领域知识,统一语言可以是敏捷看板,因为一个团队是由产物、运营、研发、测试组成的,相互之间是基于统一语言举行相同的,然后界说领域界限,区分焦点领域、普通领域、支持领域,其中焦点领域就是由焦点团队开发的,支持领域可以是外包等实现的,在通过映射上下文,确认限界上下文,最终确认系统应用界限。(图片来自网络)接纳领域驱动设计的六边形架构绘制了一张生意业务系统的领域界限图,差别颜色讲明差别领域,U/D 代表上游和下游。这个图还不算完整,因为领域业务逻辑是要为端服务的,而通过对领域的梳理,可以通用的支持许多端。

即表达为领域有界,端无界。最终,每个限界上下文即是微服务。

其实,每个系统的微服务架构演进门路各不相同,所以,实践微服务不能一板一眼原封照抄,而是要凭据自己的业务特征,合理的裁剪,找到合适落地方案。总结一句话,那就是:因需而变。虽然微服务的路径是纷歧样的,但偏向是相同的。

再次回首微服务的架构演进历程,你会发现,从单体架构开始,举行拆分,形成微服务之后,又因为种种这样的原因,许多微服务架构又在举行合并,现在领域驱动设计来了,又开始重新拆分。真可谓:话说天下局势,分久必合,合久必分。


本文关键词:ag真人官网app,微,服务,架构,与,领域,驱动,设计,应用,实践

本文来源:ag真人官网平台-www.chengxingjm.com