您的位置: 首页  >  文章  >  在Azure上部署微服务项目的经验分享

在Azure上部署微服务项目的经验分享

分类: 文章 • 2022-10-31 09:52:19

在Azure上部署微服务项目的经验分享

摘要

本文讲述了一个动态在线文档SaaS产品（以下简称DynamicPPTService）在前期云平台选型的各种考虑、业务发展后出现的问题，和最终确定使用微服务作为技术解决方案的过程。介绍了系统迁移到Azure Service Fabric平台上进行微服务化的实施过程。最终，技术团队实现了用微服务化架构精细化管理系统的目的。同时也发现，微服务架构并不能让系统“显著瘦身”，因为一些应用无法微服务化，所以采用微服务架构增加了额外的云计算资源。

背景

DynamicPPTService属于一家提供在线动态文档服务的美国科技公司，客户包括PayPal，TIAA，Fidelity等上百家美国知名金融服务机构。用户使用DynamicPPTService来设计符合自己风格样式的PowerPoint模板，连接数据动态生成最终文档。银行、保险行业用户对X产品有强烈的需求，因为他们服务的客户对数据高度敏感，所有他们需要展示与客户密切相关的数据，例如为客户量身定制保险计划或者投资组合等。奥博杰天的中国团队全权负责该产品的网站、SaaS平台、手机app等产品的研发和技术支持工作。DynamicPPTService从2010年开始在Azure云上线以来，X产品业务以每年100%以上的速度快速攀升。经过近7年的高速发展，不断增加的业务需求已经对现有的系统技术架构带来了巨大挑战，系统架构的升级改造势在必行。

挑战

DynamicPPTService服务端托管在Azure的PaaS平台Cloud Service 上，遵循Cloud Service的Web Role 和 Worker Role部署模式。在Azure platform中，Role是一个提供特定服务的应用程序，每一个体都是一台虚拟机，因此每个Role都有完整的虚拟机资源。Web Role在它的虚拟机设定内包含了IIS以及必要的功能，用来处理通过http和https访问的web请求。因此我们把用户工作区(workspace)，资源管理(admin)，动态报表管理(doc center, library)等提供web页面访问的模块都放到Web Role。Worker Role适合用来挂载无使用者界面、以服务为主的应用程。我们把报表的处理(construction)，文档生成 (conversion), 消息发送（livesend, notification）等需要消耗时间的后台应用放置到Worker Role。系统使用Azure的SQL服务存放用户上传的数据， 用Blob Storage存放用户生成的模板和上传的图片资源，用Table Storage存放一些系统配置和操作日志。还使用到In Role Cache作为数据缓存。
在Azure上部署微服务项目的经验分享

最初决定使用Azure PaaS作为托管平台而没有选择AWS或其它厂商，主要处于四点考虑：

  1. Azure在PaaS层的功能要强于其它厂商，界面操作也比较友好。
  2. 生产服务器并不直接部署，而是在新版本的测试完成后与“staging slot”交换，这意味着可以做到零停机时间。
  3. 微软的Silverlight来搭建系统界面, 能方便地支持多终端展示（从项目实际效果来看这一点的优势并不特别明显）。
  4. 我们认为使用Visual Studio + WCF框架编程能带来比Java更高的开发效率， Java工程师掌握C#的学习曲线也不太大。

注：在Azure Cloud Service中，提供了两个deployment slot，生产(production)和分期(staging)。在大多数应用环境中，我们通常对应一个staging环境(用于上线前测试确认)和一个生产环境。需要注意的是，运行production和staging slot都是收费的。参考：https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-staged-publishing。

这几年随着DynamicPPTService业务的发展， 服务端增加了更多的功能。 日益增大的用户访问量，也给旧系统带来了很大的挑战。 比较突出的几个问题是：

  • 系统耦合度高，不利于协同工作。
  • 由于功能变多，有前后台多个团队在共同维护代码，系统上线频繁。虽然也使用Git作为代码库，每次上线还是需要花大量的时间解决代码冲突，达不到敏捷开发的效果。
  • 资源使用效率不高。例如Web Role中一些不频率使用的应用由于都打包在同一个Role中，被重复部署到多台虚机上。
  • 使用的In Role Cache服务微软已经不再维护，需要替换。

方案

针对这些暴露出来的问题， 我们开始着手设计DynamicPPTService的新架构。技术上要达到的目标：
1. 提高资源利用率。
2. 降低系统耦合度，满足架构不断添加的新功能和模块。
3. 最大化使用Azure提供的云计算特性， 尽量减少人工维护工作。
4. 用Azure Redis Cache替换已经不支持的In Role Cache服务。
5. 新增数据分析分析服务，它负责提供搜索和推荐功能。

我们认为使用微服务的框架能很好的解决系统耦合的问题。如果使用了微服务架构，就可以按需对个别服务实例数量进行增减，通过优化资源配置来提升系统整体性能。

经过讨论，我们可选的方案有三个：

方案一

将原系统拆分成多个独立的service，延用之前Azure Cloud Service的role部署模式，每个service部署在一个Web Role或者Worker Role中。 这样带来的问题是每个service就要占用一个虚拟机。如果考虑高可用性，每个service至少要有2个以上实例，那整个集群使用的虚机数量还要翻倍。虽然单机使用的资源会比原来低，但是不足以抵消购买更多虚机所花的费用。

方案二

将原系统拆分成多个单独的service，使用Azure推出不久的Service Fabric集群管理框架来适应微服务架构。 Service Fabric类似于AWS的BeanStalk，我们只需管理好自己的应用代码，其它的资源需求都可以交给Service Fabric去管理。它吸引我们的特性是：

  • 微服务集群管理。提供集成界面对服务进行管理和监控，方便精细化控制系统服务。
  • 高的密度的微服务部署方式。单个节点（虚机）可以托管多个服务。

但是如果使用Service Fabric也会带来两个问题：
1. 它不自带IIS支持。Web Role中的应用要切换到Service Fabric要么能自带HTTP服务，要么使用ASP.NET Core MVC框架。这样做会牵涉到很多代码改动，工作内容涉及多个开发和测试团队。
注：ASP.NET Core MVC默认使用Kestrel 作为HTTP服务器。（参考：https://docs.microsoft.com/en-us/aspnet/core/migration/mvc ）
2. Service Fabric中每个服务都必须独占虚机的端口。由于多数web服务都使用了80和443端口，这就造成了不同的服务只能部署到不同的虚机上，不能利用到Service Fabric单个节点可以托管多个服务这一优势。虽然Azure建议可以使用反向网络代理来解决这个问题，但是打开反向代理会把它后面所有end point的http端口暴露，会有安全隐患。

所以从我们掌握的知识来判断，用Service Fabric来替代Web Role管理前端服务，技术上优势并不明显。

注: 关于Azure反向代理的内容，参考：https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reverseproxy

方案三

考虑到方案二的限制，将Worker Role中的construction, live send和notification后台服务迁移到Service Fabric上。新增的数据分析服务也部署在Service Fabric上。原Web Role中的服务进一步拆分成web响应服务和后台API服务，将后台API服务部署到Service Fabric上，前端Web响应服务迁移到能更好支持IIS的Azure App Service。这样的好处是：

  • Worker Role中的服务迁移改动小（只需要在调用启动服务的接口代码处进行稍微修改）。
  • Web Role 中的应用迁移到App Service也基本不用改动。
  • Web Role中由于消耗资源的服务被迁移到Service Fabric，剩下的 web响应服务需要的云计算资源会减少。

方案三的系统架构如下图
在Azure上部署微服务项目的经验分享

实现

为了稳妥起见，我们决定采用方案三，分两步来吃螃蟹。第一步把Worker Role中的服务进行迁移。等上线正常后再进行第二步Web Role中服务的迁移。
第一步的重点在于需要将Worker Role中服务的代码进行改写。 由于Worker Role中代码框架结构和Service Fabric中代码结构基本类似
在Azure上部署微服务项目的经验分享

只是服务启动接入点方法从原来的RoleEngryPoint 中的Run()方法改变为StatelessService 中的RunAsync()
在Azure上部署微服务项目的经验分享

经过6个月的重新部署，我们完成了DynamicPPTService微服务版本在Service Fabric上部署并顺利上线。 新版本上线后，通过Service Fabric的控制台我们能很好的管理系统的每个微服务，达到了设计预期。不过实际减掉的云计算资源并没有预想的多。旧架构使用了4台8core 56G 内存 服务器(Azure 型号 D13) 运行Web Role应用， 6台2core, 8G内存 服务器(Azure型号D2) 运行Worker Role应用，6台D2服务器运行conversion模块需要的windows office组件。使用微服务架构后，除去App Service 按使用量计费，Service Fabric集群使用了5台D13服务器。Conversion模块需要调用office的资源必须运行在window的虚机上无法微服务化， 6台D2服务器保留。 所以，如果把省掉的6台原Worker Role服务器和新增租用App Service所用的资源抵消，迁移到新架构后，还多使用了3台D13服务器。

我们最终的架构如下：
在Azure上部署微服务项目的经验分享

总结

在DynamicPPTService架构升级的这个项目中。我们运用了微服务的架构设计原则，结合Azure的技术特性，很好的完成了架构扩展，解决了业务发展带来的技术挑战。技术团队很好的判断了Azure Service Fabric还有不完美的地方 (例如不支持IIS、每个node节点部署的service都会占用一个独立端口) ，在架构设计时合理的避开这些技术劣势，充分发挥了Service Fabric擅长高密集度、精细化管理服务的优势。在实际部署中，因为有些应用不能微服务化，需要给它们保留资源，所以使用微服务架构并不能明显降低原系统所占用的资源。

协议声明: 本文已由原作者授权InfoQ中文站转载

相关推荐