微服务架构设计 第二步: 分析微服务的边界上下文 (Bounded Context)

2016.9.10, 深圳, Ken Fang

当特性负责人, 将特性的所有业务活动均分析出, 其各自的基本流, 扩展流与异常流之后, 特性负责人便可经由组合基本流, 扩展流与异常流, 而分析出从外部使用者或外部产品的视角, 有价值的端到端的业务场景切片后, 特性负责人便可将各业务场景切片中, 共同的场景提取出, 成为所谓的 infrastructure services。

也就是说:

A. 对外部的使用者或外部的产品而言, 有价值的端到端的业务场景切片, 便构成了所谓的 functional services; 可供外部使用者或外部产品经由 api layer 来调用。

B. 各 functional services 中所存在的共同场景, 便构成了所谓的 infrastructure services; 只供 functional services 调用, 外部使用者或外部产品是无法经由 api layer 来调用的。  

现在的问题是:

经由基本流, 扩展流与异常流的组合, 所构成的业务场景切片, 是否就能形成 functional services 这类微服务的最佳边界上下文 (Bounded Context) ?

要能回答这个问题, 需先思考下面的六个问题:

1. functional services 边界上下文 (Bounded Context) 内的业务场景切片是否过于庞大与复杂? 而使开发人员与测试人员不易理解?

2. functional services 边界上下文 (Bounded Context) 内的业务场景切片是否过于庞大与复杂? 而使得在版本开发中, 会产生过多的变更或缺陷, 而使得版本升级的速度与质量因此而下降?

3.  functional services 边界上下文 (BoundedContext) 内的业务场景切片是否过于庞大与复杂? 而使得在版本开发中, 此 functional services 已无法由单一的团队所完成?

4.  functional services 边界上下文 (BoundedContext) 内的业务场景切片, 实际是否仅是能完成某业务活动中的某个功能点? 因而, 使得此 functional services 需要远程调用其他多个的 functional services, 才能完成某业务活动中的某个业务切片; 别忘了, functional services 之间的远程调用, 往往可能会引入性能、可靠性、甚至是安全性等的问题。

5.  functional services 边界上下文 (BoundedContext) 内所包含的数据库是否需与过多; 举例: 超过 7 个; 其他的 functional services 发生数据一致性的问题; 别忘了, 在分布式微服务的架构下, 微服务间的数据是一定会延迟的, 所以,假如, 某个 functional services 边界上下文 (Bounded Context) 内所包含的数据库, 是需要与过多其他的 functional services 维持数据的一致性时, 则将会因过长的数据延迟, 而使得使用者的体验不佳。当然, 要维持众多 functional services 间的数据一致性, 在开发上也不是件容易的事。

6.  是否会因过多的 functional services , 而使得在自动化配置、测试与自动化部署的难度与风险增加?

所以, 当特性负责人, 经由基本流, 扩展流与异常流的组合, 所构成的业务场景切片, 而形成 functional services 这类微服务的边界上下文 (Bounded Context) 后, 便需与团队中各不同领域的成员; 架构师, 开发骨干人员, 测试经理, 资深测试人员; 再共同的协作, 针对每个 functional services, 反覆的推敲、分析、回答上述的六个问题, 直到获得大家都认可的, functional services 这类微服务的边界上下文 (Bounded Context) 为止。 

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏腾讯大讲堂的专栏

微信红包系统设计 & 优化

编者按:经过2014年一年的酝酿,2015微信红包总量创下历史新高,峰值1400万次/秒,8.1亿次每分钟,微信红包收发达10.1亿次,系统整体运行平稳, 在这...

3148
来自专栏即时通讯技术

达达O2O后台架构演进实践:从0到4000高并发请求背后的努力

达达创立于2014年5月,业务覆盖全国37个城市,拥有130万注册众包配送员,日均配送百万单,是全国领先的最后三公里物流配送平台。 达达的业务模式与滴滴以及Ub...

283
来自专栏灯塔大数据

干货|管理大数据存储的十大技巧

在1990年,每一台应用服务器都倾向拥有直连式系统(DAS)。SAN的构建则是为了更大的规模和更高的效率提供共享的池存储。Hadoop已经逆转了这一趋势回归DA...

2886
来自专栏织云平台团队的专栏

腾讯最完整的监控体系介绍,看这篇就够了!

腾讯业务监控体系的层级构成,用代表性的监控系统阐述每个监控层次的实现方法,以及与监控体系配合,业务做了哪些容灾和调度的方案。从而和大家分享腾讯最完整的关于做监控...

2.5K6
来自专栏数据和云

YH10:分布式存储解决方案zData

云和大数据时代的到来导致各行各业数据量的爆发,面对业务数据的日益剧增,企业的IT系统在性能、稳定性和扩展性等方面都面临前所未有的巨大挑战。如何有效应对云和大数据...

3514
来自专栏PingCAP的专栏

云时代数据库的核心特点

最近几年,随着云计算相关技术的发展,各种不同类型的云层出不穷,服务越来越多不同类型的企业业务,传统企业也渐渐开始探索上云的道路。在云上,作为业务最核心的数据库,...

2790
来自专栏编程一生

接口服务规划的个人想法

1264
来自专栏逸鹏说道

解析微服务架构(一):什么是微服务

解析微服务架构系列文章将分几篇描述微服务的定义、特点、应用场景、企业集成架构的演进以及微服务转型思路和技术决策考虑等内容,并以IBM技术为例介绍如何实现微服务架...

2834
来自专栏腾讯架构师的专栏

TCS 弹性计算平台:像工匠一样耕耘云计算

2016年腾讯架构平台部相继推出了两朵云:云存储和云接入,截至目前,弹性平台运营的计算力,服务了公司图片压缩、视频转码、离线计算和AI计算等多个计算场景,前不久...

2890
来自专栏织云平台团队的专栏

腾讯 SNG 监控数据的创新应用

本文将向大家分享SNG监控十年来变革背后的驱动因素和立体化的监控方案,最后给大家展示最新的智能监控的应用场景。

6.4K5

扫码关注云+社区