构建和部署微服务的模式

微服务管理意味着要看管大量相互通信的小型系统并提供自动配置功能，此外基础设施自动化也是极其重要的， James Lewis 在做技术与实践分享的时候声称这些有助于他管理日益增长的运维复杂度，而这些复杂度就是由于微服务架构造成的。

在ThoughtWorks 工作的咨询师James 对微服务的起源进行了描述，他认为这是对我们目前用于构建应用的方式的一种回应。一直以来，我们都是在构建那种庞大的而且难以修改、测试和管理的单片应用，这种应用从根本上来说就像是一个由像意大利面条那样乱作一团的代码所构成的大泥球（ big balls of mud ）。解决方案就是将原来的单片应用构建为更小的事物，并通过某些方式让它们相互之间能够进行通讯。

对于 James 而言，微服务意味着先选择一套大型的应用程序，然后识别出限界上下文（ bounded contexts ）及其内部的业务功能，并对它们进行分割，重要的是要将数据一起进行分割，也就是说要采用应用数据库而非集成数据库。为了理解业务领域的内容，关键的一点就是要在一开始就采用上下文图（ context map ）这个工具，James 引用了他的同事 lan Cartwright 的一段话：

业务和架构应该是同构的。业务人员应该能够通过查看架构的总体示意图来了解其反映的业务内容，同样，作为技术人员，我们应该能够通过浏览业务来领会其展现的架构内容。

微服务架构的一个很重要的方面就是规模，James 认为单一职责模式（SRP）（ Single Responsibility Pattern ）是一种很好的衡量标准。一个服务应该只有一个进行改动的原因，这在实践中意味着它应该是小型的并且足够专注，进而能够从概念上进行理解和把握。

James 认为微服务的一个核心概念就是能够对每个服务进行独立部署和扩展的可能性；一个服务可以被部署为多个实例，而不同的服务也可以托管在同一台服务器上。James 强调，在构建和部署分布式系统的时候，对自动化配置的关注是至关重要的，每个服务或者应用都必须自动地进行构建、部署和扩展。微服务的许多复杂性都来自于集成过程，但是我们可以应用一些模式来进行应对，还可以参考《持续交付》一书中关于构建过程的模式。

像 Chef 和 Puppet 这样的工具有助于实现机器的自动化配置，大量的服务会引入一定的复杂度，使用这些工具来进行基础设施自动化也是控制这些复杂度的重要方式。Phoenix 基础架构模式描述了一种我们利用基础架构自动化来再造所有的基础架构的方式，比如我们应该能够将电脑的信息都清除，然后运行一个脚本来重新构建它及其所有的依赖。

James 所提到的微服务大会定于十一月份下旬在伦敦举办。

查看原文地址： http://www.infoq.com/news/2014/07/building-deploying-microservices

感谢赵震一对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。