分布式系统关注点:弹性架构
点击蓝色“程序猿DD”关注我哟
来源:跨界架构师
如果我们的开发工作真的就如搭积木一般就好了,轮廓分明,个个分开,坏了哪块积木换掉哪块就好了。但是,实际我们的工作中所面临的可能只有一块积木,而且还是一大块,要换得一起换,要修得一起修。Z哥在之前《分布式系统关注点:高内聚低耦合》中提到的分层架构它可以让我们有意识的去做一些切分,但是换和修的难度还是根据切分的粒度大小来决定的。
有更好的方式吗?这是显然的。
事件驱动架构
我们来换一个思维看待这个问题。
不管是平时的系统升级也好、修复bug也好、扩容也好,其实就是一场“手术”。通过这场“手术”来解决当前面临的一些问题。
那么分层架构好比只是将一个人的手、脚、嘴、鼻等分的清清楚楚,但是整体还是紧密的耦合在一起。
怎么耦合的呢?我们人是靠“血液”的流动连接起来的。这就好比在分布式系统中通过rpc框架连接起不同的节点一样。
但是软件与人不同,有2种不同的连接方式,除了「同步」的方式之外还有「异步」的方式。因为有些时候你不需要知道其他系统的执行结果,只要确保自己将其需要的数据传递给它了即可。
恰巧有一种架构是这种模式的典型——事件驱动架构(简称EDA,Event Driven Architecture)。
平时常见的MQ、本地消息表等运用于数据传递的中转环节,就是事件驱动架构的思想体现。
事件驱动架构又细分为两种典型的实现方式,与Z哥之前在《分布式系统关注点——「共识」的兄弟「事务」》中提到的Saga模式的2种实现方式类似,一种是中心化的、一种是去中心化的。
下面Z哥来举个例子,让你看起来更容易理解一些。(例子仅为了阐述是怎么工作的,真正的实施中还需要考虑如何保证数据一致性等问题,这部分可以参考之前发表的系列文章,文末带传送门)
传统的电商场景中,用户从购物车中点击“提交”按钮后,至少需要做这几件事:生成一笔订单、生成一笔支付记录、给订单匹配发货的快递公司。
在这个场景下,中心化和去中心化有什么不同呢?
中心化
这种模式拥有一个“上帝”。
但是“上帝”不会处理也不知道任何业务逻辑,它只编排事件。
除了中心化之外,它还有什么特点呢?Z哥给它的定义是“3+2结构”。
这种模式中存在3种类型的主体:事件生产者、“上帝”(调停者)、事件处理者。然后中间夹着两层队列,以此结构就能解耦。
就像这样:事件生产者 --> 队列 --> “上帝”(调停者) --> 队列 --> 事件处理者。
那么回上面的这个例子中,事件生产者CartService发出了一个“订单创建”事件,通过队列传递给调停者。然后调停者根据事先制定好的编排规则对事件进行相应的转换,也通过队列做二次分发,传递给事件处理者。
可能你会问,这些好理解。但是,我之前也经常看到什么编排编排的,到底编排该怎么做呢?
其实编排主要做两件事:「事件转换」和「事件发送」(对应「服务编排」类框架的「调用」)。
「事件转换」实质就是给将要发送的事件对象的参数进行赋值。赋值的数据来源于哪呢?
除了事件产生的源头带入的参数,还有持续累积的「上下文」,就如下图中这样的一个共享存储空间。
可能你又会问,我怎么将多个事件处理者之间组合成一个上下文呢?
通过一个全局唯一的标识即可,每次向“上帝”丢事件的时候把这个全局唯一标识带过去。
题外话:一般来说,还会在一个全局唯一标识之下带一个内部唯一的「子流水号」,为了配合做接下去要讲到的「事件发送」。
一是为了后续排查问题的时候清晰的知道这次调用产生的异常是从哪个上游系统来的。
二是为了便于观测整个调用的逻辑是否符合编排时的预期。
怎么做呢?通过一个x.x.x.x格式的序号。比如,串行就是1,2,3。分支和并行就是2.1,2.2。分支+串行的结合就是1,2,2.1,2.2,3。
「事件发送」实质就是负责事件流转的逻辑控制,然后发往「事件处理者」去处理。它决定了是按顺序还是分支进行?是串行还是并行?
到这就不再展开了,要不然就跑题了,我们下次再细聊这部分内容。
再强调一下,「事件转换」和「事件发送」是你在实现“上帝”(调停者)功能的时候需要满足的最基本的两个功能哦。
中心化最大的优势是让流程更加的“可见”了,同时也更容易去做一些监控类的东西,系统规模越大,这个优势产生的效果越明显。
但是一个最基本的“上帝”(调停者)实现起来还需要考虑数据一致性问题,所以,会大大增加它的实现复杂度。
因此,如果你面对的场景,业务没有特别庞大,并且是比较稳定的,或许用去中心化的方式也是不错的选择。
去中心化
这个模式由于没有了“上帝”,因此每个事件处理者需要知道自己的下一个事件处理器是什么?需要哪些参数?以及队列是哪个之类的东西。
但是整体结构会变得简单很多,从“3+2结构”变成了“2+1结构”。
结构简化背后的复杂度都跑到事件处理者开发人员编写的业务代码中去了。因为他需要自己去负责「事件转换」和「事件发送」这两个事情。
嗯,改造成事件驱动架构之后,通过「队列」的解耦和异步的事件流转,系统的运转的确会更顺畅。
但是有时候你可能想进行更细粒度的控制,因为一般情况下,一个service中会处理很多业务环节,不太会只存在一个对外接口、一条业务逻辑。
在这样的情况下,很多时候你可能需要修改的地方仅仅是其中的一个接口。能不能只修改其中的一部分代码并且进行「热更新」呢?
微内核架构(插件架构)就适合来解决这个问题。
微内核架构
顾名思义,微内核架构的关键是内核。所以需要先找到并明确内核是什么?然后将其它部分都视作“可拆卸”的部件。
好比我们一个人,大脑就是内核,其它的什么都可以换,换完之后你还是你,但是大脑换了就不是你了。
微内核架构整体上由两部分组成:核心系统和插件模块。
核心系统内又包含了微内核、插件模块,以及内置的一些同样以插件形式提供的默认功能。
其中,微内核主要负责插件的生命周期管理和控制插件模块。
插件模块则负责插件的加载、替换和卸载。
外部的插件如果要能够接入进来并顺利运行,前提先要有一个满足标准接口规范的实现。
一个插件的标准接口至少会有这样的2个方法需要具体的插件来实现:
public interface IPlugin{
/// <summary>/// 初始化配置/// </summary>void InitializeConfig(Dictionary<string,string> configs);
/// <summary>/// 运行/// </summary>void Run();
...
}
最后,插件之间彼此独立,但核心系统知道哪里可以找到它们以及如何运行它们。
最佳实践
知道了这两种具有“弹性”的架构模式,你该如何判断什么情况下需要搬出来用呢?
Z哥带你来分析一下每一种架构的优缺点,就能发现它适用的场景。
事件驱动架构
它的优点是:
通过「队列」进行解耦,使得面对快速变化的需求可以即时上线,而不影响上游系统。
由于「事件」是一个独立存在的“标准化”沟通载体,可以利用这个特点衔接各种跨平台、多语言的程序。如果再进行额外的持久化,还能便于后续的问题排查。同时也可以对「事件」进行反复的「重放」,对处理者的吞吐量进行更真实的压力测试。
更“动态”、容错性好。可以很容易,低成本地集成、再集成、再配置新的和已经存在的事件处理者,也可以很容易的移除事件处理者。轻松的做扩容和缩容。
在“上帝”模式下,对业务能有一个“可见”的掌控,更容易发现流程不合理或者被忽略的问题。同时能标准化一些技术细节,如「数据一致性」的实现方式等。
它的缺点是:
面对不稳定的网络问题、各种异常,想要处理好这些以确保一致性,需要比同步调用花费很大的精力和成本。
无法像同步调用一般,操作成功后即代表可以看到最新的数据,需要容忍延迟或者对延迟做一些用户体验上的额外处理。
那么,它所适用的场景就是:
对实时性要求不高的场景。
系统中存在大量的跨平台、多语言的异构环境。
以尽可能提高程序复用度为目的的场景。
业务灵活多变的场景。
需要经常扩容缩容的场景。
微内核架构
它的优点是:
为递进设计和增量开发提供了方便。可以先实现一个稳固的核心系统,然后逐渐地增加功能和特性。
和事件驱动架构一样,也可避免单一组件失效,而造成整个系统崩溃,容错性好。内核只需要重新启动这个组件,不致于影响其他功能。
它的缺点是:
由于主要的微内核很小,所以无法对整体进行优化。每个插件都各自管各自的,甚至可能是由不同团队负责维护。
一般来说,为了避免在单个应用程序中的复杂度爆炸,很少会启用插件嵌套插件的模式,所以插件中的代码复用度会差一些。
那么,它所适用的场景就是:
可以嵌入或者作为其它架构模式的一部分。例如事件驱动架构中,“上帝”的「事件转换」就可以使用微内核架构实现。
业务逻辑虽然不同,但是运行逻辑相同的场景。比如,定期任务和作业调度类应用。
具有清晰的增量开发预期的场景。
号外:最近整理了之前编写的一系列内容做成了PDF,关注我并回复相应口令获取:
- 001 :领取《Spring Boot基础教程》
- 002 :领取《Spring Cloud基础教程》
更多内容陆续奉上,敬请期待
- END -
近期热文:
我为啥不看好ServiceMesh
GitHub 寻宝指南
“编程不规范,同事两行泪!”
虎牙直播在微服务改造方面的实践和总结
有赞搜索系统的架构演进
为什么分库分表后不建议跨分片查询
别看不起分区表:我要为你点个赞
在前后端分离的路上承受了多少痛?
中台是个什么鬼?
看完,赶紧点个“好看”鸭
点鸭点鸭
↓↓↓↓
分布式系统关注点:弹性架构相关推荐
- 分布式系统关注点(14)——「弹性架构」详解
如果第二次看到我的文章,欢迎右侧扫码订阅我哟~ ? 本文长度为3633字,建议阅读10分钟. 坚持原创,每一篇都是用心之作- 如果我们的开发工作真的就如搭积木一般就好了,轮廓分明,个个分开,坏了哪块 ...
- 分布式系统关注点:无状态
来源:跨界架构师 初识「状态」 之前在「负载均衡」中提到过一个例子,我们再翻出来一下. 开发Z哥对运维Y弟喊:"Y弟,现在系统好卡,刚上了一波活动,赶紧帮我加几台机器上去顶一下." ...
- 分布式系统关注点(12)——「无状态」详解
如果这是第二次看到我的文章,欢迎右侧扫码订阅我哟~ ? 本文长度为2728字,建议阅读8分钟. 坚持原创,每一篇都是用心之作- 前面聊完的2个章节「数据一致性」和「高可用」其实本质是一个通过提升复杂 ...
- 分布式系统关注点(9)——想通关「限流」?只要这一篇
如果这是第二次看到我的文章,欢迎右侧扫码订阅我哟~ ? 本文长度为2869字,建议阅读8分钟. 可能你在网上看过不少「限流」相关的文章,但是z哥的这篇可能是最全面,最深入浅出的一篇了(容我飘几秒-) ...
- 分布式系统关注点(20)——阻塞与非阻塞有什么区别?
如果第二次看到我的文章,欢迎右侧扫码订阅我哟~ ? 每周五早8点 按时送达.当然了,也会时不时加个餐- 前面一篇文章中,Z哥和你聊了「异步」的意义,以及如何运用它.错过这篇文章的可以先去看一下再来( ...
- 分布式系统关注点(8)——99%的人都能看懂的「熔断」以及最佳实践
如果这是第二次看到我的文章,欢迎右侧扫码订阅我哟~ > 本文长度为3319字,建议阅读9分钟. 阅读目录 熔断是什么 熔断怎么做 做熔断的最佳实践 总结 当我们工作所在的系统处于分布式系统初期 ...
- 分布式系统关注点(6)——「负载均衡」到底该如何实施?
本文长度为3032字,预计读完需1.1MB流量,建议阅读8分钟. 阅读目录 为什么没有DNS? 如何实施? 优缺点 结语 前面两篇<分布式系统关注点--初识「高可用」>.<分布式系统 ...
- 分布式系统关注点——如何去实施「负载均衡」?
本文长度为3032字,预计读完需1.1MB流量,建议阅读8分钟. 前面两篇<分布式系统关注点--初识「高可用」>.<分布式系统关注点--仅需这一篇,吃透「负载均衡」妥妥的>看完 ...
- 分布式系统关注点——如何去实施「负载均衡」? 1
本文长度为3032字,预计读完需1.1MB流量,建议阅读8分钟. 前面两篇<分布式系统关注点--初识「高可用」>.<分布式系统关注点--仅需这一篇,吃透「负载均衡」妥妥的>看完 ...
最新文章
- Git指南-Git-flow开发流程
- 服务器水厂物资管理系统,水处理管理系统及水处理管理服务器 Water management systems and water treatment management server...
- 14.1178亿人 流动人口超3亿 “大国普查”这些数据很重要
- Java LinkedHashMap values()方法与示例
- WEB开发中合理选择图片格式
- btoa java,JavaScript用btoa和atob来编码解码Base64
- linux 远程脚本批量 scopy文件
- 06 is和==的区别 encode()编码 decode()解码
- kali文件重命名_硬核教程,必看!「网络安全入门」四、文件上传漏洞
- ArmLinux BOOTLOADER全程详解
- docker运维工具
- android sdk多开,[原创]Android 应用多开对抗实践
- 【设计】死区时间控制
- Python集合运算
- Shell脚本编程实战
- 基于c语言的象棋游戏
- Java图片处理 - 缩放图片
- 随手科技企业入选互联网金融协会增选常务理事,消除随手记投资靠谱吗
- python 排列组合函数_Python概率统计(1):排列组合
- 最好的mac的epub阅读器
热门文章
- centos7 安装 wireshark
- python3 异步 asyncio aiohttp aiohttp-requests aiofiles 使用
- linux ssh 提示 too many authentication failures for root root的身份验证失败太多 解决办法
- linux c uuid guid 生成
- linux 多进程 多线程的选择
- openwrt下让telnetl与ssh(dropbear)共存
- 通过GeoIP2分析访问者IP获取地理位置信息
- JAVA中常见的Exception
- oracle 状态unknown,Oracle RAC 一个节点的instance资源状态为unknown
- C++ - 实现strstr函数