From 63c452a81842812ab9d4f74ee80e7e21476e6f32 Mon Sep 17 00:00:00 2001 From: isno Date: Fri, 5 Jan 2024 23:45:19 +0800 Subject: [PATCH] =?UTF-8?q?=E6=9B=B4=E6=96=B0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ServiceMesh/overview.md | 5 ++--- architecture/architect.md | 4 +++- http/https.md | 2 +- 3 files changed, 6 insertions(+), 5 deletions(-) diff --git a/ServiceMesh/overview.md b/ServiceMesh/overview.md index f29ecf44..d80ed7b6 100644 --- a/ServiceMesh/overview.md +++ b/ServiceMesh/overview.md @@ -2,10 +2,9 @@ 互联网大厂凭借其技术方面的深厚功力与持续投入，在最近几年已经完成了服务网格从初期探索到大规模生产应用的跨越；中小型互联网公司也紧跟大厂步伐，顺应云原生技术浪潮，完成了服务网格“初体验” -2016年1月，Buoyant 初次发布 Linkerd，第一代的 Linkerd 以Scala编写，作为业界第一个开源的service mesh方案，linkerd 绝大部分关注点都是如何做好 proxy 并完成一些通用控制面的功能，专注于 proxy 的还有 Lyft 开发的 envoy，envoy 基于C++ 11编写，是CNCF 继 Kubernetes、Prometheus 第三个孵化成熟的项目，无论是理论上还是实际上，后者性能都比 Linkderd 更好。这两个开源实现都是以 sidecar 为核心，，但是，当你在容器中大量部署 sidecar 以后，如何管理和控制这些 sidecar 本身就是一个不小的挑战。于是，第二代 Service Mesh 应运而生。 +2016年1月，Buoyant 初次发布 Linkerd，第一代的 Linkerd 以Scala编写，作为业界第一个开源的service mesh方案，linkerd 绝大部分关注点都是如何做好 proxy 并完成一些通用控制面的功能，专注于 proxy 的还有 Lyft 开发的 envoy，envoy 基于C++ 11编写，是CNCF 继 Kubernetes、Prometheus 第三个孵化成熟的项目，无论是理论上还是实际上，后者性能都比 Linkderd 更好。这两个开源实现都是以 sidecar 为核心，但实际应用中问题不少（特别是 Linkerd，其明显的资源消耗、性能影响广受诟病）。此外，这一代的产品仅限于数据层面的代理功能，当在容器中大量部署 sidecar 以后，如何管理和控制这些 sidecar 本身就是一个不小的挑战。 -还是仅限于数据层面的代理功能，虽然理念先进，但其明显的资源消耗、性能影响广受诟病。 -2017年5月，Google、IBM、Lyft 宣布新一代的服务网格 Istio 开源，有巨头背书以及新增控制平面的设计理念让 Istio 得到极大关注和发展，并迅速成为 ServiceMesh 的主流产品。 +得有个什么东西管理控制 Sidecar，于是，第二代 Service Mesh 应运而生。2017年5月，Google、IBM、Lyft 宣布新一代的服务网格 Istio 开源，有巨头背书以及新增控制平面的设计理念让 Istio 得到极大关注和发展，并迅速成为 ServiceMesh 的主流产品。 ServiceMesh 最基础的功能毕竟是 sidecar proxy，提到 proxy，怎么能少得了以 Nginx 代表的远古代理亦或资深微服务API玩家。毫不意外，nginx 推出了其 service mesh 的开源实现：nginMesh。APISIX 也在 2010年 5月推出了 apisix-mesh-agent 产品。与 William Morgan 的死磕策略不同，这些在 Proxy 领域根基深厚玩家，从一开始就没有想过要做一套完整的第二代 Service Mesh 开源方案，而是直接宣布兼容 Istio, 作为 Istio 的数据面。 diff --git a/architecture/architect.md b/architecture/architect.md index 3f41164f..ec0ae84c 100644 --- a/architecture/architect.md +++ b/architecture/architect.md @@ -21,7 +21,9 @@ 行文至此，云原生技术概论的篇章已经结束，细心的读者会注意到一个小问题，本书的命名是“深入架构原理...”，而不是“深入云原生架构...”，虽然云原生是一个足够宏观、广泛的课题，但对于构建高品质的软件产品而言，其影响服务质量还包括前端、网络、后端等等，云原生并不能涵盖所有环节，约束理论也是要求优化整体而不是单个的“孤岛[^1]。 -此外，对那些链路极长、逻辑极复杂的系统来说，"高可用"架构往往是一个伪命题，只要是人开发的系统，代码就总会携有缺陷。看似”稳定“的系统，它可能在随机某个时刻出现突发的问题。可靠的系统应当具备容错性，能够预料并应对这些故障，并将冲击降低到最小的程度，尽可能的缩小整体时效时间。处理这些意外，唯有具备深厚的基础和广泛的知识面，此后面对突发故障虽可能无法立即解决，但至少可以准确地看出源头，从而找到解决问题的正确路径。 +此外，对那些链路极长、逻辑极复杂的系统来说，"高可用"架构往往是一个伪命题，只要是人开发的系统，代码就总会携有缺陷。看似”稳定“的系统，它可能在随机某个时刻出现突发的问题。 + +既然问题不可避免，那我们就充分预测问题、设计更多的容错、做更多的演练，尽可能的缩小整体失效时间，努力将冲击降低到最小的程度。泛泛而谈容易，实操极难。架构师的最佳实践是从制造故障解决故障中成长，单当系统已经成熟，新手没有空间，那就唯有具备深厚的基础和广泛的知识面，此后面对突发故障虽可能无法立即解决，但至少可以准确地看出源头，从而找到解决问题的正确路径。 受限于笔者的功力，内容有诸多不足，但”足够的广度和一定范围内的深度“也是本书着重想要表达的内容。 diff --git a/http/https.md b/http/https.md index b842bc03..1fda80bd 100644 --- a/http/https.md +++ b/http/https.md @@ -27,7 +27,7 @@ HTTPS 流程中涉及了证书、CA、TLS、对称/非对称加密等繁杂的 不过问题还是存在，虽然协商过程解决了对称加密算法或秘钥独立性问题，但协商过程依旧是明文的，密钥仍然存在被截获的可能性。为了解决这个问题，只能继续对协商过程的数据进行加密。这个环节必须换一种思路，如果仍然采用对称加密方式，就会产生无限套娃的情况。 -我们引入一个新的概念：非对称加密算法。 +只使用对称加密就会陷入死胡同，我们引入一个新的概念：非对称加密算法。 :::tip 非对称加密 非对称加密有两个密钥：公钥、私钥，私钥加密的密文只能公钥解，公钥加密的密文只能私钥解。