【转】Azure应用部署方式对比

骑猪看日落 2023-01-09 06:34 158阅读 0赞

如图

![SouthEast][]

azure环境应用托管方式对比  
  
1. app service + serverless  
azure的app service支持几乎所有语言开发的web app，既可以手动使用publish profile部署，也可以使用vsts创建一个（CDCI）持续集成。都非常方便。  
而azure的function app可以用于创建定时执行的脚本，比如web hook，也可以把windows service逻辑搬到云环境，无需IDE。  
  
  
优势：  
pay as you go。使用才付钱，做POC（演示）的首选。比如是开发环境或测试环境，或者只是演示给客户看。这种方式比较高效。  
不要求容器化部署，数据可以放在云端的应用（如果数据落地，可考虑混合云），都可以考虑使用。  
  
  
缺陷：  
容器化部署的话需要使用azure container service。  
  
  
2. vm scale sets  
azure 的IAAS（infrastructure as a service)基础架构即服务。就是创建一组虚拟机，自己管理维护。  
优点：可以通过配置达到自动伸缩，可以自己管理虚拟机上的一切，比如子网。  
缺点：  
网络安全隐患，比如没有及时装安全漏洞的补丁。  
成本很高。  
  
  
3. azure 容器服务 （Azure container service)  
适用场景：  
azure container service更像是IAAS（infrastructure as a service)基础架构即服务的层面。如果希望在云环境自己管理维护docker容器可以考虑这种方案。  
  
  
优点：  
可以在云环境托管自己的docker镜像。  
兼得docker镜像和云托管的好处。  
  
缺点：  
需要自己管理一切配置。如端口号需要映射从host到container，并要在最外部防火墙那里管理inbound outbound的规则。  
docker中的容器通信，资源共享，可能需要借助storage account来解决，但有额外开销  
  
4. 将docker部署在本地  
优势：  
可使用swarm或kubernate动态伸缩  
节约托管成本，最大化利用硬件资源，单机就能托管多容器从而达到高可用  
一次创建image可重复使用  
  
  
弊端：  
容器的创建完全动态并由swarm管理，应用的状态数据需要在存在容器外部  
容器最好完全隔离。如果真需要通信，container之间通信需要创建bridge，跨节点通信需要创建overlay  
容器的引入需要为持续集成环境配置额外的步骤，增加了devops的成本  
container之间的共享资源需要额外处理  
  
适用场景：  
一定要本地部署并且要求docker。客户坚持需要把应用部署在本地，完全不用云。除了使用传统的多VM+负载均衡以外，可以使用docker。  
  
  
结论。首选PAAS，就是azure app service + function app；如果需要容器化考虑azure container service（ACS）；如果在本地部署，建议容器化；如果要传统的多vm+负载均衡也没问题，与docker比，只是硬件不能充分利用而已；不建议在azure上跑虚拟机 sets，开销太大还要自己维护。

[SouthEast]: /images/20221119/8cdefe5b4f564afb940405145d88afeb.png