2024年最全Cloud Native 与12-Factor_十二因子 cloud native(1)，HarmonyOS鸿蒙字节跳动面试题-CSDN博客

本文链接：https://blog.csdn.net/2401_84871291/article/details/138839937

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上鸿蒙开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

5 构建、发布、运行

基准代码进行部署需要以下三个阶段：

构建阶段：是指将代码仓库转化为可执行包的过程。构建时会使用指定版本的代码，获取和打包依赖项，编译成二进制文件和资源文件。
发布阶段：会将构建的结果和当前部署所需配置相结合，并能够立刻在运行环境中投入使用。
运行阶段：是指针对选定的发布版本，在执行环境中启动一系列应用程序进程。

应用严格区分构建、发布、运行这三个步骤。举例来说，直接修改处于运行状态的代码是非常不可取的做法，因为这些修改很难再同步回构建步骤。

部署工具通常都提供了发布管理工具，在必要的时候还是可以退回至较旧的发布版本。

每一个发布版本必须对应一个唯一的发布 ID，例如可以使用发布时的时间戳（2011-04-06-20:32:17），亦或是一个增长的数字（v100）。发布的版本就像一本只能追加的账本，一旦发布就不可修改，任何的变动都应该产生一个新的发布版本。

新的代码在部署之前，需要开发人员触发构建操作。但是，运行阶段不一定需要人为触发，而是可以自动进行。如服务器重启，或是进程管理器重启了一个崩溃的进程。因此，运行阶段应该保持尽可能少的模块，这样假设半夜发生系统故障而开发人员又捉襟见肘也不会引起太大问题。构建阶段是可以相对复杂一些的，因为错误信息能够立刻展示在开发人员面前，从而得到妥善处理。

6 进程

12-Factor 应用推荐以一个或多个无状态进程运行应用。这里的“无状态”是与 REST 中的无状态是一个意思，即进程的执行不依赖于上一个进程的执行。

举例来说，内存区域或磁盘空间可以作为进程在做某种事务型操作时的缓存，例如下载一个很大的文件，对其操作并将结果写入数据库的过程。12-Factor 应用根本不用考虑这些缓存的内容是不是可以保留给之后的请求来使用，这是因为应用启动了多种类型的进程，将来的请求多半会由其他进程来服务。即使在只有一个进程的情形下，先前保存的数据（内存或文件系统中）也会因为重启（如代码部署、配置更改、或运行环境将进程调度至另一个物理区域执行）而丢失。

一些互联网应用依赖于“粘性 session”，这是指将用户 session 中的数据缓存至某进程的内存中，并将同一用户的后续请求路由到同一个进程。粘性 session 是 12-Factor 极力反对的。Session 中的数据应该保存在诸如 Memcached 或 Redis 这样的带有过期时间的缓存中。

相比于有状态的应用而言，无状态具有更好的可扩展性。

7 端口绑定

传统的互联网应用有时会运行于服务器的容器之中。例如 PHP 经常作为 Apache HTTPD 的一个模块来运行，而 Java 应用往往会运行于 Tomcat 中。

12-Factor 应用完全具备自我加载的能力，而不依赖于任何网络服务器就可以创建一个面向网络的服务。互联网应用通过端口绑定（Port binding）来提供服务，并监听发送至该端口的请求。

举例来说，Java 程序完全能够内嵌一个 Tomcat 在程序中，从而自己就能启动并提供服务，省去了将 Java 应用部署到 Tomcat 中的繁琐过程。在这方面，Spring Boot 框架的布道者 Josh Long 有句名言“Make JAR not WAR”，即 Java 应用程序应该被打包为可以独立运行的 JAR 文件，而不是传统的 WAR 包。

以 Spring Boot 为例，构建一个具有内嵌容器的 Java 应用是非常简单的，只需要引入以下依赖：

// 依赖关系
dependencies {

	// 该依赖用于编译阶段
	compile('org.springframework.boot:spring-boot-starter-web')

}

这样，该 Spring Boot 应用就包含了内嵌 Tomcat 容器。

如果想使用其他容器，比如 Jetty、Undertow 等，只需要在依赖中加入相应 Servlet 容器的 Starter 就能实现默认容器的替换，比如：

spring-boot-starter-jetty：使用 Jetty 作为内嵌容器，可以替换 spring-boot-starter-tomcat；
spring-boot-starter-undertow：使用 Undertow 作为内嵌容器，可以替换 spring-boot-starter-tomcat。

可以使用 Spring Environment 属性配置常见的 Servlet 容器的相关设置。通常您将在 application.properties 文件中来定义属性。

常见的 Servlet 容器设置包括：

网络设置：监听 HTTP 请求的端口（server.port）、绑定到 server.address 的接口地址等；
会话设置：会话是否持久（server.session.persistence）、会话超时（server.session.timeout）、会话数据的位置（server.session.store-dir）和会话 cookie 配置（server.session.cookie.*）；
错误管理：错误页面的位置（server.error.path）等；
SSL；
HTTP 压缩。

Spring Boot 尽可能地尝试公开这些常见公用设置，但也会有一些特殊的配置。对于这些例外的情况，Spring Boot 提供了专用命名空间来对应特定于服务器的配置（比如 server.tomcat 和 server.undertow）。

8 并发

在 12-factor 应用中，进程是一等公民。由于进程之间不会共享状态，这意味着应用可以通过进程的扩展来实现并发。

类似于 unix 守护进程模型，开发人员可以运用这个模型去设计应用架构，将不同的工作分配给不同的进程。例如，HTTP 请求可以交给 web 进程来处理，而常驻的后台工作则交由 worker 进程负责。

在 Java 语言中，往往通过多线程的方式来实现程序的并发。线程允许在同一个进程中同时存在多个线程控制流。线程会共享进程范围内的资源，例如内存句柄和文件句柄，但每个线程都有各自的程序计数器、栈以及局部变量。线程还提供了一种直观的分解模式来充分利用操作系统中的硬件并行性，而在同一个程序中的多个线程也可以被同时调度到多个CPU上运行。

毫无疑问，多线程编程使得程序任务并发成为了可能。而并发控制主要是为了解决多个线程之间资源争夺等问题。并发一般发生在数据聚合的地方，只要有聚合，就有争夺发生，传统解决争夺的方式采取线程锁机制，这是强行对CPU管理线程进行人为干预，线程唤醒成本高，新的无锁并发策略来源于异步编程、非阻塞I/O等编程模型。

并发的使用并非没有风险。多线程并发会带来如下的问题：

安全性问题。在没有充足同步的情况下，多个线程中的操作执行顺序是不可预测的，甚至会产生奇怪的结果。线程间的通信主要是通过共享访问字段及其字段所引用的对象来实现的。这种形式的通信是非常有效的，但可能导致两种错误：线程干扰（thread interference）和内存一致性错误（memory consistency errors）。
活跃度问题。一个并行应用程序的及时执行能力被称为它的活跃度（liveness）。安全性的含义是“永远不发生糟糕的事情”，而活跃度则关注于另外一个目标，即“某件正确的事情最终会发生”。当某个操作无法继续执行下去，就会发生活跃度问题。在串行程序中，活跃度问题形式之一就是无意中造成的无限循环（死循环）。而在多线程程序中，常见的活跃度问题主要有死锁、饥饿以及活锁。
性能问题。在设计良好的并发应用程序中，线程能提升程序的性能，但无论如何，线程总是带来某种程度的运行时开销。而这种开销主要是在线程调度器临时关起活跃线程并转而运行另外一个线程的上下文切换操作（Context Switch）上，因为执行上下文切换，需要保存和恢复执行上下文，丢失局部性，并且CPU时间将更多地花在线程调度而不线程运行上。当线程共享数据时，必须使用同步机制，而这些机制往往会抑制某些编译器优化，使内存缓存区中的数据无效，以及增加贡献内存总线的同步流量。所以这些因素都会带来额外的性能开销。

9 易处理

12-Factor 应用的进程是易处理（Disposable）的，意味着它们可以瞬间启动或停止。比如，Spring Boot 应用，它可以无需依赖容器，而采用内嵌容器的方式来实现自启动。这有利于迅速部署变化的代码或配置，保障系统的可用性，并在系统负荷到来前，快速实现扩展。

进程应当追求最小启动时间。理想状态下，进程从敲下命令到真正启动并等待请求的时间应该只需很短的时间。更少的启动时间提供了更敏捷的发布以及扩展过程，此外还增加了健壮性，因为进程管理器可以在授权情形下容易的将进程搬到新的物理机器上。

进程一旦接收终止信号（SIGTERM）就会优雅的终止。就网络进程而言，优雅终止是指停止监听服务的端口，即拒绝所有新的请求，并继续执行当前已接收的请求，然后退出。

对于 worker 进程来说，优雅终止是指将当前任务退回队列。例如，RabbitMQ 中，worker 可以发送一个 NACK 信号。Beanstalkd 中，任务终止并退回队列会在 worker 断开时自动触发。有锁机制的系统诸如 Delayed Job 则需要确定释放了系统资源。

10 开发环境与线上环境等价

我们期望一份基准代码可以部署到多个环境，但如果环境不一致，最终也可能导致运行程序的结果不一致。

比如，在开发环境，我们是采用了 MySQL 作为测试数据库，而在线上生产环境，则是采用了 Oracle。虽然，MySQL 和 Oracle 都遵循相同的 SQL 标准，但两者在很多语法上还是存在细微的差异。这些差异非常有可能导致两者的执行结果不一致，甚至某些 SQL 语句在开发环境能够正常执行，而在线上环境根本无法执行。这都给调试增加了复杂性，同时，也无法保障最终的测试效果。

所以，一个好的指导意见是，不同的环境尽量保持一样。开发环境、测试环境与线上环境设置成一样，更早发现测试问题，而不至于在生产环境才暴露出问题。

11 日志

在应用程序中打日志是一个好习惯。日志使得应用程序运行的动作变得透明。日志是在系统出现故障时，排查问题的有力帮手。

日志应该是事件流的汇总，将所有运行中进程和后端服务的输出流按照时间顺序收集起来。尽管在回溯问题时可能需要看很多行，日志最原始的格式确实是一个事件一行。日志没有确定开始和结束，但随着应用在运行会持续的增加。对于传统的 Java EE 应用程序而言，有许多框架和库可用于日志记录。Java Logging (JUL) 是 Java 自身所提供的现成选项。除此之外 Log4j、Logback 和 SLF4J 是其他一些流行的日志框架。

对于传统的单块架构而言，日志管理本身并不存在难点，毕竟所有的日志文件，都存储在应用所部属的主机上，获取日志文件或者搜索日志内容都比较简单。但在 Cloud Native 应用中，
情况则有非常大的不同。分布式系统，特别是微服务架构所带来的部署应用方式的重大转变，都使得微服务的日志管理面临很多新的挑战。一方面随着微服务实例的数量的增长，伴随而来的就是日志文件的递增。另一方面，日志被散落在各自的实例所部署的主机上，不方面整合和回溯。

在这种情况下，将日志进行集中化的管理变得意义重大。本书的“10.4 日志管理”章节内容，会对 Cloud Native 的日志集中化管理进行详细的探讨。

12 管理进程

开发人员经常希望执行一些管理或维护应用的一次性任务，例如：

运行数据移植（Django 中的 manage.py migrate, Rails 中的 rake db:migrate）。
运行一个控制台（也被称为 REPL shell），来执行一些代码或是针对线上数据库做一些检查。大多数语言都通过解释器提供了一个 REPL 工具（python 或 perl），或是其他命令（Ruby 使用 irb, Rails 使用 rails console）。
运行一些提交到代码仓库的一次性脚本。

一次性管理进程应该和正常的常驻进程使用同样的环境。这些管理进程和任何其他的进程一样使用相同的代码和配置，基于某个发布版本运行。后台管理代码应该随其他应用程序代码一起发布，从而避免同步问题。

所有进程类型应该使用同样的依赖隔离技术。例如，如果 Rub y的 web 进程使用了命令 bundle exec thin start，那么数据库移植应使用 bundle exec rake db:migrate。同样的，如果一个 Python 程序使用了 Virtualenv，则需要在运行 Tornado Web 服务器和任何 manage.py 管理进程时引入 bin/python。