编者按：微服务架构（MSA）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多SOLID原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。
【51CTO译文】作为加快Web和移动应用程序开发进程的一种方法，微服务架构在2014年开始受到关注。今年，更多的企业组织会获得微服务带来的好处。
使用服务构建应用程序这个概念一直具有吸引力。要是既然可以汇编通过标准API利用相同服务的多个应用程序，何必要从头开始编写代码呢？只要正确配置那些服务，你应该能获得巨大的规模经济效益。
在过去，试图践行这个概念的做法在过度设计（尤其是CORBA 和 SOA趋势）的重压之下未能如愿以偿。但是微服务最令人关注的方面之一在于，使用微服务在过去是开发人员推动之下的草根现象。大致上来说，微服务就是可通过API访问的、单一用途的小型程序。这回，服务理念深得人心。
想了解微服务架构的实际案例，只要看一下Stefan Borsje在2014年撰写的这篇博客：How we build microservices at Karma，他是专门向广大消费者销售无线热点设备的Karma公司的***技术官兼联合创始人。据Borsje声称，该公司在开发网上商店时，其开发团队“无意中使用了”微服务。
我们从一个大型的后端应用程序着手，必要时将它分解成多个部分。随着不断地构建应用程序，我们开始清楚自己在努力解决的那个问题；而我们对这个问题越熟悉，我们需要为该应用程序的不同部分设置边界就来得越明显。每当我们遇到应该是独立部分的组件，我们就将它变成一个服务。
起初，这些部分相对较大，但是与其他用户采用微服务的情况一样，我们也发现那些部分可以变得越来越小。
比如说，那个整体式应用程序最初有一个“商店”组件，Borsje的开发团队将其细分为订单处理、订单执行和跟踪等服务。连面向公众的前端也被分解成了多个服务。Borsje表示，将细粒度功能分隔成独立服务大幅提升了工作效率，这在一方面归功于开发人员在开发时不需要操心整体式应用程序的所有依赖项。
对Karma来说，微服务存在的***问题在于测试方面。正如Borsje所说：“行动和最终结果相距甚远，以至于很难发现准确的因果关系。整条链中可能会出现问题，但这条链中到底哪个环节出了问题呢？”
《敏捷宣言》一书的合著者Martin Fowler在去年3月份整理出了人们青睐微服务的原因，随后在11月份发布了一篇演示文稿，较为详细地概述了多层微服务测试体系。他支持单个服务的单元测试，这不足为奇，不过他承认这不足以确定整个系统是否在正常运行。他贴心地列出了一系列整合、组件、契约和端到端测试策略，这些策略有望帮助开发人员尽量弄明白微服务最棘手的问题之一。
另一个问题是：你无法总是预测哪些微服务在某些情形下可能无力满足需求。我确信，这是Karma将其电子商务平台部署在亚马逊网络服务（AWS）上的一个原因。在AWS环境下，自动扩展功能能够在有需要的地方添加计算能力，有助于确保没有哪个服务成为瓶颈。请注意：微服务的典型代表Netfilx也使用AWS――换句话说，微服务和云相辅相成。从理论上来说，你可以使用VMware或OpenStack，自行构建具有自动扩展功能的私有云，但是这么做困难重重，这是公有云胜出的一大原因。
支持微服务的另一项***技术是Docker，这项技术用于包装应用程序，然后将它们部署在Linux容器中。事实证明，微服务和Docker可谓是天作之合，这是各大公有云现在都支持Docker的一大原因。
很显然，没有人声称微服务解决得了所有问题。但是微服务架构可能会在其他基于服务的解决方案失败的地方取得成功，因为它是自下而上出现的。开发人员确定服务类型和服务的细粒度；随着这股趋势波及到大企业，开发团队就能够决定哪些服务对整个企业而言是同类中***的服务。
如果使用过去的硬连线基础设施，不可能实现这种临时扩建（ad hoc build-out）。同样重要的是，开发人员在协作方面已大有改进，文化的转变有助于自然有序地构建软件架构，而不是遵守从上面下达的命令和规定。
据我所闻，许多企业的开发人员已经在采用微服务架构，无论管理层知情还是不知情。借助合适的云基础设施，无论是公有云还是私有云， 微服务架构不仅能够提高开发人员的工作效率，还能帮助开发人员开发出以往不可能构建的新型应用程序。
英文原文：Why 2015 will be the year of microservices
布加迪编译
