转载

微服务开发过程中的反模式

在近期举办的 QCon伦敦大会上， Tammer Saleh 在一场演讲中描述了他在微服务方面遇到的一些常见的反模式以及对应的解决方案。他表示，一体性应用的主要问题在于应用难以扩展，但更重要的问题在于团队也难以扩展。因此，选择微服务的主要原因是团队方面的因素。

对于小型应用和小型团队来说，一体性的应用没有任何问题，但随着应用的规模不断增长，以及开发者团队的膨胀，他们已无法在同一个代码库中进行合作。选择微服务能够让我们以适合自己的方式应用康威定律。

Saleh表示，微服务的构建是一项非常复杂的工作，只要在某个方面没做好，就有可能走到错误的方向上。在他看来，最常见的错误就是在起初阶段就企图实现微服务。他强调说，对于任何一种系统，起初都应该尽可能选择简单的方式，只有当团队或业务有需要时，再开始逐步地迁移至更复杂的解决方案上。他提到，对于一个公司来说，最重要的是快速进入市场赚钱，而不是去探索有趣的架构模式。他给出的方案是在起初阶段选择一体性方式，等到有必要时再进行提炼。他还指出，微服务为开发过程施加了持续的负担。

当访问量达到高峰时，必须维护足够数量的服务器，以应对峰值时的负载。但随着访问量与服务器数量的提高，数据库最终会达到过载状态。一种方案是通过队列分担这种负载，队列基本上就是一种缓冲，以缓解过高的访问量。为此，通信需要转变为异步方式，而这样一来，由于请求与响应的生命周期被打破，客户端将不得不处理异步的响应，使得整个应用的复杂度再度提高。但在Saleh看来，这一步是必不可少的，否则组织将不得不在计算资源上投入过多的金钱。

从运维的角度来说，如果某些服务尝试连接某个特定的服务，而后者又无法响应，这将成为一个严重的问题。由于大量的请求不断涌入，因此很难对已产生故障的服务进行故障诊断与修复工作。如果成百上千的其他服务仍然在向该服务发送请求，就可能会导致各种各样的问题。有一种解决方案是使用断路器，它能够使请求无法达到发生故障的服务。在正常工作情况下，断路器允许所有的访问通过，而一旦它发现了某个故障，就会阻止对它继续访问。等到出故障的服务能够再次响应，访问才能够继续通过断路器。

随着微服务的兴起，也出现了一系列新的测试模式。一种常见的模式是模拟某个待测试服务所调用的各种服务，测试某个服务的团队将不再与所调用的服务进行通信，而是为这些服务编写模拟对象。这最终意味着每个团队都需要为其所调用的服务编写自己的模拟对象，由此可能会产生大量的额外工作。按Saleh的经验来看，一种通用的解决方案是让每个团队为其负责的服务编写一个通用的模拟对象，这样一来，每个服务都只对应一个模拟对象。作为对这种方案的一种改进，他进一步提议让每个团队为服务编写特定于语言的客户端，让调用该服务的其他服务使用这个客户端。客户端将处理与服务之间的实际通信，它本身也可以提供模拟对象。在Saleh看来，这种方式的优点在于每个服务对于所用的协议具有完整的控制，并且能够在必要时进行改动。他同时相信，这种方式是一种更易用的接口。

在2015年的一篇博客文章中，Stefan Tilkov 反对在起初阶段总是以一体性方式设计应用的思想。他认为对于足够复杂的系统来说，从一开始就应该考虑将其设计为多个独立的子系统。

在今年早些时候，Ben Christensen在一场报告中谈到了使用由服务团队编写的客户端库，并将其作为访问该服务唯一的正式途径的风险。

QCon的参会者已经可以下载Saleh的报告内容了。而不久之后，InfoQ的读者也可以欣赏到Saleh的讲座内容。

查看英文原文： Anti-Patterns Working with Microservices

原文 http://www.infoq.com/cn/news/2016/03/microservices-anti-patterns

正文到此结束