云原生:运用容器、函数计算和数据构建下一代应用
上QQ阅读APP看书,第一时间看更新

1.1 分布式系统

在刚开始构建云原生应用时,开发者们遇到的最大障碍之一是这些应用服务往往运行于不同的机器之上,所以需要考虑机器间的网络通信模式。他们甚至自己都没意识到,其实这就是分布式系统。分布式系统看上去就像是一台机器在工作,但其实它由一组独立的机器组成,它们之间通过网络相连接。这样的系统可以将计算任务分配到不同的机器上,这种分配任务的能力使得应用服务在具有可扩展性、可靠性的同时也更加经济。例如,大多数云服务供应商会使用便宜一些的商用机,然后依靠软件的解决方案来处理诸如高可用和可靠性等常见问题。

1.1.1 分布式系统的误区

在初入分布式系统世界的时候,大多数的开发者和架构师会做一些错误的或毫无根据的假设。Sun Microsystems公司的研究员Peter Deutsch早在1994年就意识到了几个有关分布式系统的误区,那时候还没有人知道云计算是什么。由于云原生应用的核心也是分布式系统,所以这些误区在今天仍然存在。

下面是Deutsch列出的几个误区,其含义同样适用于云原生应用:


网络是安全的

即使在云端,你也无法保证网络是安全的。各种服务通常会部署在不同的机器上,所以在开发这些服务时你需要把潜在的网络故障考虑进去。我们稍后将在本书中讨论这个问题。


延迟是不存在的

人们常常混淆延迟和带宽,但是理解这两个概念的差异很重要。延迟指的是数据从发送到接收需要多少时间。而带宽指的是在给定时间窗口内可以传输多少数据。因为延迟对用户体验和性能有很大影响,所以你应该注意以下事项:

· 避免频繁的网络调用和一些不必要的请求。

· 在设计云原生应用时,可以考虑采用缓存、内容分发网络(CDN)、多区域部署等技术或方法来使得数据离客户端更近。

· 采用“发布/订阅”模式,以通知有新数据到达,并将其存储在本地以便可以立即使用这些数据。第3章会详细介绍包括“发布/订阅”在内的各种消息通信模式。


带宽是用之不尽的

现如今,网络带宽似乎不再是一个大问题了。但事实上,新的技术和边缘计算等新领域会开辟一些需要更高带宽的新场景。举个例子:据测算,一辆无人驾驶汽车每天大约会产生50TB的数据。这样的数据量就需要你在设计云原生应用时考虑到带宽使用情况。“领域驱动设计”(DDD)模式和类似“命令查询职责分离”(CQRS)这样的数据模式在此类带宽要求较高的场景下是很有用的。第4章和第6章将更详细地讨论如何处理云原生应用中的数据。


网络是安全的

诊断和安全是两件开发者们常常在出问题后才会去反思的事情。网络总是安全的这个假设是极其错误的。作为一个开发者或者架构师,你必须在设计时就将安全问题列入优先事项,例如,考虑采取纵深防御的策略。


拓扑结构是不变的

“宠物与牲畜宠物类比的是传统服务器或虚拟机,每一个都被照顾得很好,不可或缺。牲畜类比的是云端服务器实例,量多、可替代、短生命周期。”这个类比随着容器技术的出现而变得越来越普及。它的意思是你不会像对待具有其自身属性(如静态IP)的特定实体(宠物)一样对待机器。相反,你会把机器视为没有特殊属性的群体的一员。这个理念对于云原生应用而言非常重要,因为云计算旨在提供弹性,机器的数量会随着计算资源的消耗和请求数的变化而变化。


一个管理员可以搞定一切

在传统的软件开发过程中,通常都会有一个人来负责软件的运行环境、安装和升级应用程序。但是在现代的云计算架构和DevOps理念下,这种情况已经发生了改变。一个现代的云原生应用一般会由很多服务组成,这些服务需要协同工作,但是它们往往由不同的团队开发。因此要让一个人完全搞明白整个应用是如何工作的几乎是件不可能的事情,更别说去修复问题了。所以你需要确保你的应用有完善的治理措施,使得排查故障变得相对容易。在这本书中,我们会介绍一些相关概念,如发布管理、解耦、日志与监控等。第5章会详细介绍云原生应用的一些常见的DevOps实践。


传输是没有成本的

站在云原生的角度,这个误区有两个解释。首先,数据通过网络传输,而网络流量在大多数的公有云平台上都是要收费的。大多数云服务商对入网流量又称下行流量,指数据从公网进入云服务器产生的流量。不收费,但是对出网流量又称上行流量,指数据从云服务器流出到公网产生的流量。会收费。其次,传输的数据与对象之间的转换是有成本的,例如序列化和反序列化除了会带来网络延迟外通常还会产生一些额外的昂贵开销。


网络通信都是一样的

这个误区现在几乎不值一提了,因为几乎每个开发人员和架构师都知道在构建应用程序的时候必须考虑到不同的网络协议。


如前所述,尽管这些误区很早以前就已经提出来了,但是在步入云原生的世界时,这些错误的假设仍然值得警惕。在这本书中,我们将教你一些模式和最佳实践,这些模式和最佳实践都充分考虑了分布式系统中这些常见的误区。

1.1.2 CAP定理

提到分布式系统就不得不提一下CAP定理。CAP定理指出,任何一个通过网络连接的、共享数据的分布式系统最多只能同时满足以下三个需求中的两个:

· 一致性(Consistency, C):指所有节点访问同一份最新的数据副本。

· 可用性(Availability, A):指系统提供的数据或服务必须一直处于可用状态。

· 分区容错性(Partition tolerance, P):指系统在遇到网络分区故障的时候,仍然能够对外提供服务。

现实情况是,网络分区故障经常会出现(记得前面所提到的,“网络是安全的”是分布式系统的误区之一),所以你必须考虑到这一点。然而这样的话你就不得不在追求一致性还是高可用性之间做出取舍。很多NoSQL数据库(如Cassandra)会选择追求高可用性,而像关系型数据库会为了遵循ACID原则(原子性、一致性、隔离性和持久性)而追求一致性。