① DevOps

什么是 DevOps？

DevOps 全称是：Development and Operations，即开发和运营。是一套实践、工具和文化理念，可以实现软件开发团队和 IT 团队之间的流程自动化和集成，说白了，就是一种体系，这套体系开发、测试、运维、安全等全部与项目相关的人员都包含在其中，大家相互反馈，提升开发效率

DevOps 生命周期

DevOps 生命周期由六个阶段组成（如上图所示），左半部分代表开发，右边部分代表运营。分别是 PLAN（规划）、BUILD（构建）、CI / CD（持续集成和交付）、MONITOR（监控和警报）、OPERATE（运维）、CONTINUOUS FEEDBACK（持续反馈）

DevOps – 自动化流程

因为这部分直接讲空话很难理解，所以我就以自己所在公司的项目自动化流程为例。

首先项目由领导提出，然后由产品经理构思和提出各种方案，然后在 KAE 平台（PaaS 的一种，此处可以理解成工作平台）上发布各个阶段开发需要完成的任务，然后开发每完成一个阶段的任务，先部署在测试环境，由测试人员进行测试，此时测试可以分为手工测试和自动化测试，前者是黑盒测试，在项目页面或移动端测试开发的全部功能（手动点点点），后者是白盒测试，使用自动化工具在不同环境中测试每一个接口（又分为接口测试和性能测试），并将测试出的 BUG 反馈至 KAE 平台。此阶段一般持续三轮，分别在 gama、beta、alpha 环境（内部环境、测试环境、预发布环境）都通过后，经产品经理确认后，部署至正式环境中，接着又到新一轮循环了。

可以看到这整个自动化流程，开发、测试、产品经理都有参与的，虽然我没见过运维，但我认为运维的职责应该是管理着整个 KAE 平台，等平台服务器出问题时就会出马了。

补充一下：我司的开发只分为前端和后端，项目的代码部署在 Gitlab 上，仅开发人员能上传和修改，但是测试人员可以看到其中的报错日志；测试不仅有接口测试和性能测试，还有安全测试，包含传统的 SQL 注入、XSS、SSRF 等，这些都是自动化的，既每天定时在测试环境跑一次，有报错就会反馈。

DevOps – 可观察性

依然以我司举例，具体的可观察性体现在 KAE 上就是平台的可视化，包括项目的开发进程、BUGFIX 个数、测试结果、用户反馈、项目预期等数据的可视化。

从系统的角度来看，可观察性意味着通过观察复杂系统的外部行为来了解复杂系统的内部功能。

在组织层面，可观察性正在建立客户和团队之间的自然沟通和协作渠道，从而创建新的解决方案。

DevOps – 功能标记

原理非常简单，就是当你向项目的主分支提交 Pull Request，然后再写一些 Description（备注），那么这个备注就是功能标记。

补充：我突然想到了数据标注员这个职业，虽然名字听起来和功能标记很像，但是数据标注员的工作是对数据进行标注分类，便于 AI 的识别，与这里讲的功能标记完全没有关系~

DevOps – CI / CD（持续集成 / 持续交付与部署）

持续集成、交付和部署 (CI / CD) 是成功 DevOps 实践的基础。接下来我分别讲讲这三个概念：

持续集成（Continue Integration）是将来自多个贡献者的代码更改自动集成到单个软件项目中的实践，然后在该存储库中运行构建和测试。我认为这套流程最重点在于测试这部分上，以前的测试流程都是开发完成一个任务并将代码交给测试人员，测试人员再本地测试；而这套流程强调的是把测试的代码（针对项目的各个模块）合起来部署到平台上，平台就可以在不同的环境中不间断的进行自动化测试。

持续交付（Continue Delivery）是一种团队以自动化方式频繁且可预测地从源代码存储库发布到生产环境的方法。这套流程的重点在于发布这部分上，以前的发布流程都是开发将最终代码交给项目经理，确认后再交给测试人员，经过最终的验收测试后发布正式环境，再由客户反馈，又一步步返回至开发重新修改；而这套流程强调的是开发直接把全部代码托管至平台上，分成众多不同版本的代码（测试、存储、预发布），平台在项目上线前和版本迭代时会自动检测代码的安全性（检测危险代码和各种测试），最终选定要发布的版本进行发布，再由客户反馈，开发便可以直接对所需项目代码进行回滚和修改。


持续部署（Continue Development）与持续交付类似，唯一的不同就在于最后一步（部署到正式环境），持续部署是经过了平台测试后直接部署上线，这种做法的好处就是加快了与客户的反馈回路，但缺点也很明显，没有进行最终的验收（完善文档、环境处理、组员沟通等），适合在 DDL 前使用。

最后补充：其实看完了 Atlassian 关于这方面的介绍，我自己都无语了，这么普通的流程都能被大夸其词也是厉害。说白了，持续集成的重点就在于将一步步的代码测试，收集起来放在平台上，美其名曰自动化测试，而持续交付的重点就是将项目代码私有化（因为 Github 上开源的项目也是这样一套流程），比如我司用的就是 Gitlab，因此也可以美其名曰自动化部署。

② 云服务器

三种最流行的云服务产品类型（也称云服务模型 / 云计算服务模型）

• IaaS：Infrastructure as a Service。主要托管基础设施（服务器、存储容量和网络资源），用户可以自由配置服务器和软件环境，比如腾讯云、阿里云提供的云服务器都是 Iaas
• PasS：Platform as a Service。主要托管平台，企业中常用的云平台，用户通过 GUI 访问 Paas，开发或 DevOps 团队可以在其中协作处理整个应用程序生命周期中的所有工作，包括编码、集成、测试、交付、部署和反馈；缺点就是必须使用指定的开发语言，遵循平台的开发规范；比如新浪 SAE、百度 BAE、金山 KAE 都属于 Paas
• SasS：Software as a Service。主要托管软件，简单点说，一切不需要本地化部署的云服务产品，比如 Facebook / Twitter / Instagram 都是 Saas

IT 与云服务产品之间的关系

在传统 IT 中，组织通过购买、安装、管理和维护自己的本地数据中心来消耗 IT 资产——硬件、系统软件、开发工具、应用程序

在云计算中，云服务提供商拥有、管理和维护资产；客户通过互联网连接消费它们，并以订阅或现收现付的方式付费

下图是 IT 与各个云服务之间的关系：

各云服务产品类型的产品层

• IaaS：计算、存储、网络、CDN、数据库、安全等一系列基础产品
• PaaS：亚马逊 AWS、微软 Azure、阿里云等提供的服务 [销售产品]；新浪 SAE、百度 BAE、金山 KAE等 [内部产品]
• SaaS：各种 PC 端、移动端 APP

③ 容器技术

千万注意，接下来讨论的都是 Linux 容器，与基于虚拟化实现的 Docker on Mac 和 Windows Docker（Hyper-V 实现）本质完全不同

3.1 进程和线程

线程是最小的执行单元，而进程由至少一个线程组成

进程是最小的资源管理单元，进程就是一个应用程序在处理机上的一次执行过程

简而言之，一个程序至少有一个进程，一个进程至少有一个线程

3.2 容器

虚拟机和容器的不同：

• 虚拟机启动了 “虚拟机进程”，并在上面运行应用程序（多个应用进程）；容器本质是一个特殊的进程，可以理解为是应用进程，且套上了视图隔离和资源限制
• 虚拟机本身需要占用一部分资源（比如与底层硬件交互的时候都需要经过虚拟化软件拦截，有损耗）；容器相对来说只占用一个进程的资源
• 虚拟机比容器具有更好的隔离性和安全性。因为虚拟机的 Hypervisor 是真正对应用进程的隔离环境负责；对容器来说，真正对隔离环境负责的是宿主机操作系统本身（因为容器本质就是进程，被操作系统管理）
• 虚拟机上可以搭建不同的操作系统；容器只能使用系统的内核

容器的隔离和限制：

• Linux Namespace 机制控制被隔离应用的进程空间，使进程的 “视线受限”（如 PID Namespace 使其认为自己是唯一的进程，PID = 1，类似的还有 Mount、UTS、IPC、Network 和 User 这些 Namespace）

• Linux Cgroups 是 Linux 内核中用来为进程设置资源限制的一个重要功能，用于限制容器的资源分配（包括 CPU、内存、磁盘、网络带宽 等）

• Linux Namespace 中较为特殊的 Mount Namespace，它的作用是修改容器进程对文件系统 “挂载点” 的认知（即切换进程的根目录），但它容器进程视图的改变，一定是伴随着挂载操作（mount）才能生效

• 容器镜像就是这个挂载在容器根目录上、用来为容器进程提供隔离后执行环境的文件系统，也叫作 rootfs（根文件系统）

总结（Docker 项目最核心的原理）：

• Namespace 的作用是“隔离”，它让应用进程只能看到该 Namespace 内的“世界”
• Cgroups 的作用是“限制”，它给这个“世界”围上了一圈看不见的墙
• Mount namespace 和 rootfs 的作用是，建出一个完善的文件系统隔离环境，它构建了脚下的大地

3.3 Docker 容器

Docker 容器镜像：

• 可读写层

专门用来存放修改 rootfs 后产生的增量，无论是增、删、改，都发生在这里（如果删除了只读层的文件，实际系统的操作，是把要删除的文件 “隐藏” 起来了，并不是真正的删除，这种操作也被称为 “白障”（whiteout））

• Init 层

Init 层是 Docker 项目单独生成的一个内部层，专门用来存放 /etc/hosts、/etc/resolv.conf 等信息，这些信息一般是在启动容器时写入一些指定的值（比如 hostname），用户不想在上传镜像时让这些信息随着可读写层一起上传，于是将其专门放进该层，这样上传镜像时就只用上传可读写层

• 只读层

对应的是 ubuntu:latest 镜像的五层，这些层，都以增量的方式分别包含了 Ubuntu 操作系统的一部分。上传和下载镜像时，原镜像中的只读层里的内容都不会有任何变化

Docker 容器的核心解读：

• 这个容器进程 python app.py，运行在由 Linux Namespace 和 Cgroups 构成的隔离环境里
• 而它运行所需要的各种文件，比如 python，app.py，以及整个操作系统文件，则由多个联合挂载在一起的 rootfs 层提供
• 这些 rootfs 层的最下层，是来自 Docker 镜像的只读层
• 在只读层之上，是 Docker 自己添加的 Init 层，用来存放被临时修改过的 /etc/hosts 等文件
• 而 rootfs 的最上层是一个可读写层，它以 Copy-on-Write 的方式存放任何对只读层的修改，容器声明的 Volume 的挂载点，也出现在这一层

3.4 Kubernetes 容器云

说白了，一个运行中的 Linux 容器可以一分为二的看作：

• 一组联合挂载的 rootfs，这一部分我们称为 “容器镜像”（Container Image），是容器的静态视图
• 一个由 Namespace + Cgroups 构成的隔离环境，这一部分我们称为 “容器运行时”（Container Runtime），是容器的动态视图

那么如果将用户提交的每个 Docker 镜像以容器的方式运行起来，形成庞大的容器集群，比如 CI / CD、监控、安全、网络、存储等容器，利用容器组织和管理规范的 “容器编排” 技术，使其作为一个或多个应用程序一齐操作，这就形成了容器云生态

其中最具代表性的容器编排工具，当属 Docker 公司的 Compose + Swarm 组合，以及 Google 与 RedHat 公司共同主导的 Kubernetes 项目

浅析 Kubernetes 项目的核心功能：

• 首先遇到了容器间“紧密协作”关系的难题，于是就扩展到了 Pod（在 Pod 里的容器共享同一个 Network Namespace、同一组数据卷等）
• 我们希望能一次启动多个应用的实例，这样就需要 Deployment 这个 Pod 的多实例管理器（容器）
• 有了这样一组相同的 Pod 后，我们又需要通过一个固定的 IP 地址和端口以负载均衡的方式访问它，于是就有了 Service（Service 服务的主要作用，就是作为 Pod 的代理入口，从而代替 Pod 对外暴露一个固定的网络地址）
• 针对两个 Pod 之间需要的授权信息（如 Web 应用对数据库访问时需要 Credential（数据库的用户名和密码）信息），于是就有了 Secret（比如，Web 应用的 Pod 启动时，Kubernetes 自动把 Secret 里的数据以 Volume 的方式挂载到容器里，这样，这个 Web 应用就可以访问数据库了）
• Kubernetes 定义了新的、基于 Pod 改进后的对象（比如 Job，用来描述一次性运行的 Pod；又比如 DaemonSet，用来描述每个宿主机上必须且只能运行一个副本的守护进程服务；再比如 CronJob，则用于描述定时任务等）

Kubernetes 项目的使用方法（大家推崇的做法）：

• 首先，通过一个 “编排对象”，比如 Pod、Job、CronJob 等，来描述你试图管理的应用
• 然后，再为它定义一些 “服务对象”，比如 Service、Secret、Horizontal Pod Autoscaler（自动水平扩展器）等，这些对象，会负责具体的平台级功能

这种使用方法，就是所谓的 “声明式 API”，这种 API 对应的 “编排对象” 和 “服务对象”，都是 Kubernetes 项目中的 API 对象（API Object）

总结（Docker 项目的本质）：

• 表面上看，是为用户提供一个具有普遍意义的容器编排工具
• 真正的价值，乃在于提供了一套基于容器构建分布式系统的基础依赖

通俗的理解为什么需要 K8S？【转载】

从微服务架构来讲，多个独立功能内聚的服务带来了整体的灵活性，但是同时也带来了部署运维的复杂度提升，这时 Docker 配合 Devops 带来了不少的便利（轻量、隔离、一致性、CI、CD 等）解决了不少问题，再配合compose，看起来一切都很美了，为什么还需要 K8S？

可以试着这样理解，把微服务理解为人，那么服务治理其实就是人之间的沟通而已，人太多了就需要生存空间和沟通方式的优化，这就需要集群和编排了。Docker Compose 和 swarm，可以解决少数人之间的关系，比如把手机号给你，你就可以方便的找到我，但是如果手机号变更的时候就会麻烦，人多了也会麻烦。而 K8S 是站在上帝视角俯视芸芸众生后的高度抽象，他看到了大概有哪些类人（组织）以及不同组织有什么样的特点（Job、CornJob、Autoscaler、StatefulSet、DaemonSet 等），不同组织之间交流可能需要什么（ConfigMap,Secret 等），这样比价紧密的人们在相同 pod 中，通过 Service 不会变更的手机号，来和不同的组织进行沟通，Deployment、RC 则可以帮组人们快速构建组织。Dokcer 后出的 swarm mode，有类似的视角抽象（比如Service），不过相对来说并不完善。

3.5 Docker 和 K8S 的渊源【转载】

我现在有了一大批物理服务器，想要租界给别人使用。因此我搭建了一个物理集群，并向用户售卖，这是最初的 IaaS。 用户通过购买我的虚拟机，就能在虚拟机上部署自己的应用来使用虚拟机。在使用过程中发现（1）由于本地的开发环境和购买的虚拟机之间有各种不一致导致调试、部署困难 （2）不用应用之间可能在同一个虚拟机上，没有隔离（3）大规模的应用部署也比较麻烦。 因此出现了 PaaS，比如 Cloud Foundry，它提供了（1）大规模部署应用的能力 （2）提供了“沙盒”容器来对应用隔离，让用户进程互不干扰。 但是在使用过程中，发现“沙盒”使用起来还是不方便，比如打包过程非常痛苦，就需要大量的人力投入来让本地应用和远端 PaaS 适配 ，因此出现了 Docker。Docker 用镜像来实现本地环境和云端环境的高度一致，解决了打包困难的问题，取代了 Cloud Foundry 这类 PaaS 项目中的“沙盒”，Docker 因此崛起。

随着 Docker 被大范围使用，PaaS 的定义逐渐演变成了一套以 Docker 容器技术为核心，全新的”容器化“思路。2014 年，Docker 公司也顺势发布了自己的PaaS项目 Swarm。Swarm 项目的集群管理功能触发了其他公司的利益分配，因此 CoreOS 推出了自己的rkt容器、Mesos 发布了 Marathon 与 Swarm 竞争、Google 公司宣告Kubernetes 诞生。Docker 公司为完善平台能力，收购了第一个提出“容器编排”概念的项目Fig，并更名为 Compose。“容器编排”第一次正式进入视野

Docker 公司有了 Docker，Swarm，Compose 后，在容器商业生态具有很大的优势和话语权。为了竞争， Google、Redhat 等基础设施领域的玩家们组建了 CNCF（Cloud Native Computing Foundation）基金会，开始打造 Kuberentes。Kubernetes 很快远远 将Swarm 项目甩在身后。为了与 Kubernetes 竞争“容器编排”领域，Docker公司甚至放弃了 Swarm 项目，但最终未能打败 Kubernetes，在 2017 年，Docker 在自己的主打产品 Docker 企业版中内置 Kubernetes 项目，这标志着“编排之争”落地帷幕。容器化社区以 Kuberentes为 核心愈加繁荣。

④ 微服务

软件架构的演变

• 单体软件
• 所有功能耦合在一起，互相影响，最终难以管理
  • 哪怕只修改一行代码，整个软件就要重新构建和部署，成本非常高
  • 因为软件做成了一个整体，不可能每个功能单独开发和测试，只能整体开发和测试

可以看出，这就是典型的面向过程开发

• 面向服务架构
• 每种服务功能单一，相当于一个小型软件，便于开发和测试
  • 不同服务可以单独开发和部署，便于升级
  • 不容易出现单点故障。即使一个服务失败了，不会影响到其他服务
  • 每台服务器提供一种服务，多台服务器共同组成一个完整的网络应用

类似于面向对象开发，只不过将软件开发的每个单元，变成了每个服务（就是在后台不间断运行、提供某种功能的一个程序），服务之间通过通信协议连在一起

• 微服务
• 程序运行在容器中，每个容器可以分别设定运行环境，并且只占用很少的系统资源
  • 每个服务不再占用一台服务器，而是占用一个容器
  • 应用每增加一个"服务"，只需要新建一个容器（一个进程）
  • 这个进程可以运行在本机，也可以运行在别的服务器，或者在云端

微服务就是采用容器技术的面向服务架构，最简单的情况下，本机运行多个容器，只用一台服务器就实现了面向服务架构，这种实现方式就叫做微服务

⑤ 软件开发流

• 瀑布开发模型

  • 软件生命周期：制定计划、需求分析、软件设计、程序编写、软件测试、运行维护
  • 优点
    • 责任明确
    • 流程清晰
  • 缺点
    • 客户不参与开发过程
    • 新需求的增加会打乱整个发布节奏
    • 标准化模式导流程僵化、死板

• 敏捷开发模型

  • 软件生命周期：（计划部分需求、构建项目、全体评审）* N -> 校验并收工
  • 优点
    • 敏捷，迭代版本快
    • 客户参与，以人为本
    • 强调软件开发的产品是软件，而不是文档
  • 缺点
    • 忽视文档的重要性
    • 开发成本高（因为在每个迭代中都有一个小型的、完整的开发流程）

• DevOps

  • 软件生命周期：（规划、构建、持续集成和交付、监控和警报、运维、持续反馈）* N
  • 优点
    • 促进跨职能部门的高效协作
    • 范围更广，不只局限于开发流程，而是集开发、运维、测试于一体
    • 更具安全性，通过自动化测试来持续地检测交付产品的质量以及可交付标准，或者通过持续监控使产品更具安全性
    • 流程自动化
    • 周期短

⑥ 产品经理黑话

• To B：To Business，企业创业是面向企业，为企业提供服务（如设备制造商）
• To C：To Custumer，企业创业是面向客户，为客户提供服务（如 SaaS，微信、QQ 等）
• OA 系统：Office Automation，办公自动化
• CRM：Customer Relationship Management，客户关系管理，是指企业为提高核心竞争力，与顾客在工作上的一系列交互过程
• 中台：通用的业务模块拿出来，形成一个基础的业务层，这个业务层由在组织结构上相对独立的部门来负责，这个部门负责的东西就是中台（如下图所示）

PS：上述只是中台的起源含义，但它要根据公司规定具体的定义，比如我就处于我司的研发中台事业部，往下细分有产研部和质量平台，再细分又有各种小组（如云安全小组、云平台测试组）

Reference（参考）

1. DevOps：什么是 DevOps？
2. 云服务：IaaS versus PaaS versus SaaS
3. 极客时间：深入剖析 Kubernetes
4. 极客时间评论区：Docker 和 K8S 的渊源
5. 微服务：微服务是什么？
6. 中台：微服务、容器、云原生、Kubernetes、SOA、PaaS平台、Devops 之间的关系