update

isno · Jan 9, 2024 · 6cfdd97 · 6cfdd97
1 parent 862df91
commit 6cfdd97
Show file tree

Hide file tree

Showing 5 changed files with 26 additions and 38 deletions.
diff --git a/GitOps/summary.md b/GitOps/summary.md
@@ -1,11 +1,8 @@
 # 第十章 GitOps 落地实践
 
-现代软件工程领域中，无论是通过服务化的方式进行架构设计，还是使用敏捷开发流程，主要的目的都是提高开发效率，因此应用的构建和部署也要跟得上迭代的脚步。随着云原生技术和 PaaS 平台的普及以及 DevOps 文化的盛行，人们也一直在寻找一种能更好解决云环境中持续部署的最佳实践。在云原生时代继承 DevOps 思想，加速持续集成和持续部署的，这就是 GitOps。
-
-
 GitOps 起源于 weaveworks 公司在 2017 年发表的一篇博客：GitOps - Operations by Pull Request[^1]。在这篇文章中，作者 Alexis Richardson 介绍了一种以 Git 为唯一事实来源的软件部署方式。在这种方式下，我们需要将软件设施定义在 Git 仓库中进行管理，这里的软件设施不限于应用本身，也包括 IaaS、Kubernetes 这样的基础设置。每个工程师都可以通过提交 Pull Request 来修改软件设施，然后通过自动化程序（譬如 Flux CD、Argo CD）的方式在线上执行这些修改。
 
-这种方式的交付（使用声明式描述、使用 Git 类似的版本控制系统进行跟踪管理、更优雅的可观测性），开发人员可以更高效地将注意力集中在创建新功能而不是运维相关任务上（例如，应用系统安装、配置、迁移等）。
+这种方式的交付（使用声明式描述、使用 Git 类似的版本控制系统进行跟踪管理），开发人员可以更高效地将注意力集中在创建新功能而不是运维相关任务上（例如，应用系统安装、配置、迁移等）。
 
 
 

diff --git a/Observability/history.md b/Observability/history.md
@@ -8,10 +8,10 @@
 
 The information that you will use to determine whether an application is healthy and performing as designed is called telemetry data. 
 
-采样和汇总已知与应用程序性能问题相关的应用程序和系统数据，即遥测数据。
+遥测数据是指采样和汇总有关软件系统性能和行为的数据，这些数据（响应时间、错误率、资源消耗等）用于监控和了解系统的当前状态。
 :::
 
-事实上，我们进行可观测性，主要就是通过各类的遥测数据对分布式系统提供深⼊可⻅性，以此找到⼤量问题的根本原因并提⾼系统性能。学术界一般会将可观测性的遥测数据分解为三个更具体方向进行研究，它们分别是**事件日志、链路追踪和聚合度量**，这三个方向各有侧重，又不是完全独立，天然就有重合或者可以结合之处。2017 年的分布式追踪峰会结束后，Peter Bourgon 撰写了总结文章《Metrics, Tracing, and Logging》[^2]系统地阐述了这三者的定义、特征以及它们之间的关系与差异，受到了业界的广泛认可。
+事实上，我们进行可观测性，主要就是通过各类的遥测数据对分布式系统提供深⼊可⻅性，以此找到⼤量问题的根本原因并提⾼系统性能。学术界一般会将可观测性的遥测数据分解为三个更具体方向进行研究，它们分别是**事件日志、链路追踪和聚合度量**，总结对遥测数据的处理流程收集数据、存储（索引）、展示，再具体到事件日志、链路追踪和聚合度量这三个方向各有侧重，又不是完全独立，这三个流程之间有重合或者可以结合之处。2017 年的分布式追踪峰会结束后，Peter Bourgon 撰写了总结文章《Metrics, Tracing, and Logging》[^2]系统地阐述了这三者的定义、特征以及它们之间的关系与差异，受到了业界的广泛认可。
 
 <div  align="center">
 	<img src="../assets/observability.png" width = "350"  align=center />

diff --git a/Observability/logging.md b/Observability/logging.md
@@ -3,6 +3,7 @@
 你可能不知道 Metrics、Tracing，但你一定了解点 logging。logging 系统中最成熟的部分就是打印日志。尤其是本地日志打印，各式各样层出不穷的 logging Library，同步的异步的、有锁的无锁的、有上下文的无上下文的、高性能的低性能的，花活最多轮子也造的最多。
 
 
+日志最出名的方案莫过于 ELK，但除了 ELK 之外，还有一个新晋的佼佼者
 
 ## 收集
 
@@ -28,17 +29,14 @@ Elastic Stack 之所以流行的一个原因之一，可能是它的无侵入性
 
 这个系统中，Beats 部署到日志所在地，用来收集原始数据，然后使用 MQ 做缓冲换取更好的吞吐，接着发给 logstash 做数据清洗，最后落地到 es 集群并进行索引，使用时通过 Kibana 来检索和分析，如果有必要挂上 Nginx 做各类访问控制。
 
-<div  align="center">
-	<img src="../assets/logging.png" width = "550"  align=center />
-</div>
 
+## 存储与查询
 
-所以 ，loki的第一目的就是最小化度量和日志的切换成本，有助于减少异常事件的响应时间和提高用户的体验
+loki 一个明显的特点是非常经济，Loki 不再根据日志内容去建立大量的索引，而是借鉴了 Prometheus 核心的思想，使用标签去对日志进行特征标记，然后归集统计。Loki 只索引与日志相关的元数据标签，而日志内容则以压缩方式存储于对象存储中, 不做任何索引，这样的话，能避免大量的内存资源占用，转向廉价的硬盘存储。相较于 ES 这种全文索引的系统，数据可在十倍量级上降低，加上使用对象存储，最终存储成本可降低数十倍甚至更低。
 
+说白了，Loki 吸引人的地方就在于拥有和 Prometheus 类似机制的时序数据库以及方便拓展的硬盘资源。
 
-## 存储与查询
 
-不同的是，Loki 不再根据日志内容去建立大量的索引，而是借鉴了 Prometheus 核心的思想，使用标签去对日志进行特征标记，然后归集统计。这样的话，能避免大量的内存资源占用，转向廉价的硬盘存储。当然 Loki 会对日志进行分块存储并压缩，保留少量的元数据索引，兼顾硬盘的查询效率。
 
 数据由标签、时间戳、内容组成
 
@@ -55,32 +53,22 @@ Elastic Stack 之所以流行的一个原因之一，可能是它的无侵入性
 }
 ```
 
-只索引与日志相关的元数据标签，而日志内容则以压缩方式存储于对象存储中, 不做任何索引。相较于 ES 这种全文索引的系统，数据可在十倍量级上降低，加上使用对象存储，最终存储成本可降低数十倍甚至更低。
-
-
-## 日志展示
 
 
 
+## 日志展示
 
+在仪表可视化领域，如果 Grafana 称第二，应该没有敢称第一。
 
-使用Grafana可以非常轻松的将任何数据[^1]转成任何你想要的图表[^2]的展现形式来做到数据监控以及数据统计。
-
-
-在仪表可视化领域，如果 Grafana 称第二，应该没有敢称第一。Grafana slogn “Dashboard anything. Observe everything.” 可不是说说，
-
-:::tip 官网的副标题
-Grafana is the open source analytics & monitoring solution for every database.
-:::
-
-这个 every  database，只要你能想到的数据源，Grafana 都有官方或者非官方的数据源插件[^1]。
 
+在 Grafana Labs 公司成立之前，Grafana Dashboard 就已经在各个开源社区有不小的名气和用户积累。依靠社区的用户基础，Grafana Labs 也快速地将产品渗透至各个企业，如果你观察仔细，在各大新闻联播节目时不时会见到 Grafana 的身影：2016年，在猎鹰9号火箭首次发射期间，Grafana 出现在 SpaceX 控制中心的屏幕上；几周后，微软发布一段宣传视频，展示了他们的水下数据中心，同样出现了 Grafana 的身影[^3]。
 
-大致来说kibana能做的图形，grafana都可以做，grafana能做的展示效果，kibana不一定做的到。另外他们两点有些区别，就是如果你想做dashboard来展示的话，强烈推荐grafana。
+Grafana slogan 中的 “Dashboard anything. Observe everything.” 这个anything 和 everything 可不是说说，使用 Grafana 可以非常轻松的将任何数据[^1]转成任何你想要的图表[^2]的展现形式来做到数据监控以及数据统计。
 
 <div  align="center">
 	<img src="../assets/grafana-dashboard-english.png" width = "550"  align=center />
 </div>
 
 [^1]: 参见 https://grafana.com/grafana/plugins/data-source-plugins/
-[^2]: 参见 https://grafana.com/grafana/dashboards/
+[^2]: 参见 https://grafana.com/grafana/dashboards/
+[^3]: 参见 https://grafana.com/blog/2023/09/26/celebrating-grafana-10-top-10-oh-my-grafana-dashboard-moments-of-the-decade/
diff --git a/container/orchestration.md b/container/orchestration.md
@@ -1,6 +1,6 @@
 # 7.2 以容器构建系统
 
-仍有许多人把容器跟虚拟机相比，把容器当做性能更好的虚拟机，讨论如何把应用从虚拟机无缝迁移到容器。可是无论从实现原理还是使用方法、特性、功能等等，容器都与虚拟机没有任何相似，容器的性能优势必伴随其他方面的缺陷 -- 即容器不能完全模拟本地物理机环境中的部署方法。所以 也不存在一种普遍的方法，能够无缝地把虚拟机里面的应用迁移到容器中。“上云” 最终还是要深入理解容器的本质是什么。
+仍有许多人把容器跟虚拟机相比，把容器当做性能更好的虚拟机，可是无论从实现原理还是使用方法、特性、功能等等，容器都与虚拟机没有任何相似，也不存在一种普遍的方法把虚拟机里面的应用无缝地迁移到容器中。“上云” 最终还是要深入理解容器的本质是什么。
 
 那么，容器的本质是什么？如果把 Kubernetes 比作云时代的操作系统，那容器就是操作系统中的进程。
 

diff --git a/intro.md b/intro.md
@@ -1,23 +1,26 @@
 # 前言
 
-既然你翻开本书的第一页，如果你是一位互联网从业者，相信这几年你一定被层出不穷的技术概念迷惑：BigData（大数据）、Container（容器技术）、FaaS（函数即服务）、Serverless（无服务器架构）、ServiceMesh（服务网格）、DevOps、Observability...。相信我，此类的概念我可以一直写满一整页。但我想表达的意思是，这是个技术爆炸的时代，而软件的形态、技术方案迭代仿佛坐上了火箭。这样表现层的，可代替性  
+相信这几年你一定被层出不穷的新技术、名词、概念方法论迷惑：container、Kubnernetes、ServiceMesh、FaaS、Observability、Serverless、DevOps、FinOps...不一而足。
 
-分析这些变化背后的根因，你会发现有以下几个非常重要的驱动因素：
+每一个领域下都有7、9种选择，也难怪，行业的人被整的普遍焦虑，担心自己跟不上趋势，因技能过时而被淘汰。
 
-- 软件在改变世界
-- 互联网在加剧变化
-- 巨大规模以及敏捷开发带来的软件演进推动力
+你肯定不想花了很多时间去学习一门技术，刚刚学成就发现它已经被淘汰了，你付出巨大的精力学习，又承受这些软件在未来某一段时间取代消亡的尴尬境地，程序员职业变成了有巨大体力支撑的青春饭。或者搞了十年CRUD， 猛然回头才发现没有拿得出手的核心技能。面试时被问起自己的核心优势时，只能回答 “打字快”。
 
-软件的繁荣，总是能让收益，但又对技术决策者产生了选择以及权衡的难题。你付出巨大的精力学习，又承受这些软件在未来某一段时间取代消亡的尴尬境地，程序员职业变成了有巨大体力支撑的青春饭。
 
+这行业的很多变化只是昙花一现的表象，其根本性变化并没有那么快，很多“老”技术、 “老”方法在过去多年一直很有效，预计未来相当长时间仍然会保持有效。笔者举个例子，你看 Kubernetes 的网络方案，Cilium、Calico、Flannel、weave 表面五花八门，但它们的基本技术和底层原理总结下来基本没什么变化，只是把这些不同的计算机基本原理、方法重新组合起来，换种形式去解决因为业务变化带来的新问题。
 
-而软件之间的竞争更是成了 to be or not to be 生死存亡。用一个具体的例子，供你感受：Docker 2013 年横空出世、微服务时代如日中天、云原生时代黯然落幕，仅仅五六年时间。所幸，无论软件形态如何千变万化，如果尝试理清它们脉络，总能找到若干贯穿其中的一些共用的底层理论、方法论。你看 Kubernetes 的网络方案，Cilium、Calico、Flannel、weave 表面五花八门，但它们的基本技术和底层原理总结下来基本没什么变化。我们只是把这些不同的计算机基本原理、方法重新组合起来，换种形式去解决因为业务变化带来的新问题。
 
+真正有长久生命力并能作到历久弥新的技术是少数
 
-笔者也未曾花费精力去介绍某一种技术的 feature，软件的迭代速度是非常快的，越往上层，花活越多，埋没在技术的细节里，我“自大”地希望能说清楚问题的本质，解释清楚这样、那样的设计背后的考量，以及整个服务架构的发展历程, 走过了哪些弯路，以至于今天使用了哪些技术的缘由。讨论他们背后遵循的不变的原则，知晓这些技术做的取舍，探索它们的设计选择。
+笔者也未曾花费精力去介绍某一种技术的 feature，软件的迭代速度是非常快的，越往上层，花活越多，埋没在技术的细节里，
 
 
-技术圈里很多的基础原理和方法，几十年都未曾改变，善于思考总结的人总会从中得到相关的规律，所以，过时的不是基础的技术原理和方法，而是人的思考能力以及没有跟上节奏的对技术的认知。如果你想更进一步，开脱程序员的视野，逐步走上优秀程序员的队列，希望本书能作为你的引路人。
+而软件之间的竞争更是成了 to be or not to be 生死存亡。用一个具体的例子，供你感受：Docker 2013 年横空出世、微服务时代如日中天、云原生时代黯然落幕，仅仅五六年时间。所幸，无论软件形态如何千变万化，如果尝试理清它们脉络，总能找到若干贯穿其中的一些共用的底层原理、方法论。我“自大”地希望能说清楚问题的本质，解释清楚这样、那样的设计背后的考量，以及整个服务架构的发展历程, 走过了哪些弯路，以至于今天使用了哪些技术的缘由。讨论他们背后遵循的不变的原则、知晓这些技术做的取舍、探索它们的设计选择。
+
+
+善于思考总结的人总会从历史的进程中得到相关的规律，所以，**过时的不是基础的技术原理和方法，而是人的思考能力以及没有跟上节奏的对技术的认知**。
+
+如果你想更进一步，开脱程序员的视野，逐步走上优秀程序员的队列，希望本书能作为你的引路人。
 
 ## 本书适合哪些读者