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

Patagonia

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

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

开发者之间意见不同

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

服务边界所产生的障碍

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

独立的服务

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

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

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

服务的粒度

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

DevOps

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

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

转自 InfoQ

本文来自ChinaUnix新闻频道，如果查看原文请点：http://news.chinaunix.net/opensource/2014/0814/3196780.shtml