作者：李思源、武良军
问题背景
致景科技成立于年12月，是领先的纺织产业互联网企业，国家高新技术企业。旗下拥有“百布”、“全布”、“天工”、“致景金条”、“致景纺织智造园”、“致景智慧仓物流园”等业务板块，致力于通过大数据、云计算、物联网等新一代信息技术，全面打通纺织服装行业的信息流、物流和资金流，帮助行业实现协同化、柔性化、智能化的升级，构建纺织服装纵向一体化的数智化综合服务平台。
我们作为集团公司已经成立2年多的一个业务团队，项目并行开发上线的情况越来越多。值得一提的是，我们目前处于微服务化拆分刚开始的阶段，目前35个微服务，拆完之后大概会去到60个左右。在这样的背景下，原先大家都使用一套开发/测试/生产环境串行跑研发流程，随着项目数量、开发测试需求的变多，微服务拆分的进行，原先的方式已经不太适合我们。下面简单罗列一下，我们在这过程中所遇到的三个问题。
项目测试环境被抢占
最典型的问题就是一个项目测试环境经常性被缺陷修复的测试流程抢占，导致项目测试时断时续，对测试而言缺乏沉浸式体验，同时测试环节成为项目并行度的主要瓶颈，验证影响项目迭代的进度。
开发联调环境不稳定
为了保证开发的体验，开发环境是允许开发同学自由发布。由于使用一套环境，不同的同学进行开发环境发布，经常性地导致联调中断。不少开发同学转而寻求端到端的线下联调，在个人机器上部署上下游应用，这种模式在微服务化推广之后，特别是面对众多的微服务应用基本上寸步难行。如何解决开发阶段代码调试的便携性，成为了我们遇到的第二个问题。
线上灰度环境的缺乏
第三个问题也是最重要的，之前我们缺少专门提供给产品经理进行功能验证的预发环境。新功能完成测试之后直接上线到线上环境，研发团队为了避免避免对客户产生不良影响，经常性地将发布计划安排在晚上。抛开研发团队的发布幸福度不谈，线上环境缺乏灰度发布能力意味着新功能上线以后就会对全量用户放开，一旦发生了产品设计缺陷或者代码漏洞的情况，那么影响面将会是全网的，风险巨大且不可控。
综上所述，我们需要解决线下缺乏隔离的多套环境来支持多项目的开发和测试，同时在线上需要具备灵活的流量路由策略支持灰度发布需求。
方案调研与探索
结合我们公司实际情况，我们的目标是开发团队不依赖运维团队，即DEV=OPS。我们可以一键拉起逻辑隔离的开发/项目环境，同时可以支持预发环境隔离，对于生产环境可以通过配置灰度规则流量、自然流量来进行全链路灰度的验证。
根据我们对当前问题的分析，参考目前互联网上的解决方案，都指向了项目环境治理和服务流量治理的方案，我们稍微罗列下常用的几种方案，我们最终选择的是阿里云微服务引擎MSE全链路灰度+云效应用交付平台APPSTACK的集成方案。
自研Ribbon实现
我们使用的是SpringCloud框架，在平时的业务开发过程中，后端服务与服务之间的调用往往通过Fgin或者RstTmplat两种调用方式。这其中是通过Ribbon这个组件帮我们做了负载均衡的功能。灰度的核心就是路由，我们可以通过重写Ribbon默认的负载均衡算法，在负载均衡调用之前，增加流量路由的逻辑，那么就意味着我们能够控制服务流量的转发。
这个方案要实施下去，对于大厂来说确实可以从0到1再到进化出来，对我们来说，如果仅仅是实现一个路由的功能，做一个只支持核心场景的简陋版确实不是非常困难的事情。但如果要达到成熟可应用的阶段，需要投入专门的技术资源对其进行管理与维护，同时由于SpringCloud微服务框架本身的复杂性，随着微服务数量逐步增多，链路越来越长，相关的微服务治理问题的定位与解决，也会耗费不菲的时间成本。
物理隔离（蓝绿发布）
这种方案需要为要灰度的服务搭建一套网络隔离、资源独立的环境，在其中部署服务的灰度版本。由于与基础环境隔离，基础环境中的其他服务无法访问到需要灰度的服务，所以需要在灰度环境中冗余部署这些服务，以便整个调用链路正常进行流量转发。此外，注册中心等一些其他依赖的中间件组件也需要冗余部署在灰度环境中，保证微服务之间的可?性问题，确保获取的节点IP地址只属于当前的网络环境。这个方案需要为这些业务场景采用堆机器的方式来维护多套灰度环境，会造成运维、机器成本过大，成本和代价远超收益；当然如果应用数目很小，就两三个应用，这个方式还是很方便的，可以接受的。
MSE标签路由+APPSTACK应用编排（我们的选择）
这两款产品的说明文档见链接：
云效应用交付平台AppStack：