wydevops——微服务直上K8S云就是这么简单（续1）

        前一篇文章《wydevops——微服务直上K8S云就是这么简单》介绍了wydevops本地工作模式下，直接从源码直接发布到K8S集群的整个流程，大多数都是配置环境搭建的描述，对样例项目的配置主要集中在部署阶段（显然的，需要配置好目标集群的信息），其他内容比较少。有了前面文章对环境搭建的说明，从本文开始会逐步开始向你展现wydevops的强大功能。

 特别说明：

a. 本地工作模式下，无仓库环境的情况下，如果目标K8S集群配置了docker镜像仓库（deploy[0].k8s.dockerRepo参数），也可以支持微服务K8S部署模式。这里是对前文中无仓库环境下只能按docker方式部署的描述作一个补充说明。

b. wydevops内部会用到helm工具，helm的安装由wydevops完成，会检测本地机器的系统和架构来安装对应的helm工具。所以前面说明配置环境时没有提这点。

c. wydevops是本人根据自己带团队和遇到的实际项目的情况独立开发的，全部代码均为原创，其内部独创的yaml文件读写驱动组件、三级管理模型和扩展机制、调用链机制、资源生成器插件机制、全Shell实现等核心技术和特点使得本开源项目在架构设计、功能实现、易扩展、易集成等方面都具备独特的魅力，全网唯一（wy）。目前版本是1.0.0。由于涉及的细节功能测试存在遗漏，目前基本每天都会有更新，请大家在试用时先更新wydevops源码。

c. wydevops的目标是减少普通开发人员在K8S集群中发布服务的难度，尽量让专业的人作专业的事情，提升整个团队的生产力，持续改进，不断敏捷！同时，wydevops允许自定义helm打包目录，为专业人员提供了按自己需要定义helm包中内容的能力。这种情况下，wydevops可以看成一个标准流程工具，不涉及内容。docker构建也如是。

d. 本人微信号：wpl87654, 欢迎联系。

   好了，针对前文末尾留下的问题，我会分多篇文章进行逐一讲解。

1. 多语言项目的兼容性讨论

    要将微服务部署到K8S集群中，需要知道该服务如下内容：

• 服务的名称和版本
• 服务开放了哪些端口？每个端口的开放类型是NodePort还是ClusterIP（默认）？
• 服务的网关路由是什么？
• 该服务运行需要哪些配置文件？这些文件存放的路径是哪里(涉及dockerfile文件内容和ConfigMap资源文件的生成）？
• 上述配置文件中有哪些业务参数？这些参数的默认值是多少？发布时的设定值是多少？
• 该服务需要额外挂载的ConfigMap的名称，以及其内的文件有哪些？（wydevops默认情况下会为服务创建一个内置所有配置文件的ConfigMap资源文件）
• 服务需要的CPU和内存额度是多少，限额是多少？
• 服务是否需要打开探活和就绪探针，参数是如何的？
• 该服务是否需要持久化存储？（高级配置，不推荐某个服务自己创建持久化存储相关配置，可由公司提供统一的公共的持久化配置）
• 服务的水平扩展性配置规则是如何的？（高级）
• 服务的节点亲和性和驱逐策略是如何的？（高级）

     绝大多数的服务只需要提供上述信息即可完成K8S集群部署。wydevops完成的工作就是：

• 参数获取：从项目源码的配置文件或wydevops提供给开放人员的配置文件中获取上述信息
• 完成项目编译
• 生成docker镜像
• 生成chart镜像
• 最后使用helm工具打包部署到目标K8S集群中（docker部署方式只是整个流程的一个简略版本）。

       讨论到这里可以看到，不同开发语言的项目在整个流程中只有参数获取和编译过程才与具体项目的开发语言具备相关性。如果我们设计好这两个过程，使之能兼容或者通过统一的配置适应不同语言的项目，那么就解耦了整个流程和项目开发语言的相关性。wydevops就是在这样的指导思想下实现了它的开发语言无关性。所有可能存在语言差异性的地方，通过特有的三层扩展机制wydevops为这些差异点提供了提供兼容和扩展的能力。每个差异点都可以有默认实现（公共实现，面向公司层面）、语言级实现（面向某类开发语言组）、项目级（面向具体项目）实现。项目级扩展实现的代码随源码一起进行版本管理。其他两类扩展随wydevops源码一起进行版本管理。这充分体现了wydevops的开放性和扩展性。

        理论就讲到这里，下面结合java-sample项目源码来看看，wydevops在参数获取和项目编译阶段是怎么实现的？

2. wydevops项目参数获取机制

      最简单的办法就是提供一个参数配置模板，让开发人员去填写。但仅仅这点还达不到wydevops对敏捷的追求。wydevops希望普通开发人员不需要去关心这些参数怎么设置的，wydevops希望对某类开发语言项目定义好一些的规则（比如：项目结构规则、配置文件存储目录规则等），wydevops可便捷的遵循这些规则实现项目从源码到部署的（开发人员无感知的）处理流程。

2.1 参数映射文件介绍      

       我们打开wydevops源码中的：/script/templates/config/java/param-mapping/params-mapping-in-yaml-file.config这个文件（param-mapping文件夹中存放的都是*.config类型的文件，文件名称无特殊规定，后缀名称必须是config），内容如下图：

        图中重要参数说明如下：

define.exitOnError="false"

释义：从给定的源文件读取参数出错时是否报错退出。

define.bindingFiles|true="./src/main/resources/config/application-prod.yml,./src/main/resources/config/application.yml"

释义：定义下面参数的来源文件，后缀的true是附加说明：这些参数来源文件需要放置到ConfigMap文件中。true的后面再加一个竖杠, 例如：...|true|test-hello,这样可以指定ConfigMap的名称。如果没有这个附加配置，则wydevops会将这些参数文件存放到每个项目默认配置的ConfigMap中，其名称格式为：{项目名称}—configmap。注意：该配置的值中指定了该java项目配置文件的存放路径和文件名称（这个就是在团队中约定的Java项目配置文件存储路径和配置文件名称规则），优先级高的文件放置在前面，文件名称间采用逗号分隔。

前述两个控制参数后面的都是业务参数，这些业务参数不需要指定具体在哪个文件中：

url-prefix="globalParams.gatewayPath|/\${serviceName}"

       释义：从上述bindingFiles参数给定的文件中读取url-prefix参数的值,并赋值给wydevops为Java语言项目提供的配置模板文件(_ci-cd-template.yaml, 与param-mapping目录同级)中的globalParams.gatewayPath参数，如果url-prefix的参数值是空的则默认使用"\${serviceName}"填充。注意：$前要加上”\“。如果参数url-prefix参数在来源文件中不存在则遵循define.exitOnError参数的值决定是否报错退出（这里是不退出）。如果url-prefix参数后面存在"|true"，则所有源文件中都不存在"|"时会报错退出（这是为具体参数提供的优先级更高的exitOnError参数值），如下面的:

server.port|true="globalParams.mainPort|8080;globalParams.containerPorts|8080;globalParams.servicePorts|8080"

      释义：server.port参数如果在所有源文件中都不存在则报错退出。如果server.port参数读取成功，则分别赋值给（等号右边的，分号隔开）配置模板文件_ci-cd-template.yaml中的globalParams.mainPort、globalParams.containerPorts、globalParams.servicePorts三个参数。如果server.port为空的，则各参数使用后缀的默认值（竖杠隔开，这里都是8080）。这个参数是Java项目开放的访问端口参数。

management.endpoints.web.exposure.include=*;management.endpoints.enabled-by-default="globalParams.livenessProbeEnable|false;globalParams.readinessProbeEnable|false"

释义：如果 management.endpoints.web.exposure.include=*的前提下，从来源文件中读取management.endpoints.enabled-by-default的值，赋值给配置模板文件_ci-cd-template.yaml中的globalParams.livenessProbeEnable和globalParams.readinessProbeEnable参数。如果management.endpoints.enabled-by-default的值为空，则使用各参数后缀的默认值填充。这两个目标参数是是否开放服务的探活和就绪探针的控制参数。

特别说明：所有的目标参数只能被赋值一次，后续赋值将被丢弃。

再打开/script/templates/config/java/param-mapping/params-mapping-in-xml-file.config文件，内容如下图：

这个配置文件定义的是从java项目的pom.xml文件中读取参数，来初始化配置模板文件_ci-cd-template.yaml。根据前面的说明，我们知道：pom.xml文件不需要放置到ConfigMap中。这里截取了java-sample项目中pom.xml文件的部分内容（不需要明白这个文件是作什么用的，只需要知道这是从xml格式的文件获取wydevops需要的参数的样例。wydevops采用xmllint解析xml），如下：

大家可自行参照上一个文件的说明，尝试理解这个文件各个配置的意思。这里补充说明两点：

• 这个xml配置文件为大家展示了一种自定义参数的能力。举例说明：

pom.xml文件中的cicdName参数是个自定义的参数（熟悉maven pom.xml文件的人应该知道），根据params-mapping-in-xml-file.config文件中的配置，我们知道该参数值（唯一DevOps）被赋值给了配置模板文件_ci-cd-template.yaml中的globalParams.name参数。各类语言的开发团队可在项目中合适的yaml文件或xml文件中预定义这些参数并在语言级参数映射关系配置文件中完成绑定，即可将这些参数的值传递到wydevops标准的模板文件中。这就是普通开发人员可不需要过多配置即可完成从源码直上K8S集群的关键所在。

• 参数读取方式设置

project.properties.cicdName|false|1

上述参数后缀中有一个“1”,这个1是参数读取模式值。1表示：内容中存在中文，需要采用支持读取模式为1的方法进行读取。

2.2  参数文件解析器（map-loader.sh）

        wydevops源码中/script/helper/map-loader.sh就是上述参数映射文件的规则解析器。大家有兴趣的话可以去读源码，这里借助参数读取方式的说明，向大家简单介绍一下wydevops源码中大量使用的调用链机制。

        如下图，map-loader.sh文件中调用_readParamValueEx本地方法，从来源文件中读取参数值。

在_readParamValueEx方法中，循环从define.bindingFiles参数指定的文件列表中，依次查找并读取目标参数的值。实际读取值的第二个红框中的invokeExtendChain方法完成的。该方法启动了一次对扩展调用链的调用过程（扩展调用链是多个具备类似功能的方法的有序集合，这个调用链机制是wydevops自行设计）。

invokeExtendChain方法的第一个参数指定了调用链的名称。依据这个名称，我们可以在wydevops源码的/script/pipeline-stages/chain目录中快速定位到onReadParamValueFromFile.sh脚本文件。

该脚本文件内容如下：

这个文件中有三个以onReadParamValueFromFile开头的方法，这三个方法会被调用链管理器（extend-chain-manager.sh）从上到下依次调用，直至返回"true|"开头的值（如上图，gDefaultRetValue="true|..."，特别说明：wydevops源码中所有方法的返回值均放置在全局变量gDefaultRetValue中的)。从上图可以看到，第一个方法支持的是从后缀名为yaml或yml的文件中读取参数,第二个方法支持的是从xml文件中读取参数值，第三个方法支持的是从ini文件中读取参数的值（暂未实现）。第二个方法中因要适配不同的读取模式，再次调用了名为"onReadParamValueFromXmlFile"的扩展调用链（内容截图如下）。在这个调用链中有两个方法，第一个方法是读取英文参数值的，第二个方法就是支持读取模式为1的方法，最终执行的就是这个方法。

3.  wydevops核心机制（写到这里，感觉有必要说明一下了）

扩展调用链是基于适配器模式思想设计的，非常方便用来扩展某个功能的不同实现。wydevops中实现了三个这样类型的机制: 三级功能扩展机制、扩展调用链机制、资源生成器插件机制。下图是扩展调用链的源码目录，extend-chain-manager.sh是扩展调用链管理器，由它负责发现、组装和调用各种链中的方法。

下图是资源生成器插件源码目录，plugin-manager.sh是插件管理器，由它组装和调用各类插件。

t

三级功能扩展机制的核心调度方法在global-params.sh文件中，方法名为：invokeExtendPointFunc

其扩展点实现分为三级：公共级（面向公司技术管理层）、语言级（面向某类语言开发组）、项目级（面向具体项目开发人员）。前两级的代码在wydevops源码中，下图红框部分的文件和目录：

公共级功能扩展点源码都存放在上图common目录中，其扩展方法名称规则：{扩展名称}_ex。

语言级功能扩展点源码都存放在各语言命名的目录中，其扩展方法名称规则：_{扩展名称}_ex。语言级扩展文件内容如下图：

最后一级的源码在项目的wydevops/shell目录中，前两级都是通过方法实现的，最后这一级是一个shell文件，文件命名规则：{扩展名称}.sh

        三级功能扩展点调用顺序是: 公共级->语言级->项目级。以chart阶段主流程的调用为例子，见下图中红框部分都是不同功能扩展点的调用：

        在wydevops启动时会自动完成插件和调用链的发现、注册（组装）过程。如下图所示：

最后说明一下：

• 调用链只能实现在wydevops源码中。
• 资源生成器插件支持项目级自定义插件，项目级插件存放在项目wydevops/plugins目录中，wydevops启动时会自动扫描和加载这个目录中实现的插件。
• 功能扩展点第三级可以项目中实现  。
• 可在项目中wydevops/param-mapping目录下创建*.config类型的文件，定义或覆盖wydevops源码中对某个目标参数定义的参数映射配置。  

      总结一下，今天这篇文章主要向大家介绍了wydevops参数映射机制，这个映射机制只根文件类型相关，与语言无关，其他语言的项目可参照编写适合自己语言的参数映射文件。同时以此为引向大家介绍了wydevops的核心机制和部分规则，便于大家理解wydevops的运行机制，提升对后续文章内容的理解能力，也从从源码层面上说明了一下wydevops源码的大致组成结构。后续文章会继续回归到具体功能实现的配置说明上。

       想写的很多，但时间有限。今天就写到这里吧。上述核心机制能得以实现的基石是wydevops特有的yaml文件读写驱动组件：yaml-helper.sh。借助它的强大功能，在以yaml文件格式为主的k8s生态圈中，wydevops大有可为！