不可变基础设施
12 因素：https://12factor.net/zh_cn/
12 因素基准代码：基准代码和应用之间总是保持一一对应的关系：
一旦有多个基准代码，就不能称为一个应用，而是一个分布式系统。分布式系统中的每一个组件都是一个应用，每一个应用可以分别使用 12因素 进行开发
多个应用共享一份基准代码是有悖于 12因素 原则的。解决方案就是将共享的代码拆分为独立的类库，然后使用 依赖管理 策略去加载它们
显示声明依赖
配置：推荐将配置保存于环境变量中
把后端服务当作附加资源
严格分享构建和运行
以一个或多个无状态进程运行应用
通过端口绑定提供服务：12因素 应用完全自我加载，而不依赖于任何网络服务就可以创建一个面向网络的服务。互联网应用通过端口绑定来提供服务，并监听发送至该端口的请求
通过进程模型进行扩展
快速启动和优雅终止可最大化健壮性
尽可能的保持开发，预发布，线上环境相同
把日志当作事件流
后台管理任务当作一次性进程运行
云原生 VS 微服务云原生方案与微服务架构类似
然而，尽管微服务可通过构建云原生应用来交付，可企业仍需要采取许多措施，才能在生产环境中熟练地管理微服务
而想要享受云原生应用的各种益处，也并非一定需要微服务
很多企业都通过基于相同的原则，构建出更优秀的模块化单体式应用，从而取得云原生方案的种种效益
1.3.4 技术中台
本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
欢迎转载、使用、重新发布，但务必保留文章署名 郑子铭 （包含链接： ），不得用于商业目的，基于本文修改后的作品务必以相同的许可发布。
如有任何疑问，请与我联系 (MingsonZheng@outlook.com) 。