文章来自: <<Spring 5.0 Microservices 第二版>> 翻译.
云计算是最快速发展的技术之一。它承诺许多好处，例如成本优势，速度，灵活性，灵活性和弹性。有许多云提供商提供不同的服务。他们正在降低成本模型，使其对企业更具吸引力。不同的云提供商（如AWS Microsoft，Rackspace，IBM，Google等）使用不同的工具，技术和服务。另一方面，企业意识到这个不断发展的战场，因此，他们正在寻找从锁定到单一供应商的降低风险的选择。许多组织将其应用程序升级并转移到云端。在这种情况下，应用程序可能无法实现云平台承诺的所有好处。一些应用程序需要进行大修，而有些应用程序在迁移到云之前可能需要进行小的调整。总的来说，这取决于应用程序的架构和开发方式。例如，如果应用程序将其生产数据库服务器URL硬编码为应用程序之战的一部分，则需要在将应用程序移动到云之前进行修改。在云中，基础架构对应用程序是透明的，尤其是不能假设物理IP地址。我们如何确保应用程序甚至微服务可以跨多个云提供商无缝运行并利用弹性等云服务？在开发云原生应用程序时遵循某些原则非常重要。
Cloud native是一个术语，用于开发可在云环境中高效工作的应用程序，并了解和利用云行为，如弹性，基于利用率的计费，故障识别等。
由Heroku转发的Twelve-Factor App是一种描述现代云就绪应用程序所期望的特征的方法。这12个因素同样适用于微服务。因此，了解TwelveFactors非常重要.
1. 单一代码库
代码库原则建议每个应用程序应该有一个代码库。 可以有多个部署相同代码库的实例，例如开发，测试或生产。 代码通常在源控制系统（如Git，Subversion等）中进行管理：
扩展微服务的相同理念，每个微服务都应该有自己的代码库，而且这个代码库不与任何其他微服务共享。 这也意味着一个微服务将只有一个代码库。
2.捆绑依赖性根据此原则，所有应用程序都应将其依赖项与应用程序包捆绑在一起。
使用Maven和Gradle等构建工具，我们显式管理项目对象模型（POM）或gradle文件中的依赖项，并使用Nexus或Archiva等中央构建工件存储库链接它们。 这将确保正确管理版本。 最终的可执行文件将被打包为war文件或嵌入所有依赖项的可执行jar文件：
在微服务的上下文中，这是要遵循的基本原则之一。 每个微服务应该在最终的可执行包中捆绑所有必需的依赖项和执行库，例如HTTP侦听器等。
3.外部化配置外部化配置原则 为您提供了从代码中外部化所有配置参数的建议。
应用程序的配置参数因环境而异，例如支持电子邮件ID或外部系统的URL，用户名，密码，队列名称等。 这些将在开发，测试和生产方面有所不同。 所有服务配置都应该外部化：
同样的原则对于微服务也是显而易见的。 应从外部源加载微服务配置参数。 这也将帮助您自动化发布和部署过程，因为这些环境之间的唯一变化是配置参数。
4.支持服务是可寻址的所有支持服务都应该通过可寻址的URL访问。 所有服务都需要在执行的生命周期中与某些外部资源进行通信。 例如，他们可能正在收听或向消息传递系统发送消息，发送电子邮件或将数据持久保存到数据库。 所有这些服务都可以通过URL访问，而无需复杂的通信要求：在微服务领域，微服务可以与消息系统通信以发送或接收消息，也可以接受或发送消息到另一个服务API。 在常规情况下，这些是使用REST和JSON或HTTP或基于HTTP的消息传递端点的HTTP端点。
在微服务领域，微服务可以与消息传递系统通信以发送或接收消息，也可以接受或发送消息到另一个服务API。 在常规情况下，这些是使用REST和JSON或HTTP或基于HTTP的消息传递端点的HTTP端点。
5.构建，发布和运行之间的隔离. 这个原则提倡构建阶段，发布阶段和运行阶段之间的强烈隔离。
构建阶段是指通过包含所需的所有资产来编译和生成二进制文件。 发布阶段是指将二进制文件与特定于环境的配置参数组合在一起。 运行阶段是指在特定执行环境中运行应用程序。 管道是单向的。 因此，无法将更改从运行阶段传播回构建阶段。 从本质上讲，它也意味着不建议为生产做特定的构建; 相反，它必须通过管道：
在微服务中，构建将创建可执行jar文件，包括服务运行时，例如HTTP侦听器。在发布阶段，这些可执行文件将与发布配置（如生产URL等）结合使用，并创建发布版本，最有可能作为Docker之类的容器。在运行阶段，这些容器将通过容器调度程序在生产中部署。
6.无状态，无共享的过程
这一原则表明，流程应该是无状态的，不分享任何东西。如果
应用程序是无状态的，然后它是容错的，并且可以轻松扩展。
所有微服务都应设计为无状态功能。如果存储状态的要求，应该使用后备数据库或内存缓存来完成。
7.通过端口绑定公开服务
一个十二因素应用程序预计是独立的或独立的。传统上，
应用程序部署到服务器 - Web服务器或应用程序服务器等
分别作为Apache Tomcat或JBoss。十二因素应用程序理想情况下不会中继
在外部Web服务器上。 HTTP侦听器（如Tomcat，Jetty等）必须具有
嵌入服务或应用程序本身。
端口绑定是微服务自治的基本要求之一
和自足的。微服务将服务侦听器嵌入作为服务本身的一部分。
8.扩展的并发性
扩展原则的并发性表明应该设计流程
通过复制流程来扩展。这是除了使用线程之外
在这个过程中。
在微服务领域，服务是为扩展而非扩展而设计的
向上。 X轴缩放技术主要用于通过旋转来缩放服务
另一个相同的服务实例。服务可以弹性缩放或
缩小，基于交通流量。此外，微服务可以使用并行
处理和并发框架，以进一步加快或扩大事务处理。
9.Disposability，开销最小化可管理性以最小的开销原则提倡以最少的启动和关闭时间构建应用程序，并提供优雅的关闭支持。在自动部署环境中，我们应该能够尽快启动或关闭实例。如果应用程序的启动或关闭需要相当长的时间，则会对自动化产生负面影响。启动时间与应用程序的大小成比例关系。在针对自动扩展的云环境中，我们应该能够快速启动新实例。这在推广新版服务时也适用。在微服务环境中，为了实现完全自动化，最大限度地保持应用程序的大小尽可能薄，启动和关闭时间最短。微服务还应考虑延迟加载对象和数据。
10.开发，生产平价开发，生产相同性,规定了保持开发和生产环境尽可能相同的重要性。例如，让我们考虑具有多个服务或进程的应用程序，例如作业调度程序服务，缓存服务或一个或多个应用程序服务。在开发环境中，我们倾向于在一台机器上运行所有这些。然而，在生产中，我们将促进独立机器运行这些过程中的每一个。这主要是为了管理基础设施的成本。缺点是，如果生产失败，则没有相同的环境来重现和解决问题。该原则不仅适用于微服务，而且适用于任何应用程序开发。
11.外化日志
十二因素应用程序从不尝试存储或发送日志文件。 在云中，最好避免使用本地I / O或文件系统。 如果I / O在给定的基础架构中速度不够快，则可能会造成瓶颈。 解决方案是使用集中式日志记录框架。 Splunk，greylog，Logstash，Logplex，Loggly是日志传送和分析工具的一些示例。 建议的方法是通过点击logback appender将日志发送到中央存储库并写入其中一个发货人的端点。 在微服务生态系统中，这非常重要，因为我们将系统分解为许多较小的服务，这可能导致分散式日志记录。 如果他们将日志存储在本地存储中，那么在服务之间关联日志将非常困难：
在开发中，微服务可以将日志流引导到stdout，而在生产中，这些流将由日志转发器捕获并发送到中央日志服务以进行存储和分析。
12.Package管理流程
除应用程序请求外，大多数应用程序还提供管理任务。
这个原则建议您定位相同的版本和相同的环境 长时间运行的进程运行以执行这些活动。管理任务代码也应与应用程序代码一起打包。 该原则不仅适用于微服务，而且适用于任何应用程序开发