关于微服务应⽤的原则，可以参考⼀个12要素原则，下⾯就简单介绍⼀下其内容。
1. “12要素”原则简介
android电视
“12要素”英⽂全称是The Twelve-Factor App，来源于Heroku平台的实践。Heroku平台创始⼈Adam Wiggins汇总了这些实践经验，发布了⼀个“⼗⼆要素应⽤宣⾔（The Twelve-Factor App）”。英⽂原版地址：www.12factor/。
如今的软件产品通常都会采⽤服务⽅式进⾏交付，其总结有如下六点内容：
使⽤标准化流程⾃动配置，从⽽使新的开发者花费最少的学习成本加⼊这个项⽬。
和操作系统之间尽可能的划清界限，在各个系统中提供最⼤的可移植性。
适合部署在现代的云计算平台，从⽽在服务器和系统管理⽅⾯节省资源。 将开发环境和⽣产环境的差异降⾄最低，并使⽤持续交付实施敏捷开发。 可以在⼯具、架构和开发流程不发⽣明显变化的前提下实现扩展。
适⽤于任意语⾔和后端服务如数据库、消息队列、缓存等开发的应⽤程序。
“⼗⼆要素应⽤宣⾔”这套理论适⽤于任意语⾔和后端服务应⽤程序，同样也可以作为微服务应⽤的参考⽅法论。微服务应⽤的特征就是需要遵循⼀套设计契约，同时微服务应⽤所⾯临的⾼⾃动化、容器驱动型、基础设施管理等环境也对编写⽅式提出了要求。微服务开发⼈员必须改变⾃⼰的编程习惯来满⾜⾃动化、容器和基础设施管理的要求。这需要在开发运维⼈员与微服务应⽤之间创建出⼀套⽤于指导应⽤程序运⾏的新型“契约”。这套理想的“契约”机制⼤部分就存在于“应⽤⼗⼆要素”中所提出的基本原则中，其内容包括：（1）基准代码；（2）依赖；（3）配置；（4）后端服务；（5）构建、发布、运⾏；（6）进程；（7）端⼝绑定；（8）并发；（9）易处理；（10）环境等价；（11）⽇志；（12）管理进程等12项。
下⾯就微服务应⽤与“⼗⼆要素应⽤宣⾔”之间的关系做⼀个适应性分析。
2. 微服务应⽤的“12要素”原则
2.1 基准代码
基本含义，⼀份基准代码（Codebase），多份部署（deploy）。
橙子剥皮机
该要素原则体现到微服务应⽤有三点实践：
微服务基准代码和微服务应⽤之间总是保持⼀对⼀关系。微服务应⽤和微服务部署实例是⼀对多关系。微服务基准代码是以代码⽅式存在，⽽微服务应⽤是以⼆进制程序⽅式存在，⽽微服务应⽤部署实例是以运⾏实例⽅式存在。
对于微服务应⽤程序的源码管理，必须要有统⼀的版本控制中⼼。这样可以实现在版本控制代码库中追踪每⼀个部署的微服务应⽤。
部署的环境性质多种多样，如应⽤环境，有开发环境、测试环境、⽣产环境等，也有某种环境的多个介质，如容器、虚拟机、硬件上等。运⾏环境和配置参数有较⼤差别，但是程序源码只有⼀份基准的版本。
2.2. 依赖
基本含义，显式声明依赖关系。
该要素原则体现到微服务应⽤有三点实践：
对于每个微服务，要声明所依赖的编译包和运⾏包清单，便于构建⼯具能很正确地构造微服务应⽤，例如Maven的l⽂件、Gradle的adle⽂件。这是编译和构造过程的显式声明依赖关系。
微服务应⽤可以很清晰地表明对部署环境公开和隔绝依赖性的信息，⽽不是模糊地对部署环境产⽣依赖性。这种关系可以通过⼯具来声明实现。在容器环境中，可采⽤DockerFile来声明；在⾮集成环境中，可使⽤配置管理⼯具（Chef，Puppet，RunDeck）来显式声明服务之间依赖关系。这是安装部署的显式声明依赖关系。
业务微服务之间也要明确相互之间的依赖关系，可以通过⼀些服务编制和服务编排相关框架平台来实现。这是业务层⾯上的显式依赖关系。
2.3. 配置
基本含义，在环境中存储配置。
该要素原则体现到微服务应⽤有四点实践：
微服务应⽤的代码分为两类。⼀类是程序源码，⼀类是配置代码。任何部署之间的差异都可以视为配置编码类。微服务应⽤的配置代码存储在环境中，⽽不是将其提交到存储库。严格区分程序源码和配置代码的产⽣机制和管理机制。
根据不同的环境配置信息和配置代码，微服务应⽤的实例运⾏在不同的环境中，环境的配置编程代码也归属为配置信息。
微服务应⽤环境配置开发基于⾮版本模式，采⽤附加⽂件模式加载到微服务应⽤程序中。⽽微服务应⽤的程序源码必须进⼊版本控制，见第⼀要素原则基准代码。
汽车水箱除垢剂在微服务应⽤的程序源码避免使⽤与环境信息关联的硬编码。
微服务开发和交付分为两个完全隔离的阶段和环境。开发阶段编写基准代码，交付阶段负责管理环境变量。
2.4. 后端服务
基本含义，把后端服务当作附加资源。
该要素原则体现到微服务应⽤有四点实践：
微服务组件依赖的服务都归属为依赖资源，依赖资源包括后端服务、第三⽅服务，甚⾄是其他微服务。后端服务包括且不限于数据库服务、消息/队列、缓冲服务、⽬录服务、邮件服务、数据存储服务等。
微服务所依赖的资源都是完全可移植的，并且可以松散地耦合地整合其他类似资源。
微服务组件内部不应该具有依赖资源的功能，如果有这⽅⾯的需要，通过接⼝引⽤外部的依赖资源来实现资源重⽤，但容错、容灾和备份等特殊要求除外。
微服务组件只关注内部微服务的实现，同时仅需要了解外部资源提供的接⼝，⽽不⽤详细了解外部依赖资源的具体实现。
2.5. 构建、发布、运⾏
光标跟随基本含义，严格分离构建和运⾏。
该要素原则体现到微服务应⽤有三点实践：
微服务应⽤严格区分构建、发布、运⾏这3个阶段。其明确的区别在于，构建阶段就是微服务应⽤就是通过⾃动或⼿动⽅式，把微服务源码形成微服务组件（可独⽴运⾏的⼆进制程序）。发布阶段是把微服务组件放置到对应的发布库（如容器镜像）上，提供给外部运⾏环境来下载。运⾏阶段把微服务组件部署到对应的运⾏环境中。
使⽤持续集成/持续交付（CI / CD）⼯具来⾃动构建、发布和运⾏三个阶段的⼯作。例如，容器镜像可以轻松分离构建和发布阶段。理想情况下，微服务源码每次被编译形成组件后，提交到容器镜像，并被视为发布⼯作。同时，每次从容器镜像获取微服务组件并移植到运⾏环境中，都视为部署⼯作。
这⼏个过程与容器的Build-Ship-Run阶段完全吻合。
三个阶段持续运⾏过程中，前⼀个阶段的任何⼀点改动，都认为是微服务应⽤的整体改变，需要重新确定新的、唯⼀的版本发布ID。
2.6. 进程
基本含义，以⼀个或多个⽆状态进程运⾏应⽤。
该要素原则体现到微服务应⽤有三点实践：
FOSY
微服务最好地⽆状态且共享的，任何有状态的服务信息都持久化到后端服务中（如缓存、对象存储、关系数据存储等）。这样可以实现随意启动和⽴刻停⽌微服务，也不会有数据丢失的情况发⽣。
由于服务⽆状态，可以通过简单地添加更多⽆状态的服务实例来轻松扩展微服务。将任何有状态的数据或需要在实例之间共享的数据都存储在后端服务中。
微服务组件在设计时就必须按照随时随地会失败或者宕掉来设计。这种设计可以实现微服务进程会被随时拉起或消失，特别是在弹性扩容阶段。
2.7. 端⼝绑定
基本含义，通过端⼝绑定提供服务。
该要素原则体现到微服务应⽤有三点实践：
微服务⾃带运⾏容器，⾃我加载⽽不依赖于任何外部软件就可以启动⼀个⾯向⼤众的服务。
微服务通过端⼝提供的服务。不同的端⼝绑定不同⽀持请求协议（包括HTTP、RPC、XMPP、Redis 协议等），监听所有发送⾄该端⼝的请求。
微服务统⼀通过暴露端⼝来提供服务，尽量避免通过本地⽂件或进程来通信，每种端⼝服务通过服务发现机制⽽对外提供服务。
2.8. 并发
基本含义，通过进程模型进⾏扩展。
该要素原则体现到微服务应⽤有三点实践：
微服务架构借鉴Unix进程模型实现。虽然微服务应⽤本⾝只是⼀个进程，但可以根据业务分⽀来开启多个线程以分散进程瓶颈。
对于同⼀服务功能，可以对应启动多个微服务实例，这样可以实现⽔平扩展。
通过添加⽆状态进程实现横向扩展。
2.9. 易处理
基本含义，快速启动和优雅终⽌可最⼤化健壮性。
该要素原则体现到微服务应⽤有三点实践：
微服务启动时可以同时并发多个线程，采⽤懒加载⽅式，这样实现快速启动。
微服务终⽌是检查所有资源都是否销毁，所有监听都要关闭，释放所有的资源，最后什么也不留下地离开。
当⾮正常结束时，微服务⾃动恢复到默认状态上。
2.10. 环境等价
基本含义，尽可能的保持开发、预发布、线上环境相同。
该要素原则体现到微服务应⽤有四点实践：
保持微服务的研发、测试和⽣产环境尽可能相似，这样可以保证微服务应⽤的⾼质量，持续发布和持续部署。
通过容器部署⽅式来实现微服务的版本化，通过适配器来保证各个不同环境的差异性，同时还能⼤⼤减少环境不同带来的排错等成本沟通问题。
干果礼品盒
对于后台数据，差异性是不可避免的。这需要在开发过程中建⽴隔离机制。
最好开发运维⼀体化。
2.11. ⽇志
基本含义，把⽇志当作事件流。
该要素原则体现到微服务应⽤有四点实践：
微服务应⽤要建⽴统⼀的服务⽇志管理机制。
每个运⾏的微服务都要求直接标准输出（stdout）和错误输出（stderr）事件流。⽇志是事件流的汇总，最后形成⽇志数据源。通过集中服务，执⾏环境收集、聚合、索引和分析这些⽇志事件。
采⽤服务调⽤链来解决服务之间调⽤的问题。
通过⽇志来进⾏微服务应⽤的监控。
2.12. 管理进程
基本含义，后台管理任务当作⼀次性进程运⾏。
该要素原则体现到微服务应⽤有三点实践：
微服务本⾝应⽤和微服务的后台管理应⽤要严格分离。这两者采⽤的技术架构、框架和实现都不⼀样。
微服务后台管理应⽤也可以采⽤微服务模式来实现。
微服务管理或维护系统是微服务应⽤维护的基础部分，要作为⼀次性程序运⾏。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议