作为一种新型软件设计模式，微服务架构能够将大型应用程序拆分为多种松散耦合的不同组件。为了加快部署速度，提高可扩展性以及制定更为灵活的开发流程，Nike和Netflix等公司已经开始采用这种设计模式。但是在保证微服务基础架构平稳运行方面，运维团队还面临着诸多管理方面的挑战，比如从服务发现到自动化发布。

“我们想要对现有软件的可扩展性进行优化，避免在开发早期，基础架构规模设计过于庞大，”API监控服务公司Runscope CEO John Sheehan表示。

这家公司最初只提供一些按照功能划分的关键服务，比如管理用户身份以及存储测试数据等来实现一些底层的重复功能。而现在Runscope已经拥有50多种不同规模的内部服务，在2014年当中平均每天要部署超过30种服务。

“如果某项服务需要使用更多的资源，我们将会对其进行单独扩展，而不必为整个集群分配更多的资源，” Sheehan说，“这种相互分离的方式还能够加快我们的服务部署速度。”

为了保证这种方式的最终成功，Runscope在自动化、部署和管理工具方面进行了大量投资，并且为应用开发人员准备了能够不断构建和使用服务的库和框架。如果没有这些投资，那么管理这些服务的所产生的系统开销可能已经超过了其所带来的收益。

“如果你愿意在基础架构方面进行投资，那么规模较小、可重复使用的微服务所带来的种种好处将会显著提高ROI，” Sheehan说。

运维团队面临的全新挑战

任何一种新技术都是一把双刃剑。微服务架构引入了网络层隔离的概念，这将会引发大量全新问题，比如延迟时间以及网络不可用等等。运维团队不仅需要理解指定服务的运行原理，还要理解哪些服务和关联可能影响应用程序的性能表现，这也就是为什么API监控和测试变得如此关键的原因。

所有这些微小部分决定了应用程序的性能体验。

“如果你不了解这些组成部分之间的相互作用如何影响性能表现，那么就不能发现那些可以帮助提升应用程序稳定性的运行数据，” Sheehan说。由于网络当中出现了一些其他的变化因素，因此必须关注一些之前从未出现的问题。

监控和测试这些组件对于解决问题来说是十分重要的。

微服务架构允许每种服务运行在自己的技术栈当中，因此运维团队必须了解如何操作和维护适用于不同服务的技术栈。 

重新设计发布流程

微服务架构将单一的应用程序拆分为独立的微服务单元，将软件开发工作分配给多个松耦合团队。

“使用微服务架构的团队必须扩展软件发布管理流程，以解决服务依赖性、网络分发以及自主发布时间计划等问题，”SOA中间件提供商WSO2平台架构师Chris Haddad表示。

终端用户应用程序通常会使用多种微服务，比如产品分类、用户配置文件和分组等。此外，微服务之间也可能存在关联性。在多个团队和分布式网络拓扑当中分发微服务为企业带来了新的应用发布挑战。

“成功的团队将会在其软件发布流程当中引入服务版本控制、发布测试、增量升级以及发布回滚等功能，” Haddad说。

运维团队应该建立实现增量升级的相关流程。这种类型的更新意味着在上一个版本的基础上部署一个新的微服务版本，之后逐渐将流量引入到新版本当中。

增量升级将用户的影响范围拆分为多个部分，允许技术团队在真实的生产环境当中进行“冒烟测试”。基于A/B测试分析，如果某种刚刚部署的微服务出现问题或者用户体验十分糟糕，那么技术团队应该安全地将其回滚到之前的微服务版本。开发团队应该在发布管理流程当中加入安全和清晰的回滚功能。  

为动态网络供应做准备

微服务架构允许企业使用多种微型服务组成一个独立的应用程序。尽管在很多大型企业当中，比如Netflix和Nike，这种方式已经非常流行，但还是应该认真考虑微服务架构对于底层网络和基础架构将会造成哪些影响。

微服务能够改变虚拟网络的速度和结构，并且对底层服务产生影响。运维团队和开发人员必须思考如何将网络服务改造为以应用程序为中心——比如实现负载均衡、缓存、性能表现、监控和应用安全等功能，而不是以下这些功能——比如防御DDos攻击、VPN以及其他，应用程序基础架构提供商F5 Networks的首先技术架构师Lori MacVittie表示。

那些以应用程序为中心的服务都会和应用程序产生关联，因此会产生一种和应用程序紧密相关的服务模型。本质上，每种微服务都可以由一套与之关联的应用程序服务组成。在软件发布过程当中，企业需要提供和配置大量应用程序及其相关服务。

“随着运维和开发团队之间的协作不断加强，现在已经能够确保微服务以及其他相关服务顺利发布了，” MacVittie说。

在云中使用微服务架构还存在一些潜在问题。比如应用程序出现问题时，大多数应用程序提供商并不会主动向客户提供其网络基础架构详细信息，MacVittie说。

如果依靠内部团队维护基础架构，企业还需要考虑安全问题。安全服务强制阻止的恶意请求不会对应用程序产生太大压力，反而是安全服务可能影响应用程序的性能表现。这可能是最容易被人忽略的影响应用程序性能表现的因素，但是可以通过使用恰当的安全服务进行修复。 

实现服务发现

松耦合是微服务架构的关键准则。各个组件需要使用单独的基础架构寻找需要通信的服务IP地址。服务发现层必须和云环境——也就是虚拟机被创建和销毁的地方——当中的基础架构一样是动态的。

“你可以将服务发现工具理解为基础架构的连接纽带，”数据中心管理工具提供商HashiCorp的客户服务总监Kevin Fishner表示。

Consul、etcd和Zookeeper都是不错的服务发现工具。为了帮助配置动态服务，还可以使用一些自动化工具，比如Puppet、Chef、Ansible和Salt等。

Fishner说，企业还应该考虑和基架构相关的创建和管理工具，比如Terraform、CloudFormation和Heat。随着Docker这种容器工具的逐渐流行，企业需要使用新的调度机制，从Mesos到Kubernetes，都是顶级的基础架构管理工具。 

成功计划

迁移到微服务架构并不是一个十分容易的过程，因此开发人员和运维团队需要相互配合才能取得最后的成功。

“尽管微服务架构的理论基础就是在遵守合同的前提下，让每个拥有服务的团队都能够独立部署服务，但是这种情况却很少发生，” Codenvy CEO Tyler Jewell表示，他所管理的是一家使用微服务构建云集成开发平台的公司。

Codenvy用户和应用程序进行交互，而这些应用程序是依赖于多种微服务的独立系统。Codenvy向用户发布的新功能都会依赖于多种微服务，其中许多还需要扩展新特性。因此需要保证所有相关组件——也就是应用程序和微服务——必须同时完成部署。

“因此，我们必须在计划和发布协调方面进行改进。对于任何阶段的部署来说，这都不是一个十分容易的过程，” Jewell说。

本来选自《IT新架构》七月刊：超融合影响力。