掌门教育自2014年正式转型在线教育以来，秉承“让教育共享智能，让学习高效快乐”的宗旨和愿景，经历云计算、大数据、人工智能、AR/VR/MR以及现今最火的5G，一直坚持用科技赋能教育。掌门教育的业务近几年得到了快速发展，特别是今年的疫情，使在线教育成为了新的风口，也给掌门1对1新的机遇。随着业务规模进一步扩大，流量进一步暴增，微服务体系下，业务服务新增和迭代频率大大加快，运维和业务人员经常需要熬夜人工上线，疲劳状态下容易产生生产事故，运维成本和业务成本也将大大上升。在此背景下，基础架构部推出可以白天安全上线，流量无损的微服务灰度蓝绿发布智能化系统，并通过强有力的各种监控手段来保证流量的精确制导和调拨，提升技术驱动能力。
关于Solar
Solar作为掌门1对1下一代基础微服务体系，2019年11月开始筹划，2020年1月4日推出第一版，2020年4月15日发布1.2.0 & 2.2.0里程碑稳定版，兼容Spring Cloud Edgware版、Finchley版、Greenwich版、Hoxton版本。基于三层体系而构建：
基础公共组件。Solar的基础组件，基础公共组件一般呈原子层面的独立存在，组件间也可适当耦合，基本上可达到一个组件被移除，不影响另外一个组件的运行的特征。
基础公共框架。Solar的基础框架，依托Spring Cloud服务体系，以框架形式对外暴露。它的另外一个重要特征，是对基础公共组件的聚合，一种“搭积木”的方式进行构建。
基础公共服务。Solar的基础服务，以公共服务形式对外暴露。它的另外一个重要特征，是对基础公共组件的使用，它是Solar框架卫星环绕式的组成部分。
Solar基于Spring Cloud技术栈，支持Eureka注册中心、Apollo配置中心、Zuul网关、2个限流熔断降级组件（Sentinel、Hystrix）等，Skywalking + Opentracing和CAT的APM调用链监控，Prometheus + Grafana指标监控，Kibana日志监控等，具有企业级的插件引入、开箱即用特征。它包含几大核心模块：
全链路灰度蓝绿发布智能化&DevOps发布平台集成
Zuul网关动态过滤转发灰度蓝绿&Furion统一控制台
Sentinel全链路熔断限流降级权限和自研功能
Apollo & Eureka & VI & Sensitive & EventBus & Agent & XXL-Job等中间件和组件
Docker CI &自动化测试
服务和网关一键脚手架
监控三要素，Tracer（Skywalking & CAT），Metrics （多维度的业务指标监控），Logger（MDC，Kibana & ES & GOHANGOUT等的ELK日志集群）
打通基础数据中间件，MySQL（ShardingSphere）& RocketMQ & MongoDB & Redis
支持大数据平台，Kafka & Elastic Search & InfluxDB
接入GPM监控平台，Prometheus & Grafana & InfluxDB & AlarmCenter （运维、邮件、钉钉机器人和掌控APP告警）
接入阿里云，OSS支撑
术语解释
全链路
用于端到端的调用访问范畴，一般是往网关到下游若干服务的链路拓扑结构。例如，网关 -> A服务 -> B服务 ->……的调用和访问。
灰度发布
灰度发布又名金丝雀发布，指不停机旧版本，部署新版本，低比例流量（例如：5%）切换到新版本，高比例流量（例如：95%）仍走旧版本。通过监控观察确认无问题，逐步扩大范围，慢慢的把所有流量都迁移到新版本上来。
灰度发布的作用：支持白天向生产环境发布新服务，安全平滑的逐步切换流量，保证流量以最小代价实现无损。
全链路灰度发布
全链路灰度发布是指流量在全链路权重分配。如下两条链路，流量必须走“链路1”或者“链路2”，不能出现交叉情形，例如，A服务（1.0版本）不允许去访问B服务（2.0版本），这样方式可以有效避免新旧版本不兼容的情况。
链路1：网关 -> A服务（1.0版本） -> B服务（1.0版本）
链路2：网关 -> A服务（2.0版本） -> B服务（2.0版本）
操作者给“链路1”分配95%的权重流量，给“链路2”分配5%的权重流量。假如“链路2”中任何一个服务出现问题，我们可以直接切掉“链路2”的5%流量，实施流量回滚。下文中提到的版本1.0表示已经上线的旧服务，版本2.0表示即将要上线的新服务。
蓝绿发布
蓝绿发布即不停机旧版本，部署新版本，将流量切到新版本，便于快速回滚，旧版本待流量为零，可以继续保留较长时间后下线。
蓝绿发布的作用：支持白天向生产环境发布新服务，通过条件方式，实现在两个部署环境快速切换，如果新服务存在问题，可以快速切换到老服务，保证流量以最小代价实现无损。
全链路蓝绿发布
全链路灰度发布是指流量在全链路条件分配。如下两条链路，流量必须走“链路1”或者“链路2”，不能出现交叉情形，例如，A服务（1.0版本）不允许去访问B服务（2.0版本），这样方式可以有效避免新旧版本不兼容的情况。
链路1：网关 -> A服务（1.0版本） -> B服务（1.0版本）
链路2：网关 -> A服务（2.0版本） -> B服务（2.0版本）
操作者给“链路1”分配一个Http Header值，给“链路2”分配另一个Http Header值，例如：Header中domain=green，选择执行“链路1”，domain=blue，选择执行“链路2”。假如“链路2”中任何一个服务出现问题，直接把domain切换到www，实施流量回滚。
适用条件
所有全链路服务必须前置Solar网关，即所有全链路服务的流量必须通过Solar网关进入
所有全链路服务必须接入Solar框架
未接入Solar框架的服务必须实施最后一次滚动发布，使之接入Solar框架后具备全新的全链路灰度发布和蓝绿发布的能力
业务服务如果存在静态IP负载均衡，Solar框架也兼容，但不会对它灰度发布和蓝绿发布
蓝绿发布流程
注意：我们实现了对灰度发布和蓝绿发布的糅合，下文提到的“蓝绿发布”有广义性，同时包含狭义的“蓝绿发布”和“灰度发布”的含义。
蓝绿成功的流程：
创建蓝绿计划（Plan） -> 蓝环境部署（Deploy） -> 执行蓝绿（Blue-Green） -> 蓝绿验证（Check） -> 下线绿环境（Offline） -> 完成蓝绿计划（Finish）
蓝绿失败的流程：
创建蓝绿计划（Plan） -> 蓝环境部署（Deploy） -> 执行蓝绿（Blue-Green） -> 蓝绿验证（Check） -> 蓝环境回滚（Rollback）
蓝绿发布前
创建蓝绿计划：
用户在CD平台上创建蓝绿计划，他需要事先统筹确定，今天有多少个服务要发布新版本（本文假设需要发布A新服务和B新服务为例进行阐述），执行全链路版本条件驱动或者权重放量。
根据蓝绿计划里的服务列表自动创建基准兜底的服务版本匹配策略（版本只取生产环境上运行的服务版本），保证流程只运行在绿环境里，规则推送给线上所有网关。
<rule>
<strategy>
<version>{"solar-service-a":"1.0", "solar-service-b":"1.0"}</version>
</strategy>
</rule>
蓝绿发布中
部署蓝环境的全链路服务
A新服务和B新服务的机器通过VI启动点火成功并拉入流量（注册到注册中心）之后，进入蓝绿环节。
执行蓝绿
根据用户提交的蓝绿计划，CD平台将自动创建蓝绿策略。注意：下文中提到的XML展现方式，用户是接触不到的，只是为了表达逻辑含义而已。
执行蓝绿条件驱动模式：
通过蓝绿发布计划的配置页面，配置服务版本号，路由链路，以及每条链路的路由条件，下面配置表示为Http Header中domain字段为Green时候走route1的链路，domain字段为Blue时候流量走route2的链路。Header字段可自定义，对于同一网关和BI下不同业务系统的蓝绿发布和路由，可以通过namespace进行隔离，其作用是支持不同业务系统同时实施蓝绿发布方案。
<rule>
<strategy-customization>
<conditions type="blue-green">
<condition id="condition1" header="#H['domain'] == 'green'" version-id="route1"/>
<condition id="condition2" header="#H['domain'] == 'blue'" version-id="route2"/>
</conditions>
<routes>
<route id="route1" type="version">{"solar-service-a":"1.0", "solar-service-b":"1.0"}</route>
<route id="route2" type="version">{"solar-service-a":"2.0", "solar-service-b":"2.0"}</route>
</routes>
</strategy-customization>
</rule>
执行蓝绿权重放量模式：
通过蓝绿发布计划的配置页面，配置服务版本号，路由链路，以及每条链路所占的权重百分比，下面配置表示为route1的链路（Green链路）所占的流量百分比为5%，route2的链路（Blue链路）所占的流量百分比为95%。相对于“蓝绿条件驱动模式”，“蓝绿权重放量模式”需要使用者分几次条件蓝绿权重，并进行多次观察，小心放量。
<rule>
<strategy-customization>
<conditions type=“gray">
<condition id="condition1" version-id="route1=95;route2=5"/>
</conditions>
<routes>
<route id="route1" type="version">{"solar-service-a":"1.0", "solar-service-b":"1.0"}</route>
<route id="route2" type="version">{"solar-service-a":"2.0", "solar-service-b":"2.0"}</route>
</routes>
</strategy-customization>
</rule>
蓝绿验证
通过蓝绿验证的工具（例如：Skywalking全链路调用链中验证），验证蓝环境是否有新流量接入，新流量是否会引起业务调用异常和错误。相对于“蓝绿条件驱动模式”，“蓝绿权重放量模式”需要使用者多次执行“全链路侦测”，观测权重百分比概率执行是否准确。
蓝绿发布后
蓝绿成功，执行如下步骤：
下线绿环境。下线绿环境的所有服务
完成蓝绿计划。清除蓝绿策略
蓝绿失败，执行如下流程：
蓝绿验证失败后，执行蓝环境回滚。当全链路中任何一个服务出现问题，就需要回滚。回滚方式，切回基准度低策略，默认指向绿环境。
<rule>
<strategy>
<version>{"solar-service-a":"1.0", "solar-service-b":"1.0"}</version>
</strategy>
</rule>
回滚后，对于出问题的服务，进行问题排查，重新上线，再执行蓝绿发布计划。
蓝绿发布并行隔离
当同一网关下，不同系统同时并行执行蓝绿发布，为避免冲突（不同系统的全链路蓝绿发布中包含相同的服务，但指向不同的版本匹配），可以通过命名空间（namespace）进行隔离，namespace通过Http Header传入，由Spel表达式进行命中，表达方式如下：
<rule>
<strategy-customization>
<conditions type="blue-green">
<condition id="condition1" header="#H['namespace'] == 'x-system' && #H['domain'] == 'green'" version-id="route1"/>
<condition id="condition2" header="#H['namespace'] == 'y-system' && #H['domain'] == 'blue'" version-id="route2"/>
</conditions>
<routes>
<route id="route1" type="version">{"solar-service-a":"1.0", "solar-service-b":"1.0"}</route>
<route id="route2" type="version">{"solar-service-a":"2.0", "solar-service-b":"2.0"}</route>
</routes>
</strategy-customization>
</rule>
注意：上述方式只适用于“蓝绿条件驱动模式”。
蓝绿的外界驱动和网关驱动
外界驱动
在全链路中，由外界传递蓝绿的Header标志值到网关上，来驱动全链路蓝绿发布，例如：上文提到的namespace和domain的Header。外界一般包括界面端，手机端等元素。
网关驱动
在全链路中，外界不传递蓝绿的Header标志值，而是通过在策略中加入对应的Header值，并写入到网关上，来驱动全链路蓝绿发布。表达方式如下：
<rule>
<strategy-customization>
<conditions type="blue-green">
<condition id="condition1" header="#H['namespace'] == 'x-system' && #H['domain'] == 'green'" version-id="route1"/>
<condition id="condition2" header="#H['namespace'] == 'y-system' && #H['domain'] == 'blue'" version-id="route2"/>
</conditions>
<routes>
<route id="route1" type="version">{"solar-service-a":"1.0", "solar-service-b":"1.0"}</route>
<route id="route2" type="version">{"solar-service-a":"2.0", "solar-service-b":"2.0"}</route>
</routes>
<headers>
<header key="namespace" value="x-system"/>
<header key="domain" value="green"/>
</headers>
</strategy-customization>
</rule>
外界不需要做任何改动，根据蓝绿的Header匹配，确定走route1的路由路径。
注意：上述方式只适用于“蓝绿条件驱动模式”。
蓝绿智能化实践
智能化，包括运维部署智能化和蓝绿驱动智能化。
运维部署智能化：业务人员部署服务时候，不需要接触任何云环境，只需要几步界面点击即可完成。
蓝绿驱动智能化：业务人员只需要按照既定的版本迭代规则，不需要接触复杂的蓝绿规则策略，只需要几步界面点击即可完成。
计划创建
我们可以通过创建一个发布计划，执行蓝绿发布。一个发布计划可以关联多个服务，即进行全链路的蓝绿发布。
计划审批
创建完的蓝绿发布计划会进入待审批状态，每个服务至少需要一个Owner审批通过后才可进入发布配置。由于涉及到生产环境上的服务上下线，我们采用了非常严格的权限控制。
发布配置
审批通过后，进入发布配置页。
发布系统配置
该步骤为运维智能化发布步骤：
选择应用参与蓝绿发布的版本信息
选择应用参与蓝绿发布的Group信息（运维层面的分组信息）
完成后进入【堡垒发布】。
堡垒发布
堡垒机的作用是尝试全链路新版本流量的引流，具有流量堡垒、屏障和保护作用。一旦堡垒机流量出现问题，可以快速回滚。
堡垒机发布完成后，生成兜底规则，兜底规则的作用是确保新版本上线过程中，或者快速回滚过程中流量打回到老的稳定版本，下一步进入【蓝绿配置】。
蓝绿策略配置和执行
权重放量模式：
蓝绿版本选择：所有应用的蓝版本和蓝条件必须配置
蓝绿权重配置：根据案例输入蓝绿版本的权重百分比。权重百分比的设置过程，是需要人工观察和不断减少旧版本权重，增加新版本权重的过程
条件驱动模式：
蓝绿版本选择：所有应用的蓝版本和蓝条件必须配置，绿版本和绿条件为可选
蓝绿条件配置：根据案例输入蓝绿版本的表达式
表达式提供用户自主校验功能，可选择对应规则进行校验。表达式分为两种：
普通模式，支持简单的==，!=， >，>=，<，<=六种操作，并且通过 && 或者 || 串联起来
高级模式，通过Spring Spel语句的编写，支持更多高级的科学计算和逻辑计算场景
校验通过后进入下一步 【开始验证】。
执行验证
蓝绿和兜底规则生效后，可以执行如下功能，进行准确性验证。
蓝绿全链路路由预检测功能，输入路由规则可以查看预检测结果。
路由策略预检测。在符合当前条件下，从网关派发到全链路服务的路由Header Json内容是否准确，是否符合预期。
路由路径预检测。在符合当前条件下，从网关到全链路服务进行智能化侦测，把途径的服务的版本等各类信息打印出来。
跳转定位到Skywalking观察全链路追踪的结果。
从Skywalking的SOLAR Span上，我们可以看到很多关键性的信息：
TraceId和SpanId输出
AppId和服务名输出
所在服务的IP地址输出
灰度版本，区域和子环境输出
灰度版本路由规则输出
调用链服务中的RestController的类名，方法名，入参，出参输出
调用链服务中的任何代码未被捕获的异常的输出
业务扩展接口自定义业务数据输出
通过对接Skywalking后台实现流量追踪。
通过掌门监控平台，对接钉钉机器人的通知机制，随时监控蓝绿规则和策略的变更。
执行回滚
验证失败后，执行回滚。当全链路中任何一个服务出现问题，就需要回滚。回滚方式，即删除配置strategy-customization节点下的策略，保留strategy节点下的策略，默认将执行基准兜底的服务匹配策略。
Baking阶段回滚后，对于出问题的服务，进行问题排查，重新上线，再执行发布计划。
执行全量发布
验证通过后，将执行全量发布，蓝绿发布流程结束。
后续展望
我们将不仅局限在Spring Cloud微服务侧的蓝绿发布，将持续推进前端、网关、Nginx等端到端和各类技术栈的蓝绿发布，实现真正全链路的蓝绿发布，争取把广大业务部门的同学从熬夜的泥潭里早日解放出来，做到白天无损且安全的生产环境发布。
作者介绍：
吴毅挺，掌门技术副总裁，负责技术中台和少儿技术团队。曾就职于百度、eBay、携程，曾任携程高级研发总监，负责从零打造携程私有云、容器云、桌面云和PaaS平台。
任浩军，掌门基础架构部研发经理。曾就职于平安银行、万达、惠普，曾负责平安银行平台架构部PaaS平台基础服务框架研发。10多年开源经历，GitHub ID：@HaojunRen，Nepxion开源社区创始人，Nacos Group Member，Spring Cloud Alibaba & Nacos & Sentinel & OpenTracing Committer。
文章来源：掌门技术，点击查看原文。
基于Kubernetes的DevOps实战培训
基于Kubernetes的DevOps实战培训将于2020年5月15日在上海开课，3天时间带你系统掌握Kubernetes，学习效果不好可以继续学习。本次培训包括：容器特性、镜像、网络；Kubernetes架构、核心组件、基本功能；Kubernetes设计理念、架构设计、基本功能、常用对象、设计原则；Kubernetes的数据库、运行时、网络、插件已经落地经验；微服务架构、组件、监控方案等，点击下方图片或者阅读原文链接查看详情。
来源：oschina
链接：https://my.oschina.net/u/4321566/blog/4264603