大型云原生项目在数字化企业落地过程解密

当前，随着互联网的高速发展，各企业的业务量出现几何级增加趋势。愈来愈多企业发现，使用传统模式部署及运营的产品愈来愈难以适应新模式下的要求，运维工做愈加难以推动。如何搭建一套可以知足子系统高效调度，系统资源充分利用，同时具备动态调整资源，具有高系统扩展性的应用调度系统，成为摆在各企业面前的一道难题。

用友云开发者中心是一个应用全生命周期管理的平台，它的底层基于容器技术，结合DevOps等理念，为用户提供了资源管理、持续集成、应用管理等应用基础服务，同时提供了完备的应用调度服务。如今，开发者中心正用着它全新的技术模式快速改变着公司和用户建立、发布和运行分布式应用的方式。

本文将站在实施人员的角度，带您了解面对具体客户实施现场时须要考虑的实际问题，给出一种通用的部署开发者中心方法，同时解析部署于开发者中心的业务应用的访问链路，分析各访问环节可能遇到的问题。

经过本文的讲解，相信您必定可以更加熟悉开发者中心在客户现场的实施过程，同时会对开发者中心的业务链路有更加深入的理解，以便更加容易排查和解决客户现场可能遇到的业务访问相关问题。

1 了解客户IT需求，制定实施方案

咱们知道，面对具体客户和其所在行业，会遇到不一样的业务需求。平台所面对的客户和所需承载的压力也有不一样，为了平台交付后的稳定运行，在项目实施前须要对客户的业务进行了解，跟据客户前期的基础数据，行业经验等信息，与用户充分沟通后，给出最适合的资源需求清单，并完成方案设计。

在了解客户需求等基本状况时，须要确认的信息至少应包含客户的业务特色及规模、平台注册用户数、预期业务峰值与低谷期访问量、现行业务流、可能出现瓶颈的地方、业务风险、有无外部数据交互等。

了解客户需求后，须要评估IaaS资源需求。评估时，须要考虑客户的业务特色，综合评估将来一段时间的业务量，并根据项目经验评估项目所需资源。

开发者中心对主机资源需求的详细配置以下表。一般出于提升可用性等缘由，建议客户使用集群模式安装平台。

配置项	集群模式主机配置推荐	完整安装模式推荐配置
数量	6+2	1
内存	16G及以上	80G 及以上
CPU	8核，2.4G Hz	40核，2.4G Hz
硬盘	（主节点）500GB及以上 （节点机）200GB及以上	1TB及以上
网卡	1000Mb及以上	1000Mb及以上
操做系统	CentOS 7.4及以上	CentOS 7.4及以上

在客户需求及基础资源准备完毕后，须要制定详细的项目实施方案。制定方案时，应该考虑到如下几点：

l 产品版本：包括开发者中心版本、所用中间件版本、应用版本等

l 基础设施：包括检查主机的实际配置，检查系统安全性，设计网络安全方案等

l 基础平台：制定开发者中心的部署方案，着重考虑关键节点的高可用实现方法，数据存储、维护方式等

l 业务架构：制定业务架构方案，制定数据库、中间件等服务部署方案

2 实施部署开发者中心

开发者中心提供了大量的基础平台功能，具备较多的功能模块，所以其在实施部署时，须要按其给出的文档，按规范操做进行。

一般，开发者中心建议采用6+n模式实施部署，即平台部署于6台服务器，n台服务器接入到资源池中，用于部署业务应用。

在部署平台前，根据已有计算资源规划每台服务器的用途，较为合理的一种资源配置方案以下表。

IP	主机名	功能	CPU （核心数）	内存 （GB）	硬盘 （GB）
x.x.x.x	dc-master	平台心主节点	16	32	1000
x.x.x.x	dc-slave	平台从节点	16	32	200
x.x.x.x	dc-slave-dns	平台从节点、DNS	16	32	200
x.x.x.x	dc-k8s-master	Kubernetes 主节点	16	32	200
x.x.x.x	dc-prometheus	Prometheus监控	16	32	1000
x.x.x.x	dc-ycm-insight	监控大盘服务端组件	16	32	200

开发者中心的部署过程可概述为四个阶段：

l 第一阶段：在CentOS 7操做系统上，配置并确认好基础安装环境

l 第二阶段：上传并解压开发者安装包，安装开发者中心后台管理系统

l 第三阶段：添加节点机，并启动各个模块

l 第四阶段：按顺序安装开发者中心其余组件，完成开发者中心安装

在第一阶段，须要对安装环境进行确认，保证安装环境符合安装要求。具体须要检查确认的内容包括安装盘完整性，服务器操做系统及内核版本，CPU、内存、磁盘大小，主机名称，防火墙状态，Python版本等。

在第二阶段，部署开发者中心后台管理系统。在此阶段中，因为安装部署内容较多，配置较多，所以安装过程当中最有可能因为环境等缘由致使出现安装异常中断现象。了解具体的安装内容，可更好的便于在出现异常情况时定位并排查问题。

在此阶段中，具体的安装内容以下：

1. 平台根据用户选择的安装模式和指定的IP地址等基础配置，在系统中加载安装配置文件，并对系统进行对应设置；

2. 平台启动Nexus服务，同时设置系统的yum源，用于平台安装时加载所依赖的系统组件；

3. 安装Java、系统经常使用工具如net-tools等，并安装Docker服务；

4. 解压镜像仓库等压缩文件，并适配全部配置文件中的内容，以适应当前安装环境。此步骤需消耗较长时间，安装过程当中需耐心等待；

5. 启用镜像仓库服务，并拉取平台所需的模块镜像到服务器中；

6. 安装并配置Calico网络，创建SDN环境；

7. 经过docker compose服务，启动平台依赖的中间件服务，同时启动开发者中心后台管理系统；

8. 初始化开发者中心所用的数据库；

9. 在本地安装Mesos-Slave节点，使本机加入资源池中，具有部署应用能力；

10. 启动开发者中心的部分基础模块。

在第三阶段，启动License Server服务，并按照部署计划，经过开发者中心后台管理系统，将其余节点机加入至资源池中，而后部署开发者中心所有所需模块。所有模块启动后，可根据用户需求配置邮箱地址等用户定制化内容。

在第四阶段，按照安装文档要求，在各服务器中依次安装Kubernetes Master服务、系统监控服务、DNS服务、监控大盘服务等，完成平台的实施过程，并验证平台功能。

3 功能模块全景图

开发者中心所涉及的模块众多，依赖中间件也较多，理清各模块间的调用关系，以及依赖的中间件关系，有助于在使用开发者中心遇到平台相关问题时，快速定位出现问题的模块，找出问题的缘由所在，并解决问题。

开发者中心各模块可按其功能归类。具体的类别、功能描述、模块间调用关系，及其依赖的中间件可见下文。开发者中心的大多数模块均用到了MySQL数据库服务、Redis缓存服务、ZooKeeper分部式协调服务，在描述中再也不赘述。

权限控制及域名管理类

包括单点登陆器、用户中心、租户中心、校验中心、域名管理等模块，用于控制用户的登陆，系统权限，域名访问等功能。用户经过DNS、Nginx等中间件访问平台后，首先调用的即此类别中的模块。一些Spring Cloud微服务相关的组件也在此类中。

前端工程类

包括门户和前端工程两个模块，用于在浏览器中向用户展示和交互平台功能。用户登陆系统后，经过前端工程访问平台提供的如资源池管理、持续集成、应用管理等功能。

资源池服务类

包括资源池管理、资源池API、远程登陆、资源池定时任务等四个模块，用于提供资源池管理相关功能。用户可将自有服务器添加至资源池中，以部署业务应用。此类服务依赖中间件MongoDb，用来缓存节点部署应用数等状态信息。

构建与部署类

包括持续集成、应用部署、定时调度等三个模块，用于提供持续集成相关功能。持续集成中的持续构建任务和流水线任务，均经过持续集成模块实现，构建镜像后经过应用部署模块，将任务发送至应用管理模块。设定定时构建的流水线任务，将经过定时调度模块触发任务，完成指定的工做。须要注意的是，在应用部署时，仅第一次部署的新应用会调用应用部署模块。已部署的应用在执行部署操做时，会直接调用应用管理模块。用户经过流水线任务构建应用时，上传的war包等资源会存储于FastDFS提供的分布式存储服务中。

应用管理类

包括应用管理、定时调度、智能运维、应用拓扑图等四个模块，用于提供应用管理相关功能。应用管理模块向用户提供当前部署的应用状态等信息，智能运维向用户推荐最可能操做应用。此类模块调用中间件较多，如RabbitMQ消息队列服务，系统监控服务，应用性能监控服务等。用户部署应用在资源池节点机中，其依赖于Mesos/Marathon服务，Calico、etcd服务等。

基础数据管理类

包括统一接入、基础数据、权限模型等三个模块，用于提供基础数据管理相关功能。用户在建立应用后，会经过基础数据模块将应用信息保存至数据库中，以便于其余模块统一调用。应用的受权、统一接入等功能也由此类模块提供。

镜像仓库服务类

包括镜像认证服务、镜像仓库、镜像同步等三个模块，用于提供镜像仓库服务相关功能。用户构建的应用每次执行构建操做时，均会经过此类服务，将镜像保存至服务器中。此类模块依赖镜像仓库中间件，同时在资源池节点机在启动业务应用时，相其提供对应的应用镜像。

监控服务类

包括监控大盘API、前端埋点、监控大盘后台、全链路监控等模块，用于监控并记录应用运行时的状态。经过此类模块可更加深刻的了解应用运行时的情况，如应用占用资源状况，应用内部请求调用链路及耗时等信息。此类模块依赖中间件ElasticSearch、Kibana、kafka等，保存监控信息。

报警、变动及日志类

包括报警中心、变动大盘、应用日志、短信服务等模块，用于采集应用运行时日志，记录应用变动状态等信息，并在出现应用异常情况时触发报警系统。

资源申请及审批类

包括资源池申请、应用审批、中间件管理等模块，用于快速搭建业务应用所需中间件，及进行业务应用相关审批流程。

4 基于Docker+Calico网络的应用部署架构

开发者中心在部署应用时，使用Docker技术来构建应用镜像，将任务发送至资源池中，由资源调度系统定夺接收任务的节点机，并经过Docker容器的方式启动应用。

Docker是一个开源的引擎，能够轻松的为任何应用建立一个轻量级的、可移植的、自给自足的容器。使用Docker，能够实现更快速的交付和部署应用，方便的对应用实例进行扩容缩容等操做，与Mesos调度框架结合，可以进一步提升系统资源的利用率，简化应用管理过程。

当应用部署至各节点机后，接下来须要考虑并解决的问题是跨主机容器通讯问题。开发者中心采用Calico搭建SDN网络，解决多主机容器网络问题。

在原理上，使用Calico 搭建的虚拟网络中，整个过程始终都是根据iptables规则进行路由转发，并无进行封包/解包的过程，这使得其传输效率更高。

5 应用访问链路物理结构

如前文所述，应用可基于Mesos架构，使用Docker技术部署于Calico的虚拟网络中。一个应用能够启动多个实例，以实现高可用特性。当应用的一个实例出现问题时，只要系统中此应用仍有其余实例存活，便可保证整个业务系统的可用性。

一个应用的多个实例之间，须要由服务发现和负载均衡技术实现业务的统一出口，开发者中心采用Marathon-LB来实现此功能。Marathon-LB是Marathon的服务发现系统，它使用HAProxy实现代理服务器的功能。使用Marathon-LB能够配置应用的固定端口，而访问应用的IP就是运行Marathon-LB的节点机IP。Marathon LB会监听Marathon的调度事件，获取容器实际运行的IP与端口，而后更新HAProxy的配置文件。所以，当从新部署应用时，仍然能够经过固定的IP与端口访问该应用。Marathon-LB的服务发现功能由系统自动完成，用户无需手动配置。

Mesos-DNS主要功能是对部署在Mesos架构下的应用生成域名，并提供相应的域名解析服务。Mesos-DNS为Mesos任务定义了一个DNS域，默认为.mesos。此时，用户直接访问由Mesos-DNS生成的域名来访问应用。可是大多数状况下，用户难以感知和记录自动生成的DNS地址来访问服务，所以此项功能更多用于平台内部应用相互调用时的场景。

那么，用户如何使用自定义的域名，来访问本身构建部署的业务应用呢？此时Ceryx即可登场了。Ceryx是一个动态反向代理，它的内部依托于Nginx服务，可代理主机上任意多的服务，同时它的配置可即时生效。Ceryx的这种域名解析服务又被称为泛域名解析服务。在Ceryx的帮助下，用户可自定义业务应用的域名，并由此来访问业务应用。

在开发者中心创建的应用体系内，不只仅有业务应用，更有一些平台内部服务做为底层支撑，全部服务均需有相同的统一出口，便于统计和管理。同时在一些项目内，客户也有须要配置短域名等需求。Nginx做为反向代理（Reverse Proxy），可知足上述的所有要求。Nginx能够以代理服务器来接受网络上的链接请求，而后将请求转发给内部网络上的服务，这个Nginx所在的代理服务器对外就表现为一个服务器。

最后，在接入层面，开发者中心使用DNS实现对访问域名的解析。所谓域名解析，即经过域名获得该域名对应的IP地址的过程。域名是互联网上的身份标识，是不可重复的惟一标识资源。当用户配置了主机的DNS为开发者中心的DNS后，便可使用自定义域名放问开发者中心和业务应用。

6 应用访问过程详解

在了解了开发者中心应用访问物理链路后，能够模拟一次请求，以更清晰的了解应用的访问过程。本文以模拟一个业务域名a.app.yyuap.com为例，描述其访问过程以下：

1. 用户输入域名后，经过DNS域名解析服务，将请求转发至Nginx反向代理服务；

2. Nginx经过内部的匹配规则，寻找并匹配最优解。Nginx在匹配域名至对应的location时有着复杂的匹配规则，感兴趣的读者可查阅相关资料，这里再也不赘述；

3. Nginx匹配到对应的转发规则后，将请求转发至Ceryx服务。此时Nginx提交请求的访问域名仍为a.app.yyuap.com，未作任何解析和转换；

4. EDNA服务实时获取用户的域名配置，并主动将其刷新至Redis缓存服务中；

5. Ceryx从Redis缓存服务中获取对应的域名解析规则，并将域名转换为由mesos生成的域名地址；

6. Ceryx获取到了转换后的地址，如marathon-lb.isv.marathon.mesos:36273。36273端口是Marathon-LB服务为应用代理的随机端口号。此时完成了泛域名解析的工做；

7. Ceryx经过Mesos-DNS域名解析服务，获取marathon-lb.isv.marathon.mesos 的实际IP地址，如192.168.33.101；

8. 请求继续转发至Marathon-LB负载均衡服务；

9. Marathon-LB内部由HAproxy服务实现，其根据端口号寻找定位应用实例；

10. Marathon-LB定位成功后，根据指定的算法规则，将请求匹配至应用中健康的某一实例下，并将请求地址转换为由Calico虚拟网络生成的业务Docker实例IP和端口，如172.20.17.11:31999，转发此请求。

11. 业务应用的Docker实例处理此请求，并将请求原路转发返回，最终返回至用户端。

以上即开发者中心中，应用的一次完整的请求访问过程。

7 业务访问关键节点问题排查方法

在应用的访问链路中，任何一个关键节点出现故障，都可能致使应用访问请求失败，在浏览器页面中出现50三、504等错误代码提示。了解各关键节点的部署位置，部署方式，应用链路相关数据，将有助于出现应用链路错误时，排查问题。

DNS服务相关问题排查方法

DNS服务即域名解析服务，由实施部署平台时，在规划服务器中手动启动执行。DNS服务由BIND服务实现，并使用Docker容器方式启动。

l 确认DNS容器存在并正在运行：登陆DNS所在主机，执行 docker ps | grep bind 命令，若返回对应容器信息，且状态为RUNNIND，可确认DNS容器存在，不然需从新启动DNS服务；

l 确认DNS服务日志无异常或错误信息：经过docker logs -f DNS容器ID命令，可跟踪查看DNS的docker容器输出日志，判断是否有异常发生；

l 确认DNS的转发规则中配置了所需的域名：编辑install_dns.sh文件，查看env变量的配置，此变量为DNS的转发规则。若其配置没有正确填写，需修改成正确的配置后，从新启动DNS服务，使配置生效；

l 确认发出请求主机或服务器配置了对应的DNS服务：在每台服务器的/etc/resolv.conf文件中，配置了DNS的地址。若没有正确配置，则请求中的域名将没法正常解析。

Nginx服务相关问题排查方法

Nginx服务负责提供反向代理服务，在实施部署平台时，通常部署于开发者中心主节点中。Nginx服务由docker-compose方式启动。

l 确认Nginx容器存在并正在运行：登陆开发者中心主节点服务器，执行 docker ps | grep nginx 命令，可查看对应容器及状态。如需重启Nginx服务，则需进入${DCEE_HOME}/script/compose_manage目录，执行docker-compose up -d nginx命令；

l 确认服务端口存活，且服务器的防火墙设置为容许访问状态：通常状况下，Nginx的服务端口设置为80。在服务器中执行netstat -tunlp| grep 80命令，可查看80端口存活，及是否由Nginx服务占用；

l 确认Nginx的配置文件正确：进入${CONFIG_CENTER}/nginx目录中，应用的配置信息位于upstream-dev.conf文件中。打开并确认文件中的配置是否正确。修改配置文件后，需重启Nginx的docker容器，使配置生效。

Ceryx服务相关问题排查方法

Ceryx服务负责提供泛域名解析服务，在实施部署平台时，由用户在开发者中心后台管理系统中启动。Ceryx服务使用Docker容器启动，运行于开发者中心的主节点或从节点中。

l 确认Ceryx服务是否正常运行：在浏览器中打开并登陆开发者中心后台管理系统，在容器管理中查看Ceryx容器运行状态，若无此容器或容器健康情况不为健康，则可经过查看日志等方法，使Ceryx服务正常工做；

l 确认Redis缓存中有对应数据：Ceryx服务对应用的转发请求依赖于Redis服务，其会从Redis缓存中获取应用转发地址。经过工具查看Redis服务中数据，若无对应数据，则可能EDNA服务出现异常。

Marathon-LB服务相关问题排查方法

Marathon-LB服务负责提供负载均衡功能，其在安装开发者中心主节点服务时自动部署启动。在Marathon-LB容器的内部，负载均衡功能实际由HAProxy服务完成。

l Marathon-LB服务是否正常启动：登陆开发者中心后台管理系统，在容器管理中查看marathon-lb容器状态。Marathon-LB正常工做需占用较大内存，建议适当增长内存分配，保障服务稳定可用；

l Marathon-LB注册端口是否与服务器本地端口有冲突：因为Marathon-LB在工做时需向所在宿主机申请大量端口，若出现与服务器的端口冲突的情形，则会致使Marathon-LB服务没法正常工做。致使端口冲突的可能的缘由较多，如宿主机端口被用户应用或其余中间件占用，应用在长链接未断开时被更新，Calico使用随机端口访问等。排查问题时需根据用户实际环境，一一排查；

l Haproxy页面是否含有应用注册的相关信息：在浏览器中输入http://开发者中心主控机IP:9090/haproxy?stats，访问HAProxy信息页，确认访问的应用是否已注册至HAProxy中。

总结

本文对开发者中心的实施过程进行了简单介绍，同时着重介绍了基于开发者中心搭建应用的部署架构，并详细解析应用访问过程，给出了几种排查应用访问关键节点问题的方法。

经过本文，您能够了解开发者中心的实施部署过程，了解功能模块及其用途，对部署于开发者中心的应用访问链路有更加深刻的理解。同时能够以此为依据，解决在使用开发者中心时遇到的应用访问链路问题。

须要读者注意的是，影响业务正常访问的因素仍然有不少，如服务器问题、平台架构服务问题、应用自身问题、网络问题等。排查问题时，不限于本文列出的情形及解决办法。但愿本文可以抛砖引玉，给读者您带来更多解决问题的思路。

开发者中心还有更多的功能和秘密，等待着你来探索！