基于.net的微服务架构下的开发测试环境运维实践_.NET_编程开发_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 编程开发 > .NET > 基于.net的微服务架构下的开发测试环境运维实践

基于.net的微服务架构下的开发测试环境运维实践

 2017/8/2 10:38:55  凌晨三点半  程序员俱乐部  我要评论(0)
  • 摘要:眼下,做互联网应用,最火的架构是微服务,最热的研发管理就是DevOps,没有之一。微服务、DevOps已经被大量应用,它们已经像传说中的那样,可以无所不能。特来电云平台,通过近两年多的实践,发现完全不像大家说的那样简单,大家是报喜不报忧,实在是水太深,谁做谁知道。今天就与大家分享一下在微服务架构+DevOps下,开发测试环境的一些运维痛点问题和解决方法。架构的复杂度直接决定了运维的工作量,架构不是越复杂越好,而是适合最好。下面简单说说几种架构的优缺点。基于.net在搭建应用时
  • 标签:.net net 测试 开发 服务 架构

     眼下,做互联网应用,最火的架构是微服务,最热的研发管理就是DevOps, 没有之一。微服务、DevOps已经被大量应用,它们已经像传说中的那样,可以无所不能。特来电云平台,通过近两年多的实践,发现完全不像大家说的那样简单,大家是报喜不报忧,实在是水太深,谁做谁知道。今天就与大家分享一下在微服务架构+DevOps下,开发测试环境的一些运维痛点问题和解决方法

      架构的复杂度直接决定了运维的工作量,架构不是越复杂越好,而是适合最好。下面简单说说几种架构的优缺点。基于.net在搭建应用时,最常用的方法就是采用Asp.net MVC,前端、后端 All in到一个站点中,省时省力,完全不用关心部署运维的复杂度。但是弊端也非常明显,所有内容部署在一个站点下,如果业务复杂,系统的变化频率非常高,稳定性堪忧,基本无解。再复杂一些的就是前后端分离:H5(或Winform) + WebAPI,此种架构虽然把前后端的变化分开了,但是后端逻辑缺少复用,存在大量公共方法或者重复代码。更复杂的就是:前端+WebAPI+Service,这种模式下虽然抽取了公共服务,但是部署粒度还是很粗,基本上会按照业务范围分多集群部署。同一个集群下,部署的服务如果太多,程序集冲突、服务变更重启集群影响范围大等问题依旧是难解的问题。所以为了隔离变化、降低对其他服务的影响,集群的划分粒度会越来越小,甚至演变到一个服务一个集群,这就是微服务的形态了。这几种架构模式总结起来就是水平、垂直两个维度的变化,水平维度从一类站点变为了多类站点,以解决变化的影响访问、代码复用的问题。垂直维度从所有应用部署在一个站点中,变化到一个服务一个集群,隔离变化带来的影响。架构从一个点演变到两个维度的变化,最终带来的运维成本指数级的增长。下面是特来电云平台微服务架构图,从图中可以看出,整体架构比较复杂。

clip_image002

      为了支持全国的充电业务,特来电云平目前已经有近千台服务器,应用程序100类+,WebAPI接口2000+,服务接口500+,开发测试环境几十个,仅仅生成环境每天热更新就会高达20次+。20多次的热更新,都必须经过单元测试后,部署到与生产环境近乎一致的测试环境中进行接口测试、UI测试,然后再在准生产环境中进行回归测试,最终才能灰度发布到两个数据中心。说到这里,大家很可能会想到通过DevOps来规范环境的同步:CI完成后,通过CD把产品更新部署到多个环境进行测试,然后发布到生产环境。是的,正常情况下,这个流程没问题,但是现实非常残酷。有太多的因素导致测试环境与生产不一致。下面就简单说说:

clip_image004

  1. .net Framework 无法采用Docker,更新包中不仅仅有程序文件的更新、还有配置的更新、SQL的更新。在如此大的规模下,人工更新成本高的离谱,基本上需要专岗来做。而人工做,很容易出错。必须工具化、自动化,补丁更新必须100%通过工具做,不能有人工干预,否则就会在各个环境中出现不一致的情况
  2. 系统几乎每个小时都会发生一次变化,常见的增减应用程序、增减服务、增减WebAPI,这些信息的变化都会影响系统环境。只要一个程序、接口、服务管理不到位,系统就可能会给你颜色看。所有的机器信息、服务信息、配置信息必须集中管理维护,并在各类环境中实现自动同步。CMDB是必备的管理系统。
  3. 在日常的研发中,很多需求会涉及到多个产品研发部门联合开发,集成测试的周期很长,而测试环境的数量有限,经常出现一些紧急需求没有测试环境的尴尬问题。
  4. 测试环境会频繁的执行更新,甚至一个更新会反复多次,极易导致测试环境与生产环境不匹配。从而引起,程序热更新后存在bug,需要紧急回退。
  5. 开发测试环境是对每个开发人员开放的,每个人都会登录系统Debug。你懂的,只要Debug一次,程序很大几率就会发生变化。
  6. 一个业务可能需要几个、甚至十几个程序提供服务才能正常运行,一个环节出现问题,整个系统就会出错。如何快速的分析、排查问题,是个痛苦的问题。这是让很多人抓狂的问题。
  7. 。。。

      在面对如此多的变化时,DevOps变的很理想、很无力。DevOps的落地,需要在不断的改良中找到平衡点。我们的解决方法是:

  • 搭建CMDB系统,管理各类环境的部署信息。比如:集群信息、进程信息、服务信息、WebAPI信息、配置信息等。并且这些信息的变更要通过系统集中管理,决不允许出现CMDB信息与部署信息不一致的情况。
  • 搭建补丁系统。开发交付包标准化管理。通过补丁制作工具,制作格式化的补丁,通过补丁安装平台,实现补丁包的安装。系统程序、SQL的变更全部通过补丁平台进行。补丁系统是一个非常复杂的系统,后续有机会再详细介绍

clip_image006

  • 搭建模板机环境,当生产系统更新了补丁或者CMDB信息发生变化后,通过自动化的工具,主动推送到模板机中。保证生产环境与测试环境的实时同步。各类测试环境从模板机克隆,并通过工具与模板机定时同步变化。同步完成后,通过自动化测试工具和环境检查工具,确定环境是可用的。

clip_image008

clip_image010

  • 开发全链路监控系统,并在系统的各个入口处埋点,帮助开发人员分析系统问题。全链路监控系统也是一个非常复杂的系统,后续有机会再详细介绍。下面是全链路的基本原理图和运行效果图。

clip_image012

clip_image014

      做互联网应用需要有基因,更需要有填坑的勇气和毅力,填坑的过程就是攀登技术高峰的过程,永无止境!本文也仅仅是从架构的方面给大家分享,不过内容全部已经落地,没有吹NB的意思。希望这个技术分享能对大家有用!

发表评论
用户名: 匿名