您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
基于.net的微服务架构下的开发测试环境运维实践
 
   次浏览      
 2019-3-26 
 
编辑推荐:
来自cnblogs,文章主要是讲解微服务下的讲解的运维,从搭建搭建环境到监控系统等等,更多请看下文。

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

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

 

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

 

.net Framework 无法采用Docker,更新包中不仅仅有程序文件的更新、还有配置的更新、SQL的更新。在如此大的规模下,人工更新成本高的离谱,基本上需要专岗来做。而人工做,很容易出错。必须工具化、自动化,补丁更新必须100%通过工具做,不能有人工干预,否则就会在各个环境中出现不一致的情况。

系统几乎每个小时都会发生一次变化,常见的增减应用程序、增减服务、增减WebAPI,这些信息的变化都会影响系统环境。只要一个程序、接口、服务管理不到位,系统就可能会给你颜色看。所有的机器信息、服务信息、配置信息必须集中管理维护,并在各类环境中实现自动同步。CMDB是必备的管理系统。

在日常的研发中,很多需求会涉及到多个产品研发部门联合开发,集成测试的周期很长,而测试环境的数量有限,经常出现一些紧急需求没有测试环境的尴尬问题。

测试环境会频繁的执行更新,甚至一个更新会反复多次,极易导致测试环境与生产环境不匹配。从而引起,程序热更新后存在bug,需要紧急回退。

开发测试环境是对每个开发人员开放的,每个人都会登录系统Debug。你懂的,只要Debug一次,程序很大几率就会发生变化。

一个业务可能需要几个、甚至十几个程序提供服务才能正常运行,一个环节出现问题,整个系统就会出错。如何快速的分析、排查问题,是个痛苦的问题。这是让很多人抓狂的问题。

 

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

搭建CMDB系统,管理各类环境的部署信息。比如:集群信息、进程信息、服务信息、WebAPI信息、配置信息等。并且这些信息的变更要通过系统集中管理,决不允许出现CMDB信息与部署信息不一致的情况。

搭建补丁系统。开发交付包标准化管理。通过补丁制作工具,制作格式化的补丁,通过补丁安装平台,实现补丁包的安装。系统程序、SQL的变更全部通过补丁平台进行。补丁系统是一个非常复杂的系统,后续有机会再详细介绍。

 

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

 

 

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

 

 

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

   
次浏览       
相关文章

DevOps转型融入到企业文化
DevOps 能力模型、演进及案例剖析
基于 DevOps 理念的私有 PaaS 平台实践
微软开发团队的DevOps实践启示
相关文档

DevOps驱动应用运维变革与创新
运维管理规划
如何实现企业应用部署自动化
运维自动化实践之路
相关课程

自动化运维工具(基于DevOps)
互联网运维与DevOps
MySQL性能优化及运维培训
IT系统运维管理