基于微服务的企业应用架构设计范式

这个话题曾经分别在PWorld大会和QCon2016大会上做过分享,得到不错的反响,因此借着今天这个机会也分享给大家。

微服务好像是这两年突然火起来的,其实和很多其他架构风格一样,微服务架构也是我们在用软件改变世界的过程中,为了适应内外部环境的变化,而逐渐演化出的一种当前的最佳实践。

比如SOA,比如J2EE,比如传统分布式;微服务架构和它们都有千丝万缕的联系。


范式一、采用同步方式记录业务流水

流水记录了业务状态最终确定前的整个过程,是给业务参与各方看的,这个参与各方包括了客户(比如大家拿到的信用卡刷卡记录)、第三方系统(比如对账文件)、内部用户(比如我们给客服打电话,客服可以知道你的交易历史)等等。

由于流水的作用和系统日志非常像,因此有些系统在设计时会把这两者混淆起来,基于性能的考虑,会像记录日志那样,用异步方式来记录流水。其实这是非常大的误区。就像上面所说,流水有业务含义,是给业务参与各方看的,它所记录的数据应该是和业务数据有一致性要求,而日志是给我们程序员看的,偶尔丢个一两条是可接受的。

因此我们需要用同步的方式来记录业务流水,也就是说记录流水应该和正常的业务操作在同一个事务中。

上图中,第一个“内部操作”更改了业务数据状态,因此需要同步记录业务流水,其他几个环节只记录日志即可。


范式二、流水号设计的GAIR模式

在记录流水和日志的过程中,我们需要唯一标识一笔服务调用。站在IT全局的视角来看,我们需要记录并能在适当的时候还原整个调用链。出现数据不一致时,我们要进行补偿操作,又需要能够定位错误发生时的数据状态……

这些都需要以“流水号”为基础,这就带来了微服务架构的第二个范式——流水号的GAIR(盖尔)模式

G、A、I、R分别代表:Global_ID(全局流水号)、Answer_ID(响应流水号)、InRequest_ID(外部请求流水号)、Request_ID(内部请求流水号)

这四个流水号的产生方、产生时机各不相同,下图展示了它们之间的区别和联系。


范式三、元数据驱动的微服务定义

以元数据的方式定义微服务带来两个好处。

一、机器可读,这给未来全面自动化提供了前提条件。

二、标准统一,这给服务在整个交付环节中的横向打通提供了支撑。

我们在实践中,以元数据方式,定义了服务接口数据的结构、每个数据项所遵循的数据标准、每个服务接收请求数据时的校验规则和值转换规则等等。

这些元数据提供给专门的服务治理系统、数据治理系统、DevOps平台,从而构建出数字化IT。


范式四、同步模式异步化

在移动互联的外部环境中,微服务化的IT系统如何应对不确定的并发请求、超量请求?同时还要兼顾我们所连接的外部系统的网络中断、宕机等服务不可用、超时等一系列问题。

要解决这些问题,需要运用我们的第四个范式:以异步的方式处理同步调用。

在实践中,我们所使用的异步方式和传统异步不太一样。

传统基于事件的异步,每个并发流作为一个有限状态机,应用直接控制并发,随着负载的增加,吞吐量会饱和,响应时间也会线性增长。

我们使用SEDA(Staged Event Driven Architecture),将接入、接出与逻辑处理相隔离,根据不同的业务操作类型合理分组,分别对待。


范式五、进程间服务无状态

什么是状态?首先,我们这里所说的状态是一种数据。如果一个数据需要在多个服务之间共享才能完成一笔交易,那么这个数据就被称为状态。

依赖这个状态的服务,就是有状态服务。否则,就是无状态服务。

在业务上,状态的共享是不可避免的。典型的用户Session、现在新出现的云粘贴、网约车都是需要状态在不同服务间共享的场景。

但在技术实现上,考虑到系统的可伸缩性,我们又需要做到无状态化处理。

具体有四种手段:

一、请求方持有状态,每次调用时传递给服务提供方

二、粘滞+复制,这种技术并不新鲜,传统的JavaEE应用服务器集群就采用这种方式。这种方式对应用来说简单有效,但需要中间件支持。

后面两种手段类似,都可以称为状态共享

一种是,把状态保存在分布式缓存中

另一种,把状态保存在持久化数据库中

区别也显而易见,在此不做赘述。

具体使用哪种方式,要从多个维度综合考量,这里列出了我们经常考量的几个维度:时间窗口、性能、可靠性、安全性。


范式六、保证最终数据一致性

接下来是微服务架构下的数据一致性问题。这是一个大课题,概括的讲,我们可能需要转变思路,考虑采用柔性事务,使得数据达到最终一致。

当然,有些场景是必须要追求强一致性的,那么我们可能要在设计服务时就要考虑,是不是可以不分布。毕竟,“低耦合”是美好的,但同时还要有“高内聚”。

保证数据最终一致性有三种模式:

1、可靠事件模式

2、补偿模式

3、TCC模式


范式七、用编排实现微服务组合

前面讲了这些模式,从架构角度来看挺清楚,确实也应该这么做。但是从工程角度来看,实施起来难度其实也不小。微服务之间的调用超时、事务、异步、状态等等,要做到代码写好,不出错,恐怕也是一个门槛比较高的事情。

所以,我们强调:用编排方式实现微服务的组合。

无论是配置式的编排:

还是图形式的编排:

都可以大大降低编程复杂度,使得一些很好的架构思想不会因为工程实现上的复杂和高门槛,而难以落地,最终成为空谈。

如果大家对编排方式实现微服务的组合没有直观的感觉,推荐大家访问:ifttt.com,一试便知。


范式八、业务配置集中管理

最后一个范式是:业务配置集中管理

记得前两天有位群友问我,docker启动时,如何根据不同的参数动态加载面向测试、生产环境的配置。

这个问题的答案就是业务配置集中管理。

其实技术上,业务配置集中管理没有什么太多的难点。我们需要做的是有一个切实可行的步骤来逐步实现。


总结

这些八个范式当然没有涵盖微服务架构中的所有方面,希望能够在以后的实践中总结出更多的经验,可以分享给大家。

时间: 2024-11-05 17:22:29

基于微服务的企业应用架构设计范式的相关文章

面向微服务的企业云计算架构转型

云计算的本质是提高效率,而不是降低成本,公有云就是要提高社会的效率,私有云就是要提高 IT 的效率. 从这个角度看,实施云计算就是做精益运营,而微服务架构为精益运营提供了架构上的保证,因为微服务是小的.容易变化的.容易控制的. 大家好,我是焦烈焱,今天主要介绍普元利用云计算模式,帮助企业实施数字化转型过程中,在技术上遇到的挑战,以及我们解决问题的方法. 首先解释一下什么是数字化?数字化就是把人.事/物和商业联系起来,Garnter 提到未来的企业都是数字化的企业,IT将成为企业核心竞争力,甚至每

从 SOA 到微服务,企业分布式应用架构在云原生时代如何重塑?

作者 | 易立 阿里云资深技术专家 导读:从十余年前的各种分布式系统研发到现在的容器云,从支撑原有业务到孵化各个新业务,企业的发展离不开统一的.与时俱进的技术架构.本篇文章从企业分布式应用架构层面介绍了云原生计算架构带来的变化,希望能够帮助更多企业的 IT 转型,利用云计算技术推动其成为市场竞争中的敏捷力量. 进入 21 世纪以来,我们见证了企业分布式应用架构从 SOA(Service-oriented Architecture),到微服务架构,再到云原生应用架构的演化. 为了说明企业架构演化背

微服务Dubbo和SpringCloud架构设计、优劣势比较

本文主要围绕微服务的技术选型.通讯协议.服务依赖模式.开始模式.运行模式等几方面来综合比较Dubbo和Spring Cloud 这2种开发框架.架构师可以根据公司的技术实力并结合项目的特点来选择某个合适的微服务架构平台,以此稳妥地实施项目的微服务化改造或开发进程. 微服务架构是互联网很热门的话题,是互联网技术发展的必然结果.它提倡将单一应用程序划分成一组小的服务,服务之间互相协调.互相配合,为用户提供最终价值.虽然微服务架构没有公认的技术标准和规范或者草案,但业界已经有一些很有影响力的开源微服务

【转】从SOA到微服务,企业分布式应用架构在云原生时代如何重塑

摘要: SOA 采用中心化的服务总线架构,解耦了业务逻辑和服务治理逻辑:微服务架构回归了去中心化的点对点调用方式,在提升敏捷性和可伸缩性的同时,也牺牲了业务逻辑和服务治理逻辑解耦所带来的灵活性. 为了解决上述挑战,社区提出了 Service Mesh(服务网格)架构.它重新将服务治理能力下沉到基础设施,在服务的消费者和提供者两侧以独立进程的方式部署. 这样既达到了去中心化的目的,保障了系统的可伸缩性:也实现了服务治理和业务逻辑的解耦,二者可以独立演进不相互干扰,提升了整体架构演进的灵活性.同时服

基于微服务springboot商城前后台的设计(毕业设计)

又到一个毕业季,很多人毕业设计又没有完成,这是一个伤心的事情,不过不要慌,有我们帮助您,商城系统,管理系统 酒店管理系统 ,微信小程序等,都可以直接使用 大家还没做的可以联系我 上面是公司的官网 联系方式QQ:1161724197 微信:H1161724197 原文地址:https://www.cnblogs.com/itboxue/p/12594679.html

解析微服务架构(二):融入微服务的企业集成架构

上一篇文章介绍了微服务架构的起源.定义.通用特性.常见概念误区.微服务架构与SOA架构比较.微服务架构收益以及企业引入微服务架构的策略. 本文将介绍融入微服务的企业集成架构的演进,并描述交互式系统的微服务模式及相关技术决策,然后给出了一个具体的微服务架构业务应用的例子. 交互型系统(System of Engagement)与记录型系统(System of Record) 随着移动互联网的快速发展,企业除了需要提供传统核心IT系统能力之外,还需提供客户与合作伙伴友好型的以交互为重点的创新及交互式

《基于微服务架构的在线学习系统设计与实现》第三章 文献随笔(四)

一.基本信息 标题:基于微服务架构的在线学习系统设计与实现 时间:2019 来源:微服务架构 关键字:在线学习系统:微服务架构:spring cloud框架:API网关 二.研究内容 1.研究背景 基于对国内外的各学习网站的体验与分析,结合软件工程的需求分析方法,综合大学生的学习习惯以及学习方法对系统进行的功能性需求分析以及非功能性需求分析. 2.在线学习系统的需求分析   (1)功能需求分析 学生用户需求分析: 网站注册.用户登录.个人信息管理.课程列表.课程公告.课程评分.课程收藏.课程讨论

基于微服务的软件架构模式(转载)

转载:原文链接 基于微服务的软件架构模式 [编者的话]微服务只是最近提出的概念,实际上很多巨头公司(FB.Twitter.AWS等)已经在亲身实践.微服务并不是银弹,但是我们可以参考它的 思想来解决自己遇到的问题.对于已经找准市场,业务即将或者马上就要急剧发展的创业公司,适合使用基于微服务的软件架构. 今天阅读了两篇关于微服务的文章,总结一些笔记,简单翻译了一篇文章.说明:并没有严格按照原文一字语句翻译,有部分自己的理解,还有部分是意译. 微服务(micro services)这个概念不是新概念

Longhorn发布:基于微服务的开源分布式块存储

Longhorn项目现已正式发布!这是一个基于云和容器部署的分布式块存储新方式.Longhorn遵循微服务的原则,利用容器将小型独立组件构建为分布式块存储,并使用容器编排来协调这些组件,形成弹性分布式系统. Why Longhorn? 如今,基于云和容器的部署规模日益扩大,分布式块存储系统也正变得越来越复杂,单个存储控制器上的volume数量在不断增加.2000年代初,存储控制器上的volume数量只有几十个,但现代云环境却需要数万到数百万的分布式块存储卷.存储控制器变成了高度复杂的分布式系统.