下面是摘自维基百科的一段话。

微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通信。

看起来过于抽象，Service Mesh 在我看来，就是如何处理服务于服务之间的关系，如服务之间的相互调用关系，核心服务的熔断等，这不仅不含一个普通的 A 服务对 B 服务的一次 RPC 调用，也涉及RPC调用时具体的超时时间、重试次数等细节。最终目的是让整个服务形成一张网一般。而开发人员只需要注重自己的业务逻辑开发，而服务之间的联系全部交给 Service Mesh。

想象一下，你的代码不再需要考虑各种超时逻辑、也不需要考虑熔断和集成各种底层网络库。你的代码只有业务本身。

在K8S的中， Service 暴露给外界的三种方法。其中有一个叫作 LoadBalancer 类型的 Service，它会为你在 Cloud Provider（比如：Google Cloud 或者 OpenStack）里创建一个与该 Service 对应的负载均衡服务。

但是，由于每个 Service 都要有一个负载均衡服务，所以这个做法实际上既浪费成本又高。作为用户，我其实更希望看到 Kubernetes 为我内置一个全局的负载均衡器。然后，通过我访问的 URL，把请求转发给不同的后端 Service。

这种全局的、为了代理不同后端 Service 而设置的负载均衡服务，就是 Kubernetes 里的 Ingress 服务。

这篇文章将从K8S的架构、存储、网络及服务暴露等几个方面介绍,记录K8S的学习过程。

在之前的文章中介绍了如何编译支持HTTP3的Nginx 为了一键将H3 Nginx上云，一劳永逸，本文会记录一下容器化Nginx的过程。

之前的文章介绍了QUIC发生了什么, QUIC 已经演变成了一个“传输层”协议。其上可以运行 HTTP 协议。

从 HTTP/1.1（1999 年发布）到 HTTP/2 发布（2015 年发布）之间的发展差距很大，随着 2019 年 HTTP/3 的发布，HTTP/3 即将成为互联网上超文本传输协议的下一代协议，HTTP/3 是Google QUIC协议的演变。它与传统的 HTTP 有很大的不同。QUIC 是一种新的可靠传输协议，可以被视为一种下一代TCP。