【IT168 评论】11月注定是一个不平凡的月份，从11月11日的双十一到11月25日的黑色星期五再到11月28日的网络星期一，购物者在迎来shopping黄金时代的同时，零售商也进入到了一年中最为繁忙的阶段。面对如此汹涌的购物人潮，你的服务架构还禁得住考验吗?

　　对于购物狂来说，Hudson's Bay Company (HBC)这个名字应该不陌生吧，HBC旗下有Lord&Taylor、Saks 5th Avenue 等品牌，去年黑色星期五他们尝试了一种新的服务架构，并且收效还不错，下面小编就为大家介绍一下，希望能对今年双十一的商家有所帮助。

　　HBC目前部署的是Oracle WebLogic server和 RedPrairie的Blue Martini电商平台，HBC基础设施团队Matthew Pick表示这个堆栈已经被开发改进多年，所以升级改造的难度非常大。但是面对日益增多的业务，HBC不得不做出转型，HBC团队尝试了很多种方法，结果发现容器和微服务的效果不错。

　　Pick团队选择产品详细页面(PDP)作为他们升级改造的第一个尝试项目， PDP是一个电子商务应用程序，它包含产品描述和图像。 HBC开发人员将PDP分为12个独立的微服务，每个微服务都嵌入在应用程序容器中。

　　当PDP切换到基于微服务的设计时，微服务的一些优势就显现出来了：升级之后开发和推送变得更容易，故障的排除问题也更加简化，例如如果产品价格下降，那么一个负责团队就可以解决。容器和微服务支持移动观看和响应式设计，拥抱它们也为HBC的战略部署打开了新的突破口。

　　去年黑色星期五期间，HBC对新PDP服务做了测试，当时他们将一部分的流量发送到PDP微服务进行处理。但是为了确保万无一失，HBC也做了一些应对措施，一旦PDP微服务出现问题，那么它将立刻关闭，所有流量将被以传统方式来处理。Pick回忆起去年黑色星期五和网络星期一期间PDP微服务的表现时表示：有时候在遇到新技术还是应该去试一试的。

　　HBC基于微服务架构应用程序的尝试得到了越来越多企业的认可，近两年由于应用程序开发人员希望更快地编写和部署新代码，更轻松地管理复杂应用程序，所以微服务得到了快速的发展，已经慢慢成为了一种流行趋势。但是，微服务也和其他新技术一样面临着一些挑战。

　　什么是微服务

　　关于微服务定义的说法有很多，但是至今都没有一个通用的结论。IDC分析师Al Hilwa将微服务描述为微服务是更精细化的软件架构，其中应用程序的组件是独立设计和发展的。微服务是用一组小服务的方式来构建一个应用，服务独立运行在不同的进程中，服务之间通过轻量的通讯机制(如RESTful接口)来交互，并且服务可以通过自动化部署方式独立部署。正因为微服务架构中，服务之间是相互独立的，所以不同的服务可以使用不同的语言来开发，或者根据业务的需求使用不同类型的数据库。

　　Cloud Technology Partners 高级副总裁David Linthicum表示：企业对微服务的兴趣点在于他们想要寻找下一代面向服务的架构，容器会是微服务的驱动力。

　　提到微服务，很多人都会自然的想到SOA，两者虽然相似但其实两者是有区别的，大多数专家都认为SOA通常更局限于传统基础设施组件、单一的编程语言和开发环境。而微服务可以使用不同的语言来编写，使用标准化的API进行相互之间的通信，并且可以托管在下一代基础设施上，例如在虚拟化或公有云环境中部署容器。网友何明璐认为一句话来谈SOA和微服务的区别，即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。

　　微服务的优势

　　敏捷性：利用应用程序的去耦组件，每个单独的部分可以独立开发。GitLab的首席执行官Sid Sijbrandij表示：有了微服务架构，你不再需要把整个开发团队都押上去。假设你有一个100人的团队，之前可能100个人都需要在一个应用程序上工作，而现在可以分为10个10个人的小团队，每个团队分别开发应用程序的组件，并随时准备部署新功能，而且新功能一旦准备就绪就可以立即启动，不再需要等待整个应用启动。

　　降级：微服务架构中如果应用程序的一个组件失败，它不会关闭整个应用程序。451 Research分析师Donnie Berkholz表示我们的目标是最大限度地减少故障带来的影响。举个例子，如果银行网站是使用微服务方法构建的，就算资金转移功能损坏了，客户仍然能够检查其余额。所以，当服务被独立构建和部署时，理论上一个服务出现问题是不会影响到其他服务的。

　　减少开发团队之间的同步：在微服务架构中，每个开发团队都是独立的，所有组件都通过通用API集成在一起，每个开发团队只需专注自己的部分就可以啦。

　　微服务的挑战

　　微服务架构的转型是由一定局限性的，451 Research分析师Berkholz表示，拥有敏捷或开发运维心态的团队构建微服务应用程序的成功性更高。在这些环境中，代码被快速编写、测试和部署，许多开发商店已经采用了自动化的服务基础设施。451 Research表明，三分之二的企业采用了敏捷开发方法，40%的企业采用了Devops。 Berkholz表示这是最有可能通过微服务成功的企业，尚未采用这些方法的企业在向微服务过渡的时候会遭遇更多困难。

　　Pick认为容器和微服务是共生的。 当将整体应用程序被分解为组件时，容器中允许应用程序开发人员和基础架构操作团队在同一页面上运行这些服务， 开发人员把应用程序打包在容器中，而操作团队准备基础结构来运行容器。

　　微服务还受其他基础设施的影响。 Forrester分析师Dave Bartoletti表示当企业的开发人员开始接受这些趋势时，IT基础设施的作用就会发生变化。目前，有大量的工具支持微服务架构，如利用VMware和OpenStack的私有云软件建立内部云，如果不想自己构建基础设施，则可以使用来自Amazon，Microsoft，Google和其他公司的公共云平台。来自Cloud Foundry或Red Hat的PaaS平台可用于自动化基础架构控制。所谓的“无服务器”计算平台是事件驱动应用程序的理想选择，例如物联网用例中的应用程序。 从根本上来看，随着每个平台变化，IT的角色从供应基础设施转向将微服务部署到自己的环境中的开发人员。

　　微服务的适用场景

　　并不是所有应用程序都适合微服务架构。 Berkholz认为适合使用微服务架构的应用程序首先必须要足够复杂，可以分解成许多不同的组件， 如果它是一个简单的应用程序，做一个单一的功能，那么就可能不需要微服务。

　　对于Pick和HBC来说，他们已经向微服务过渡迈出了成功的一步，但想要取得最后的胜利会是一个缓慢的过程。 Pick表示在可预见的未来，他们计划将容器和微服务以及其他系统构建的应用程序组合在一起。

　　微服务中最重要的是分辨出应用程序中的哪些功能可以分解。DISYS副总裁Ahmar Abbas表示，功能分解会影响到微服务各组件之间是否可以独立运行，需要共享数据或传输数据的组件可能会减弱微服务风格。如果组件间的通信时间长于组件的实际处理时间，那么应用程序将失去效率，系统中最好的组件设计是每个组件都不依赖于另一个组件运行，每个功能能够独立的增加和删减。