BT

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

数据是实现微服务的难点

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

企业在创建和开发微服务的过程中,最困难的问题之一就是他们的数据。如果我们采用领域驱动设计(Domain-Driven Design,DDD)来分析业务领域并剖析数据所代表的含义,将会有助于实现微服务架构Christian Posta在一个关于微服务实现的系列博客文章中阐述了该理念。

Posta是Red Hat的中间件主架构师,对于他来说,选择微服务架构的主要原因在于这种架构能够让负责系统不同组成部分的团队按照不同的进度来开展工作,并且能够让他们之间的相互干扰达到最小。当按照这种方式来组织团队的时候,系统架构能够反映出这种变化,并且会向微服务架构来演化。

但是,如何让团队之间的这种自治真正运转起来,这一点其实并不简单。在单体架构中,通常会使用事务并且只有一个数据库,如果每个服务都具有一个数据库,那么这会变成一项挑战,对于传统的企业来讲更是如此。

Posta指出,在实现微服务方面,互联网公司和传统企业之间有着巨大的差异。互联网公司采用微服务的目的主要是解决大量数据和扩展性的问题,而传统企业要同时处理业务和扩展性方面的复杂性。播放影片或发送推文的复杂性要远远低于保险索赔系统的复杂性。

在为相对复杂的企业域构建微服务时,我们需要找到在这个域中不同责任的边界。在每个边界中,我们会创建领域模型,这个模型是针对业务责任所设计的,并反映了这种业务责任。针对每个边界的数据模型会由同一个边界中的领域模型来驱动。采用DDD的方式我们能够找到这些边界,并会为每个边界创建一个有界上下文(bounded context),每个上下文将会成为一个微服务。

在Posta的经验中,开发人员在构建分布式系统时,会倾向于假设只有一个关系型数据库,并试图将网络的不稳定性抽象出来。跨多个服务所带来的分布式数据问题通常会通过二阶段提交来解决。与这种做法不同,Posta相信,我们必须要寻找每个有界上下文中的事务性边界,并找到满足业务限制和不变量的最小原子单元,不要让事务传播到其他的上下文之中。

我们还需要有一种机制,能够让服务通知其他的服务发生了什么,针对这种需求,Posta推荐使用事件。我们的服务会发布事件,描述在这个域中发生了什么,其他的服务会读取这些事件,调整它们自己的模型并将变更进行持久化。

关于这些理念的更深入描述,Posta引用了Vaughn Vernon发布的一系列博客文章,这些文章基于DDD理念,描述了聚集、事务边界和有界上下文。

查看英文原文Data is the Hard Part Working with Microservices

评价本文

专业度
风格

您好,朋友!

您需要 注册一个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