12|云时代的挑战(上):弹性边界还是业务边界?
徐昊
该思维导图由 AI 生成,仅供参考
你好,我是徐昊。今天我们来聊聊云原生架构中弹性边界对业务建模的影响。
通过前面旧约部分的学习,我想可能会给你留下这么一种印象,4-6 节和 7-9 节分别给领域驱动设计打了两个大补丁:
通过不同的上下文对象,弥补原生对象模型从单体架构过渡到多层架构时的各种水土不服;
通过不同的建模方法,从业务维度展开入手,以不同的角度寻找可以被建模成对象的领域概念。
最终经由我们打过补丁的业务建模方法,就是一种在领域驱动框架下,从业务角度出发,又兼顾了架构约束的特殊的面向对象建模法(Object Oriented Modeling)。
如果你希望达到如下的诉求:
采用领域驱动设计的“两关联一循环”作为主要沟通协作的方式;
将模型作为统一语言,并用于提炼知识的循环;
在单体分层架构模式下,将模型的能力通过 RESTful API 暴露。
那么之前所学就基本满足你的要求了。但如果你的目标架构不仅仅是单体分层架构,而是更云化的架构风格,比如微服务(Microservices Architecture)等等,有了不同的关注点,那之前打的这两个补丁,就不足以支撑我们在新的架构风格下完成业务建模了。
因为更云化的架构风格有了新的关注点:弹性边界(Elasticity Boundary)。弹性边界是云原生(Cloud Native)架构的核心概念,决定了我们是否能够充分发挥云平台的全部能力。于是我们就需要新的方法来弥补原生对象模型的不足,以满足我们的需要。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了云原生架构中的弹性边界对业务建模的重要性及影响。作者强调了弹性边界在云平台架构软件时的关键性,并提出了弹性优先原则,强调在云平台上弹性永远是第一优先级。通过比较单体架构和微服务架构的弹性边界划分,阐述了弹性边界对系统运营成本和灵活性的影响。此外,还讨论了弹性边界与业务上下文的配合以及在领域驱动设计中如何体现弹性边界的挑战。最后,介绍了新的建模方法8X Flow来解决这些问题。总的来说,本文通过深入的技术讨论,为读者提供了对云原生架构中弹性边界的重要性和实现方式的全面了解。文章内容涵盖了云平台弹性边界的概念、弹性优先原则、微服务架构下的弹性边界划分指导原则以及弹性边界对业务建模的挑战,为读者提供了全面的技术视角和实践指导。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《如何落地业务建模》,新⼈⾸单¥68
《如何落地业务建模》,新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(11)
- 最新
- 精选
- Jxin本章: 让我们站在产品视角看待这个弹性边界的划分方式。 弹性边界可以为产品提供成本优势,成本优势可以构建护城河阻挡竞争对手。但护城河除了成本还有很多元素,比如创新。那么创新和成本孰轻孰重,这个不好说,得看商业周期的阶段。但大多数时候我觉得创新应该更重要些,创新决定存活,成本决定活得多好。那么站在软件工程的角度如何去支撑产品视角的创新?答案是合理的业务边界与扩展性。这就得出我的观点,以业务为边界比以弹性为边界对于企业发展更有利。但这个观点其实不一定成立,因为它把业务边界和弹性边界划分成非此即彼的对立概念,而现实中,它们是可能划分出相同系统结构的两个视角的决策依据,既合理的业务边界也是合理的弹性边界。如果必须得做个先后,我还是比较推崇业务边界优先,弹性边界随后,创新放在成本前面。引用CEO埃隆·马斯克在财报会议的话:真正重要的是创新节奏,这才是保持竞争力的核心要素。 课后题: 1.弹性边界依旧会有网状依赖的场景,这时候发版的顺序与节奏就依旧要提前规划,唱票执行。 2.服务提供方弹性扩容的滞后会导致服务依赖方扩容的虚高。比如服务提供方10台机器,服务依赖方也是10台机器,这个时候流量是平稳的。然后服务依赖方随着流量激增扩容到了50台,而服务提供方依旧是10台,那么很快服务提供方资源就会被打满。反应到服务依赖方就是大量线程等待,可能会引发服务依赖方进一步扩容到100 150台。(虽然cpu不是强关联资源,内存才是。但是线程的创建也是有内存开销的。如果严控线程上限,那么线程打满时该不该扩容也是个问题)
作者回复: 这是个因果的问题 业务边界和弹性边界谁是因 提示:弹性的低成本通过逆康威定律影响现实中业务运营模式 然后传递到软件
2021-07-2923 - Oops!业务的边界相对比较稳定,弹性的边界不仅和业务有关,也受具体实现的影响,更具动态性,因为流量会传导下去,业务逻辑会影响流量的流向,进而影响各依赖模块的弹性需求。在建模阶段考虑弹性边界是否太早了些,毕竟考虑弹性需求的主要动机是提效降本,这是一个系统优化的问题。为了很灵活的应对各个业务领域动态的弹性需求,将服务拆的更细一些,或者设计是考虑按需部署的需求,支持各个领域服务灵活部署,可以按照流量需求或部署到一起或分开来,会不会比在建模时考虑弹性边界更能有效的应对流量的变化呢?
作者回复: 看下一课
2021-07-293 - 邓志国对大部分应用来说,可能几台机器的扩展就到头了。这种情况下,弹性带来好处非常有限,可能大于带来的复杂度导致的成本增加。
作者回复: 那就不要说自己是云啊 hosted dc也不丢人
2021-08-112 - 码农戏码微服务的拆分,认知还停留在原始的功能上下文纬度,质量(部署、性能、可用性)以及康威定律上。理解的“微”不是要多小,而是要系统职责单一 虽然上云了,也知道云的伸缩性,但从没考虑到架构需要跟随更新,前面课程中提到的要保持对架构演化趋势足够关注真不是一句空话,认知被刷新了 软件的变更和部署也是弹性诉求,这倒与现在的一些考虑点相符,也就是从系统迭代和发布频率角度考虑拆分微服务 弹性优先,理解为对拥抱变化的深一层解释,没云时,软件架构不管怎么变,至少所在硬件容器是相对固化的,扩容也那没么灵活,到云时代基础设施都能随流量动态变化了,一切都在变;从弹性优先看我们当前的微服务拆分几乎都是错的,弹性一致的也被拆了好些,更没想过一旦流量暴增,流量传递超成系统整体扩容带来的容器资源超限,似乎没掌握云时代微服务的精髓,真的不如单体架构来得爽快
作者回复: 微服务的成本高于单体 如果没有对应的收益 不如不搞
2021-08-061 - bird弹性优先还是业务优先,是不是还要结合业务体量规模、流量去评估,如果是中小规模,微服务也就十几个,应该还是业务优先吧?
作者回复: 业务优先不需要拆微服务
2021-07-2931 - 黄鹤受楼上邓志国同学的问答,补充个问题: 2B应用,想做SAAS模式。需不需要做成云,或者,其中的哪些部分适合做成云,哪些不适合?这是最近在思考的一个问题。 采用什么样的布署结构?哪些适合按上下文边界来拆分布署,哪些适合按客户或客户群来拆分布署?有哪些因素影响这个设计决策?
作者回复: 至少做成IaC
2021-08-262 - escray云平台是微服务的前置条件,那么云平台的前置条件是什么? 从弹性边界角度来考虑是否需要拆分微服务,也就是说某个业务上下文是否值得放入独立的弹性边界,这个的确是一个比较合理的拆分思路,可能还可以结合某个业务是否经常发生变化。
作者回复: Infrastructure as code
2021-08-17 - 冯弹性边界可能会经常变化,一个弹性边界会不会突然分裂成几个,这种分分合合,感觉好难hold住
作者回复: 所以不能硬来 从业务里借力
2021-07-29 - 云师兄归根到底,在云时代进行业务建模时,我们需要确立一种模型结构以反映弹性边界。同时,在弹性边界切分业务上下文时,还需要确立另一种模型结构,去重建一致性边界。2021-07-292
- davix康威定律劃分的微服務難以避免😪2022-05-06
收起评论