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

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

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

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

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