黑色星期五“网购星期一”是购物者的最爱，也是许多零售商一年中最忙的时候。哈德逊湾公司(HBC)拥有并经营Lord & Taylor, Saks 5th像Avenue和其他几个品牌一样，去年的假日购物潮成了尝试新网站功能的最佳时机。
HBC使用一个相当典型的Oracle WebLogic应用服务器和一个名为蓝色马提尼从RedPrairie公司的电子商务平台。基本上栈已开发和完善了多年。它的工作，但它是“难以部署，难以改变，并...很难升级，说：”马修匹克，谁在HBC管理的基础设施工程团队，并谈到了该公司的数字化改造在一次会议在今年早些时候召开了由云供应商Joyent公司。
因此，HBC工程师开始探讨他们如何解决这些问题。微服务和容器竟然是答案。
Pick和工程团队选择产品详细信息页面(PDP)作为开始他们的重新平台项目的第一个地方。PDP是电子商务应用程序的一部分，其中包含产品描述和图片。HBC开发人员没有将PDP嵌入到应用程序中，而是将其分成12个独立的微服务，每个微服务都驻留在应用程序容器中(一个加载图像，另一个提供文本，等等)。
挑选看到了许多的优势，切换到基于微服务的设计：升级会更容易开发和推动，以及解决问题会更精简。例如，对于微服务，如果价格报告功能下降，问题是（理论上）包含到一个服务团队负责解决它。拥抱容器和微服务也是一个更广泛的战略，以支持移动浏览和响应式设计的一部分。
当它在去年的黑色星期五/网络星期一发布新的PDP时，HBC做了一个黑暗的发布，这意味着只有一部分公司的流量被发送到PDP微服务。如果新方法有问题，它可以被关闭，所有流量将以传统方式处理。“我们并没有把整个网站都点燃，”匹克说。“在某种程度上，有了新技术，你就不得不说，‘让我们试试吧。’”
Pick和HBC是正在试验基于微服务体系结构的应用程序的越来越多的组织之一。这一趋势在过去两年中得到了极大的发展，因为应用程序开发人员希望更快地编写和部署新代码，更容易地管理复杂的应用程序。但与任何新技术一样，微服务也面临着一系列挑战。
microservices是什么?
专家描述微服务的方式有很多，但没有一个统一的定义。IDC分析师阿尔·希尔瓦(Al Hilwa)将微服务描述为“一种更细粒度的软件架构，其中应用程序组件是独立设计和开发的”。这些组件使用通用的api组装在一起。基本上，应用程序或服务被分解成许多不同的组件，并与api结合在一起。
听起来有点熟？微服务哈肯回到昔日的流行语：面向服务的架构（SOA)，即分别构建应用程序组件的思想。
“在微服务企业的兴趣是寻找下一代的方法来面向服务的架构，以及使用与容器微服务的推动下，”大卫林西克姆，在咨询云技术合作伙伴高级副总裁说。
尽管它们很相似，但大多数专家表示，SOA通常更局限于使用更传统的基础设施组件的单一编程语言和开发环境。微服务代表了一种相对更为敏捷的方法，用于开发由小型独立流程组成的复杂应用程序。组成应用程序的微服务可以用不同的语言编写，使用标准化的api相互通信，并驻留在下一代基础设施上，例如在使用应用程序容器的同时在虚拟化或公共云环境中。
优势
微服务方法提供了一些优势:
——敏捷性:通过解耦应用程序的组件，可以独立地开发每个单独的部分。创业公司GitLab的首席执行官Sid Sijbrandij说:“你不再需要把整个开发团队都锁在同一个步骤里。”GitLab是一个与GitHub竞争的代码库。你可以让10个10人的团队来开发应用程序的组件，并在他们准备好时部署新功能，而不是让100人来开发单个应用程序。而不是计划更新和等待整个应用程序启动，新功能一旦准备就绪就会启动。
-graceful降解：451研究分析师唐尼·伯克霍尔兹(Donnie 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负责全球服务的副总裁阿巴斯(Ahmar Abbas)说，让各种微服务组件相对独立地运行是有帮助的。需要共享数据或传输数据的组件实际上会减慢微服务风格的应用程序的运行速度。
他说:“如果组件之间的通信时间长于组件的实际处理时间，那么您的应用程序将会失去很多效率。”最好是设计系统的组件，这样就不会有一个组件完全依赖于另一个组件来运行。这将有助于提高效率，并允许每个功能独立地伸缩。
Berkholz说，这是原因之一，为什么微服务通常用于构建新应用程序或服务的新组件。“有可能是转换现有的应用程序的成本非常高，”他说。“它可以是一个更容易购买到的好处，当你没有转换成本。”