8.0 KiB
微服务和容器：需要去防范的 5 个“坑”
微服务与容器天生匹配，但是你需要避开一些常见的陷阱。
因为微服务和容器是 天生的“一对”，所以一起来使用它们，似乎也就不会有什么问题。当我们将这对“天作之合”投入到生产系统后，你就会发现，随着你的 IT 基础的提升，等待你的将是大幅上升的成本。是不是这样的？
（让我们等一下，等人们笑声过去）
是的，很遗憾，这并不是你所希望的结果。虽然这两种技术的组合是非常强大的，但是，如果没有很好的规划和适配，它们并不能发挥出强大的性能来。在前面的文章中，我们整理了如果你想 使用它们你应该掌握的知识。但是，那些都是组织在容器中使用微服务时所遇到的常见问题。
事先了解这些可能出现的问题，能够帮你避免这些问题，为你的成功奠定更坚实的基础。
微服务和容器技术的出现是基于组织的需要、知识、资源等等更多的现实的要求。Mac Browning 说，“他们最常犯的一个 [错误] 是试图一次就想‘搞定’一切”，他是 DigitalOcean 的工程部经理。“而真正需要面对的问题是，你的公司应该采用什么样的容器和微服务。”
[ 努力向你的老板和同事去解释什么是微服务？阅读我们的入门读本如何简单明了地解释微服务。]
Browning 和其他的 IT 专业人员分享了他们遇到的，在组织中使用容器化微服务时的五个陷阱，特别是在他们的生产系统生命周期的早期时候。在你的组织中需要去部署微服务和容器时，了解这些知识，将有助于你去评估微服务和容器化的部署策略。
1、 在部署微服务和容器化上，试图同时从零开始
如果你刚开始从完全的单例应用开始改变，或者如果你的组织在微服务和容器化上还没有足够的知识储备，那么，请记住：微服务和容器化并不是拴在一起、不可分别部署的。这就意味着，你可以发挥你公司内部专家的技术特长，先从部署其中的一个开始。Sungard Availability Services]5 的资深 CTO 架构师 Kevin McGrath 建议，通过首先使用容器化来为你的团队建立知识和技能储备，通过对现有应用或者新应用进行容器化部署，接着再将它们迁移到微服务架构，这样才能最终感受到它们的优势所在。
McGrath 说，“微服务要想运行的很好，需要公司经过多年的反复迭代，这样才能实现快速部署和迁移”，“如果组织不能实现快速迁移，那么支持微服务将很困难。实现快速迁移，容器化可以帮助你，这样就不用担心业务整体停机”。
2、 从一个面向客户的或者关键的业务应用开始
对组织来说，一个相关陷阱恰恰就是从容器、微服务、或者两者同时起步：在尝试征服一片丛林中的雄狮之前，你应该先去征服处于食物链底端的一些小动物，以取得一些实践经验。
在你的学习过程中可以预期会有一些错误出现 —— 你是希望这些错误发生在面向客户的关键业务应用上，还是，仅对 IT 或者其他内部团队可见的低风险应用上？
DigitalOcean 的 Browning 说，“如果整个生态系统都是新的，为了获取一些微服务和容器方面的操作经验，那么，将它们先应用到影响面较低的区域，比如像你的持续集成系统或者内部工具，可能是一个低风险的做法。”你获得这方面的经验以后，当然会将这些技术应用到为客户提供服务的生产系统上。而现实情况是，不论你准备的如何周全，都不可避免会遇到问题，因此，需要提前为可能出现的问题制定应对之策。
3、 在没有合适的团队之前引入了太多的复杂性
由于微服务架构的弹性，它可能会产生复杂的管理需求。
作为 Red Hat 技术的狂热拥护者，Gordon Haff 最近写道，“一个符合 OCI 标准的容器运行时本身管理单个容器是很擅长的，但是，当你开始使用多个容器和容器化应用时，并将它们分解为成百上千个节点后，管理和编配它们将变得极为复杂。最终，你将需要回过头来将容器分组来提供服务 —— 比如，跨容器的网络、安全、测控”。
Haff 提示说，“幸运的是，由于容器是可移植的，并且，与之相关的管理栈也是可移植的”。“这时出现的编配技术，比如像 Kubernetes ，使得这种 IT 需求变得简单化了”（更多内容请查阅 Haff 的文章：容器化为编写应用带来的 5 个优势）。
另外，你需要合适的团队去做这些事情。如果你已经有 DevOps shop，那么，你可能比较适合做这种转换。因为，从一开始你已经聚集了相关技能的人才。
Mike Kavis 说，“随着时间的推移，部署了越来越多的服务，管理起来会变得很不方便”，他是 Cloud Technology Partners 的副总裁兼首席云架构设计师。他说，“在 DevOps 的关键过程中，确保各个领域的专家 —— 开发、测试、安全、运营等等 —— 全部都参与进来，并且在基于容器的微服务中，在构建、部署、运行、安全方面实现协作。”
4、 忽视重要的需求：自动化
除了具有一个合适的团队之外，那些在基于容器化的微服务部署比较成功的组织都倾向于以“实现尽可能多的自动化”来解决固有的复杂性。
Carlos Sanchez 说，“实现分布式架构并不容易，一些常见的挑战，像数据持久性、日志、排错等等，在微服务架构中都会变得很复杂”，他是 CloudBees 的资深软件工程师。根据定义，Sanchez 提到的分布式架构，随着业务的增长，将变成一个巨大无比的繁重的运营任务。“服务和组件的增殖，将使得运营自动化变成一项非常强烈的需求”。Sanchez 警告说。“手动管理将限制服务的规模”。
5、 随着时间的推移，微服务变得越来越臃肿
在一个容器中运行一个服务或者软件组件并不神奇。但是，这样做并不能证明你就一定在使用微服务。Manual Nedbal， ShieldX Networks 的 CTO，他警告说，IT 专业人员要确保，随着时间的推移，微服务仍然是微服务。
Nedbal 说，“随着时间的推移，一些软件组件积累了大量的代码和特性，将它们放在一个容器中将会产生并不需要的微服务，也不会带来相同的优势”，也就是说，“随着组件的变大，工程师需要找到合适的时机将它们再次分解”。
作者：Kevin Casey 译者：qhwdw 校对：wxy