原文链接：https://www.infoq.com/articles/envoy-service-mesh-cascading-failure 作者：Jose Nino 作者：Daniel Hochman 译者：殷龙飞 关键要点 在过去的四年中，Lyft 已从单体架构转变为数百个微服务。随着微服务数量的增加，由于级联故障或意外内部拒绝服务导致的中断次数也在增加。 今天，这些故障情况在 Lyft 基础设施中基本上是一个已解决的问题。Lyft 部署的每项服务都通过使用 Envoy 代理自动获得吞吐量和并发保护。 Envoy 可以作为中间件部署或仅在请求入口时部署，但最大的好处来自于在应用程序本地的入口和出口部署它。在请求的两端部署 Envoy 允许它充当服务器的智能客户端和反向代理。 在接下来的几个月里，Lyft 将与 Netflix 的并发限制库背后的团队合作，将基于其库的系统带入 Envoy L7 过滤器。 级联故障是高吞吐量分布式系统中不可用的主要原因之一。在过去的四年中，Lyft 已从单体架构转变为数百种微服务。随着微服务数量的增加， 由于级联故障或意外内部拒绝服务导致的中断次数也在增加。今天，这些故障情况在 Lyft 基础设施中基本上是一个已解决的问题。 Lyft 部署的每项服务都会自动获得吞吐量和并发保护。通过对我们最关键的服务进行一些有针对性的配置更改，基于负载的事件减少了 95％，从而影响了用户体验。 在我们检查特定的故障情况和相应的保护机制之前，让我们首先了解如何在 Lyft 部署网络防御。Envoy 是一个 源自 Lyft 的代理， 后来开源并捐赠给 Cloud Native Computing Foundation 。Envoy 与许多其他负载均衡解决方案的区别在于它被设计为以“网格”配置部署。 Envoy 可以作为中间件部署或仅在请求入口时部署，但最大的好处来自于在应用程序本地的入口和出口部署它。在请求的两端部署 Envoy 允许它充当服务器的智能客户端和反向代理。 在双方，我们可以选择采用速率限制和断路来保护服务器免受各种情况下的过载。 核心概念 并发和速率限制 并发和速率限制是相关的，但不同的概念; 同一枚硬币的两面。在考虑限制系统负载时，运营商传统上会考虑每秒的请求数。 限制发送到系统的请求的速率的行为是速率限制的。通常进行压力测试以确定服务将变为过载的请求率，然后将限制设置在低于该点的某处。 在某些情况下，业务逻辑决定了速率限制。 在硬币的另一面，我们有并发性，即同时使用多少个单元。这些单位可以是请求，连接等。例如，我们可以考虑某个时间点的并发飞行请求数，而不是考虑请求率。 当我们考虑并发请求时，我们可以应用排队理论来确定服务在队列开始构建之前可以处理的并发请求数，请求延迟增加，以及服务因资源耗尽而失败。 全局与本地决策 Envoy 中的断路器是根据本机信息计算的。每个 Envoy 实例都会跟踪自己的统计数据并制定自己的断路决策。与全局系统相比，该模型具有一些优势。 第一个是可以在内存中计算限制，而无需对中央系统进行网络调用。第二个是限制随着集群的大小而扩展。第三，限制考虑了机器之间的差异， 无论它们是否收到不同的查询组合，或者在性能上有差异。 [Read More]

原文链接：https://searchitoperations.techtarget.com/tip/Istio-service-mesh-tech-boosts-Kubernetes-work-with-trade-offs 作者：[Alan R. Earls 译者：殷龙飞 为什么 IT 团队不可以使用一种工具，使开发人员能够专注于编写应用程序代码，使管理员可以以专注于 IT 资源的操作？尽管如此，Istio 确实需要研究利弊。 Kubernetes 是一个开源容器编排系统，它提供了管理和扩展容器化应用程序的强大功能，但有些事情它不能很好地完成。而 Istio 增加了额外的支持，它可以管理微服务之间的流量。 Istio 服务网格项目是平台无关的，协作和开源的，由 IBM，Google 和 Lyft（基于应用程序的传输服务）开发。它使用代理 sider car 模型在云平台上连接，保护，管理和监控微服务网络。Istio 明确定义了基础架构的作用，与运行在其上的软件分离。 Istio 整合的利弊 编排工具 Kubernetes 与 Istio 的整合，可以让开发人员和 IT 管理员在应用程序容器化这一共同目标上一起努力，IT 管理软件提供商 SolarWinds 的首席软件架构师 Karlo Zatylny 表示: “软件开发人员……将注意力集中在编写能够创造最大商业价值的代码上”。他们不需要考虑部署因素，例如支持容器的 VM 和物理环境。 Zatylny 说：通过 Istio，IT 管理员可以专注于计算资源和网络资源，而不是处理特定的硬件和虚拟分配。部署的基于微服务的应用程序在消耗可用资源方面变得更有效率，而不是在过度使用未充分利用基础架构的某些部分。Istio 还使用配置驱动的通信架构，这提高了开发周期的速度，因此开发人员可以在业务需求变化时轻松地进行软件重新设计。 尽管代码重用和其他设计选择使复杂性最小化，但 Istio 服务网格设计带来了复杂性和额外的管理开销。 Istio 在上行和下游提供负载平衡，授权，可见性和运行状况检查，使管理员能够查找，连接和路由各个部署部分。IDC 分析师 Brad Casemore 表示，它将网络应用于开放系统互连模型第7层的微服务交付环境，而不是IP的第3层或第2层的以太网。 Red Hat 产品管理高级主管 Rich Sharples 说，在 Istio 服务网格中控制和数据平面之间的分割概念可能会使用户感到困惑，但实际上相当简单。数据平面使用简单的代理体系结构来调解服务网格中每个服务的所有入站和出站流量。控制平面处理服务注册和发现，认证，访问控制，证书管理（即签名，发布和撤销）和服务网格配置，以及来自服务和服务代理的遥测数据。 服务网络可在 API 后面实现安全，可靠的服务器到服务器通信。“当你构建微服务时，你通常会公开一个 API，它会公开功能，然后通过一系列服务来实现”， Gartner 分析师 Anne Thomas 表示。因为容器是短暂的，这意味着它们不会保留会话信息，管理员必须定期重新连接它们，并且它们需要安全授权功能，以确保部署的服务器到服务器通信受到保护和运行。 [Read More]

Spring 5 源码分析之Spring技术内幕的读书笔记 再读Spring技术内幕，由于之前没做笔记，再读一次觉得做个记录很有必要，这里会把我看这本书的所看所想做简单地记录，首先发现书中讲的Spring版本太老了，书中的Spring版本讲的是3.x版本的，现在Spring版本已经是5.x了，我会把更新部分的内容同样写出来，这里做个做一个读书笔记，看到少写多少吧，以免到时候忘的干净，第一章讲了Spring家族产品包含那些，例如Spring core，spring bean,spring tx,spring mvc spring android等等，讲了Spring的由来，以及Spring的设计理念。不过接下来第二章比较有意思，开始讲SpringIoc的设计原理，在Spring的Ioc中主要有BeanFactory这个接口，根据这个最原始的容器定义接口分别扩展出不同的接口， Spring Ioc容器的实现 这里上一下ioc主要的核心接口设计图 书中主要讲的一个代表性容器是XmlBeanFactory，比过这个容器在5.X时已经设置为不推荐使用的状态，这个类的继承实现类图如下所示，从注释上来看，这个类在3.1时已经不推荐用了，推荐直接用DefaultListableBeanFactory @Deprecated @SuppressWarnings({"serial", "all"}) public class XmlBeanFactory extends DefaultListableBeanFactory { private final XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(this); /** * Create a new XmlBeanFactory with the given resource, * which must be parsable using DOM. * @param resource the XML resource to load bean definitions from * @throws BeansException in case of loading or parsing errors */ public XmlBeanFactory(Resource resource) throws BeansException { this(resource, null); } /** * Create a new XmlBeanFactory with the given input stream, * which must be parsable using DOM. [Read More]

原文链接：https://www.circonus.com/2018/06/comprehensive-container-based-service-monitoring-with-kubernetes-and-istio/ 作者：Fred Moyer 译者：殷龙飞 运营容器化基础设施带来了一系列新的挑战。您需要对容器进行测试，评估您的 API 端点性能，并确定您的基础架构中的不良的组件。Istio 服务网格可在不更改代码的情况下实现 API 的检测，并且可以自由的设置服务延迟。但是，你如何理解所有这些数据？用数学的方式，对，就是这样。 Circonus 是 Istio 的第一个第三方适配器。在 之前的文章中，我们讨论了第一个用于监视基于 Istio 的服务的 Istio社区适配器。这篇文章将对此进行扩展。我们将解释如何全面了解您的 Kubernetes 基础设施。我们还将解释如何为基于容器的基础架构增加 Istio 服务网格实现。 Istio 概述 Istio 是 Kubernetes 的服务网格，这意味着它负责所有服务之间的通信和协调，就像网络路由软件为 TCP/IP 流量所做的一样。除了 Kubernetes 之外，Istio 还可以与基于 Docker 和 Consul 的服务进行交互。它与 LinkerD 相似，它已经存在了一段时间。 Istio 是由 Google，IBM，思科和 Lyft 的 Envoy 开发的开源项目。该项目已经有一年的历史了，而 Istio 已经进入了大规模生产环境。在这篇文章发布时，当前版本为 0.8。 那么，Istio 如何融入Kubernetes 生态系统？Kubernetes 充当数据层，Istio 充当控制层。Kubernetes 承载应用程序流量，处理容器编排，部署和扩展。Istio 路由应用程序流量，处理策略执行，流量管理和负载均衡。它还处理遥测联合，如指标，日志和跟踪。Istio 是基于容器的基础设施的交叉防护装置和报告部分。 上图显示了服务网格体系结构。Istio 为每项服务使用了一个 envoy sidecar proxy。Envoy 通过 GRPC 调用代理到 Istio Mixer 服务的入站请求。然后，Mixer 应用流量管理规则，并联合请求遥测。Mixer 是 Istio 的大脑。运维人员可以编写 YAML 文件来控制 Envoy 如何重定向流量。他们还可以指定监测信息推送和可观测性系统的遥测技术。可以在运行时根据需要应用规则，而无需重新启动任何 Istio 组件。 [Read More]

原文链接：https://searchitoperations.techtarget.com/feature/Service-mesh-architecture-radicalizes-container-networking 作者：Beth Pariseau 译者：殷龙飞 容器化是IT行业最喜欢的超级英雄，因此容器在服务网格中具有强大的伙伴关系是唯一的选择。他们一起对抗网络管理混乱。 这篇文章也可以在高级版中找到。 现代堆栈：Kubernetes sidecar 是否能提供容器般的快乐？ Beth Pariseau 高级新闻作家 容器和微服务产生了一种称为服务网格的新型网络架构范例，但 IT 行业观察人士对它是否会看到广泛的企业用途持不同意见。 服务网格体系结构使用一个代理，该代理称为附加到每个应用程序容器，虚拟机或容器编排 pod 的 *sidecar 容器*，具体取决于所使用的服务网格的类型。然后，该代理可以连接到集中式控制平面软件，这些软件收集细粒度的网络遥测数据，应用网络管理策略或更改代理配置，建立并执行网络安全策略。 IT系统中的服务网格体系结构还处于初期阶段，但与集装箱一样，其突出地位一直很快。在 2017 年 12 月云原生计算基金会（CNCF）的 KubeCon 和 CloudNativeCon 上，服务网格已经绕过容器成为尖端 DevOps 商店中最热门的主题。 “我们经常发现自己希望构建应用软件，但我们实际上在做的是一遍又一遍地编写相同的代码来解决某些实际上非常困难的计算机科学问题，这些问题应该被考虑到某种通用接口中”，微服务监控创业公司 LightStep 首席执行官 Ben Sigelman 在 KubeCon 的服务网格主题演讲中表示。 “服务网格可以帮助发现服务，互连这些服务，断路由，负载均衡，……安全和身份验证” , Sigelman说，他是前谷歌工程师，OpenTracing 的创建者，OpenTracing 是开源的，提供不依赖供应商的 API。 服务网格简史 最早版本的 sidecar 代理技术在 2016 年初开始出现在网络规模的商店，如谷歌和推特，微服务管理需要对网络进行新的思考。与传统的单体应用程序不同，微服务依靠外部网络来沟通和协调应用程序功能。这些微服务通信需要密切监控，有时需要大规模重新配置。 用于使微服务网络管理自动化的最早技术依赖于库，作为应用程序代码的一部分进行部署，如 Netflix 的 Hystrix。因此，开发人员需要进行网络管理。这些库也必须用特定环境中使用的每种应用程序语言编写。这提出了一个难题，因为微服务精神的一个主要原则是小团队可以自由地使用任何语言进行独立的服务管理。 大多数认为自己正在做微服务的组织并没有真正做到真正的微服务。 安妮托马斯分析师，Gartner 在 2016 年初，在 Twitter 上实施了第一批微服务的工程师成立了 Buoyant 公司，该公司采用 sidecar 代理方法替代应用程序库。Buoyant 在 2016 年年中创造了术语*服务网格*，其最初的服务网格产品 Linkerd 使用 Java 虚拟机（JVM）作为 sidecar，这种设计将网络管理负担从应用程序开发人员转移出来，并支持对多语言的集中管理应用网络。到目前为止，Linkerd 是主流企业 IT 商店中唯一上生产环境的服务网格体系结构。使用的客户包括 Salesforce、PayPal、Credit Karma、Expedia 和 AOL。 [Read More]

原文链接：https://hackernoon.com/traffic-routing-between-fn-functions-using-fn-project-and-istio-fd56607913b8 作者：Peter Jausovec 译者：殷龙飞 在本文中，我将解释如何在 Fn 函数之间使用 Istio 服务网格实现基于版本的流量路由。 我将首先解释 Istio 路由的基础知识以及 Fn 部署和运行在 Kubernetes 上的方式。最后，我将解释我是如何利用Istio 服务网格及其路由规则在两个不同的 Fn 函数之间路由流量的。 请注意，接下来的解释非常基本和简单 - 我的目的不是解释 Istio 或 Fn 的深入工作，而是我想解释得足够多，所以您可以了解如何使自己的路由工作。 Istio 路由 101 让我花了一点时间来解释 Istio 路由如何工作。Istio 使用 sidecar 容器（ istio-proxy ）注入到您部署的应用中。注入的代理会劫持所有进出该 pod 的网络流量。部署中所有这些代理的集合与 Istio 系统的其他部分进行通信，以确定如何以及在何处路由流量（以及其他一些很酷的事情，如流量镜像，故障注入和断路由）。 为了解释这是如何工作的，我们将开始运行一个 Kubernetes 服务（myapp）和两个特定版本的应用程序部署（v1和v2）。 在上图中，我们有 myapp 一个选择器设置为 Kubernetes 的服务app=myapp , 这意味着它将查找具有 app=myapp 标签集的所有 Pod，并将流量发送给它们。基本上，如果您执行此操作，curl myapp-service 您将从运行 v1 版本应用程序的 pod 或运行 v2 版本的 pod 获得响应。 我们还有两个 Kubernetes 部署 - 这些部署myapp运行了 v1 和 v2 代码。除 app=myapp 标签外，每个 pod 还将version标签设置为 v1或 v2。 [Read More]

原文链接：https://medium.com/@prune998/istio-envoy-cert-manager-lets-encrypt-for-tls-14b6a098f289 作者：Prune 译者：殷龙飞 更新 感谢 Laurent Demailly 的评论，这里有一些更新。这篇文章已经得到了更新： 现在有一个 Cert-Manager 官方 Helm 图表 Istio Ingress 也支持基于 HTTP/2 的 GRPC Istio Istio 是管理微服务世界中数据流的一种新方式。事实上，这对我来说更是如此。 人们不停的谈论微服务与单体应用，说微服务更好开发，易于维护，部署更快…… 呃，他们是对的，但微服务不应该仅仅是小应用程序之间互相通信。微服务应该考虑沉淀为你的基础设施的这种方式。考虑如何决定您的“简单”应用程序公开指标和日志的方式，考虑您如何跟踪状态，考虑如何控制服务之间的流程以及如何管理错误，这些问题应该是做微服务应该考虑的。 那么 Istio 能够在这个微服务世界中增加什么？ Istio 是一个服务网格的实现！ Whaaaaaat？服务网格？我们已经有了 Kubernetes API，我们需要“网格”吗？ 那么，是的，你需要服务网格。 我不会解释使用它的所有好处，你会在网上找到足够的文档。但是用一句话来说，服务网格就是将您所有的服务提供给其他服务的技术。 事实上，它还强制执行所有“微服务”最佳实践，例如添加流量和错误指标，添加对 OpenTracing（ Zipkin 和Jaegger）的支持，允许控制重试，金丝雀部署……阅读 Istio doc ！ 所以，回到本话题… 必要条件 建议运行在 Kubernetes1.7 及以上的集群版本 一个或多个 DNS 域名 让 Istio 利用Ingress Controller 在你的集群中工作 将上面的 DNS 域名配置为指向 Istio Ingress IP SSL SSL 是安全的（很好），但它通常是软件中实现的最后一件事。为什么？之前它实现起来是“很困难的”，但我现在看不出任何理由。Let’s Encrypt 创建一个新的范例，它的 DAMN 很容易使用 API 调用创建 Valide SSL 证书（协议被称为ACME …）。它为您提供 3 种验证您是域名所有者的方法。使用 DNS，使用 HTTP 或第三种解决方案的“秘密令牌”不再可用，因为它证明是不安全的。 [Read More]

Aspen Mesh的Andrew Jenkins说，转向微服务本身并不能消除复杂性。 知识共享零 在本文中，我们与Aspen Mesh的首席架构师Andrew Jenkins谈论了如何从单一应用程序转向微服务，并通过一些关于服务网格的宣传来管理微服务架构。有关服务网格的更多信息，请考虑参加于2018年5月2日至4日在丹麦哥本哈根举行的KubeCon + CloudNativeCon EU。 微服务解决了许多公司面临的单片架构问题。你在哪里看到最大的价值？ Andrew Jenkins ： 对我来说，这是关于最小化时间对用户的影响。向虚拟化和云转型的关键是降低与支持应用程序的所有基础架构相关的复杂性，以便您可以灵活地分配服务器和存储等。但是这种转变并不一定会改变我们构建的应用程序。现在我们有了灵活的基础架构，我们应该构建灵活的应用程序以充分利用它。 微服务是那些灵活的应用程序 - 构建小型，单一用途的模块并快速构建它们，以便您可以快速将它们交付给最终用户。组织可以使用它来根据实际用户需求进行测试并迭代构建。 2.随着企业从单一应用程序向微服务转移，收益显而易见，但公司在采取行动时遇到的一些挑战是什么？ Jenkins ： 转向微服务本身并不能消除复杂性。任何一个微服务的复杂性都很小，但是整个系统都很复杂。从根本上说，公司希望知道哪个服务正在与哪个服务对话，代表哪个服务对象，然后能够使用策略来控制该通信。 经许可使用 3.组织如何尝试应对这些挑战？ Jenkins ： 一些公司从第一天起就将这种可见性和策略部分添加到他们构建的每个应用程序中。当公司投资于定制工具，工作流程，部署管理和 CD 管道时，这种情况尤其常见。我们也发现这些公司通常是以几种语言为导向，并且几乎写出他们自己运行的所有内容。 如果您的应用程序堆栈是多边形的，并且是新开发和迁移现有应用程序的组合，则很难证明将这些部分单独添加到每个应用程序是合理的。来自不同团队和外部开发的应用程序的应用程序更多地提高了这一点，一种方法是分别对待那些不符合要求的应用程序 - 将它们置于策略执行代理之后，或者从可见性角度将它们视为更多的黑盒子。但是，如果你不必做出这种分离，那么如果有一种简单的方法来获得任何语言的任何应用程序的原生式策略和可见性，那么你可以看到它的优势。服务网格就是这样的一种方法。 4.作为管理微服务架构的最终解决方案，围绕服务网格存在大量宣传。你的想法？ Jenkins ：是的，这绝对是攀登炒作循环曲线。它不会适合所有情况。如果你已经有微服务，并且你觉得你有很好的控制能力和可视性，那么你已经有了一个很好的开发人员工作流程，那么你就不需要把所有东西都撕掉，并且明天在服务网格中填充。我建议你可能仍然想知道里面的内容，因为当你的团队处理新的语言或环境时它可能会有帮助。 我认为我们应该了解服务网格如何将功能集成到一个一致的层中。我们都喜欢保持我们的代码干爽（不要重复自己）。我们知道两个相似的实现永远不会完全相同。如果您可以利用服务网格来获得一个可以在整个基础架构中运行的重试逻辑的实现，那么真正简化了开发人员，操作人员以及与该系统一起工作的每个人的操作。我敢打赌，你的团队中没有人想再写一个重试循环的副本，特别是没有人想调试用go编写的文件和用python编写的文件之间的细微差别。 5.随着要监控的服务数量的增加，这些服务中的每一个很可能： - 使用不同的技术/语言 - 住在不同的机器/容器上 - 拥有自己的版本控制 服务如何解决这些差距？ Jenkins ： Service mesh的第一个承诺是为任何语言编写的微服务（对于任何应用程序堆栈）执行相同的操作（即可见性和控制部分）。接下来，当您考虑不同的容器互相交谈时，服务网格可能会帮助与该层相关的许多内容。例如，你是否相信保护每个单独运行的容器而不是外围（防火墙）安全？然后使用服务网格提供从容器到容器的mTLS。 我还看到，版本控制差异是更深的应用程序生命周期差异的表现。所以这个团队使用这样的版本控制，广泛的资格认证阶段和谨慎的升级策略，因为他们提供了每个人都依赖的最核心的服务之一。另一个从事全新原型服务的团队有一个不同的政策，但您肯定希望确保他们不写入生产数据库。将他们的“方形挂钩工作流程”装入你的“圆孔工艺”并不是正确的。 您可以使用服务网格以适合他们的方式将这些不同的应用程序和服务移植到系统中。现在显然你想要使用一些判断，而不是为每一个小的微服务定制固定，但我们听到很多关于服务网格的兴趣，以帮助消除这些生命周期和期望之间的差异。再次，它的全部是提供快速迭代，但不放弃可见性和控制。 6.控制平面与数据平面：服务网格为每个平面提供值？ Jenkins ： 今天开始制作网络服务是多么容易。您可以将代码放入推文中。虽然这不是真正的 Web 服务。为了使其具有弹性和可扩展性，您需要在应用程序的数据平面添加一些内容。它需要做 TLS，它需要重试失败，它只需要接受来自这个服务的请求，但不是那个，并且它需要检查用户的认证，等等。服务网格可以帮助您获得数据平面功能，而无需向应用添加代码。 而且，由于现在已经在数据平面层中，因此可以在不修改应用程序的情况下升级和增强该层。 服务网格为您的微服务带来了控制平面的一致性。像 Kubernetes 这样的容器编排系统提供了描述你想要运行哪些容器的常用方法。这并不是说你不能在没有它们的情况下运行容器，那是因为一旦你运行了一些容器，你就需要一个一致的方式来运行它们。服务网格就是这样，用于容器之间的通信。 7.服务网格的流行语是“可观察性”。你能分享一下真实世界中的可观察性提供的好处吗？ Jenkins ： 我们曾与一个团队谈过，他们告诉我们他们花了几个小时的时间在电话上试图解决一些跨越很多服务和组件的问题。他们从每项服务中收集了大量数据，他们知道答案是在某处的大量数据中。但是他们花了很多时间在信息的每个快照之间进行翻译。他们不相信翻译中的每一步都是正确的 - 毕竟，如果他们明白发生了什么事情，他们首先会设计出这个问题。最重要的是，哪里开始寻找并不总是很清楚。 他们要求的是一种观点 - 一个地方收集的所有服务信息，以及他们问题最重要的信息。同样，服务网格不是万能的，我不会保证你永远不必再看日志文件。但我的目标是，一旦这个团队拥有一个服务网格，他们总是有信心，他们已经对每一个微服务进出的内容有了很好的观察，并且服务网格已经指出他们正确的方向。 [Read More]

这个原文是 5 月初发表的原文的翻译。补充一下这篇文章的背景，Cookpad 是一家拥有 200 多种产品开发的中型科技公司，拥有 10 多支团队，每月平均用户数量达到 9000 万。https://www.cookpadteam.com/ 你好，我是来自生产团队的开发人员Taiki。目前，我想介绍一下在 Cookpad 上构建和使用服务网格所获得的知识。 对于服务网格本身，我认为您将对以下文章，公告和教程有完整的了解： https://speakerdeck.com/taiki45/observability-service-mesh-and-microservices https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/ https://blog.envoyproxy.io/service-mesh-data-plane-vs-control-plane-2774e720f7fc https://istioio.io/docs/setup/kubernetes/quick-start.html https://www.youtube.com/playlist?list=PLj6h78yzYM2P-3-xqvmWaZbbI1sW-ulZb 我们的目标 我们引入了一个服务网格来解决故障排除，容量规划和保持系统可靠性等操作问题。尤其是： 降低服务组的管理成本 可观察性的改进 (分别参考了 Twitter 和 Medium的博客) 建立更好的故障隔离机制 就第一个问题而言，随着规模的扩大，存在难以掌握哪个服务和哪个服务正在进行通信，某个服务的失败是哪里传播导致的问题。我认为这个问题应该通过综合管理服务在哪里和服务在哪里连接的相关信息来解决。 对于第二个问题而言，我们进一步深究了第一个问题，我们发现我们不知道一个服务与另一个服务之间的通信状态。例如，RPS，响应时间，成功/失败状态的数量，超时，断路器的激活状态等。在两个或更多个服务引用某个后端服务的情况下，因为它们未被请求源服务标记，所以会导致后端服务的代理解析或负载均衡器的度量标准信息不足。 对于第三个问题，“故障隔离尚未成功设置”。此时，在各应用程序中使用库，超时/重试·断路器的设置完成了。但是需要什么样的设置，必需单独查看应用程序代码。由于没有配置清单，会导致难以持续改进这些设置。另外，因为与故障隔离有关的设置应该不断改进，所以最好是可测试的，并且我们需要这样一个基础平台。 为了解决更高级的问题，我们还构建了gRPC 基础设施建设，配送跟踪处理委托，流量控制部署方式多样化，认证授权网关等功能。这部分将在稍后讨论。 当前状态 Cookpad 中的服务网格使用 Envoy 作为 data-plane，并创建了我们自己的 control-plane。尽管我们最初考虑安装已经作为服务网格实现的 Istio，但 Cookpad 中的应用程序大多数都使用名为 AWS ECS 的容器管理服务进行操作，因此与 Kubernetes 合作的优点是有限的。考虑到我们想实现的目标以及 Istio 软件本身的复杂性，我们选择了我们自己的 control-plane 的路径，该平面可以从小型起步。 此次实施的服务网格的 control-plane 分由几个组件组成。我将解释每个组件的角色和操作流程： 集中管理服务网格配置的存储库。 使用名为 kumonos 的gem从上面的设置文件生成 Envoy xDS API 响应 JSON 将生成的响应 JSON 放置在 Amazon S3 上，并将其用作 Envoy 的 xDS API 该设置在中央存储库中进行管理的原因是， [Read More]

SpringBootServletInitializer 源码分析如何实现SpringBootServletInitializer整个加载过程 实现自定义WebApplicationInitializer配置加载 实现自定义ServletContainerInitializer配置加载 示例代码 首先web.xml主要配置各种servlet,filter,listener等,如常见的Log4jConfigListener,OpenSessionInViewFilter,CharacterEncodingFilter,DispatcherServlet等,此大部分信息均是容器启动时加载. 在SpringBoot中我们从SpringBootServletInitializer源码入手: public abstract class SpringBootServletInitializer implements WebApplicationInitializer { @Override public void onStartup(ServletContext servletContext) throws ServletException { // Logger initialization is deferred in case a ordered // LogServletContextInitializer is being used this.logger = LogFactory.getLog(getClass()); WebApplicationContext rootAppContext = createRootApplicationContext( servletContext); if (rootAppContext != null) { servletContext.addListener(new ContextLoaderListener(rootAppContext) { @Override public void contextInitialized(ServletContextEvent event) { // no-op because the application context is already initialized } }); } else { this. [Read More]