云原生12要素
云原生十二要素是由Heroku创始人AdamWiggins首次提出并开源，并由众多经验丰富的开发者共同完善，这综合了他们关于SaaS应用几乎所有的经验和智慧，是开发此类应用的理想实践标准。
1.基准代码
每个可部署app在版本控制系统中都有一个独立的代码库，可以在不同的环境中部署多个实例。
2.依赖
App应该使用适当的工具（如Maven、Bundler、NPM）来对依赖进行显式的声明，而不该在部署环境中隐式的实现依赖。
3.配置
配置或其他随发布环境（如部署、staging、生产）而变更的部分应当作为操作系统级的环境变量注入。
4.后端服务
后端服务，例如数据库、消息代理应视为附加资源，并在所有环境中同等看待。
5.构建、发布、运行
构建一个可部署的app组件并将它与配置绑定，根据这个组件/配置的组合来启动一个或者多个进程，这两个阶段是严格分离的。
6.进程
一个或者多个无状态进程之间不需要共享任何状态信息。任何需要的状态都置于后端服务（例如cache、对象存储等）。
7.端口绑定
该应用程序是独立的，并通过端口绑定（包括HTTP、负载均衡）导出任何/所有服务。
8.并发
并发通常通过水平扩展应用程序进程来实现。
9.易处理
通过快速启动和优雅的终止进程，可以最大程度上的实现鲁棒性。这些方面允许快速弹性缩放、部署更改和从崩溃中恢复。
10.开发/生产等价
通过保持开发环境、测试环境和生产环境尽可能的相同来实现持续交付和部署。
11.日志
不管理日志文件，将日志视为事件流，允许执行环境通过集中式服务收集、聚合、索引和分析事件。
12.管理进程
行政或管理类任务（如数据库迁移），应该在与app长期运行的相同的环境中一次性完成。
技术中台基于十二要素的实践
1.基准代码
作为云原生十二要素的第一条，基准代码首先指明了云原生模式下的开发原则，而用友技术中台无论是自身的架构设计还是帮助企业构建企业业务开发上都是以该设计原则为基准。核心要素有以下几点：
首先使用代码仓库进行应用代码的统一管理，这个要求是基础的，它使得开发的代码可以通过代码仓库管理对应的版本。在用友技术中台中应用在构建过程中，可以为每个应用开发配置对应的git代码仓库，让应用开发和代码仓库管理有效的连接起来。
除git代码仓库，用友技术中台支持dockerfile的应用构建方式，这样使得企业在代码仓库的选择上可以多元化，几乎可以支持linux下的所有代码仓库。
再次要做到一份基准代码对应一个应用。如果一份基准代码可以编译出多个应用，那么说明多个应用的代码是揉在一起的，应该考虑将基准代码进行拆分，这也是微服务的设计原则的体现之一。在用友技术中台的每个应用组件也是保证一份代码对应单一的组件应用，每个组件的关系拓扑如图所示：
最后的要点是一份基准代码可以多份部署，这也是容器所倡导的一次构建在任何地方可以运行的要素之一。在用友技术中台中应用的基准代码会以流水线的形式保存起来，每个流水线有对应的版本，使用者可以根据对应的流水线发布到多个资源池环境和主机上。这样可以让使用者在维护好流水线版本的同时，让一份基准代码部署到多个环境，并且保证基准代码的唯一性。
2.依赖
在不使用云原生的情况下，如果出现软件应用的依赖性问题，我们可以通过手动进行处理，比如手动安装一下依赖库等。但是在云原生环境下，往往每天都伴随大量的构建和发布工作，所维护的应用也越来越多。这种手动处理的方式已经无法解决这类问题。而使用容器技术可以解决上述的环境依赖问题。通过显示声明依赖关系，在dockerfile中将应用和依赖打包成容器镜像，在用友技术中台中，它的底层核心就是容器技术，在技术中台中发布的应用也是容器化的，我们可以通过在构建的时候使用dockerfile来声明应用的依赖关系。
在dockerfile中可以声明基础操作系统镜像，而RUN的每个层可以是应用运行的对应依赖关系，同时也可以是依赖的环境变量等。
3.配置
有些时候开发者往往把代码和配置文件放置一起，这样会导致一些问题，比如配置文件得敏感信息像密码、证书等会被泄露，也不利于代码在多套环境的区分。随着配置文件的越来越多，需要一个统一管理环境配置的功能模块，在用友技术中台中有单独的配置管理模块，方便使用者管理应用的相关配置。
使用者可以在构建应用的时候提取出应用的配置信息，并且可以更改配置，在应用部署的时候启用配置。
4.后端服务
对于云原生应用来说，在使用像数据库、缓存系统和日志收集等后端服务时，不建议将这些后端服务放到应用本地使用，因为云原生应用本身要求是无状态化的，这样就要求后端服务不应该放在应用本地。在用友技术中台中应用可以通过添加变量的方式，配置后端服务，通过这种方式可以使得应用可以横向扩展，实现容器应用的可靠性和扩展性。
5.构建、发布、运行
在用友技术中台中构建、发布、运行主要通过流水线模块实现，本次构建的数据和历史信息都会保存在系统中，而且构建出来的容器镜像具有唯一的tag标识，发布的唯一性可以具有溯源性并且可以在出现故障时通过标识进行回滚操作。
在持续集成和持续步骤中，技术中台将每个环节串连在流水线配置中。CI的英文名称是Continuous Integration，中文翻译为持续集成。CI中，开发人员将会频繁地向主干提交代码，这些新提交的代码在最终合并到主干前，需要经过编译和自动化测试流进行验证。CD可对应多个英文名称，持续交付Continuous Delivery和持续部署Continuous Deployment。在持续交付中，每个阶段（从代码更改的合并，到生产就绪型构建版本的交付）都涉及测试自动化和代码发布自动化。在流程结束时，运维团队可以快速、轻松地将应用部署到生产环境中或发布给最终使用的用户。技术中台CI/CD的运行效果如下：
6.进程
作为无状态进程就要求应用进程的内部不要保存状态信息，而这些进程的状态信息应该保存在数据库和分布式缓存系统中。在用友技术中台中，每个容器应用的状态信息都通过kubernetes进行维护，管理端通过kubernetes提供的的API进行调取应用进程的状态信息，而应用进程的状态信息会保存在kubernetes的etcd中。这样避免应用数据的直接共享的模式，方便应用的横向扩展和解决串行的单点问题。
7.端口绑定
在云原生模式下，每个应用都应该可以独立绑定对应的端口。因为在云原生模式下，每个应用都会经历多次的重新部署、重启和横向扩展的操作，而面对这些操作容器应用的对外的URL地址应该保存不变。例如在用友技术中台中，每个应用都有独立的负责均衡配置，它是不变的伴随着应用的整个生命周期。
同时在每个应用的属性标签中，可以为每个容器应用绑定应用端口，它支持USER模式和HOST模式两种方式，同时支持TCP和HTTP两种协议类型。
8.并发
在云原生模式下，这里指的并发更多说的是应用进程的横向扩展能力，当业务访问压力增大的时候，可以实现应用的快速水平扩展。在用友技术中台中，对应容器应用不但可以实现手动的方式指定实例个数完成应用进程的快速扩缩，也通过自动扩缩来让技术中台自动化完成扩缩任务。
开启自动扩缩模块，技术中台会根据应用实例的实时应用负载水平判断实例的扩缩个数。
9.易处理
在云原生模式下，易处理主要说的是应用的快速启动和优雅终止，通过应用的快速启动和停止，实现业务应用的快速恢复和在故障后的重新部署，是系统集群健壮性的体现之一。在用友技术中台中，每个应用是独立的一个容器，而容器技术的一个重要特性就是可以实现应用进程的快速启动和停止。同时技术中台也可以操作每个容器应用的重启或销毁的生命状态。
10.开发/生产等价
在云原生模式中，开发和生产环境的等价要求环境的一致性，这样可以尽可能的避免由于环境不一致导致的一些生产环境的问题。尽量的缩小开发环境和生产环境的差异，可以使得在云原生环境下每天可以进行成百上千次的构建任务和发布任务，避免差异性导致的诸多问题。同时这个原则要求开发者不能只关心开发环境的自己的代码，更要密切关注线上环境代码的运行状态，这个也是企业DevOps文化的重要意义。
在技术中台中，每个应用构建的操作在流水线中执行，而由于容器镜像的一致性可以使得无论是开发环境还是生产环境是等价的。同时在开发环境中的容器镜像可以通过推送镜像的方式直接发布到生产环境。
11.日志
在云原生设计中要求应用日志应当作为事件流来处理，允许执行环境通过集中式服务收集、聚合、索引和分析事件。不建议将日志文件直接输出到本地文件，而应该以事件流的形式输出到标准输出STDOUT和标准错误输入STDERR，然后进行捕获事件流并转发到相关分布式日志处理系统中。
在用友技术中台中的日志处理过程可以理解为日志生命周期的治理过程，分别为产生、收集、存储、处理、销毁这些过程。
根据云原生日志设计原则，在技术中台中每个容器应用可以将日志的标准输出STDOUT和标准错误输入STDERR传输给收集端，通过data-log组件收集，具体实现如下：
日志与事件：可以在容器应用的日志与事件选项卡中查询对应日志信息。
实时日志和历史日志：可以分别对实时日志、历史日志两个维度来查看应用日志信息。
关键词检索功能：可以通过输入关键字按照自己需要检索对应的日志信息。
系统事件：可以在系统事件选项卡中查看容器docker在主机上的运行状态比如：容器的启动、停止、pod创建、pod杀掉、镜像拉取等。
人员操作：可以在人员操作选项卡中查看平台用户对该容器应用的操作，比如应用重启，实例扩缩、实例强杀等操作。
汇总应用日志功能：可以通过选择对应产品线和产品同时选择多个应用进行查询对应的日志信息。
查询历史日志信息：可以通过不同的开始时间和结束时间选择对应时间段内所记录的日志信息。
关键词检索功能：可以通过输入关键字按照自己需要检索对应的日志信息。
12.进程管理
在云原生十二要素中关于进程的管理方式不建议直接通过SSH方式，而开发者经常会执行一些管理或维护应用的计划任务，比如数据库管理员需要定期执行SQL更新。在用友技术中台可以将数据库的SQL更新操作放置在流水线执行，如下所示：
将SQL命令通过git代码仓库进行版本管理，让使用者通过技术中台流水线的能力执行更新SQL的操作，同时可以设置定时执行的策略来触发流水线更新。
并且配合技术中台配置文件的管理功能，将更新脚本写入配置文件中，方便使用者的更新脚本的变更。
云原生架构下给企业带来的优势
可以看到用友根据云原生十二要素理论打造出技术中台，通过技术中台可以帮助企业快速拥抱云原生，通过企业云原生的技术体系落实，优化自身业务系统，可以更加快速的创新和低成本试错，给整体架构能力带来极致弹性，从而更好的服务于业务。
