背景
在互联网高速迭代的浪潮下，置信每位研发人员都经验过新我的项目的需要研发、测试验收、部署上线、性能迭代、甚至我的项目下线的全过程。其中“需要研发”、“测试验收”、“性能迭代”、“我的项目下线”这类环节对于研发人员来说，基本上能够无效的把控，在整个我的项目的生命周期内，也是投入最多的几个环节，因而能够提前预估出正当的工夫打算。
这几个要害的环节中，将我的项目部署上线，往往是最初一个环节。对我的项目组成员和需求方来说，软件研发实现当前，投入生产环境，是一个瓜熟蒂落的事件，须要立马实现。
然而在网校大背景下，一个新我的项目投入到生产环境是一个十分庄重的事件，实际上须要经验的几个环节如下：
- 新域名备案（筹备必要的材料）
- 服务器申请（机房抉择、单机硬件配置、零碎选型、网段布局、机器命名、容量预估）
- 服务器生产（必要软件初装、参数校对）
- 研发受权（筹备dev or guest人员名单、筹备机器标签进行批量受权）
- 投入公布零碎（创立公布我的项目、填充机器信息、我的项目人员分工）
- 配置网关（集群抉择、vhost配置、upstream配置）
- 域名解析（是否通过全站减速/高防等防护产品、提供解析地址失效）
- 若是容量预估有余，还须要再经验一遍#2～#6（多批生产的机器存在环境配置不统一的隐患）
- 如果遇到我的项目下线，往往域名又被容易疏忽掉，造成一些无用且曾经备案的域名，不易治理
整个过程最快也要以天为单位，隔天交付生产；慢的话要数天能力实现生产环境的部署，并且须要跨多个部门协同实现。2020年公益直播顶峰前夕，“连轴转”实现服务扩容的搭档，尤其铭心刻骨。
因而，为了解决新我的项目部署周期长的问题，基础架构部启动了两个我的项目：《域名收敛》、《容器平台》。
《域名收敛》我的项目，次要为了缩短：#1、#7、#9这3个环节上耗费的工夫和精力。
《容器平台》我的项目，次要为了缩短：#2、#3、#4、#5、#6、#8这6个环节上耗费的工夫和精力。
并且当初两个我的项目曾经无缝联合，在同一个平台上实现。
上面将具体的介绍，咱们如何给开发实现的新我的项目，在1小时内公布上线提供便当，实现小时级交付生产，以及以后的我的项目利用规模。
容器平台
物理机与虚拟机时代整个新服务上线流程重大依赖机房资源、运维部署、多个零碎的环境配置、以及性能压测。
漫长的解决流程
资源申请流程 -〉 资源洽购 -〉 机器受权 -〉 服务运行环境配置（环境、网络） -〉 配置公布零碎 -〉 配置网关/日志 -〉 性能压测
硬件资源有余时，须要排队洽购审批，到资源上架初始化过程可能长达数月，漫长的解决流程十分打击开发人员的激情。
在资源短缺的时候，也须要数天的解决流程。咱们须要去解决这些漫长的流程的问题 ，在互联网时代敏捷性决定了业务的生与死。
咱们是如何做到便捷性的呢？
- 通过容器的环境一致性
- 网校云的对立调度硬件资源使咱们能无效盘活无效固定资产池
- 通过买通网关、日志体系，每位研发老师齐全自助的实现所有配置。
利用疾速公布
驱动于git devops的设计，用户只须要提供git仓库地址及我的项目域名，平台会调用pipeline引擎构建镜像，通过配置基于git事件的触发全自动构建镜像，而后依照模板创立 deployment,service,及ingress的kubernets等利用及资源。流水线作业设计，零打碎敲实现利用公布与镜像构建。
与网关进行了自动化买通， 利用部署实现后咱们将集群的网关ingress的地址提交给网关， 触发网关的upstream更新操作，从而实现了服务的发现以分流。
同时与公司公布零碎进行买通，在用户公布完利用后，能够取得一个hook地址，公布零碎设置hook后，在公布的时候登程k8s的滚动降级，以实现混合部署利用的同步降级。
云原生的PIPELINE引擎
gitlab事件触发充沛借鉴了K8S 自带的CI/CD零碎Prow的零碎设计，实现gitlab的主动事件告诉反对：
- Tag事件
- Push事件
- Merge事件
引擎通过向注册相干事件并监听， 当事件到来时会依据事件类型散发事件给相应的插件来解决。曾经实现了和网校云容器平台的无缝连贯， 通过在简略的web配置就能够构建出基于指定Tag或指定Commit的镜像。
引擎齐全运行在容器之上，多插件和PIPELIE、灵便多变的设计让利用的公布不会拘泥于特定的运行与构建环境，助力新我的项目的新环境的疾速公布于迭代。
弹性扩容
以基于horizontal pod autoscalers实现的 集群利用的主动弹性伸缩， 依据CPU使用量指标， metrics server从kubelet中的cAdvisor组件中获取cpu的资源耗费，默认状况下，每10s采样一次，每30s计算一次cpu使用量。当业务顶峰降临， 监控到pod的CPU占用量超过预约的阈值， 会主动减少服务的正本数量（在设定范畴），反之会减小正本数量，开释集群资源，由此实现集群资源的高效利用。
自动化日志收集
咱们采纳了filebeat作为日志采集工具。
- filebeat以daemon set模式运行，保障了每个节点都会有一个filebeat容器运行。
- filbeat容器能够采集宿主机以及该宿主机上其余容器的日志。
- 能够在咱们的容器平台，抉择须要收集日志的利用，即可实现日志采集。
- 通过configMap（配置核心）的形式，对采集配置进行治理
因为咱们曾经和网校的日志核心买通，咱们所采集的日志将均被采集到kafka中，而后落地到日志核心ES集群。
域名收敛
一、为什么要做域名收敛
随着网校用户体量飞速发展，业务越来越多样化，复杂化，各服务之间的耦合度也越来越高，依赖重大，相互影响。为了加重依赖，各我的项目都心愿有独立域名来提供服务，业务方也开始频繁申请新域名，使网校对外裸露的域名越来越多。这种做法逐步造成了网校域名泛滥景象。据不齐全统计，截止2019年年中，网校申请的域名有数千个，而且以每周数十的速率增长，其中通过网关的域名就曾经破千，而且很多域名曾经处于无人认领的状态，没有人敢确认这些服务是否在线上running，因而也不敢轻易去批改或下线。除此之外，域名的泛滥成灾也给网校的研发与运维带来了很多痛点问题：
- 研发人员:
- 上线艰难： 域名申请、域名备案、域名解析、网关创立利用、vhost、upstream、申请后端机器、后端nginx+fpm配置、公布代码。周期长（1周~1月），流程简短，效率极低，研发人员将大量精力消耗在我的项目上线上。
- 开发艰难： 无论是app、H5、web等客户端，开发须要适配不同域名的不同接口，代码臃肿，难以保护，单app端依赖的接口就有涵盖了近百域名，开发人员曾经不堪重负。
- 运维人员：
- 治理保护： 上千的域名保护治理艰难，只增不减，很多域名没有访问量，无人保护，无人认领。
- 配置艰难： 运维对接各种开发配置需要，造成网关层配置毫无标准，简单简短，频繁批改，出错率高，风险性大。
- 平安问题： 裸露域名过多升高了零碎的安全性，大量域名须要备案审计、平安扫描，也暴露出了很多安全漏洞。
2020年2月网校公益直播期间，由网校技术委员会发动的‘竞品剖析’专项进行了多项技术评测指标，其中在服务端域名管控上，咱们施行的力度远远不迭对手，网校的研发和运维人员还没有造成域名收敛的意识，不仅没有制订相干的标准文档，也没有对应的技术手段实现域名复用。
针对以上这些痛点问题，网校服务端技术委员会、运维团队、团体平安组携手发动了《网校域名收敛专项》，我的项目目标是要解决网校域名泛滥的问题，一方面要对现有的域名进行收敛与标准，另一方面对后续新上线我的项目流程进行调整与优化，减速推动我的项目的自动化与标准化上线流程，为网校云的建设铺路。
二、如何实现域名收敛
2.1 域名布局
那么该如何实现域名收敛呢？首先咱们将网校的服务大抵分为进行了分类，大抵如下：
- 依照服务类型分类：WEB服务与API服务，前者输入的是html，后者输入的是json数据。
- 依照服务范畴分类: 对内服务与对外服务，前者只提供内网或者办公区服务，后者提供公网服务。
如此一来，就有四种类型的服务： 对外WEB，对内WEB， 对外API，对内API。
因而咱们设计了四个域名与之对应: app.xueersi.com; app.xesv5.com; api.xueersi.com;api.xesv5.com; 这四个域名的作用如下。
- app.xueersi.com : 次要代理对外WEB利用，面向公网用户，例如站点首页。
- app.xesv5.com ： 次要代理对内WEB利用，面向外部用户，例如admin治理后盾，各种监控平台，告警平台等对内零碎。
- api.xueersi.com : 次要代理对外API服务，例如app,ios,pc端调用的api服务，阿里云、微信等第三方回调api。
- api.xesv5.com : 次要代理外部api服务，例如用户数据等中台类api接口。
2.2 计划制订
2.2.1 服务标签化
以网校的站点架构特点来说，简直所有的服务都由对立的Nginx网关进行反向代理，一个域名对应一个vhost与upstream，通过Nginx的proxy_pass进行路由转发。为了实现域名收敛，咱们决定对网关层进行技术改造，实现基于收敛域名的动静路由散发，所谓的收敛域名就是指下面提到的四个专用域名app.xueersi.com,app.xesv5.com,api.xueersi.com, api.xesv5.com， 除非凡状况外，尽量让所有的服务都可能复用这四个收敛域名(也能够叫做网关的专用’代理域名’)。
如果大家都共用同一个域名，怎么辨认不同的服务呢？ 很简略，依据url来辨认， 咱们会将url中第一个’/'前面的字段作为每个我的项目的标签，网关层会依据"标签"辨认不同服务，比方新上线一个学习利用，想应用study.xueersi.com, 则业务方能够拿"study"作为我的项目标签，同时复用app.xueersi.com这个域名，当用户拜访http://app.xueersi.com/study/...，网关会通过改写host，upstream，uri来实现以下转发规定：
- 改写upstream：从proxy_pass http://app.xueersi.com 改写成 proxy_pass http://study.xueersi.com
- 改写host ： 从 app.xueersi.com 改写成 study.xueersi.com
- 改写uri : 从 /study/course/getInfo?a=1 改写成 /course/getInfo?a=1
此时对于后端服务来说，用户申请的是http://app.xueersi.com/study/...，通过网关转化后，后端真正接管到的申请为： http://study.xueersi.com/cour...
同理，其余服务也是相似，复用同一域名，独占一个标签。
2.2.2 上线流程简化
在服务标签化之后，服务的裸露模式就从‘域名’依赖转换成了‘标签’依赖，那么对于研发人员则省去了域名申请，域名解析，网关创立vhost等步骤，以部署在kvm的服务为例，上线流程简化为：
其中开发须要做的只有两件事件：
- 域名备案 ：从立项到上线之间任意工夫备份即可(安全部门硬性要求，公网域名必须备案，私网域名能够不必)。
- 创立upstream: 通过网关后盾创立即可。
对于接入了网校云的服务，依赖于k8s的容器运行环境，这种服务的上线会更快，网关曾经和k8s进行了买通，只须要在k8s上进行利用创立，抉择好对应的网关集群，一键切流即可上线一个新我的项目。
2.3 技术实现
从上述的技术计划中不难看出，实现的关键点在于网关须要对每一个以收敛域名打头的申请，依照url进行切割，提取进去申请的"标签"，同时改写申请的host、upstream、uri，于是在网关层咱们开发了dyroute插件实现了上述性能。该插件不仅反对host，url，header，body，ip，referer，cookie等十几种筛选条件，也反对URL的多段宰割和提取，能够按需对host、upstream、uri进行定制。
三、问题与解决
现实很饱满，事实很骨感。真正推动域名收敛的过程，咱们遇到了很多辣手的问题，这里记录了次要的几个。
3.1 path池
依照网关的这套转换规则会存在一个破绽，以 app.xueersi.com 为例，如果有人申请 app.xueersi.com/A 则会间接的拜访到 A.xueersi.com,拜访 app.xueersi.com/B 则会拜访到 B.xueersi.com，也就是他能够任意试探拜访咱们的不通服务。你可能会问，app.xueersi.com 的设计初衷不就是代理公网服务吗？就算试探中了也没有关系，原本就是面向公网用户的。网校的域名有一个"不成文"的规定，就是 .xueersi.com 都是对外的，.xesv5.com 都是对内的，然而因为历史起因，很多域名并没有准守这套规定，例如 oa.xueersi.com 原本应该是对内的OA零碎，然而却用了 .xueersi.com 的对外域名。如果有用户通过 app.xueersi.com/oa 发送申请，则能够毫无拦截的拜访到咱们对内的零碎。同理，对于原本对外确用了 .xesv5.com 的服务，也会有相似的问题。
针对此问题，咱们设计了path池机制，每一个收敛域名须要和一个path池进行绑定，咱们会在创立upstream的时候把对应的标签退出到path池，只有退出到了对应path池的url能力失常通过网关，其余胡乱试探的/A，/B，/C的申请会被网关拦挡。
3.2 日志切割
以 app.xueersi.com 为例，在网关上会配置一个对应的vhost，当申请到来时Nginx会匹配中这个vhost，也就是所有接入到这个域名的服务都会共用vhost。一个vhost就有一份log文件的问题，如果前期这个域名接入了上百个服务，那这上百个服务的access log全副会记录到
app.xueersi.com_access.log 这份文件中，势必会造成单份日志文件过大的问题，同时会对ELK的搜寻造成困扰，用户很难找到本人服务对应的日志。
针对此问题，咱们采取了一种"变量式"日志记录形式，即"access_log /home/nginx/logs/app.xueersi.com_{host}_access.log", 当接入app.xueersi.com的申请到来时，网关层会辨认标签信息并将host进行对应的改写，到了Nginx的log阶段，会辨认以后的host变量决定往哪份log文件里写日志。例如 app.xueeris.com/A 则会写入app.xueersi.com_A_access_log,而 app.xueersi.com/B 则会写入app.xueersi.com_B_access_log。
3.3 cookie爆炸
当多个服务共用一个域名时另一个辣手的问题是cookie，服务端如果都往app.xueersi.com里set cookie，一是不同cookie key可能会反复，二是如果没有标准前期很可能会超出浏览器的最大cookie长度限度。
针对此问题，咱们从两方面着手解决。一方面设计了一套cookie管理系统，后端服务如果想要在 app.xueersi.com 里设置cookie，都必须在管理系统上进行申请，如果该cookie曾经有人申请过，则不容许反复申请，cookie管理系统上会记录每个cookie对应的服务信息。 另一方面对dyroute插件进行革新，在发送响应给客户端之前，会对cookie进行校验，不属于该域名的cookie会被拦挡。
3.4 跨域
跨域问题也是令人头疼的一个问题，团体平安组反馈，这些收敛域名会存在跨域危险，须要在有跨域限度。然而有的服务心愿可能在网关层对立解决跨域申请，有的服务则心愿后端本人解决跨域，有的服务心愿后端自行处理，有的心愿可能任意origin能够跨域拜访，有的则心愿只能‘http_origin’的拜访，甚至会有心愿自定义增加allow header头的业务。要想在一个域名vhost里cover所有的需要很难做到，咱们和业务方以及平安组探讨了一个折中计划，即所有接入域名收敛的服务对立在网关层进行跨域解决，网关会容许团体内的域名互相拜访，例如’.xesv5.com，.xueersi.com, .100tal.com’之间的跨域拜访没有限度，而内部域名则会被拦挡。另外咱们在allow header里增加了浏览器辨认的通用header头，同时设置有其余变量供业务方选定作为自定义字段。
3.5 双活
接入了域名收敛的服务中，有一部分服务是有双活需要的，然而这些域名是解析到了世纪互联IDC，无奈满足双活需要，于是咱们将这些域名的公网解析前移到了切流网关上，并利用切流网关的能力实现了双活需要，默认会间接转发到世纪互联， 如果有业务须要转发到阿里云会依据提前设定好的路由规定进行阿里云转发。
其实拦在咱们背后的问题远远不止于此，例如前端js动静配置问题，网关插件执行程序问题，多环境、多事业部域名收敛布局、多协定反对问题、接入全站减速问题、动态资源cdn缓存问题等等。而且面临的阻力也十分大，并不是所有人都乐意承受这个事件，特地是针对一些老的服务，没有人违心去革新，改革总会面临着走出舒服区，适应新的规定，因而很多人会有抗拒。咱们要推动全网校的前端、后端、运维、团体平安以及各部门的我的项目负责人，制订一套网校级的域名收敛标准，同时将这套历史教训推广到全团体。
通过了半年的致力，咱们也获得了一点小小的成绩，不仅在网校落地了一套域名收敛标准，以网关和容器为外围，成功实践于网校云平台，收敛的域名总数也冲破500大关。
咱们置信，既然认定了是对的，就始终干上来，解决麻烦的最好办法就是不怕麻烦，总有一天会看到播种。
作者简介
陈朝飞为好将来PHP/Golang开发高级专家