采用微服务 企业将面临这三个挑战

ZD至顶网 4月19日 国际报道：微服务（Microservices）是目前企业IT领域最热门的话题之一，这一点有充分的证据可以证明。微服务往往会提供一些信息技术和他们具有优势的交易，尤其是能够快速高效地对代码进行一些微小修改和降低风险的能力。另一大优势在于：其服务往往以业务能力为核心，能让自己顺利地持续交付。

微服务表示的是一种建立在小型、可分离进程基础上的软件架构，通过与语言无关的API进行通信。虽然这些服务本身相对易于使用，企业（特别是那些寻求将现有独立应用程序向微服务架构转换的公司）需要认识到，微服务并不会神奇地令复杂性“消失”。

相反，应用程序交付和管理的复杂性将从一个单独、大型的应用程序的问题转化为跟踪及将多种服务的外部关系可视化的一个挑战。处理复杂、单一的应用程序问题将被处理复杂的网络所代替，而这一复杂网络由分布式的、必须协同运行的相对简单的组件构成。

微服务的前景几乎每天都在受到手机和物联网(IoT)的影响，而这恰恰使得改善、加快软件交付的压力增加。为应对这种压力，各企业需要采用全新的交付模型，发布可以处理许多服务及其依赖关系的策略和工具。

大型单一应用往往具有很长的发布周期，而且每个版本均具有许多复杂的功能，虽然这些应用在市场上总会有自己的一席之地，但软件开发环境一直在变化，不断呈现出新的机遇和挑战。

挑战一：如何应对不断变化的部署模式

您的企业如何从这些需要几十甚至上百步来部署其众多元件功能的单一应用模式转换到管理一套更多、更简单组件的模式呢？

虽然工作流工具能够绘制出每一步部署必须要做的工作，但其旨在为一个大型部署将一系列步骤串成一套复杂的部署，所以这些工具不适合这个挑战。它们往往不适合处理众多小型部署、组件之间的依赖关系、或并发版本等任务。

如果你不能轻松地协调多种服务以实现一个端对端用例，尤其是在你需要能够同时运行多种不同服务的兼容版本时，那么提供个人服务或单击即可的容器并没有多大帮助。同样，你需要在选择要部署的服务上具备一定的灵活性，这样一来，一项服务上的测试失败将不会立即叫停你的交付过程，而且也将阻止所有其他在同一交付流程的服务继续运行。

要充分利用微服务架构，你需要对你的部署相关性和配置有一个概述。这允许你为持续的交付流程提供最合适的速度和效率效益。

挑战二：如何处理服务之间的依赖关系

在一个微服务环境中，单项服务间可能存在众多依赖关系。随着整个服务架构变得越来越复杂，组件数量越来越多，IT人员不可能追踪所有的依赖关系并在缺乏自动操作的情况下防止冲突。如果漏过了某一种依赖关系，整个系统将可能在某个很长的微服务调用处失败，而且很难找出原因或追踪问题的来源。

在这种情况下，要为不同的服务协调多个交付流程相当困难。不可避免的是，你最终将得到一个流程网络，它必须是一个能共享信息的无缝生产之路。

当然，在你处理成品时仍会有大量的手工操作任务，因此使用工具能够支持手工操作是非常重要的。然而我们要知道，自动化往往能减少错误、提高效率。

挑战三：如何避免陷入错误的实现技术中无法逃脱

目前，围绕容器技术（Container Technology），特别是应用容器引擎Docker有许多争议。不过，谁知道未来会是什么样呢？你可以采用技术而非容器实现微服务。

致力于一项新技术始终是一场赌博。如果市场发生了变化，或是你所研究技术背后的公司破产了，你将不可避免地被遗弃。不论其底层实现技术如何，确保你的工具和过程能够无缝运行还是有意义的。

随着市场如此之快的发展，在你可以为自己的企业选定一种使适用的解决方案前，保证你的实施方案具备开放性和灵活性将是一种明智之举。

总结

总之，对一个由相互依赖服务构成的复杂网络进行自动化、可视化和整合化改变，是交付微服务应用程序的一个主要挑战。

如果这种复杂性增长到了人们无法管理的地步，企业需要采用部署并发布可以管理的众多组件之间关系的工具。通常而言，这意味着企业需要接受一个旨在处理依赖关系的交付模型。