微服务和容器技术有风险，望君三思而后行

本文讲的是<b>微服务和容器技术有风险，望君三思而后行</b>，【编者的话】微服务和容器技术拥有令人兴奋的潜力，强烈建议客户开始研究这些技术。但是，这并不是说客户应该立即全面采用。上述技术领域的发展太快了，必须清晰地了解这些技术能干什么，不能干什么，才能够决定是否采用这些技术。毕竟，生产环境不是拿来做研发试验的竞技场。

我个人认为微服务和容器拥有令人兴奋的潜力，强烈建议客户开始研究这些技术。但是，这并不是说客户应该立即全面采用。

上述技术领域的发展太快了，必须清晰地了解这些技术能干什么，不能干什么，才能够决定是否采用这些技术。毕竟，生产环境不是拿来做研发试验的竞技场。

1. 业务真的需要

在采用微服务或者容器技术之前，需要搞清楚一个最根本的问题：业务当中是否真的存在一个现有技术或手段无法解决的问题？

微服务和容器是比较新的技术，发展快速，但离成熟阶段还有距离。必须仔细权衡采用上述技术为团队和组织带来的好处和风险。

问问自己：不用任何新技术，能够解决掉现在的问题吗？这个设问有助于你搞清楚一种情况，有人非常渴望使用新技术，但问题的解决实际上并不需要用到这种新技术。如果是这样，应当坚决停止采用新技术。

2. 技术实力够

如果微服务/容器确实能够解决其它方式无法解决的问题，接下来，要确保拥有专家水平的平台工程师资源。

这不光是指用到的大部分API和框架都是全新的。要让基于容器的平台在生产环境运转起来，需要解决一系列后续问题：优化网络，选择存储策略，备份和失效恢复，安全，等等。

3. 愿意“边做边学”

目前，在生产环境中应用微服务和容器技术时，会遇到很多问题，这些问题都没有现成可用的答案。即使工程团队实力足以应对这些挑战，在应用这些技术之后的几年内，需要不停地实验和学习。

例如，最初选择的某些API和框架变化巨大，没有提供向后兼容保证，甚至完全废弃了。有些不适合业务情景或者不成熟的API和框架，需要推倒重来。从运维过程到应用交付模式的最佳实践，都得自己来。

4. 微服务 != 容器

我们与有平台/运维背景的客户，或者那些听过Docker或者其它技术并且想深入了解的客户交流时，发现他们认为微服务和容器是“同一枚硬币的两面”，用了这个技术就必须用另外一个技术。

我同意容器会引导用户交付更小而不是大型一体的应用（虽然，我也看到很多几 GB 大小的容器镜像）。然而，反之并不成立：应用程序采用微服务架构，并不意味着一定要使用容器作为底层的运行时技术。

实际上，如果要把已有的应用程序“微服务化”，而且不能完全重头再来，那么就更有不用容器的理由了。坚持使用已有的运行时平台（在服务器上很容易运行几十个或者几百个微服务进程，无需把这些进程封装为容器），相当于从“改变方程式”中消除了容器这个最大的变量，从而降低项目的风险。

5. 处理微服务之间的依赖

我们经常听到把微服务定义成一个“独立部署的单元”。从实践的角度看，如果设计的微服务不依赖任何其它组件就能成功地运行，这当然很好。但在大多数实际用例中，“没有任何微服务是一个孤岛”：一个服务可以启动，独自响应 API 调用；但在用户真实使用情景中，往往需要几个服务的协调和配合。

例如，订单服务启动后，自己就能告诉用户有多少订单。但用户的操作包括浏览商品目录、选择商品、完成购买和跟踪订单的完成，这需要同时运行一批相互配合的服务。

6. 不光是hello world这样的应用

Docker特别流行的一个主要原因是它的上手体验非常棒。在容器中运行某种语言编写的示例程序（例如Hello World 程序）会有一个非常简单、有成就感的体验。接下来，要对容器做些定制也很容易。

然而，如果要在生产环境中用容器运行真实的应用程序，特别是还想把应用封装为微服务，遇到的挑战完全不同。构建自有PaaS平台就是一个工程上的挑战，除此之外，还有一系列与流程相关的问题需要解决。

总结

在你决定采用微服务和容器技术之前，确保自己已经理解所面临的挑战，明白需要投入的时间和资源……最重要的是要保证：实际业务真的需要应用这些技术，为此付出的努力和承担的风险都是值得的。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

译者介绍

柳泉波，读书踢球喝茶写程序。

原文发布时间为：2015-04-19

本文作者：bnuhero

本文来自云栖社区合作伙伴DockerOne，了解相关信息可以关注DockerOne。

原文标题：微服务和容器技术有风险，望君三思而后行