分布式系统发展史.docxVIP

分布式系统进展史 2021-09-27 ? 接着，我们进入了多任务操作系统和个人电脑的时代。利用Windows、Unix、Linux等操作系统，我们可以在同一台计算机上运转多个任务。这使得分布式系统开发人员能够在一台或者几台通过消息传递连接的计算机内构建和运转整个分布式系统。这催生了面对服务的架构（SOA），其中每个分布式系统可以通过一组集成在一台计算机或多台计算机上运转的服务来构建。我们通过WSDL（用于SOAP协议）或WADL（用于REST协议）等言语适当地定义服务接口。接着，服务的使用者将利用这些接口来进行客户端的实现。 ?? 随着计算力量和存储价格的降低，世界各地的组织都开头使用分布式系统和基于SOA的企业IT系统。但是，一旦服务或系统的数量添加，这些服务之间的点到点连接就不再是可扩展和可维护的了。这催生了集中式“服务总线”概念的产生。服务总线通过类似集线器的架构将全部系统连接在一起。这个组件被称为ESB（企业服务总线）。它作为一个“言语”翻译者，就像一个两头人在挂念一群使用不同“言语”但期望相互通信的人进行沟通。在企业应用中，“言语”代表着在通信时不同系统的消息传递协议和消息格式。 ?? 这种模式工作得很好，即便在今日也能正常工作。随着万维网的普及和模型的简化，基于REST的通信比基于SOAP的通信模型变得愈加流行。这促进了基于应用程序编程接口（API）的REST模型通信的进展。由于REST模型的简约特性，我们需要在标准REST API实现之上实现平安（身份验证和授权）、缓存、流控和监控等各品种型的功能。但我们并不想独立地在每个API上实现这些功能，而是需要一个公共组件将这些功能应用于这些API之上。这样的需求催生了API管理平台的进展。现在，它已经成为了任何分布式系统的核心功能之一。 ? 随后，我们见证了分布式系统大爆炸的时代。Facebook、Google、Amazon、Netflix、LinkedIn、Twitter等互联网公司变得特别浩大。他们开头想要构建跨越多个地理区域和多个数据中心的分布式系统。这样的需求使他们的技术焦点转向了一切开头的地方。工程师们开头思考单台计算机和单个程序的概念。他们不再把一台计算机当作一台计算机来看，而在同一台计算机内创建多台虚拟计算机。这催生了关于虚拟机的想法，即同一台计算机可以充当多台计算机并且全部并行运转。虽然这是一个还不错的办法，但在宿主计算机的资源利用方面，这并不是最好的选择。运转多个操作系统需要更多的资源，但在同一个操作系统里运转多个程序并不需要这些资源。 这些问题最终催生了关于容器技术的想法。容器只使用一个宿主操作系统（Linux）的内核，就可以运转多个程序并分别依靠于相互独立的运转时。这个概念在Linux操作系统上已经有一段时间了。随着基于容器技术的应用程序部署的普及，它变得愈加流行并且有了很多改进和提升。容器可以像虚拟机一样工作，却不需要多一个操作系统的开销。您可以将应用程序和全部相关的依靠项放入容器镜像中。它便可以被放在任何可以运转容器的宿主操作系统中运转。Docker和Rocket是两个抢手的容器构建平台。 ?? 容器技术为Netflix、LinkedIn和Twitter等组织供应了底层框架，用于构建他们要求苛刻的永久在线的多区域、多数据中心应用平台。但这并不意味着利用容器技术没有任何难点。基于容器的部署带来的轻量特性让跨多个容器的平台维护和编排变得格外简单。随着微服务架构（MSA）的消灭，单体式应用程序被分成更小块的微服务。这些微服务能够完成整个服务里的某一个特定功能并部署在容器中（在大多数情况下都可以）。这给分布式系统生态系统带来了一系列新的需求。要让系统最终保持全都，并且彼此之间没有太多简单的通信。 ? 这些新的需求最终挂念工程师们构建了一个容器编排系统。该系统可用于维护更大规模的容器部署的全都性。毋庸置疑的是，这个领域的顶尖技术来自Google。由于它们的规模格外大。他们构建了名为“Kubernetes”（又名k8s）的容器编排平台，并成为大规模容器编排需求的现实标准。k8s让工程师可以： 在大型集群中运转容器 将数据中心视为一台计算机 把握服务之间的通信（在容器上运转） 动态伸缩与为多个服务进行负载均衡 Kubernetes和Docker让应用程序员的生活愈加轻松。他们不用再考虑他们的应用在不同的环境（操作系统、开发环境、测试环境、生产环境等）下的不同表现。他构建的容器镜像在全部环境中运转表现几乎完全相同，由于全部依靠项都被打包到镜像中了。 ?? 但是，虽然我们有了容器和编排框架，我们仍旧需要一个管理这些服务器的团队。这意味着数据中心需要使用像Docker和Kubernetes这样的技术进行管理，以确保它对于应用程序来说就像一个单台计算