本文将介绍四种受欢迎的微服务部署策略,以帮助企业获得更高的敏捷性、灵活性、以及可扩展性 。
作者:陈峻编译来源:51CTO
在过去的几年中,由于微服务架构(Microservices architecture)能够提供高级别的软件可扩展性,因此十分流行 。尽管大多数组织都能够接受这种架构模式,但是他们也或多或少地遇到了,诸如如何将应用程序分解成为基于微服务的模式等多方面的挑战 。
过去,我们曾经帮助美国最大的电信公司等客户,成功地实现了基于REST的微服务应用部署 。我们在降低运营成本的同时,提高了整体服务的可用性 。下面,我们将分享四种受欢迎的微服务部署策略,并在此基础上和您讨论:企业应该如何利用微服务来获得更高的敏捷性、灵活性、以及可扩展性 。
微服务部署的挑战
通常,部署单体(monolithic)应用意味着您需要配置多台物理服务器或虚拟机,并在每台服务器上运行某个大型应用程序的多个实例 。这样的部署方式虽然简单直接,但是对于微服务应用却并不一定适合 。
首先,在部署微服务应用之前,您必须熟悉编写此类服务所涉及到的各种框架和语言 。由于每一项服务都可能涉及到其特定的部署,不同的资源要求,以及扩展和监控方面的需求,因此这往往是最大的挑战之一 。其次,就企业的角度而言,他们希望部署服务的过程尽量实现快速、可靠、且具有一定的成本效益 。可见,我们需要通过灵活、可扩展的多种微服务部署模式,来应对广泛的组件集成请求 。
微服务的部署策略
1.基于主机(物理机或虚机)的多服务实例
“基于主机的多服务实例”模式是最为传统的应用程序部署方法 。在该模式下,软件开发人员可以提供单个或多个物理机或虚机,同时在每个主机上运行多个服务实例 。此模式有几种不同的实现形式,其中包括:将每一个服务实例都作为一个单独的进程,或是在同一进程中运行多个服务实例 。
文章插图
优点
由于多个服务实例使用的是同一服务器、及其操作系统,因此它们的资源使用效率相对较高 。
由于您只需要将服务复制到主机上,即可运行之,因此服务实例的部署也相对较快 。例如:如果某个服务是由JAVA编写的,那么您只需要复制JAR或WAR文件;而如果它是用Node.js或Ruby编写的,则复制源代码便可 。
如果某个服务本身带有进程,您可以直接启动之;当然也可以将其动态地部署到某个容器中 。而如果该服务属于某个容器进程(或进程组),而且正运行在多个实例里,那么您可以直接对它进行重启 。
挑战
除非每个实例都是一个单独的进程,否则您对服务实例的实际控制权并不大 。而且,您无法限制每个实例能够使用到的资源比例 。这将带来主机内存被大量消耗的隐患 。
如果多个服务实例在同一进程中运行,它们之间会缺乏隔离关系 。这通常会导致在相同进程中,某个行为异常的服务能够直接影响、甚至中断其他的服务 。
由于运营团队需要了解服务的详细信息,因此在部署期间,他们可能发生人为错误的风险较高 。显然,开发和运营团队之间需要通过必要的信息交换,来尽可能地消除复杂性 。
2.基于主机(物理机或虚机)的服务实例
此类微服务的部署方法能够让您在对应的主机上单独地运行每一个实例 。此处的实例包括:基于单个虚拟机的服务实例,和基于单个容器的服务实例 。
基于单个虚拟机的服务实例模式,能够让您将每个服务打包成为诸如Amazon EC2 AMI的虚拟机(VM)镜像 。此处的实例就是指那些通过既有镜像运行起来的VM 。目前,使用该模式的一个典型应用便是Netflix的视频流服务 。为了构建自己的VM,您可以配置诸如Jenkins之类的连续集成服务器,当然也可以直接使用packer.io 。
文章插图
优点
基于虚拟机的服务实例有着一项显著的优点:由于是独立运行,它的内存使用数量是受限的,并且无法从其他服务中窃取额外的资源 。
您可以利用诸如AWS之类成熟的云基础架构,来实现负载平衡和自动扩展 。
由于一旦服务被打包成为了VM,那么在某种程度上说,该服务就会变成黑匣子,也就是实现了对于服务的封装,因此部署的整个过程会变得更加简单和可靠 。
推荐阅读
- 对于PHP开发常见的问题总结
- 在 Linux 中使用 Bash 脚本删除早于“X”天的文件/文件夹
- 网站被黑或K权重恢复的操作方法
- 解决了redis的这些问题,你就是redis高手
- 如何成为一个成功的 Java 开发人员?
- 了解百度的高级搜索让你需要的数据呈现在你的面前
- 分布式基础之CAP
- 奶在温奶器里最长放多长时间 温奶器里的奶最多保存几小时
- 洗衣液还是皂液好 皂液和洗衣液哪个洗的干净
- 雪糕模具是硅胶的好还是Pp的好 雪糕模具硅胶好还是塑料好