微服务架构的演进和解决的问题

许多软件公司都是从构建最小可行产品(Minimum Viable Product,MVP)进入市场并发展起来的;产品最初是单仓内的单体架构(Monolith),其功能由各小团队完成,小团队之间的依赖极其有限。

Airbnb也是如此,但在 2017 年,这个集中式架构达到了它的极限:

1. 软件变更速度降低;

2. 各团队分头并行演进面临限制;

3. 组件所有权混乱;

于是Airbnb 决定采用微服务架构(MicroServices),原本的单体应用被拆分为前台和后台(前后端分离),微服务可能出现在两边,再由专业的服务迁移团队(Dedicated service migration team)来专门负责组件的调整。(但如果与许多国内厂商相比,事实上Airbnb在这方面已经领先很多步了。)

三年时间里,伴随着业务的快速增长,Airbnb的微服务和对应的团队持续增加;也正因此,原来的问题又再次出现了:功能需要由多个服务和不同团队同步进行开发。

对微服务进行拆分以后,服务依赖的复杂度变得很高,服务治理也越发困难,一线的开发人员也很难理解服务之间的关系。(这点其实在中国的许多互联网公司里也普遍存在)

所以第三步,Airbnb将微服务合并成了宏服务(Marco Services),宏服务内部使用thrift通信,对外则通过暴露GraphQL接口实现对接,进一步治理了企业的平台架构。

Airbnb的微服务架构演进

从Airbnb的架构治理之路上可以看出,随着对架构治理的进步,企业会逐步碰到以下问题:

依靠核心角色进行架构治理带来的低效与脆弱性:当核心数字化业务从MVP生长为完整且复杂的产品后,业务上、团队上、技术上都会开始丰富并产生分化,不同模块需要独立进行演进,而不是共同配合一起来发布版本;所以团队表现出来的这些架构上的问题:软件变更速度降低、各团队分头并行演进面临限制、组件所有权混乱,都是因为不同模块的业务感受到自身发展受到集体拖累,而表达出来的、独立演进的诉求; 但究其根本,是研发团队需要过多得去理解不在其责任范围内的代码,而带来效率上的下降,是小团队工作、协作方式延续导致的结果;当团队规模很小时,核心架构师们可以快速对接并了解产品的架构全貌;而当团队规模扩大、核心人员离职等情况发生后,团队间再继续依靠频繁沟通、对齐的方式来解决问题,就会变得低效且重复;这时更需要通过明确团队职责和协作方法,用流程和机制来代替“人对人”之间的管理与合作。 微服务架构能够有效地解决团队责任田的问题,虽然这对于技术人员的专业性要求很高,而且必不可免的少不了专门的团队来辅助执行(也就是说有额外成本),但在建设过程中确实能降低各模块团队所需要面对的复杂性,最终微服务实现的其实就是将核心角色脑子中的知识,通过架构传递给团队。

难以理解的依赖地图,图片来源:Airbnb博客

依赖微服务进行架构治理带来的复杂度:随着微服务拆分的越来越多,对微服务本身的理解复杂度就又上升了;且不论是因为人员能力不足、还是沟通不足够充分,总之常态的结果就是必然导致微服务架构的这些问题:由于微服务的颗粒度较细而产生的理解复杂度、这些细颗粒度的微服务缺乏稳定的协作节点(导致修改、协作成本高)、缺乏协调能力导致协作成本由团队承担、即使是很小的变化也往往会导致连锁的影响; 问题的核心就在于,团队虽然通过微服务架构降低了与其它团队协作的成本,但这种缺乏管理的微服务生产方式,又会导致团队间缺乏必要的合作,最终致使承载在架构上的知识和上下文变得支离破碎,这时就需要对微服务进行管理(比如用分层、分领域等方式使微服务能更方便地被检索和理解)。 Airbnb探索出来的“三层架构”解决方案,就是用统一语言的API(Unified APIs)支持产品快速迭代,再通过耦合很强的单体“中央数据处理层”(Central data aggregator)来统筹API之间的关系,最后用抽象出来的API集合作为领域对偏底层的微服务进行合并。

简单来说,架构治理就是一个复杂的知识传递过程,本质上解决的是厘清“谁负责哪块代码,并如何让别人知道他负责这部分的代码,以及如何使用和协作这块代码”的问题;这样在团队进行代码开发时,可以用最低的成本理解并按设计思路去使用他人(微服务的负责人)提供的服务。

而除了过程中总结的方法论本身外,Airbnb也少不了用工具、组织架构辅助、配合方法论的执行。

比如Airbnb 部署了“Scry Ownership”,它是技术组件所有权数据(如所有者、维护者、通信渠道)的应用管理者。也就是说,通过这个工具,当你碰到不理解的微服务的时候,也能找得到人去询问并进行更深层次的合作。

“Scry Ownership”,图片来源:Airbnb博客

又比如Airbnb的“三层架构”解决方案,也是分别对应专门的产品团队(Product Team)、数据集成团队(Data aggregation team)和领域平台团队(Domain platform teams),来负责不同层级具体的开发;换句话说,Airbnb让组织架构配合技术架构进行了调整和匹配。

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

推荐阅读更多精彩内容