微服务架构设计 第二步: 分析微服务的边界上下文 (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 条评论
登录 后参与评论

相关文章

来自专栏码匠的流水账

聊聊系统设计中的trade-off

trade-off翻译过来大致是折中的意思,也就是说系统设计通常牵扯的点比较多,有的设计方案这个方面比较好,但是又有其他缺点,没有十全十美的方案,只是在特定的上...

662
来自专栏java一日一条

程序员面试的标准答案并不标准

Peter Verhas在技术面试时问了一个看似无关的问题,并得到了一个虽然没错但并不恰当的答案。随后,他宣称,“有时候,我会碰到那些不但不知道答案,还自作聪明...

261
来自专栏java一日一条

4个理由告诉你Java为何排行第一

Java已经有20年的历史了,甚至更久,而这取决于你所询问的人和你的计算方式。忽略它的年龄不看,Java依然排行第一。它的实用性、性能和向后兼容性都彰显其价值所...

502
来自专栏IT可乐

深入理解计算机系统(序章)------谈程序员为什么要懂底层计算机结构

  万丈高楼平地起,计算机系统就像程序员金字塔的地基。理解了计算机系统的构造原理,在写程序的道路上才能越走越远。道理LZ很早就懂了,可是一直没下定决心好好钻研,...

2217
来自专栏恰同学骚年

Scrum Guide - Scrum指南中文版

现在公司在使用敏捷开发模式进行日常的开发和管理工作,所以我看了下Ken Schwaber的《Scrum Guide》这本小册子,原本是英文的,这里提供中文的,...

722
来自专栏CDA数据分析师

工具 | R、Python、Scala 和 Java,到底该使用哪一种大数据编程语言?

有一个大数据项目,你知道问题领域(problem domain),也知道使用什么基础设施,甚至可能已决定使用哪种框架来处理所有这些数据,但是有一个决定迟迟未能做...

1968
来自专栏斑斓

设计匠艺 | 意图导向编程

意图体现在编程层面,仍然可以作为设计的导向,是谓“意图导向编程”。这种设计方法实则就是让设计者能够换位思考,站在调用者的角度思考接口。“假如我是调用者,我希望对...

3407
来自专栏技术小黑屋

Java程序员必读的9本书

本文列出的9本书在Java程序员界都是被认为很棒的书。当一个程序员开始初学Java时,他的第一个问题应该是如何选择一本书来作为指导学习Java。这个问题也就表明...

592
来自专栏我是攻城师

4个理由告诉你Java为何排行第一

2575
来自专栏数据的力量

数据分析工具--R语言各种优点

1543

扫码关注云+社区