BT

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

来自微服务实践受挫后的一些经验

| 作者 Jan Stenberg 关注 34 他的粉丝 ,译者 赵震一 关注 0 他的粉丝 发布于 2014年8月14日. 估计阅读时间: 3 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

虽然微服务microservices)是一种有关服务的设计和构成的正确理念,但是它很快会给你带来麻烦。Richard Clayton撰写了一篇文章,该文章讲述了他在实现和维护一个微服务架构中所遭遇的挫折,以及他在该过程中的观察和学习到的经验。

Richard是Berico Technologies公司的首席软件工程师,他强调他的团队虽然在开发微服务的过程中遭受了挫折,但是大部分的原因都与技术和实现的具体实践无关。在这个项目过程中,Richard找出了他认为造成这些挫折的五个主要原因。

开发者之间意见不同

在对微服务架构与一个更加传统的单片架构的利弊权衡问题上,团队中成员的观点并不一致,加上原本鼓励决策民主化,导致团队在无谓的争论中花费了大量的时间,同时带来了成员之间感情上的摩擦。而部分缺乏能力的开发者引入了大量存在缺陷的实现,同样也降低了团队的生产力。

服务边界所产生的障碍

根据将服务分配到人的决策,我们把后端分解成了8个独立的服务,从而强行固化了特定服务与开发者的权责关系。这导致开发者一方面抱怨它们的服务开发进度受阻于其他服务的开发任务,而另一方面却又拒绝帮助别人一起完成这些阻碍了进度的任务。这种隔离方式,同样也让开发者忘记了整个系统的首要目标,而只顾自己专注于个人的服务开发工作之中。

独立的服务

选择在服务间共享公共通用代码还是选择采用具有重复功能的独立服务,成为了一个需要权衡的重要问题,因为这最终有可能会导致重大的重构。.

在为每个服务约定API这件事上让人非常受挫,尤其是需要在每个服务间传递的模型,这方面这将导致很多常见的问题,特别是面向前端开发者时,这个问题仍然没有很好的解决方案。

没有显式定义好服务间的通信方式,而在所有场景中都使用着同一套机制,但是这种方式工作得并不好。最终,团队开始尝试一种CQRS的的通信模式,而这项尝试还没有时间来完整实施。

服务的粒度

对团队来说,一开始就分解成8个服务的动作有些过大,或许拆成两个服务会是一个更好的开始,而最终再根据实际需求将这些服务分解到多个微服务中去。

DevOps

持续交付(CD)的管道实现方面,或许是团队做得最好的部分。团队在这方面花了大量的时间来学习大量的课程,例如:维护多个小服务所产生的负担。

Richards就团队该如何开始微服务实践方面给出了一些建议,包括确认团队是否已经具备必要的技能、采用一种注重实效的方式以及适应团队和客户的能力。

查看英文原文:Experiences from Failing with Microservices

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

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

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

一开始就分解成8个服务的动作完全就是错误的 by Wong Peter

应该先分出1个服务,作为试验田,不但可以培训团队所需技能,还能减少摊子一下铺的太大的风险。成功后再逐个分解服务,逐个替换直至最后。

允许的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通知我

1 讨论

深度内容

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT