phpcms网站,网站开发 发送邮件功能,泰国做性的短视频网站,凡客家装眼下#xff0c;做互联网应用#xff0c;最火的架构是微服务#xff0c;最热的研发管理就是DevOps#xff0c; 没有之一。微服务、DevOps已经被大量应用#xff0c;它们已经像传说中的那样#xff0c;可以无所不能。特来电云平台#xff0c;通过近两年多的实践#xff… 眼下做互联网应用最火的架构是微服务最热的研发管理就是DevOps 没有之一。微服务、DevOps已经被大量应用它们已经像传说中的那样可以无所不能。特来电云平台通过近两年多的实践发现完全不像大家说的那样简单大家是报喜不报忧实在是水太深谁做谁知道。今天就与大家分享一下在微服务架构DevOps下开发测试环境的一些运维痛点问题和解决方法。 架构的复杂度直接决定了运维的工作量架构不是越复杂越好而是适合最好。下面简单说说几种架构的优缺点。基于.net在搭建应用时最常用的方法就是采用Asp.net MVC前端、后端 All in到一个站点中省时省力完全不用关心部署运维的复杂度。但是弊端也非常明显所有内容部署在一个站点下如果业务复杂系统的变化频率非常高稳定性堪忧基本无解。再复杂一些的就是前后端分离H5或Winform WebAPI此种架构虽然把前后端的变化分开了但是后端逻辑缺少服用存在大量公共方法或者重复代码。更复杂的就是前端WebAPIService这种模式下虽然抽取了公共服务但是部署粒度还是很粗基本上会按照业务范围分多集群部署。同一个集群下部署的服务如果太多程序集冲突、服务变更重启集群影响范围大等问题依旧是难解的问题。所以为了隔离变化、降低对其他服务的影响集群的划分粒度会越来越小甚至演变到一个服务一个集群这就是微服务的形态了。这几种架构模式总结起来就是水平、垂直两个维度的变化水平维度从一类站点变为了多类站点以解决变化的影响访问、代码服用的问题。垂直维度从所有应用部署在一个站点中变化到一个服务一个集群隔离变化带来的影响。架构从一个点演变到两个维度的变化最终带来的运维成本指数级的增长。下面是特来电云平台微服务架构图从图中可以看出整体架构比较复杂。 为了支持全国的充电业务特来电云平目前已经有近千台服务器应用程序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的意思。希望这个技术分享能对大家有用
相关文章
谷歌发布的首款基于HTTP/2和protobuf的RPC框架GRPC拥抱.NET Core跨平台的轻量级RPCRabbit.Rpc基于DotNet Core的RPC框架(一) DotBPE.RPC快速开始基于.NET CORE微服务框架 -surging的介绍和简单示例 开源剥析surging的架构思想基于.NET CORE微服务框架 -谈谈surging的服务容错降级我眼中的ASP.NET Core之微服务.NET Core 事件总线,分布式事务解决方案CAPCAP 介绍及使用【视频】
原文地址http://www.cnblogs.com/vveiliang/p/7264397.html .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
