黑色星期五和网络星期一是一个购物者的喜悦和许多零售商最繁忙的一年时间。对于哈德逊湾公司（HBC），拥有并经营洛德 - 泰勒，萨克斯5th大道等几个品牌，去年的假日高峰竟然是尝试新的网站功能的最佳时机。
HBC使用一个相当典型的Oracle WebLogic应用服务器和一个名为蓝色马提尼从RedPrairie公司的电子商务平台。基本上栈已开发和完善了多年。它的工作，但它是“难以部署，难以改变，并...很难升级，说：”马修匹克，谁在HBC管理的基础设施工程团队，并谈到了该公司的数字化改造在一次会议在今年早些时候召开了由云供应商Joyent公司。
因此，HBC工程师开始探讨他们如何解决这些问题。微服务和容器竟然是答案。
挑选和工程团队选择了商品详细页（PDP）为第一的地方开始自己的平台革新项目。PDP是一块电子商务的应用程序，房屋产品说明和图像。代替的PDP被嵌入在应用程序中，开发人员HBC打破了它成12个单独的微服务，在应用程序容器每一个托管（一个负载的图像，另一用于文本等）。
挑选看到了许多的优势，切换到基于微服务的设计：升级会更容易开发和推动，以及解决问题会更精简。例如，对于微服务，如果价格报告功能下降，问题是（理论上）包含到一个服务团队负责解决它。拥抱容器和微服务也是一个更广泛的战略，以支持移动浏览和响应式设计的一部分。
当它在去年的黑色星期五/网络星期一发布新的PDP时，HBC做了一个黑暗的发布，这意味着只有一部分公司的流量被发送到PDP微服务。如果新方法有问题，它可以被关闭，所有流量将以传统方式处理。“我们并没有把整个网站都点燃，”匹克说。“在某种程度上，有了新技术，你就不得不说，‘让我们试试吧。’”
挑选和HBC是越来越多的是与基于微服务架构的应用试验机构之一。这是由应用程序开发者编写和更快速地部署新的代码，更轻松地管理复杂的应用程序的渴望多数民众赞成获得显著蒸汽，在过去两年的趋势。但是，像任何新技术，微服务来与自己的挑战。
什么是微服务？
有许多方法专家介绍微服务，但没有一个在定义达成一致。基本上，它是不是建立单一应用程序，开发人员构建了一系列弥补应用组件的想法。IDC分析师Al Hilwa描述微服务为“一个更精细的软件架构，其中应用程序组件的设计和独立发展。”该组件使用通用API缝合在一起。基本上，应用或服务被分解成许多不同的组件和使用API胶合在一起。
听起来有点熟？微服务哈肯回到昔日的流行语：面向服务的架构（SOA)，即分别构建应用程序组件的思想。
“在微服务企业的兴趣是寻找下一代的方法来面向服务的架构，以及使用与容器微服务的推动下，”大卫林西克姆，在咨询云技术合作伙伴高级副总裁说。
尽管它们很相似，但大多数专家表示，SOA通常更局限于使用更传统的基础设施组件的单一编程语言和开发环境。微服务代表了一种相对更为敏捷的方法，用于开发由小型独立流程组成的复杂应用程序。组成应用程序的微服务可以用不同的语言编写，使用标准化的api相互通信，并驻留在下一代基础设施上，例如在使用应用程序容器的同时在虚拟化或公共云环境中。
优势
微服务方法提供了一些优势:
- 敏捷：通过解耦应用程序的组件，可以独立地开发每个单独的部分。创业公司GitLab的首席执行官Sid Sijbrandij说:“你不再需要把整个开发团队都锁在同一个步骤里。”GitLab是一个与GitHub竞争的代码库。你可以让10个10人的团队来开发应用程序的组件，并在他们准备好时部署新功能，而不是让100人来开发单个应用程序。而不是计划更新和等待整个应用程序启动，新功能一旦准备就绪就会启动。
-graceful降解：如果应用程序的一个组件出现故障也不会撤下整个应用程序。“我们的目标是尽量减少失败的爆炸半径，解释说：” 451 Research分析师唐尼Berkholz。例如，如果一个银行的网站使用的是微服务的方式建立，如果转移资金的功能被打破，客户将仍然能够查看他们的收支。当服务是独立构建和部署，然后 - 在理论上 - 如果一个服务出现故障也不会影响到其他人。
减少开发团队之间的同步。在微服务架构开发团队创建构成独立的其他球队的申请件。每个那些部分写入到一个通用的API，所有的组件相集成。有开发团队只专注于一个单一的一部分促进良好的编码习惯，Sijbrandij说;功能单一的球队成为了该功能的专家。
然而，基于微服务实际构建的应用程序可能难啊容易。
挑战
451研究分析师Berkholz表示，采用敏捷或devops思维模式的团队更有可能成功构建微服务应用程序。Devops是将开发人员和操作功能结合在一起的实践——字面上或以某种基于团队的方式。
在这些环境中，代码是快速编写，测试和快速部署。许多DEVOPS店已经接受了自动化，自助服务的基础设施，如用于测试和开发或生产级应用高度虚拟化或云环境。451项调查研究表明，组织三分之二的敏捷方法的应用开发和大约40％的人使用DEVOPS采用。这些都是Berkholz说是最有可能与微服务成功的组织。那些没有采用这些下一代应用的发展趋势组织可能会发现微服务更加困难的过渡。
通常，在这些敏捷和DEVOPS店，正在使用的应用程序容器。在HBC挑选，他说，容器和微服务是共生的。当你打破了单片应用为组件，在容器中运行这些服务允许应用程序开发和基础设施运营团队是在同一页上。开发商知道包装容器中的应用程序和运营团队准备的基础架构来运行容器。
微服务还有其他的基础设施影响。Forrester分析师戴夫•巴托莱蒂(Dave Bartoletti)表示，当开发人员开始接受这些趋势时，IT基础设施的角色就会发生本质上的变化。
“开发商谁建微服务不会去IT和文件为新虚拟机的一票，”他解释说。敏捷开发者的期望，基础设施资源的按需提供，通过API和弹性可扩展性。
当然，有很多工具可以支持这种基础设施环境。可以使用来自VMware或OpenStack的私有云软件来构建内部云。如果不想自己构建基础设施，可以使用来自Amazon、Microsoft、谷歌和其他公司的公共云平台。来自Cloud Foundry或Red Hat的PaaS平台可用于自动化基础设施控制。所谓的serverless计算平台非常适合于事件驱动的应用，如在物联网的使用案例互联网。从根本上说与这些平台的改变IT的变化，从供应基础设施建立，开发人员可以部署到自己的微服务环境的作用。
什么微服务是最好的
并不是所有的应用程序都能从微服务架构中受益。Berkholz说，这个应用程序必须足够复杂，可以分解成许多不同的组件。如果它是一个简单的应用程序，只具有一个功能(想想一个只有几个星期的网站的营销活动)，那么微服务可能就没有必要了。一个包含很多组件的复杂应用程序，比如一个用于处理物联网数据流的应用程序，可以作为单独的组件进行开发和管理。
于拾HBC，以微服务转型已经成功，但它是一个缓慢的过程。对于可预见的未来，匹克计划管理使用的容器和微服务和其他系统，如某些数据库和其他传统平台构建的应用程序组合，这将需要更长的时间来过渡。“现在PDP已经成功，我们正在建设的一切出去微服务，”他说。“但是，这需要时间。”
考虑哪些应用程序的功能将被分解成组成部分是非常重要的。艾哈迈尔阿巴斯，在咨询DISYS的全球服务副总裁说，这是有帮助的组件相对彼此独立经营的各种微服务。组件需要共享数据或传输数据实际上可以减缓在微服务风格使一个应用程序。
他说:“如果组件之间的通信时间长于组件的实际处理时间，那么您的应用程序将会失去很多效率。”最好是设计系统的组件，这样就不会有一个组件完全依赖于另一个组件来运行。这将有助于提高效率，并允许每个功能独立地伸缩。
Berkholz说，这是原因之一，为什么微服务通常用于构建新应用程序或服务的新组件。“有可能是转换现有的应用程序的成本非常高，”他说。“它可以是一个更容易购买到的好处，当你没有转换成本。”