net的微服务架构

眼下，做互联网应用，最火的架构是微服务，最热的研发管理就是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的变更全部通过补丁平台进行。补丁系统是一个非常复杂的系统，后续有机会再详细介绍。