微服务笔记(二):边界

上篇简单介绍了微服务,列举了单块应用和微服务的一些区别,之后又在网上阅读了别人写的一些微服务文章,对比之下感觉自己的归纳和文笔还是差的太远,以后还需多练。

既然要使用微服务,那就必须要考虑如何对整个系统进行分解,哪些功能应该放到一个服务中,哪些不应该,即确定微服务的边界。有人会觉得这个问题很头疼,无从下手,也有人会觉得这个很简单,但是分解后的服务不断出现各种问题,让后续的开发变得十分痛苦。

我认为找到边界是采用微服务架构的最基本前提,也是最有挑战的部分,在没有认清服务边界的情况下,不要轻易使用微服务,否则可能带来很多意想不到的问题和麻烦。

什么样的微服务边界是合适的?

了解面向对象设计的朋友应该对“单一职责原则”、“开闭原则”等基本原则都不陌生,这些原则在架构方面同样十分受用。架构的核心价值不在于使用多么先进或者NB的技术,而在于使系统具有高度可扩展性,从而灵活应对业务的不断变化,持续演进。有句话说的好,“架构不是设计出来的,而是演进出来的”。而扩展性的基础就是松耦合、高内聚,这是我们应该多花一些心思思考的地方。

松耦合

微服务之间应该是高度松耦合的,从而避免一个微服务中的问题扩散到整个系统。如何判断是不是松耦合,最直接的一点就是可以独立修改和部署一个服务而不影响系统其他部分,如果修改一个功能时不得不对系统其他部分也同时做出修改,那么就要反思服务的边界是不是有问题了。

松耦合的服务应尽可能避免暴露内部实现细节,因为暴露内部实现细节意味着服务的修改,可能会需要服务的消费方也要跟着修改。此外也应该避免存在多种服务间的调用方式,这样也会增加服务的耦合度。

高内聚

既然要避免修改一个服务的时候带来系统其它部分的修改,就要保证相关行为都放在一个服务内,这就是高内聚的核心,也即我们思考如何找到服务边界要考虑的核心问题。

前篇有说过,“一个微服务只专注于一种业务,遵循单一职责原则”,即微服务的专注,要确保专注,就不能有其他无关行为夹杂进来,也不能有自身相关行为偷溜到其他系统中,要准确的把握所有相关行为并牢牢地把它们拴在一起。

什么方法能找到微服务边界?

分层

很多应用都会采用分层架构,所以会有种划分微服务方案,就是直接将原来的分层作为系统分解的边界,分解出来的微服务各自负责一个层的工作。比如一个可能很多人见过的例子,就是把数据持久化层单独做成一个服务,它负责所有的数据库操作,带来的好处是业务开发只需关注业务模型,而不用考虑底层存储,有专门的团队对持久化服务进行迭代和优化,对业务模型和数据存储做适配,但是随之而来的问题是大部分业务的修改都需要该服务同时也跟着修改,新的业务需求需要业务开发团队和持久化服务开发团队进行大量沟通才能进行,服务针对某个业务作出修改后导致其他业务出现问题等等,所以系统虽然做了分解,但仍然是高耦合的,无法独立对一个服务随时进行修改和部署。

分割

如果说水平的分层作为服务边界不是一个好的选择,那么垂直分割又如何?通常一个良好的系统在开发时都会考虑用模块来组织代码,将不同的行为放在不同的模块中,比如订单模块、支付模块,如果设计得当,各个模块之间的耦合会相对较低,业务逻辑基本都是高内聚的,只是共用了一些非业务逻辑的代码,所以按照模块的边界来分割系统应该是不错的切入点。

领域驱动设计(DDD)

在QCon伦敦2016大会上,《领域驱动设计》一书的作者Eric Evans提出,使用领域驱动设计(DDD)概念减少微服务环境中通用语言的复杂性。Evans建议,将每个微服务设计成一个DDD限界上下文,这为系统内的微服务提供了一个逻辑边界,无论是功能,还是通用语言。

限界上下文(Bounded Context)为高内聚提供了很好的理论指导,它的核心就是将特定职责的相关行为控制在一个有显示边界的范围内,Evans的一个比喻非常形象:“细胞之所以会存在,是因为细胞膜定义了什么在细胞内,什么在细胞外,并且确定了什么物质可以通过细胞膜”。近年来微服务的兴起又为DDD提供了很好的应用场景,只要深入挖掘领域知识,识别出合理的上下文,就能合理拆分微服务。

不过我觉得领域驱动设计是一门需要长时间积累的学问,你需要和领域专家充分沟通,共同找出通用语言,逐步深入挖掘领域知识来对领域模型进行迭代,这是一个持续的过程,因此在初期对领域知识掌握有限的情况下,不应急着过早划分细粒度的上下文。比较好的方式是先找出粗粒度的上下文,循序渐进,随着领域知识的深入再逐步分解,这个过程可能是长期的,颇具挑战的,而且往往会走一些弯路、远路,但是随着领域知识的沉淀和经验的积累,最终总是能得出更加准确的上下文边界和模型的。

总结

微服务要求有低耦合、高内聚的边界,使用 DDD 的限界上下文作为微服务边界是一种很合理的方式,但是服务的拆分应随着领域知识的深入逐步迭代进行,不可操之过急。所以重点又落在了 DDD 上,这也是我一直以来最感兴趣的架构思想,待以后对 DDD 的精髓有了更深的理解再和大家进一步分享和交流。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 158,736评论 4 362
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,167评论 1 291
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,442评论 0 243
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,902评论 0 204
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,302评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,573评论 1 216
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,847评论 2 312
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,562评论 0 197
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,260评论 1 241
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,531评论 2 245
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,021评论 1 258
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,367评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,016评论 3 235
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,068评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,827评论 0 194
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,610评论 2 274
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,514评论 2 269

推荐阅读更多精彩内容

  • “微服务架构”这一术语在前几年横空出世,用于描述这样一种特定的软件设计方法,即以若干组可独立部署的服务的方式进行软...
    ThoughtWorks阅读 16,815评论 1 71
  • 微服务近年来可谓炙手可热,合理的使用微服务架构可以解耦系统、提供更好的软件伸缩性以及提高组织的敏捷性。然而现实中较...
    MagicBowen阅读 2,998评论 0 13
  • 在开发一个微服务之前,我们要设计微服务。设计微服务和领域驱动设计(DDD)有密切的关系,DDD有助于我们设计微服务...
    书兴阅读 14,705评论 7 40
  • 一、微服务将变得轻量级 架构需要由人去设计,这些人被称为架构师。或许很多人并未授予架构师的头衔,但自己却从事着架构...
    justmilkrain阅读 5,336评论 10 109
  • 在我们的软件开发流程中,经常需要面临改动,有来自用户需求的改动,来自市场的,以及为了一些潜在机会而产生的改动等。当...
    草莓豆豆龙阅读 5,547评论 0 7