【Dubbo】微服务架构(三): 部署

工作中使用了微服务架构，接下来的一段时间里，我会写一系列的文章来介绍微服务架构，同时我也会在github上写一个microservices的应用框架（地址会在后续文章给出）。(该文章来自于http://blog.csdn.net/u012422829/article/details/68952361)

这篇文章主要讲述了部署一个微服务架构的应用有哪些可选方案。

翻译和整理自：

• http://microservices.io/patterns/deployment/single-service-per-host.html
  
• http://microservices.io/patterns/deployment/multiple-services-per-host.html
  
• http://microservices.io/patterns/deployment/service-per-vm.html
  
• http://microservices.io/patterns/deployment/service-per-container.html
  
• http://microservices.io/patterns/deployment/service-deployment-platform.html
  
• http://microservices.io/patterns/deployment/serverless-deployment.html

一、单主机单服务

在一台主机上部署一个服务。

这种方法的优点包括：

• service实例互相分离
• 没有资源请求冲突或者依赖版本冲突的风险
• 一个service实例只能消耗最多一台主机的资源
• 很容易监控、管理、重新部署

缺点：

• 资源利用率可能不如单主机多服务高

二、单主机多个服务

在一台主机（物理机或者虚拟机）上运行多个不同服务的实例。

有几种不同的方法来把一个服务部署在一台共享的主机上，包括：

• 把每个service实例部署成JVM实例。
• 把多个service实例部署在同一个JVM里。

这种模式的优点：

• 比单主机单服务有更好的资源利用

这种模式的缺点：

• 有资源需求冲突的风险
• 有依赖版本冲突的风险
• 难以限制一个service实例的资源使用
• 难以监控每个服务的资源使用情况

三、单虚拟机单服务

把服务打包成一个虚拟机的Image，然后部署在一个单独的VM上。

这种模式的优点：

• 可以直接通过提高虚拟机个数的方式来做scale，Amazon Autoscaling Groups（译者注： 不了解的可以去看看AWS的一些基础知识）甚至可以根据负载做自动化的调节
• VM包含了构建这个service的所有技术细节，所有的service都用同样的方法来开始和停止
• 每个service实例是分离的
• VM会限制一个service实例所消耗的CPU和内存资源
• 例如AWS这样的IaaS解决方案提供了一个成熟的、有很多特性的基础设置来部署和管理虚拟机，比如说，Elastic Load Balancer、Autoscaling Groups

这种模式的缺点：

• 构建一个VM的Image比较花时间

四、每个容器一个Service

（译者注：不了解容器的，可以去看看我之前的Docker系列文章:  http://blog.csdn.net/u012422829/article/details/54930799。 我工作的项目中也是这样部署的。）

把service打包成（Docker）容器的Image， 然后把service实例部署成一个容器。现在有几个Docker集群管理的解决方案， 包括 Kubernetes（k8s）、 Marathon/Mesos、 Amazon EC2 Container Service（ECS）。

这种模式的优点：

• 可以直接通过改变容器实例的方式来做scale
• 容器包含了构建这个service的所有技术细节，所有的service都用同样的方法来开始和停止
• 每个service实例是分离的
• 容器会限制一个service实例所消耗的CPU和内存资源
• Container构建和启动很快。

这种模式的缺点：

• 部署容器的基础设置不如部署VM的基础设置丰富。

五、Serverless架构的方式

使用一个隐藏了任务服务器的概念的部署的基础设施。这个基础设施拿到你的service的代码，然后运行。为了使用这种方式部署，你需要打包你的代码，把它上传到基础设施，然后描述你想要的性能指标。

这个部署的基础设施由公有云提供商来操作。它一般使用容器或者虚拟机的方式来分离服务，但是这些细节你并不需要知道。你不需要负责管理操作系统等等。现在有一些不同的serverless部署的环境： AWS Lambda、Google Cloud Functions、 Azure Functions， 他们提供了类似的功能，但是AWS有最丰富的功能。

一个AWS Lambda function是一个无状态的组件，它被调用去处理事件。 要创建一个AWS Lambda function， 你需要把你的代码打包成一个ZIP文件，然后上传到AWS Lambda。你同时还要指定这个处理事件的function的名字以及它的资源使用限制。

当事件产生的时候，AWS Lambda找到你的function的空闲实例，然后调用处理的function。 

有四种方法来调用一个Lambda function。

一种选择是你配置你的Lambda function，使它对别的AWS service（比如S3, DynamoDB）所产生的事件（比如S3 bucket上创建了一个新的object、DynamoDB上有条数据被删除等等）进行响应。

另一种方法是配置AWS Lambda Gateway，把HTTP 请求路由到lambda function上。 AWS Gateway把一个HTTP请求转化成一个事件对象， 然后调用lambda function，然后根据lambda function的返回值生成HTTP响应。

你也可以通过AWS Lambda Web Service API明确调用Lambda function。你调用Lambda function的应用提供一个JSON对象，传给Lambda function， web service会把结果返回给你。

第四种方法是使用CRON的方式周期性调用。比如说，你可以告诉AWS每5分钟调用一次你的Lambda function。

这种模式的优点：

• 不需要关心底层架构，只要关注代码
• 非常有弹性，根据负载自动scale
• 只要为请求数付钱， 便宜

这种模式的缺点：

• 这种架构比VM或者容器有更多的限制。比如说，AWS只支持很少几种语言，只适用于部署响应请求的无状态应用，你不能部署一个长期运行的有状态的应用如数据库、消息代理
• 输入源有限制。比如说AWS Lambda不能订阅一个像RabbitMQ那样的消息代理
• 应用必须快速启动。Serverless 架构不适用于花很多时间启动的service
• 高延迟的风险。基础设施在为你的function启动一个instance、function 初始化的时间可能比较长。当突发的、大量请求进来的时候，一开始会比较缓慢。