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