BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

从一体性架构转换为微服务架构

| 作者 Jan Stenberg 关注 34 他的粉丝 ,译者 邵思华 关注 3 他的粉丝 发布于 2015年12月17日. 估计阅读时间: 3 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

在今年的伦敦微服务大会上,Ian Cooper演讲中为听众描述了从一体性架构转至微服务架构的一些指导原则。在他看来,架构的转换对于业务干系人来说唯一的价值就在于成本的降低。它既不会增加或保护你的收益,而可伸缩性与分布式的特性也不是能够说服业务人员的好的理由。之所以这种架构转换能够减少项目的总体成本,是因为开发人员在转换后的架构中所面对的将是相对较小、较简单的上下文,从而提高了他们的生产力。

Cooper也是伦敦.NET用户组的创建者,他指出:人们在提到微服务的时候通常会连带提起业务能力,但对于业务能力的概念很少有清晰的定义。在他看来,业务能力本质上就是某个业务为客户所提供的有价值的功能,例如保险公司的保险销售业务。业务能力通常来说是非常稳定的,但这种能力也通常表现在一个较高的层次上。Cooper随后将这些业务能力转换为边界上下文(这一概念来自于领域驱动设计)的形式,使他们的表现更为具体。

在一体性的架构中,同样也存在着多个边界上下文,但他们会对资源进行共享,例如领域对象和数据库架构。这样一来,就造成了系统的各个部分之间的依赖性。一个功能的变更很可能会产生涟漪效应,影响到系统中的其他功能,这意味着系统的每一部分必须共同进行编译与部署。要将这样的架构转换为微服务的环境,你所要做的一切就是将这些互相依赖的功能分解为各自独立的边界上下文。虽然说起来简单,但Cooper认为实现起来并不容易。

Cooper描述了一种从一体性架构转换为微服务架构的方式,即对系统进行全部重写,但对他来说,这也意味着这一项目从敏捷变为了瀑布式工作流。其原因在于整个系统的替换必须要做到功能性的完整,新的系统必须在完全容纳了老系统的功能后才能上线。这样一来,新系统的开发在很长一段时间内将无法获得任何用户反馈,对于系统的表现只有在上线后才能了解。这样的项目往往会因为长时间内无法交付任何商业价值而被砍掉。

与上一种方式相比,Cooper所建议的方式是找到在整个业务中产生产生最多价值的特性,例如那些能够产生市场差异化、属于关键任务的特性、或者是变更快速的特性。Cooper接下来将这些特性逐个替换为新的代码,这种方式能够让他将某个边界上下文中的功能替换为新代码。最后,该上下文中的所有旧代码将失去功能,并被移除出系统。最终,到了某一时间点,所有的功能都将得到替换。在Cooper看来,这种方式的优点在于它保持了项目的敏捷性,通过增量式的架构重构以管理风险,并且能够更早、更频繁地进行交付。

来年的伦敦微服务大会计划在2016年11月7日至8日举办。

查看英文原文:Moving from a Monolithic to a Microservices Architecture

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT