云原生构建 微服务、容器化与容器编排

第1章 何为云原生，云原生为何而生

SOA也就是面向服务的架构

软件架构的发展主要经历了集中式架构、分布式架构以及云原生架构这几代架构的发展。

微服务架构，其实是SOA的另外一种实现方式，属于SOA的子集。

 在微服务架构下，系统中每一个服务都是一个独立的可部署单元，各个服务之间相互解耦并且通过通信协议进行通信。另外需要注意的是，在微服务架构中由于分布式架构的内生复杂性，也就是服务通信与服务治理等方面的复杂性，还需要考虑服务注册与发现、统一配置中心、链路追踪等方面的问题。除了可以看到各个业务服务外，还会看到一些基础的服务组件。需要注意的是，一个由业务微服务与非业务的基础服务组件组成的微服务架构才能称为一个较为完整的微服务架构。

1.2.3 云原生架构

云原生架构，其实是一个构建和运行应用程序的方法，是一整套技术体系与方法论。

1.3.2 什么是云原生应用

当使用云原生应用时就可以充分利用云原生平台的弹性与分布式优势，以此实现快速部署、按需伸缩、不停机交付等。一般情况下，这些架构使用微服务进行构建，也就是说对于云原生应用可以将其想象为一系列独立的、小型的、松耦合的服务。

1.4.1 云原生应用设计理念

简单来说云原生应用的设计理念，就是围绕着部署在云平台的应用程序能够充分利用云平台的弹性与分布式的优势来进行的。

对于云原生应用的设计理念，主要从面向分布式设计、面向韧性设计、面向弹性设计等方面进行介绍。

在面向分布式设计中，需要关注的重点是松耦合的微服务。

松耦合的微服务是指应用在设计时应该根据具体业务需求将整体业务拆分成一系列独立的、小型的、松耦合的服务，整体业务有这些服务共同来完成。另外在拆分这些服务时，需要注意的是这些服务一定是围绕着业务功能进行构建的，同时这些服务可以通过自动化的部署机制进行独立的部署与运行。

除此之外，这些服务之间的通信采用类似于HTTP这种轻量级协议进行通信，这就要求开发流程最好是以API驱动的，也就是说应用一定要把设计阶段与开发阶段分开，在设计阶段时先定义好API规范，这些API规范应该在描述其功能的基础上尽量简洁，然后在开发阶段严格遵守API规范进行相关的开发工作。

在面向韧性设计中，需要关注的重点是高可用与故障恢复。

高可用是指应该根据具体的业务需求即业务可用性要求，将业务服务进行不同程度的冗余，比如，将同一个业务服务部署在不同的机房、不同的服务器、不同的进程等。

故障恢复是指应用处理业务时，如果业务服务中断了，应用可以快速恢复以确保业务继续正常运行。

在面向韧性设计的过程中，可以使用容器技术，也就是将业务服务都进行容器化，业务由一组容器化的服务来提供。一方面，可以通过容器快速地将服务移植到相同或不同的操作系统环境上；另一方面可以通过容器平台容器平台确保容器实例运行数量保持不变。

在面向弹性设计中，需要关注的重点是扩展。

扩展是指应用在业务处理的高峰或低谷时间，可以依赖于云平台也就是云的特性进行自动的弹性伸缩。

需要注意的是，业务服务都应该被设计成无状态的，也就是说业务服务的实例可以随时上下线，任何一个业务服务的实例都可以处理业务请求，这样才能使得应用在良好的扩展性方面与生俱来。

云原生应用的12要素为构建云原生应用提供了方法论，是在构建云原生应用的过程中需要遵循的基本原则。

1.基准代码

可以将其理解为日常工作中存放在版本控制系统中的对应的代码库。

在12要素中基准代码强调的是一份基准代码多份部署，也就是说应用对应的代码既可以在测试环境部署，也可以在生产环境部署等。应用与基准代码之间应该是一一对应的关系。

2.依赖

在日常开发工作中其实经常碰到，比如，软件项目中的一个模块如果需要完成自己的功能必须借助其他模块的能力时，该模块就需要依赖其他模块。

在12要素中依赖强调的是管理依赖关系，也就是说应用应该显式地声明自己的依赖项。一方面是有利于管理依赖项；另一方面当有新的开发人员进入项目组时，只需一个构建命令就可以安装所有的依赖项解决环境配置的问题。

3.配置

在开发编写应用代码时，通常会将项目应用中数据库的链接地址、账号、密码等信息放到一个单独的文本文件中进行保存，然后在代码中引用这个文件中的内容，这个文件一般称为配置文件，对于文件中的内容一般称为配置或者配置信息。

4.后端服务

是指在应用运行时所需的通过网络调用的各种服务，比如，我们日常开发工作中经常用到的关系型数据库MySQL、缓存系统Redis，消息中间件ActiveMQ等。

在12要素中后端服务强调的是把后端服务当作附加资源，当部署应用时就按需伸缩这些资源。不管是第三方服务还是本地服务都应视为附加资源。

5.构建、发布和运行

构建是将应用代码进行打包的过程；发布是在相应的环境中部署应用代码包；运行是在相应的环境中启动应用程序。

6.进程

可以理解为正在运行的应用程序的实例。

12要素中进程强调的是以一个或多个无状态进程运行应用，也就是说在日常开发工作中应用程序的运行一般以一个或者多个进程的形式存在。应用进程应该是无状态的。

7.端口绑定

是指可以通过IP+端口的方式来访问服务。

在12要素中端口绑定强调的是通过其来提供服务，也就是当应用程序启动后，应用程序会去监听指定端口的请求。一般情况下都是通过域名访问服务，但是在向域名发送请求时，请求都会被路由到绑定的端口的进程中。

8.并发

是指应用程序与计算单元不是一一对应的关系，一个应用程序可以有多个计算单元。

在12要素中并发强调的是通过进程模型进行扩展，也就是说应用应采用多进程的运行方式按需运行。在Java应用中一般采用多线程的运行方式，随着微服务与容器技术的使用也可以更好地实现扩展。

9.易处理

是指应用进程可以快速启动与停止。

在12要素中易处理强调的是快速启动和优雅终止，可最大化健壮性，也就是说应用可以通过快速启动与停止来确保应用的稳定性。当停止应用时应该妥善处理正在运行的任务，比如将该任务退回至后端队列服务中。

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

是指应该减少各个环境、环节之间的差异。也就是说应用依赖的基础环境、开发人员等应尽量保持一致。不论是测试、生产等环境下部署的后端服务的版本应该是一样的。

11.日志

在日常开发工作中一般使用日志来记录日期、时间、操作者及动作等相关信息。

在12要素中日志强调的是把日志当作事件流，也就是说日志应该是按照时间顺序汇总的事件流。应用一般都有多个进程存在，也就会产生多份日志，可以采用日志索引分析系统以便于对日志进行搜索、分析和展示等。

12.管理进程

可以理解为执行的一些管理与维护应用的任务。

在12要素中管理进程强调的是后台管理任务当做一次性进程运行，也就是说应该一次性运行需要执行的管理与维护应用的任务。执行管理与维护应用的任务的环境应与应用的环境保持一致。

12要素不仅仅适用于构建云原生应用，对于日常工作过程中碰到的一些软件产品或项目的开发也同样适用。

1.4.3 云原生应用的构建步骤

1.思想变革：宣传DevOps文化，增加DevOps能力

在构建云原生应用前，应改变我们以往的思维，不再是开发只负责开发，运维只负责运维，我们需要促进开发、运维等部门之间的沟通、协作与整合，以便于能够更加高效地协同工作，加快软件交付以及提高整体产出。

2.应用开发：使用微服务思想设计应用程序

在云原生应用的构造步骤中第二步的重点就是微服务，也就是说，应用程序在设计时就应根据具体业务需求将整体业务设计成松耦合的微服务，需要采用以API驱动的开发流程。需要注意的是，在应用的整体开发过程中需要遵循云原生应用的12要素，以便于应用可以满足快速扩展与添加功能的基本条件。

3.容器革命：实现不可变基础设施

在应用开发完毕后，需要为应用提供独立的部署单元与执行环境，通过容器技术可以实现该需求。同时，使用容器技术实现基础设施的实例创建后就不可进行更改，如果需要更改只能通过新的实例进行替换，以便于解决环境差异、大规模运维等问题。

4.持续交付：应用全生命周期自动化

在应用开发、部署、上线运行后，当又有新的业务需求来临时，需要考虑持续集成、持续部署与持续发布，以便于能够在应用的构建、测试与发布中变得更快、更频繁。

第2章 从0到1——单体应用

2.1.1 单体应用：不可分割的软件框架

单体应用是指一个包含所有功能的应用程序的归档包，而归档包的格式主要依赖于相关的编程语言和框架。比如，在Java中归档包的格式可以是JAR归档格式或者是WAR归档格式，也可以是EAR归档格式或者其他归档格式。但是严格意义上来说，单体应用其实是一种软件架构，该架构对软件整体结构及组件进行了抽象的描述，可以指导软件系统各个方面的设计。

从单体应用的组成上来说，一个单体应用包含了很多业务逻辑与服务，由多个部分组成，这些组成部分缺一不可。比如，负责用户鉴权的部分、负责处理业务逻辑的部分、负责数据库的数据访问部分以及处理HTTP请求并进行响应的部分，这些部分共同组成了单体应用，并且不能缺少其中的任何一部分，一旦有部分缺失将导致应用程序不可用。

从代码层面上来说，一个单体应用的所有代码都存在于同一个代码库中，并且当编译代码是也会将单体应用的所有代码编译到一起。虽然单体应用的所有代码都在一起，但是在进行单体应用的开发时，一般会遵循分层原则，比如，将业务逻辑抽象出来构建业务层，在数据库之上构建数据访问层。

时序图是展示按时间顺序排序的对象之间交互的图。

类图是一种静态的结构图，主要是描述系统的类的集合、类的属性以及类之间的关系。

 2.3.1 Spring Boot：快速配置开发的脚手架

Spring Boot由Pivotal团队于2013年开始研发并于2014年4月发布全新、开源的轻量级框架，Spring Boot 基于Spring4.0设计，该框架继承了Spring框架原有的优秀特性，并且还通过简化配置进一步简化了Spring应用的整个搭建和开发过程。比如，当使用Spring Boot时可以使用特定的方式进行配置，不再需要定义一些样板化的配置，Spring Boot的设计目的是用来简化新的Spring应用的初始搭建以及开发过程。

Spring Boot的核心功能有很多，具体如下：

创建独立的Spring应用程序；

基于其Maven或Gradle插件创建可执行的jar或war；

使用内嵌的Tomcat、Jetty或Undertow；

提供如指标、健康检查和外部化配置等功能；

不需要XML配置；

通过提供的starter来简化Maven配置。

2.3.2 Spring Boot Starters：依赖关系描述符

Spring Boot Starter是在Spring Boot 中提出的一个概念，可以理解为一个依赖关系描述符，它包含一组依赖关系，通过这些依赖关系可以减少手动添加的依赖数量。

当使用Spring Boot时，可以省略很多烦琐的配置。比如，当想要构建rest webservice时，只需添加spring-boot-starter-web依赖；当想要使用Spring和JPA进行数据库访问时我们只需添加spring-boot-starter-data-jpa依赖。

Spring Boot官方提供了很多Starter，官方提供的Starter以“spring-boot- starter-*”的方式来命名，如果要创建自己的Starter，建议命名方式是“*-spring-boot- starter”

Spring Cloud：系列框架的有序集合

Spring Cloud是一系列框架的有序集合，主要提供了快速构建分布式系统中一些常见模式的工具。

联系与区别

Spring是一个一站式的轻量级的Java开发框架，Spring的核心是控制反转（IOC）和面向切面（AOP）。

Spring MVC是在Spring基础上的一个MVC框架，主要用于来处理Web开发的路径映射和视图渲染，Spring MVC属于Spring 框架中Web层开发的一部分。

Spring Boot是一个全新开源的轻量级框架，相对于Spring MVC框架来说，Spring Boot可以更专注于开发微服务后台接口，并且Spring Boot使用默认大于配置的理念，可以快速集成Spring相关插件，同时自动过滤掉不需要配置的多余插件，简化了项目的开发配置流程，并在一定程度上取消了xml配置，能够快速开发单个微服务。

Spring Cloud是一系列框架的有序集合，在Spring Cloud中大部分的功能插件都基于Spring Boot来实现，对于Spring Boot与Spring Cloud，可以理解为Spring Cloud依赖于Spring Boot开发，而Spring Boot可以用来独立开发，Spring Cloud可以将多个Spring Boot单体微服务进行整合以及管理。对于Spring Cloud来说，Spring Cloud更关注全局的微服务整合和管理。

2.3.5 Spring Initializr：项目结构创建工具

1.Spring Initializr功能

提供了快速进行框架初始化配置的能力，通过Spring Initializr可以选择即将初始化项目的发布部署方式、扩展依赖包等，全部选择完毕后，就可以自动生成对应的项目结构。

在使用Spring Boot进行单体应用开发时会采用Spring Initializr创建Spring Boot项目结构，通过前面的描述，可以将其理解为是一个工具，可以构建Spring Boot项目结构，并且当使用Spring Initializr构建时可以选择Spring Boot的版本，同时还可以选择构建的项目是基于Maven或者Gradle。

2.Spring Initializr的常用用法

主要有三种方式：通过Web界面使用、通过集成开发工具如IntelliJ IDEA使用以及通过Spring Boot CLI使用。这三种方式中的通过Web界面及集成开发工具使用都由可视化界面来操作，而通过Spring Boot CLI使用更适合与习惯命令行操作的开发人员，不过通过Web界面使用以及通过Spring Boot CLI使用还需要将生成的项目再导入集成开发工具中。

关于项目的分层设计，采用常见的符合高内聚、低耦合思想的三层架构，将项目分为控制层、业务逻辑层和持久层。