编者注：微服务架构（MSA）是一种架构概念，旨在通过将功能分解为离散服务来解耦解决方案。您可以将其视为在架构级别而不是获取服务的类应用许多SOLID原则。微服务架构是一个非常有趣的概念。其主要作用是将功能分解为离散的服务，从而降低系统的耦合度，提供更灵活的服务支持。【翻译】微服务架构在2014年开始受到关注，作为加速Web和移动应用程序开发过程的一种方式。今年，更多的组织将受益于微服务。使用服务构建应用程序的概念一直很吸引人。当您可以通过标准API组装多个利用相同服务的应用程序时，为什么还要从头开始编写代码？只要正确配置这些服务，您就应该能够获得巨大的规模经济。过去，在过度工程的压力下，尤其是CORBA和SOA趋势下，实现这一概念的尝试都失败了。但微服务最有趣的方面之一是使用微服务曾经是一种由开发人员驱动的草根现象。从广义上讲，微服务是可通过API访问的小型单一用途程序。这一次，服务理念深入人心。有关微服务架构的实际示例，请查看这篇2014年的博客：我们如何在Karma构建微服务，作者是Karma的首席技术官StefanBorsje，该公司是一家向消费者销售无线热点的公司，也是联合创始人。根据Borsje的说法，该公司的开发团队在开发在线商店时“无意中使用”了微服务。我们从一个大型后端应用程序开始，并在必要时将其分解成多个部分。随着我们继续构建应用程序，我们会清楚我们要解决的问题；我们对问题越熟悉，就越需要为应用程序的不同部分设置界限。每当我们遇到一个应该是独立部分的组件时，我们就把它变成一个服务。起初，这些部分相对较大，但正如其他用户采用微服务的情况一样，我们也发现这些部分可以变得越来越小。例如，那个单体应用程序最初有一个“商店”组件，Borsje的开发团队将其细分为订单处理、订单履行和跟踪等服务。甚至面向公众的前端也被分解为多个服务。Borsje说，将细粒度的功能分离成独立的服务大大提高了生产力，部分原因是开发人员在开发时无需担心单体应用程序的所有依赖关系。对于Karma来说，微服务最大的问题是测试方面。正如Borsje所说：“行动和最终结果相差甚远，很难找出确切的因果关系。链条上可能会出现问题，但链条中哪里出了问题？”《敏捷宣言》该书的合著者MartinFowler在去年3月梳理了人们青睐微服务的原因，然后在11月发布了一个演示文稿，更详细地概述了多层微服务测试系统。毫不奇怪，他赞成对个别服务进行单元测试，尽管他承认这不足以确定整个系统是否正常运行。他深思熟虑地列出了一系列集成、组件、契约和端到端测试策略，这些策略有望帮助开发人员理解微服务中最棘手的问题之一。另一个问题是你不能总是预测哪些微服务在某些情况下可能无法满足需求。我确信这就是Karma在AmazonWebServices(AWS)上部署其电子商务平台的原因之一。在AWS环境中，自动扩展会根据需要增加计算容量，有助于确保没有任何单一服务成为瓶颈。注意：微服务的典型代表Netflix也使用AWS——换句话说，微服务和云是齐头并进的。理论上，你可以使用VMware或OpenStack来构建自己的具有自动扩展能力的私有云，但这样做很困难，这也是公有云获胜的一大原因。另一个支持微服务的流行技术是Docker，它用于打包应用程序，然后将它们部署在Linux容器中。事实证明，微服务和Docker是天作之合，这也是现在各大公有云都支持Docker的原因之一。显然，没有人声称微服??务可以解决所有问题。但是微服务架构可能会在其他基于服务的解决方案失败的地方取得成功，因为它是自下而上出现的。开发人员确定服务的类型和粒度；随着这种趋势蔓延到大型企业，开发团队能够确定哪些服务对整个企业来说是一流的。如果使用过去的硬连线基础设施，这种临时扩建是不可能的。同样重要的是，开发人员在协作方面有了很大改进，这种文化转变有助于以自然顺序构建软件架构，而不是遵循来自上层的命令和规定。据我所知，许多企业的开发人员已经在采用微服务架构，无论是否具备管理知识。有了正确的云基础设施，无论是公共的还是私有的，微服务架构不仅可以提高开发人员的生产力，还可以帮助开发人员开发以前无法构建的新型应用程序。英文原文：为什么2015年将是布加迪编撰的微服务年
