下载掌阅APP，畅读海量书库
立即打开
由于人们首先想到的是让两台或多台计算机相互通信，因此构思出了，如图1-1所示的简易通信模型。
图1-1 简易通信模型
互相通信的两个服务可以满足最终用户的一些需求。但这个示意图显然过于简单，缺少包括通过代码操作的字节转换和在线路上收发的电信号转换在内的多个层。虽然一定程度上的抽象对于讨论是必需的，但仍需添加网络协议栈（组件）以增加细节内容，如图1-2所示。
图1-2 增加网络协议栈（组件）后
上述这个修改过的模型自20世纪50年代一直使用至今。一开始，计算机很稀少，也很昂贵，所以两个节点之间的每个环节都被精心制作和维护。随着计算机变得越来越便宜，连接的数量和数据量大幅增加。人们越来越依赖网络系统，工程师需要保证他们构建的软件能够达到用户所要求的服务质量。
当然，还有许多问题急需解决以达到用户要求的服务质量。人们需要找到解决方案让机器互相发现，通过同一条线路同时处理多个连接，允许机器在非直连的情况下互相通信，通过网络对数据包进行路由、流量加密等。
其中，有一种机制称为流量控制，下面以此为例。流量控制是一种防止一台服务器发送的数据包超过下游服务器可以承受上限的机制。这是必要的，因为在一个联网的系统中，至少有两台不同的、独立的计算机，彼此之间互不了解。计算机A以给定的速率向计算机B发送字节，但不能保证B可以连续地、以足够快的速度来处理接收到的字节。例如，B可能正在忙于并行运行其他任务，或者数据包可能无序到达，并且B可能被阻塞以等待本应该第一个到达的数据包。这意味着A不仅不知道B的预期性能，还可能让事情变得更糟，导致B过载，B现在必须对所有这些传入的数据包进行排队处理。
一段时间以来，大家寄希望于建立网络服务和应用程序的开发者能够通过编写代码来解决上面提出的挑战。在这个流程控制示例中，应用程序本身必须包含某种逻辑来确保服务不会因为数据包的原因而过载。这种重联网的逻辑与业务逻辑一样重要。抽象示意图如图1-3所示。
随着像TCP/IP这样的标准横空出世，流量控制和许多其他问题的解决方案被融入网络协议栈本身。这意味着这些流量控制代码仍然存在，但已经从应用程序转移到了操作系统提供的底层网络层，如图1-4所示。
这个模型相当成功。几乎任何一个组织都能够使用商业操作系统附带的TCP/IP协议栈来驱动他们的业务，即使有高性能和高可靠性的要求。
图1-3 逻辑分离后
图1-4 分层后
随着节点和稳定连接的数量越来越多，行业中出现了各种各样的网络系统：从细粒度的分布式代理和对象，到由较大但重分布式组件组成的面向服务的架构。这样的分布式系统带来了几个难题，有一些是新出现的，也有原有难题的“升级版”。
20世纪90年代，Peter Deutsch和他在Sun公司的同事撰写了《分布式计算的八大错误》一文，文中列出了人们在使用分布式系统时通常会做出的一些假设。Peter认为，这些假设在更原始的网络架构或理论模型中可能是真实存在的，但在现代世界中是不成立的：
·网络是可靠的；
·延迟为零；
·带宽是无限的；
·网络是安全的；
·拓扑是不变的；
·管理员实时监控维护；
·传输成本为零；
·网络是同构的。
因此，工程师们必须处理这些问题。
为了处理更复杂的问题，需要转向更加分散的系统（我们通常所说的微服务架构），这在可操作性方面提出了新的要求。下面则列出了必须要处理的问题：
·计算资源的快速提供；
·基本的监控；
·快速部署；
·易于扩展的存储；
·可轻松访问边缘；
·认证与授权；
·标准化的RPC；
因此，尽管数十年前开发的TCP/IP协议栈和通用网络模型仍然是计算机之间相互通信的有力工具，但更复杂的架构引入了其他层面的问题。此时业界出现了微服务思想，以期解决上述问题。例如，微服务用服务发现与断路器技术来解决上面列出的几个弹性扩展和分布式问题，如图1-5所示。
图1-5 加入微服务层后
微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制（通常用HTTP资源API）。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。
我们为了将系统构建为微服务架构，除了服务是可独立部署、可独立扩展的之外，每个服务都提供一个固定的模块边界，甚至允许不同的服务用不同的语言开发，由不同的团队管理。图1-6展示了单体应用到微服务的简易图解。
图1-6 单体应用到微服务的简易图解
然而历史往往会重演，第一批基于微服务构建的系统遵循了与前几代联网计算机类似的策略。这意味着落实上述需求的责任落在了编写服务的工程师身上。我们以服务发现和断路器来说明。
服务发现 是在满足给定查询条件的情况下自动查找服务实例的过程，例如，一个名叫Teams的服务需要找到一个名为Players的服务实例，其中该实例的environment属性设置为production。当用户调用一些提供提供服务发现的组件，它们会返回一个满足条件的服务列表。对于中心化的架构而言，这是一个非常简单的任务，通常可以使用DNS、负载均衡器和一些端口号的约定（例如，所有服务将HTTP服务器绑定到8080端口）来实现。而在更分散的环境中，任务开始变得越来越复杂，对于以前可以通过盲目信任DNS来查找依赖关系的服务，现在必须处理诸如客户端负载均衡、多种不同环境、地理位置上分散的服务器等问题。如果之前只需要一行代码来解析主机名，那么现在的服务则需要很多行代码来处理由分布式引入的各种问题。
断路器 是由Michael Nygard在其编写的《Release It》一书中引入的模式，书中对该模式的一些总结：
断路器背后的基本思路非常简单。将一个受保护的函数调用包含在用于监视故障的断路器对象中。一旦故障达到一定阈值，则断路器跳闸，并且对断路器的所有后续调用都将返回错误，并完全不接受对受保护函数的调用。通常，如果断路器发生跳闸，还需要对其进行某种监控警报。
随着分布式水平的提高，它们也会变得越来越复杂。系统发生错误的概率随着分布式水平的提高呈指数级增长，比如一个组件中的一个故障可能会在许多客户端和客户端的客户端上产生连锁反应，从而触发数千个电路同时跳闸。而且，以前可能只需几行代码就能处理某个问题，现在需要编写大量的代码才能处理。
因此微服务反对之声也很强烈，认为微服务增加了系统维护、部署的难度，导致一些功能模块或代码无法复用，增加系统集成与测试的难度，而且随着系统规模增长，会导致系统越来越复杂。那么有没有一种框架或开发平台可以尽可能便捷、一站式解决上述问题呢？有！那便是Spring Cloud。