《云原生架构进阶实战》精读笔记

写在前面

• 书籍介绍：本书从云原生的核心思想和理念开始，重点讲述企业引入云原生架构的必要条件、企业如何准备云原生开发和部署环境，企业如何运维云原生架构，并在最后提供云原生相关案例，为企业展现云原生的实战场景和步骤，从而让企业对云原生架构有一个直观的感受。
• 我的简评：暂无
• ！！福利：文末有pdf书籍、笔记思维导图、随书代码打包下载地址哦

第一章 云原生架构

1.1.云计算的演化

• 1. 虚拟化是将不存在的事物或现象虚拟成存在的事物或现象的方法，在计算机领域则是指软硬件资源的虚拟化。硬件资源的虚拟化包括计算资源虚拟化、存储资源虚拟化和网络资源虚拟化。
• 2. 虚拟化技术目前做得较好的公司有VMware、Citrix、Microsoft、RedHat 和 Oracle 等公司。
• 3. 人们更希望出现一种能够对计算、存储和网络等资源的按需自动分配、按使用量付费的服务，这就催生了云计算模式。

1.2.什么是云原生

• 1. 云原生（Cloud Native）概念是由Pivotal的Matt Stine在2013年首次提出的
• 2. 目前已经包括了 DevOps（Development 和Operations的组合）、持续交付（Continuous Delivery，CD）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）和十二要素（The Twelve-Factor App）等几大主题。
• 3. 原先的 IaaS 层升级为敏捷基础设施，而PaaS和SaaS层则合并为微服务架构
• 4. 云原生主要包括两部分内容：云原生基础架构和云原生应用

1.3.云原生基础架构

• 1. 云原生基础架构可以借助容器化技术和公有云技术去实现
• 2. 一般的公有云还是要借助人力去申请、分配。而云原生基础架构则是用程序代码自动去申请
• 3. Kubernetes的容器编排技术为云原生基础架构提供了必要的平台支撑功能。是否是云原生基础架构的关键在于是否使用自动化处理的方式。
• 4. 云原生应用对基础架构的基本要求有：运行时间和隔离；资源分配和调度； 环境隔离；服务发现；状态管理；监测和日志记录；度量聚合；调试和追踪

1.4.云原生应用

• 1. 云原生应用程序的关键在于提供弹性、敏捷性、可操作性和可观察性
• 2. 目前实现云原生应用程序所需特性的常用方法有：微服务；健康状况报告；自动测量数据；弹性；声明模式而不是响应模式；
• 3. 微服务：解决面向大量互联网用户提供服务的并发量问题，最好的方法之一就是分解单体应用为众多小的服务模块。
• 4. 微服务：UNIX哲学是“程序应该只关注一个目标，并尽可能把它做好。让程序能够互相协同工作
• 5. 健康状况报告：为了能够由软件控制一切，应用程序必须提供可供管理软件监测的度量指标
• 6. 健康状况报告：在云原生架构下，一切皆是代码，一切皆可由软件控制。
• 7. 自动测量数据：健康报告是告知管理程序所辖应用程序的生命周期状态，而自动测量数据是告知应用程序的业务度量指标。
• 8. 自动测量数据：度量的指标一般称为服务级别指标（Service Level Indicator，SLI）或关键绩效指标（Key Performance Indicator，KPI）。
• 9. 弹性处理故障：云原生应用程序应当正视故障而不是竭力避免故障。处理过载的一种常见方法是适度降级。最现实的处理方式是服务降级，返回部分回应或使用本地缓存中的旧信息进行回应。
• 10. 声明式通信：很多时候，网络通信是通过RESTful HTTP调用完成的，但也可以通过其他接口实现，例如远程过程调用（RPC）。
• 11. 声明式通信：传统应用程序可以通过消息队列、共享存储上的文件或触发 shell 命令的本地脚本来自动执行任务。

1.5.十二要素应用

• 1. 十二要素应用程序方法是 Heroku 的开发者起草的。十二要素中提到的特征并不特定于云提供者、平台或语言。
• 2. 一份基准代码（Codebase），多份部署（Deploy）：企业一般会采用代码版本控制系统来跟踪管理所有修订版本的代码库
• 3. 显式声明依赖关系（Dependency）：应用程序不会隐式依赖系统级类库。它一定通过依赖清单确切地声明所有依赖项。
• 4. 在环境中存储配置：十二要素应用推荐将应用的配置存储于环境变量中
• 5. 把后端服务（backing services）当作附加资源：后端服务是指程序运行所需要的通过网络调用的各种服务，如数据库（MySQL、CouchDB），消息/队列系统（RabbitMQ、Beanstalkd），以及缓存系统（Memcached）
• 6. 严格分离构建、发布和运行：基准代码通过构建、发布和运行三个阶段转化成一份部署。
• 7. 以一个或多个无状态进程运行应用：符合十二要素的应用程序的进程必须是无状态且无共享的。任何需要持久化的数据都需要存储在后端服务内。
• 8. 通过端口绑定（Port binding）来提供服务：符合十二要素的应用程序可以自我加载而不依赖于任何网络服务器。
• 9. 通过进程模型进行扩展：十二要素应用的进程不需要守护进程，也不需要写入PID文件，而是借助操作系统的进程管理器（如systemd）进行输出流控制、进程崩溃响应，以及进程的重启和关闭的请求。
• 10. 快速启动和优雅终止可最大化健壮性：十二要素应用的进程是可分解的（disposable），它可以瞬间开启或者停止。
• 11. 尽可能地保持开发、预发布和线上环境相同：十二要素应用要求必须缩小本地和生产环境的差异，企业可以使用Docker来进行环境的统一，无论是开发环境还是生产环境，都使用Docker来进行测试和正式运行。
• 12. 把日志当作事件流：在十二要素应用中则不应该考虑存储到自己的输出流，不应该试图去写或者管理日志文件。相反，每一个运行的进程都会直接将日志存储到标准输出（stdout）事件流。
• 13. 后台管理任务当作一次性进程运行：一次性管理进程应该和正常的常驻进程使用同样的环境。

1.6.实现云原生模式

• 1. 如果一个应用程序比较复杂，则应该采用微服务模式，将复杂功能拆分为细微的服务，然后通过集成这些细微服务来组装成一个应用系统。
• 2. 云原生应用并不限定语言，它只对诸如弹性、服务发现、配置、日志记录、健康检查和度量检查等模式有要求。
• 3. 目前常用的做法主要有两类：单一语言情况下，可以通过导入标准库的形式在程序代码中声明云原生特征；多语言情况下，则可以通过伴生（sidecar）模式来解决。该模式将实现各种功能的微服务应用通过容器化部属捆绑在一起。
• 4. 应用程序的集成、测试和部署应该是自动化、自助式的，按照DevOps文化来进行。

1.7.何时采用云原生

• 1. 企业的现有基础架构是否敏捷？
• 2. 企业的开发团队、部署团队、运维团队是否独立？技能是否相通？
• 3. 企业的业务是否需要更快地迭代，是慢步速应用还是快步速应用？
• 4. 企业是否有云原生应用？是否有满足十二要素的应用？是否有微服务等应用？
• 5. 以上问题的答案都是“是”，那么企业完全可以毫无顾虑地采用云原生架构

1.8.云设计模式

• .1. 为了在云中构建可靠、可扩展、安全的应用程序，Microsoft从可用性、数据管理、设计与实施、消息、管理和检测、性能和可伸缩性、弹性、安全等方面总结了34种模式。

1.9.服务网格（Service Mesh）

• 1. 服务网格是用于处理服务到服务通信的专用基础设施层。它负责通过包含现代云原生应用程序的复杂服务拓扑来可靠地传递请求。
• 2. 目前，服务网格已成为云原生堆栈的关键组件。
• 3. 服务网格的主要特点有：应用程序间通信的中间层； 轻量级网络代理；应用程序无感知；解耦应用程序的重试/超时、监控、追踪和服务发现。
• 4. 目前两款流行的服务网格开源软件Istio和Linkerd都已经在Kubernetes中集成，但是Istio的接受度和采用量更多一些。
• 5. Istio的功能可以细分为以下四个类别：流量管理：控制微服务之间的流量，以执行流量分割、故障恢复和金丝雀发布；安全性：在微服务之间提供基于身份的强认证、授权和加密；可观察性：收集度量值和日志，以更好地了解集群中运行的应用程序；策略：强制实施访问控制、速率限制和配额，以保护应用程序。

1.10.云原生的未来

• 1. 云原生应用不适合在传统的基础设施中运行，因为它需要更高程度的服务发现、可编程性、自动化、可观测性、强大的网络通信及安全性等。
• 2. 云原生基础设施发展并产生重大变革。这些变革主要出现了三种新兴趋势：新用例、超越核心构建的技术演进、生态系统成熟
• 3. 具体有：混合云环境中使用云原生基础设施架构；在边缘计算中引入云原生技术，简化管理；服务网格继续发展，并以Istio领先；发展基于Kubernetes的融合函数即服务的技术fPaaS（又称FaaS）；基于成本考虑，云原生技术更多部署在裸机或者针对容器化定制的微虚拟机上；越来越多的第三方软件提供商采用容器化技术轻量级部署；对有状态应用的支持越来越丰满；跨Kubernetes的成熟项目将会越来越多。

第2章 Kubernetes核心对象

2.1.Kubernetes架构

• 1. Kubernetes主要是通过API或者声明式配置管理容器化工作负载和服务的一整套系统
• 2. Kubernetes主要提供了以下功能：服务发现和负载均衡；存储编排；自动部署和回滚；管理资源；自我修复；密钥和配置管理；
• 3. Kubernetes 不是一个传统 PaaS 平台，它提供的功能包括部署、扩展、负载平衡、日志记录和监控，且解决方案都是可选和可插拔的
• 4. Kubernetes分控制节点（Master Node）和工作节点（Worker Node）
• 5. 工作节点（Node）是在 Kubernetes 中承载业务工作的节点。每个节点上都运行Docker、kubelet和kube-proxy等服务，从而保障Pod的正常运行。
• 6. Master节点是一个Kubernetes master组件，管理工作节点的方方面面。
• 7. Kubernetes中运行的所有镜像都来源于某个镜像库，可以是Docker Hub，也可以是客户自建的私有Docker镜像库。

2.2.命名空间

• 1. 命名空间（Namespace）是Kubernetes中的一个重要概念，如同编程语言中的命名空间，它把系统内部的对象归集到不同的逻辑小组中，从而便于分别管理

2.3.Pod

• 1. Pod是Kubernetes中创建应用的最小、最简单的基本执行单元。Pod封装了应用程序的容器（一个或多个）、存储资源、网络以及其他相关选项。
• 2. Pod支持多个协作容器组成一个有凝聚力的服务单元。Pod中的容器自动放置在同一个节点上，共同调度，共享资源和依赖关系，彼此通信，并协调何时可以终止，以及如何终止。
• 3. 初始化容器与普通容器非常像，除了如下两点：它们总是运行到完成；每个都必须在下一个启动之前成功完成；
• 4. 为了更精确地判断容器状态，Kubernetes中提供了就绪探针（Readiness Probe）和存活探针（Liveness Probe）。存活探针用于判断容器启动就绪后是否还在持续正常服务；就绪探针用于判断容器是否可以接受流量，是针对有前端服务的容器来讲的；
• 5. Google推出了一个busybox镜像，该镜像含有基本的网络工具，用于在容器网络中测试

2.4.部署

• 1. Kubernetes中的部署是指如何控制一组Pod的运行状态使其满足生产需要。部署分为无状态部署和有状态部署
• 2. ReplicaSet的目的是维护一组状态稳定的Pod副本，从而保证指定数量的相同Pod的可用性。
• 3. 部署（Deployment）是一个拥有ReplicaSet并通过声明来控制Pod滚动、更新的对象。虽然ReplicaSet可以独立使用，但是它主要被用作协调Pod创建、删除和更新的机制
• 4. 有状态部署（StatefulSets）是用于管理有状态应用程序工作负载的一种部署方法
• 5. 有状态部署适合以下场景：需要独特的网络标识符；需要独立持久的存储；需要有序的部署和扩展；需要有序的升级；
• 6. 一个DaemonSet确保每个节点上只运行一个副本。
• 7. DaemonSet适合以下场景：每个节点上运行集群存储后台驻留程序，例如glusterd、ceph；每个节点上运行日志守护程序，例如fluentd、logstash；每个节点上运行Prometheus node exporter、sisdig、collectd等代理；

2.5.服务

• 1. Kubernetes内部的部署只能在集群内部访问，若要暴露这些工作负载，Kubernetes提供了工作在 ISO/OSI 模型的传输控制层的服务和工作在应用层的 Ingress 两种方式暴露后端工作负载
• 2. Kubernetes服务（Service）定义了这样一种抽象：在逻辑上通过标签来选定一组Pod，提供一种策略，让外网和前端客户能够访问这组Pod
• 3. Headless Service中，.spec.clusterIP需要设置为“None”。这也就决定了Headless Service只能在集群内部使用
• 4. 类型通过Type的取值来描述：ClusterIP、NodePort、LoadBalancer、ExternalName
• 5. 可以在服务中设置外部IP，将服务暴露给这个外部IP，从而通过外部IP进入集群。
• 6. 主要将HTTP和HTTPS协议从外部路由到集群内部的Service。
• 7. Ingress可以为内部服务提供外网URL，也可以提供流量负载均衡功能、终止SSL/TLS功能以及基于名称的虚拟主机功能
• 8. 每个Ingress规则都包含以下信息：可选主机；路径列表；后端列表；
• 9. 现阶段的Ingress有三种类型：单一服务入口；简单扇出入口；基于名称的虚拟主机；

2.6.存储

• 1. Kubernetes中的存储是以卷来描述的。卷有静态卷和动态卷两种。云原生基础架构下，大多数场景需要使用动态卷
• 2. Kubernetes中支持的卷类型多达几十种，本书主要讲述以下几种：configMap、emptyDir、glusterfs、hostPath、persistentVolumeClaim
• 3. ConfigMap资源提供了一种将配置数据注入Pod的方法。存储在ConfigMap对象中的数据可以直接映射到Pod中。
• 4. emptyDir是与Pod生命周期相同的卷。在Pod创建时会先创建卷，在Pod销毁时，该卷也会被销毁。
• 5. glusterfs 是 RedHat 公司推出的集群文件系统，性价比高于存储厂商的方案。
• 6. hostPath卷是指将在主机节点的文件系统中的文件或目录加载到Pod中。
• 7. 持久卷声明（persistentVolumeClaim）是指在创建Pod时根据storageClass动态申请卷，然后加载到Pod中。这是在云原生架构下强烈建议的方式。

2.7.RBAC

• 1. 基于角色的访问控制（Role-based access control, RBAC）是Kubernetes基于某个用户的角色来控制对资源访问的方法
• 2. 角色是指在某个命名空间下的权限规则集合，而集群角色则是面向整个集群的权限规则集合。
• 3. 角色绑定是将角色中定义的权限授予用户或用户组。它包含授予权限的对象列表、引用的角色。

第3章 敏捷基础架构

• 1. 敏捷基础架构的目的是通过代码来自动化动态完成服务器部署、更新，以及存储和网络资源的动态分配，这样运维人员可以像开发软件系统一样快速迭代，从而迅速满足各项工作负载的即时需求

3.1.部署本地Repository

• 1. 在一个完善的DevOps环境下，必须对常用的Yum、Maven、Nuget、NPM和Docker实施本地库镜像
• 2. 部署本地 Repository 的方法有很多种，本书选用了 Sonatype Nexus Repository Manager
• 3. Nexus默认支持许多主流的软件包格式，如：Bower、Docker、Git LFS、Maven、npm、NuGet、PyPI、Ruby、Gems、Yum、Proxy、Rawfil
• 4. 每一类服务，都可以创建如下三种类型的Repository。 ● Proxy，对指定URL的库提供代理服务，并进行缓存。 ● Hosted，本地存储包，提供私有包的存储和发布服务。 ● Group，组合Proxy和Hosted同种格式在一起，通过同一个URL端点对外提供服务
• 5. 使用Repository的常见方法是：先建立一个Hosted类型的库，然后创建一个指向官方Repository 的 Proxy 类型的库，最后创建一个包含刚创建的 Hosted 类型和 Proxy 类型的Group类型。一般发布给用户作为读取的库只需要知道Group类型的库就可以了。如果要发布包到本地库中，则需要告知用户Hosted库的访问URL，并做好权限控制
• 6. 本书建议将多种Repository以Docker形式安装到一台虚拟机中，在虚拟机上以Docker形式提供各类服务，而不是分散安装到很多虚拟机中或者安装在Kubernetes集群中。
• 7. 在Docker中设置服务代理是通过修改服务配置来实现的。有三个环境变量可以设置： HTTP_PROXY、HTTPS_PROXY和NO_PROXY。
• 8. 在前端部署一个nginx 作为反向代理，对外提供80和443端口服务。
• 9. Nexus涉及三个端口：8081 Nexus系统默认端口，Maven、NPM、Raw等类型的库都要使用该端口；082 Docker Hosted库设置的HTTP端口；8083 Docker Group库设置的HTTP端口

3.2.部署Kubernetes

• 1. 操作系统选用CentOS 7，最小化安装，所有命令以root身份运行

3.3.部署MetalLB

• 1. Google 开源了MetalLB 项目（网址为 https://github.com/google/metallb ）。 MetalLB 作为 Pod 运行在Kubernetes中，为Kubernetes提供负载均衡。它主要有两个功能：地址分配和外部通告
• 2. MetalLB使用以下标准的路由协议来实现此目的：ARP/NDP；BG
• 3. MetalLB 由两部分组成：集群范围内的控制器和每个节点一个实例的协议通告者（Speaker）
• 4. MetalLB也能够很好地支持externalTrafficPolicy选项，并根据用户选择的策略和通告协议实施不同模式的通知
• 5. 但是Kubernetes目前暂不支持多协议共享IP，也就不允许通过同一个共享IP来提供UDP和TCP服务

3.4.部署GlusterFS

• 1. GlusterFS 是一个免费、开源的可扩展网络文件系统，具有强大的横向扩展能力，通过扩展可以支持PB级存储容量和处理数千个客户端。GlusterFS借助TCP/IP或InfiniBand RDMA网络将物理分布的存储资源聚集在一起，使用单一全局命名空间来管理数据。使用常见的现成硬件，用户可以为媒体流、数据分析以及其他数据和带宽密集型任务创建大型分布式存储解决方案。
• 2. GlusterFS的主要特性有：可横向扩展性；无元数据服务器要求；高可用性；全局统一命名空间；弹性卷管理；协议标准化；
• 3. 分布式卷是指将不同文件均匀分布在不同节点上
• 4. 部署GlusterFS的方法主要有以下几种：使用Ansible自动部署；使用下一代Gluster管理接口GlusterD2；容器部署；手工部署；

3.5.使用GlusterFS卷

• 1. 在Kubernetes中使用GlusterFS卷有以下两种形式：静态卷；动态；
• 2. 动态卷是通过RESTful API来实现卷的动态分配。目前最常见的方法是通过heketi来实现。heketi可以安装在实体机上，也可以在独立的Docker上创建

3.6.使用NFS卷

• 1. NFS 服务器上一般是通过export来描述已共享路径，通常也都具有空间配额功能

3.7.升级kubernetes

第4章 DevOps实战

• 1. DevOps 是开发（Development）和运维（Operations）的组合词，它是一种重视软件开发人员和IT运维技术人员之间沟通合作的文化、流程以及平台和工具。

4.1.DevOps实战

• 1. 这个过程与传统开发过程有以下几个区别： ● 开发人员不需要负责系统测试、发布和部署。 ● 开发人员所用开发环境应当与最终部署环境相同，可以借助容器实现环境相同。 ● 开发人员通过版本控制软件提交代码
• 2. 版本控制系统是开发环境的中心，它承载了代码管理、问题管理功能，甚至承载了自动集成、自动发布等功能
• 3. 常用模式是当版本控制系统中有代码提交时，就触发构建服务器进行源代码构建。常用软件有Jenkins和GitLab Runner
• 4. 当构建服务器确认了代码质量并进行构建后，构建结果应当存放在一个工件库中。NPM Repository、Docker Registry、Maven2 Repository都是针对不同开发语言或者对象的工件库
• 5. 当源代码构建成系统存放于工件库后，开发人员或者运维人员就可以在测试环境中对新系统进行测试。
• 6. 预发布环境是和正式生产环境一致的环境，该环境中运行的新构建的系统，与正式生产环境中的系统可以并行存在，并可以通过负载均衡设备按规则分发给预发布环境
• 7. 待所有前述流程都进行完毕，便可以进行发布。发布过程亦应自动化进行。以通过GitLab Runner进行发布，也可以借助Jenkins、Ansible、Puppet等工具自动化发布。
• 8. 云原生架构主要包含两部分：云原生基础架构和云原生应用

4.2.软件部署策略

• 1. 目前应用部署策略主要有六种：重建部署、滚动部署、蓝绿部署、金丝雀部署、A/B部署以及影子部署
• 2. 重建部署策略是最简单的一种部署方式。如图4-2所示，它采取的策略是先停止在线业务，然后部署新版本。
• 3. 滚动部署策略是指通过逐个替换应用的所有实例来缓慢发布应用的一个新版本
• 4. 蓝绿部署策略是指在不影响现有业务的情况下新增服务器进行新版本部署，待部署完成测试正常后，通过负载均衡设备将流量切换到新增服务器上，然后删除老版本服务器。
• 5. 金丝雀部署策略是指在蓝绿部署基础上，不采取一次性切换流量，而是按照一定比例分发流量到新旧两个版本系统上
• 6. A/B测试部署策略是在金丝雀部署策略的基础上。企业进行底层支持系统的切换（如单点登录系统、基于微服务的支撑系统等）时可以采取该策略
• 7. 影子部署策略是指同时部署了新旧两套系统，流量同时分发给新旧两套系统，但是新系统处理后的结果并不会返回给用户。这种方式主要是起到模拟作用，用来测试新版系统的性能、功能是否能够满足现有的流量需求

4.3.部署Gitlab

• 1. Git 是一个开源的分布式版本控制系统，旨在快速高效地处理从小型到大型项目的所有事务。Git易于学习、小巧，具有闪电般快速的性能。它超越了Subversion、CVS、Perforce和ClearCase等SCM工具，具有廉价本地分支、便捷的临时区域和多个工作流程等功能
• 2. 部署GitLab的方法主要有三种： ● 在操作系统中安装GitLab。 ● 使用Docker快速部署GitLab。 ● 在Kubernetes集群中部署GitLab
• 3. GitLab公司建议使用helm在Kubernetes中部署GitLab，可以参考https://docs.gitlab. com/charts/，

4.4. Gitlab集成自动CI/CD

• 1. 持续方法主要有三种： ● 持续集成（Continuous Integration, CI） ● 持续交付（Continuous Delivery, CD） ● 持续部署（Continuous Deployment, CD
• 2. 持续集成是指针对每次推送到代码库中的代码，通过一组脚本来自动构建、测试，从而减少向应用程序引入错误的可能性
• 3. 持续交付是持续集成的一个步骤。代码推送到代码库后通过一系列构建和测试，然后进行持续部署，如果部署是手动触发的，称为持续交付；如果是自动触发的，则称为持续部署
• 4. GitLab CI/CD是GitLab内置的强大工具，允许企业将所有持续方法（持续集成、交付和部署）应用于企业开发过程，而无须第三方应用程序或集成。

4.5.容器部署模式

• 1. 在设计微服务的集成时，尤其是非业务本身如弹性、服务发现、配置、日志、健康检查和度量标准等微服务必备元素，企业必须设计一种优良的模式。
• 2. Service Mesh架构的神奇，它降低了微服务架构相关的复杂性，并通过伴生模式提供了许多功能，如负载均衡、服务发现、流量管理、熔断等
• 3. sidecar模式的优势有：保持业务逻辑完整和可维护；提高业务容器的安全性；分离网络配置；内聚性/可复用性；
• 4. 依据sidecar模式的特点，企业可以在以下几个场景中使用该模式：代码同步（Git Sync）；保持服务配置更新；作为日志代理发送日志给服务器；反向代理和SSL终结；

第5章 日志记录

5.1.模式

• 1. 日志收集有两种模式：伴生（sidecar）模式和DaemonSet模式

5.2.日志采集

5.3.部署Elasticsearch

• 1. Elasticsearch的底层是开源的Lucene，Elasticsearch是对它的封装，并提供了RESTful API。Elasticsearch部署简易，开箱即用

5.4.部署Kibana

• 1. Kibana是一款开源的数据分析和可视化软件，它是 Elastic Stack成员之一，用于和 Elasticsearch协作。可以使用 Kibana对Elasticsearch索引中的数据进行搜索、查看、交互操作

5.5.部署fluentd作为syslog server

第6章 云原生下的监控

• 1. 日志记录一般使用ELK套件（Elasticsearch+Logstash+Kibana），也可以使用第5章讲述的EFK套件（Elasticsearch+Fluentd+Kibana）。监控则使用GPE套件（Grafana+Prometheus+Exporter）。

6.1.Prometheus简介

• 1. Prometheus是一个开源的监视和警报工具。
• 2. 作为新一代监控框架，Prometheus具有以下特点：强大的多维度数据模型；灵活而强大的查询语句（PromQL）；易于管理；高效；使用拉取（pull）模式采集时间序列数据；可以采用push gateway方式把时间序列数据推送至Prometheus server端；可以通过服务发现或者静态配置获取监控的目标（target）；有多种可视化图形界面；易于伸缩；
• 3. Prometheus 生态圈中包含了多个组件：Prometheus server：用于收集和存储时间序列数据；客户端库（Client Library）：为需要监控的服务生成相应度量值并暴露给Prometheus server；推送网关（Push Gateway）：主要用于短期执行的程序；Exporters：用于暴露已有第三方服务的度量给Prometheus；报警管理器（Alert manager）：从Prometheus server端接收到警报后，会去除重复数据、分组，并路由到报警服务，发出报警；
• 4. Prometheus可录制任何纯数字时间序列。它适用于以机器为中心的监控以及高度动态的面向服务架构的监控

6.2.使用Exporter采集数据

• 1. 在Prometheus架构中，Prometheus Server并不直接监控目标，它主要负责数据的收集、存储并且对外提供数据查询支持。
• 2. Prometheus社区提供了大量Exporter实现，基本上都是用Go语言编写的。
• 3. Exporter 基本上都是独立运行的，与所要监控的目标进程是相对独立的。Exporter 主要通过分析目标进程提供的相关接口来获取数据，然后将这些运行状态数据转换成可供Prometheus读取的监控数据，相当于中间代理人的角色
• 4. 比较常用的Exporter当属Node Exporter，它主要用来监控类UNIX操作系统的内核，提供硬件和操作系统层级的指标
• 5. cAdvisor（Container Advisor）是Google开源的一款用于分析容器资源使用和性能特征的可视化工具，在主机上运行cAdvisor可以轻松获得当前主机上容器的运行状态信息，并以图表形式向用户展示
• 6. Prometheus 社区提供了 Blackbox Exporter 进行黑盒监控，允许用户通过 HTTP、HTTPS、DNS、TCP以及ICMP协议对网络服务进行探测。

6.3.在Kubernetes中部署Prometheus

• 1. Prometheus服务主要为Grafana提供数据服务，Grafana主动向Prometheus拉取数据，因此Prometheus容器需要设置成可被其他服务访问
• 2. Prometheus 具备自动发现服务的功能，只需为 Prometheus 提供访问 Kubernetes 集群的API URL即可
• 3. 部署Prometheus可以使用Docker Hub上的prom/prometheus，并修改其配置文件路径和存储路径。

6.4.部署Blackbox Exporter

6.5.Node Exporter

• 1. Node Exporter 不是以普通 Pod 方式运行在集群中，而是以 DaemonSet 的方式在Kubernetes集群中每个节点上只运行一个示例

6.6.Grafana

• 1. Grafana 是一款开源的功能丰富的度量分析和可视化工具。它可以对数据源进行数据查询然后可视化展示，并具有通知告警功能
• 2. 主要特点有：可视化；告警；通知；动态仪表板；混合数据源；标记；即席（Ad-hoc）过滤器
• 3. Grafana 本身并不保存数据，其分析的数据源主要来自Graphite、InfluxDB、Prometheus、Elasticsearch、OpenTSDB、CloudWatch等系统

6.7.在Kuberbetes中部署Grafana

• 1. 在Kubernetes中部署Grafana如同部署一个普通应用一样简单，只需要创建持久卷，然后部署Grafana，再对外暴露Grafana服务即可
• 2. 部署Grafana相当于部署一个普通的无状态应用

6.8.案例：监控Drupal站点

第7章 服务网格应用

• 1. Peter Deutsch总结了常见“分布式系统的误区”。主要有以下几个方面：网络是可靠的：任何组件和基础设施都会发生故障，当规模足够大时，这将成为必然；可忽略的延迟、宽带是无限的：当业务高峰时，网络资源不足会导致系统稳定性下降；网络是安全的；拓扑结构不会发生变化；只有一个管理员；传输的代价是零；网络是同构的。

7.1.Istio架构

• 1. Istio、Linkerd作为服务网格技术的代表作，通过sidecar代理拦截了微服务之间的所有网络通信，用统一方式实现服务之间的负载均衡、访问控制、速率限制等功能
• 2. 数据平面由一组以sidecar方式部署的智能代理（Envoy）组成。
• 3. 控制平面通过负责管理和配置代理来路由流量： ● Pilot：负责流量管理。 ● Mixer：负责提供策略控制和遥测收集。 ● Citadel：负责提供通信的安全保护
• 4. Istio架构设计中有几个关键目标：最大化透明度；可扩展性；可移植性；策略一致性；
• 5. 使用 Istio 流量管理模型，本质上是将流量与基础设施扩容解耦，让运维人员可以通过Pilot指定流量遵循什么规则，而不是指定哪些Pod/VM应该接收流量—Pilot和智能Envoy代理会帮用户处理。
• 6. Istio提供了一个简单的配置模型，用来控制API调用以及应用部署内多个服务之间的四层通信。运维人员可以使用这个模型来配置服务级别的属性，这些属性可以是断路器、超时、重试，以及一些普通的持续发布任务，例如金丝雀发布、A/B 测试、使用百分比对流量进行控制，从而完成应用的逐步发布等
• 7. Istio中包含四种流量管理配置资源，分别是Virtual Service、Destination Rule、Service Entry以及Gateway。下面会讲解这几个资源的部分重点。 ● Virtual Service在Istio服务网格中定义路由规则，控制路由如何路由到服务上。 ● Destination Rule是Virtual Service路由生效后，配置应用与请求的策略集。 ● Service Entry通常用于在Istio服务网格之外启用服务的请求。 ● Gateway 为 HTTP/TCP 流量配置负载均衡器，最常见的是在网格边缘的操作，以启用应用程序的入口流量
• 8. Virtual Service 定义了在 Istio 服务网格中如何控制服务请求的路由规则
• 9. Destination Rule 还定义了对应目标主机的可路由 subset（例如有命名的版本）， Virtual Service在向特定服务版本发送请求时会用到这些子集
• 10. Istio内部会维护一个服务注册表，可以用Service Entry向其中加入额外的条目。通常这个对象用来启用对 Istio 服务网格之外的服务发出请求。
• 11. Gateway为HTTP/TCP流量配置了一个负载均衡，多数情况下在网格边缘进行操作，用于启用一个服务的入口（ingress）流量

7.2.安装与卸载Istio

7.3.使用Istio

• 1. Istio部署后，并不会立刻对现有Pod起作用，若要对某一命名空间注入Istio，可以通过kubectl label来标注

7.4.Istion常见场景

• 1. Istio 提供灵活的适配器模型（Mixer）来执行授权策略，并为网络中的服务提供多项功能，如日志收集、配额执行、授权系统和遥测指标收集系统
• 2. 分布式调用追踪：追踪信息由一组分段（span）组成，每个分段对应一个微服务。Istio通过在Envoy代理上收集这些 span 相关信息，实现对应用无侵入地分布式调用跟踪分析
• 3. 遥测度量收集：Envoy收集指标相关的原始数据，如请求的服务、HTTP状态码、调用时延等信息，并将这些指标数据发送给Mixer，通过Mixer Adapters将指标信息转换后发送到后端监控系统中，如 Prometheus 或者 InfluxDB 等
• 4. 灰度发布应用：Istio通过高度的抽象和良好的设计，采用一致的方式实现了灰度发布。
• 5. 采用Istio进行灰度发布的流程如下：部署新版本的服务，并通过路由规则将测试用户的流量指向新版本服务；待测试稳定后，运维人员修改路由规则，将生产流量按比例逐渐切换到新版本系统中，如按5%，10%，50%，80%逐渐导入；待新版本工作正常后，将所有流量导入到新版本服务中；
• 6. 在微服务架构中，存在着众多互相依赖的服务单元。若一个服务出现故障，就会形成故障蔓延，最终导致整个系统的瘫痪。为了解决这类故障传递问题，服务网格引入断路器实现熔断。断路器是创建弹性微服务应用程序的重要模式。断路器允许用户编写限制故障、延迟峰值以及消除其他不良网络特性影响的应用程序
• 7. 断路器模式是指在某个服务发生故障时，断路器的故障监控机制及时向服务调用方返回一个错误响应，避免调用方长时间等待，从而阻止了故障在整个系统中蔓延
• 8. 管理员通过destination policy设置断路触发条件和断路时间等参数。
• 9. Istio断路器还支持配置最大链接数、最大待处理请求数、最大请求数、每链接最大请求数和重试次数等参数。
• 10. 在微服务系统中存在大量服务实例，当部分服务实例出现问题时，微服务应用需要具有较高的容错性，通过重试、断路、自愈等手段保证系统能够继续对外正常提供服务。
• 11. Istio通过服务网格承载了微服务之间的通信流量，因此可以在网格中通过规则进行故障注入，模拟部分微服务出现故障的情况，对整个应用的健壮性进行测试
• 12. 服务网格的引入有利于微服务治理，并在不侵入应用程序的情况下实现微服务治理，回避了微服务的多元化问题，提高了维护的简易性

第8章 案例

• 8.1.在Kubernetes中部署Drupal 8 站点
• 8.2.云原生架构下的Node.js自动CI/CD方法
• 8.3.Apereo CAS自动横向缩放部署策略
• 8.4.Apache Kafka部署与使用
• 8.5.云原生应用架构在上海海事大学信息化建设中的实践

写在后面

• pdf书籍、笔记思维导图、随书代码打包下载地址：暂无，后面补上
• 思维导图在线查看：点击打开
• 得到电子书地址：点击阅读