云原生模式读后感(二)

云原生模式书籍介绍:https://item.jd.com/12704245.html

记录一些书中的总结

第二部分云原生模式

7.应用程序生命周期：考虑不断的变化

(1)在云原生环境中，必须考虑应用程序的生命周期，并将它看作单独的逻辑实体，即使每个应用程序实例都有自己独立的生命周期。

(2)还必须仔细关注某个应用程序的生命周期事件，看其会如何影响软件中其他的应用程序。

(3)只有当一个应用程序的多个实例可以同时支持不同的配置时，才能使用滚动升级的部署方式。否则，必须使用蓝/绿升级的部署方式。两者都可以在零停机时间内完成。

(4)一个精心设计的密码轮换模式，可以通过滚动升级的方式来实现。

(5)如果人为替换应用程序的实例也可以实现这种模式，那么也可以这样做。让我们放下这种偏见。

(6)应用程序日志应该被发送到stdout和stderr，大多数云原生平台都会在那里处理它们。

(7)应用程序的状态必须是可用的，这样才能持续检查系统的健康情况，并且所依赖的应用程序才能够适应变化。

(8)无服务器计算是云原生的一种极端形式，它使用了本书中介绍的大多数模式。

8 如何访问应用程序：服务、路由和服务发现

(1)可以用一个简单的抽象将客户端和依赖服务之间松耦合。

(2)有两种主要的负载均衡方法—集中式（或者服务端）和客户端。每种方法都有各自的优点和缺点。

(3)负载均衡器的配置必须是动态且高度自动化的，因为在云原生环境中，流量被路由到的实例比过去变化的频率大得多。

(4)诸如DNS之类的名称服务是服务发现协议的核心，该协议允许客户端在不断变化的网络拓扑中找到相关服务。

(5)在使用域名服务时，作为一名开发人员，你必须考虑到名称到IP地址的映射表是最终一致的，你必须考虑到映射记录可能已经过期的情况。

(6)使用一种服务发现协议可以让软件部署变得更有弹性

9 交互冗余：重试和其他控制循环

请求重试的基本模式很简单：应用程序向远程服务发出请求，如果在合理的时间内没有接收到响应，将再次尝试

(1)重试一个超时请求可以降低本来会通过系统传播的错误。

(2)如果处理不当，即使修复了连接性的问题，排队中的重试请求也会使系统过载。

(3)正确配置的重试既可以显著降低重试风暴的风险，又可以在不太严重的停机事故中提供巨大的好处。

(4)只有在安全的情况下才使用重试，是一名开发人员应该承担的责任。

(5)你不仅应该养成实现服务的核心逻辑的习惯，还应该养成在意外情况下实现回退逻辑的习惯。

(6)重试只是一种控制循环模式的例子。

(7)对于组成云原生软件的分布式系统，控制循环是一项必不可少的技术。

10 前沿服务：断路器和API网关

断路器

在软件中，断路器的运行方式基本相同。当负载过高时，断路器会打开并阻止流量通过。但是它有两个不同之处。首先，用来检测何时应打开断路器的机制是基于实际的故障，而不是对可能的故障的预测（你肯定不希望电路在检测到小火苗后才会跳闸）。其次，软件中的断路器通常具有内置的自我修复机制（这与让人类在黑暗的房屋中找到配电板，并手动翻转断路器的方式不同）。

api网关

开源和商业API网关比微服务和基于云的架构兴起得还要早。例如，Apigee（自被Google收购）和Mashery（被Intel收购，然后出售给TIBCO）都是在20世纪00年代初期成立的公司，都专注于开发API网关。API网关在软件架构中扮演的角色始终如本章标题所述，始终位于实现的最前面，并且提供了大量的服务

服务网格

我们不必一步就实现服务网格（Service Mesh），所以让我一点一点地来介绍，从一个在服务网格中起核心作用的原语开始。然后，我将继续介绍服务网格及其在云原生软件架构中扮演的日益重要的角色。

(1)在服务的前端设计了许多模式，用来控制与该服务的交互方式。

(2)断路器是用来防止服务过载（包括重试风暴所产生的流量）的基本模式。

(3)API网关早于云原生架构出现，如今已经发展得可以很好地适应高度分布式化、不断变化的软件部署环境。

(4)应用于交互的客户端和服务端的模式，都可以封装并作为一个挎斗代理被部署。

(5)服务网格为挎斗代理添加了一个管理平面，该管理平面允许运维人员控制安全性，提供可观察性，并允许配置组成云原生软件的服务/应用程序的集合。

11 故障排除：如同大海捞针

(1)必须主动将度量指标和日志从执行服务的运行时环境中取出，因为在服务遇到故障或者升级后，这些执行环境通常会变得不可用。服务的执行环境应被视为短暂的。

(2)聚合来自多个服务实例的日志对于可观察性很重要。通常首选按时间顺序来处理不同服务的日志。

(3)可观察性信息、日志、指标和跟踪数据的收集可以放在挎斗代理中实现，这使得应用程序可以专注于业务逻辑，并将运维需求集中到服务网格中。

(4)完善的分布式跟踪技术及其实现，为深入了解分布式应用程序的运行状况和性能提供了宝贵的洞察能力。

(5)本书前面介绍的许多模式都可以用来提供所需的可观察性。应用程序配置、应用程序生命周期、服务发现、网关和服务网格都有各自的作用。

12 云原生数据：打破数据单体

(1)当为微服务提供一个数据库来存储其所需的数据时，能显著提高自治性。这会让系统整体具有更好的弹性。

(2)尽管在许多情况下有缓存总比没有好，但是使用缓存来填充本地数据库充满了挑战。缓存不适合用于数据频繁变更的场景。

(3)通过事件主动将数据变更推送到本地的数据存储，是一种更好的方法。

(4)尽管我们生产和消费的实体是事件而不是消息，但是该技术的基础仍然是我们熟悉的发布/订阅模式。

(5)将事件日志作为数据的唯一真实来源，所有服务的本地数据库仅保留投射数据，这样可以让运行在高度分布式、不断变化的环境中的云原生软件，实现数据上的一致性。