互联网时代为面对流量井喷式增长，为了解决快速交付、高可用、模块化扩展等问题。程序也从单体架构转变为微服务架构，为了使服务职责单一，工作的重心在服务的拆分和精细化分工。微服务架构虽然解决了协作效率、更好的快速实现需求和弹性扩展的问题，但是也引入了让应用间依赖变得更复杂，程序部署的复杂度变得更高等问题。在商业化环境私有化部署的实践中，大量的微服务需要重新部署到一个全新的独立环境中，如何解决资源初始化、协调多服务顺序启动等问题呢？

京东交易中台，作为微服务架构的践行者，在京东技术的私有化部署实践中也不可避免的要面临同样的问题，下面是交易中台对解决这些问题的一些探索和实践。

针对私有化部署交付项目进行了复盘发现目前主要的痛点在交付流程工具化程度很低，几乎所有节点都需要人工支持，而微服务带来的大规模应用部署更是使局面进一步混乱。一个应用发布的主要流程及痛点如下：

镜像管理：部分应用镜像和配置没有完全分离，同样的部署需要修改代码重新生成镜像，由于公司的内网和客户的网络不通，镜像需要多次手工搬迁才能到达客户环境。

资源申请：在客户环境中，存储、中间件等资源都是全新的，需要进行各种初始化操作，如新建数据库，建表等。

程序验证：分布式应用大量依赖外部服务，由于别名没有统一规范需要，启动顺序和别名都需要各种沟通和人工配合。

程序配置修改：环境信息资源发生变化，服务别名改变需要大量修改配置文件。

未来快速部署想实现的方式：通过配置、模版描述、让程序一次构建，可以在任何环境部署。我们把程序抽象成了镜像和配置，在业务需求不变的情况下镜像一般不需要修改，但是配置由于依赖了资源和中间件，所以在不同环境就需要不同的配置信息。配置是指独立于程序之外，但是对程序的作用是可以配置的变量，在同一个镜像的不同配置下也会有不同的运行结果。

我们先来看看罗汉堂的整体架构，如下图所示：

罗汉堂的管理中心由罗汉堂管理平台和任务执行器组成。管理平台主要完成组件及应用元数据的配置、部署等工作。任务执行器主要用来元数据解析、部署顺序计算及推送部署信息到客户内网。

罗汉堂的控制中心主要部署在客户内网环境，用于解决跨网通信的问题，同时可以接受管理端指令用于中间件注册及资源申请、部署等功能。

主要建设思路如下：

标准化：为了解决程序维护规范问题定出了一套完整的规范，规定了商业化部署中间件的范围、镜像必须和配置解耦、配置文件管理方式等。

应用自描述：让应用通过自描述，描述清楚程序的资源依赖、中间件依赖、配置文件信息等。

流程自动化：每次部署耗费大量的人力，我们尝试环境部署流程自动化，通过系统快速部署、持续改进。参考云原生应用OAM规范的关注点分离原则，让基础运维定义环境变量模版、研发修改配置管理环境变量、应用运维复杂环境配置，然后自动进行部署。

为了适配多环境运行，我们引入应用元数据和配置模版来解决不同环境配置的内容不一样的问题，为了实现资源自动初始化。我们尝试定义一种描述语言，在应用研发修改代码情况下让研发在不需要关注描述语言本身情况下，描述清楚应用的环境信息，主要描述信息有应用的作用、应用的资源依赖、应用的中间件依赖、应用的状态等。我们把应用元数据大概进行了抽象，则可以分为：

• 描述类：和页面打通后台新增后前台能直接显示；
• 配置类：主要是应用配置类信息，未来适配环境迁移，一般配置模版一般执行时对利用模版引擎对模版进行渲染然后同步到指定目录或者k8s环境变量；
• 资源类：主要配置资源信息，运行是需要初始化到信息，一般运行时会动态到调用API进行资源初始化；
• 任务类：初始化时需要执行任务，一般需要替换任务执行模版然后进行任务调用；
• 依赖类：主要用于依赖可视化展示和任务执行顺序依赖；限制：展示类到用户可以随便扩展，涉及执行类需要用户定制任务。

下图是数据库图形描述配置文件一个例子。

我们做了数据库资源组建用户根据提示添加资源申请信息和初始化脚本，应用编辑时会根据资源会生成数据库实例配置相关组件，MYSQL实例组件的ID关联配置文件替换配置文件VALUE就完成 后配置文件效果如下。

拖拽图形化编辑配置文件后配置文件就有了语意，MySQLDB_184 表示这个配置关联了MYSQL类型资源，并且资源ID是184，URL表示这个配置表示为MYSQL的链接。这样在解析配置文件时就能够初始化配置关联资源，并且把资源申请回来的URL动态的替换到配置文件。

在做配置文件描述设计时前期当时一直在讨论对配置文件的KEY进行描述，或者把配置文件VALUE指定一套标准让大家进行修改。但是考虑到如果对KEY进行描述相对结构比较复杂，如果对VALUE进行规范化改造会存在大量的修改，最终敲定按现在这种结构进行描述，这样可以在程序不改造情况下实现应用的快速描述。

使用管理中心，可以轻松的管理应用及快速进行部署环境管理及部署，如下图所示：

目前定义流程也是基于关注点分离去实现的。大概流程如下：

基础运维：通过拖拽的方式定制出中间件资源或者网络资源等。目前主要支持的定义组件类型大概有以下几种：

• 资源类型组件：主要是业务依赖部署环境相关存储资源，比如MYSQL组件，MYSQL组件主要描述MYSQL 表名及项目DML；
• 中间件类型组件：主要是业务依赖中间等相关资源；比如JSF组件，主要描述JSF的注册中心等信息；
• 部署类型组件：主要用来描述应用的容器相关信息，比如JDOS磁盘大小、CPU核数等。

业务研发：通过运维人员中间件，把应用依赖的资源、中间件等信息进行填写和关联到应用再到配置，从而形成镜像和应用元数据。

应用运维：部署时先部署TPAAS层，然后维护中间件相关资源进行部署。在新环境要部署应用，建立部署任务，生成部署计划描述文件。

任务执行器：在初始化资源时，依据应用中的元数据描述通过控制中心申请资源，并将申请的结果渲染到数据绑定的配置文件中；发布时，依据应用的描述计算应用间的依赖关系，确定部署应用的顺序，然后有序部署。部署完成自动完成从部署是否成功的校验，返回给前端。

在实际部署时，程序配置是各式各样的，预先图形化所有配置信息显然是不可能的。这时候我们采用平台本身通过拖拽方式生产出描述组件。如上图所示，组件生产人员可以在平台设计出不同描述的组件，然后研发在配置时可以利用组件描述自己的应用信息，研发在配置好环境变量推送配置时，执行任务会根据组件和组件配置的信息初始化所需要的资源和初始化环境配置。

在实践过程中，我们把组件大概抽象成了三层：1.展示层：我们采用JSON Schema方式进行描述，用JSON Schema的好处是通用学习成本低并且可以天然支持JSON Schema直接转换成HTML；2.业务逻辑层：在平台生产出业务组件后，前台就会进行展示，业务逻辑层需要解析出前台组件代表的业务含义，在前台拖拽组件时会给他们一个身份，这样在业务逻辑层解析组件时就会根据业务身份执行不同个性化组件；3.数据层：实际部署时需要人工或自动填充的内容。

一次性部署大量的应用，判断应用是否成功启动成为我们遇到的新挑战。前期判断标准比较暴力的，基本认为程序JSF注册成功、日志启动没有错误就算启动成功，但是在交付时我们发现部署质量存在一定问题。因此在自动判断程序启动成功做了尝试。

业界比较通行的做法是使用Probe探针来判断应用是否启动成功。基本实现方式是通过kubelet调用容器Handler（处理程序）。一般有三种类型：容器内执行指定的命令、在对应的IP地址上指定的端口做TCP检查（如果端口打开则认为是成功的）、对容器IP上指定端口和路径进行Http Get请求（如果状态码大于200且小于400，则诊断被认为是成功的）。

Probe判断基本执行范围是程序之外的，在实际应用判断是否启动成功时一般我们也会检查程序依赖的中间件或等相关链接状态。所以中间件和资源的描述信息也为程序启动状态校验提供了必要的信息。假如程序依赖MYSQL，在判断到docker启动成功后，我们会进一步去验证docker与MYSQL是否成功建立连接。

 目前增加判断类型有：

云原生的普及在很大程度上推动了基础设施即代码的实现，用户通过YAML文件描述资源，然后推送到K8S进行执行。但是对于研发和交付来说，YAML文件也有一定的学习成本。所以在设计时借鉴OAM相关理念，基于低代码方式来实现资源的描述，后期解析描述文件调用JDOS接口进行部署，如果需要到其它云平台执行可以把描述文件转换成YAML。

罗汉堂项目已经在交易研发部试用，在部署POC项目中第一次尝试关注点分离部署方式，在相关业务研发不参与部署前提下4个罗汉堂平台研发负责交易全部应用部署，耗时一周全部部署完成。从目前的试用结果看，与部署POC正式环境相比，在部署周期小幅提升的基础上，人员成本降低了80%。随着未来罗汉堂系统成熟和业务研发成本边际递减，未来成本会持续下降，部署效率会大幅提升。

资源评估方案：能够根据用户可视化功能模块的选择和业务量自动计算依赖应用，中间件和中间件的资源量，为商业系统定价、部署提供数据预告支持。

商业化一键验收工具：尝试整合罗汉堂和京东内部自动化测试工具，建设商业化项目自动化验收能力，以减少现在商业化环境验收时联调和测试成本，同时提供一键标准化验收能力。

丰富中间件范围：目前罗汉堂快速部署能力是基于京东T-PaaS层进行建设的，未来在商业化部署中为了减少商业化成本、适应不同的业务场景，还会尝试开源和商业化中间件及云平台进行打通。

作者：交易研发部李坤然