Docker和微服务专业技术的崛起.docx

Docker和微服务技术的崛起 作为一名软件开发者或技术爱好者，像“微服务”和“Docker”这样的术语已经不绝于耳，但你是否仍然不明白为什么会有这么多相关的炒作？ SOA“简史” 在 2000 年初，我们目睹了面向服务架构（Service Oriented Architecture，SOA）的崛起，这是一种非常流行的软件架构设计范式。简而言之，SOA 是一种软件架构模式，用于构建大型的企业应用程序，这些应用程序通常要求集成多种服务，而每种服务使用不同的平台和编程语言来构建，并通过通用的通信机制进行交互。 以下是面向服务架构（SOA）的简单图示： 关键点 SOA 是大型软件产品（如企业应用程序）的首选。 SOA 侧重于将多个服务集成到单个应用程序中，而不是强调模块化应用程序。 在 SOA 中，用于服务间交互的通用通信机制被称为企业服务总线（Enterprise Service Bus，ESB）。 基于 SOA 的应用程序本质是单体。也就是说，单个应用程序层包含了用户界面或表示层、业务逻辑或应用程序层，以及数据库层，这些全部都集成到一个平台中。 关于“单体架构” 让我们以网店为例。我们知道，很多电商网站都可以通过多种设备访问，所以这些网站通常都为笔记本电脑和移动设备提供了不同的用户界面。 我们也知道，多个操作或服务彼此依赖，以确保应用程序的正常运行。其中一些服务负责创建账号、显示产品目录、建立和验证购物车、生成账单、确认订单、完成支付等。 在单体应用程序中，所有这些服务都在同一个应用程序层上运行，因此这个电子商务网站的软件架构如下所示： 缺点 很显然，随着服务数量的增加，应用程序的规模将不断增长。这可能会让构建和维护应用程序代码库的开发人员不堪重负。 难以更新当前的技术栈，即使是在当前技术栈中修改一点内容也会是一场噩梦。 每一项变更都要求开发人员重建整个应用程序，十分浪费资源。 随着客户群的增加，我们将有更多的请求需要，这将需要更多的资源。因此，建立可扩展的产品时至关重要的。对于单体应用程序，我们只能在一个方向上进行伸缩，即垂直伸缩，而不是水平伸缩。这意味着我们可以通过添加更多硬件资源（如内存和 CPU）在单台计算机上扩展应用程序，但横向扩展（跨多台计算机）仍然是一项挑战。 救星“微服务”来了！ 微服务架构可以被认为是对 SOA 的特殊化，也是一种可以克服单体架构缺陷的替代模式。 在微服务架构中，我们专注于将应用程序模块化，将其分解成较小的独立服务，这些服务可独立于其他服务或整个应用程序本身而构建、部署、伸缩和维护。这些独立服务被称为微服务，因此这种架构被称为微服务架构。 关键点 微服务架构和 SOA 虽然不一样，但它们确实存在一些相似之处。微服务架构被称为 SOA 的变体，甚至是 SOA 的一种特殊化。换句话说，SOA 可以被认为是微服务架构的超集。 人们之所以能够在这些架构之间找到相似性，主要是因为它们都专注于构建具有松散耦合的服务。这些服务具有明确的界限，并且每个服务都具有独立的功能集。 不同之处在于，SOA 可能意味着其他很多东西。例如，SOA 适用于单体架构，重点是将系统集成在一个应用程序中，并确保代码的可复用性。但对微服务架构来说并不是这样的，微服务架构的重点是通过构建独立服务和确保产品的可伸缩性来模块化应用程序。 优点 引入关注点分离的理念，在软件应用程序开发中实现敏捷，不管是在简单的还是复杂的领域。 微服务的独立能力或独立性带来了以下好处： 将开发人员分成小团队来降低复杂性，每个小团队负责构建和维护一个或多个服务。 允许部署分块，而不是每次发生变更都要重新构建整个应用程序，以此来降低风险。 增量更新或升级一个或多个服务的技术栈，而不是在一个时间点更新整个应用程序，以此降低维护难度。 可以使用任意的编程语言来构建服务，除此之外，还可以为每个给定服务维护单独的数据模型。 3. ? 可以构建全自动的部署机制，确保个体服务的部署、服务管理和自动伸缩。 技术的演变 除了软件架构模式的发展之外，我们还看到 Docker 和 Kubernetes 等新技术的出现，用于支持我们的软件基础设施，实现对可伸缩产品和服务的高效管理。我们已经从硬件虚拟化发展到容器化。 或许你会想，这意味着什么？ 让我们借助下图来理解 IT 基础设施领域的发展： 第一张图显示的是一台物理机器或一台硬件服务器。通常，我们在构建应用程序时使用的是宿主操作系统提供的资源，在部署应用程序时也使用了相同的模式。但如果你想扩展应用程序该怎么办呢？在某些时候，你可能需要另一台硬件服务器。而随着数量不断增加，成本和其他资源（如硬件和能源消耗）也会随之增加。 此外，你可能会想，是否有必要在任何时候都使用所有的硬件资源和操作系统？当然不是。既然这样，那么为什么还需要这么庞