在这篇文章中，我将讨论微服务是什么以及它们为何如此重要。我们将从微服务的历史以及它们与单体架构的比较开始。然后，我们将讨论微服务架构的一些原则、它的潜在缺点，以及它如何与容器和Kubernetes等现代工具一起工作。随着组织开始构建更复杂的应用程序并且编写单体应用程序的做法变得越来越有问题，微服务应运而生。传统上，应用程序构建为整体，所有代码都集中在一个大型代码库中。由于不同功能之间没有明确的区分，因此有可能更新应用程序的一部分而无意中影响完全不相关的功能。即使是简单的更改，您也必须重新部署整个应用程序，如果出现问题，一切都会受到影响，而不仅仅是正在更新或扩展的组件。对于这个问题，我们可以通过将单体架构拆分成模块（半独立的组件）来解决，虽然这可能比实现微服务要简单得多，但一直没有真正流行起来。面向服务的体系结构(SOA)吸引了很多人，但很大程度上失败了，主要是因为它留下了许多悬而未决的问题，例如如何正确分解服务。基于微服务的架构是一种更具声明性的SOA类型，它源于现实世界的用例，并已被众多组织成功采用。微服务只不过是一种模块化架构，不同的模块通过网络进行通信。什么是微服务？微服务是小型、自治的应用程序组件，它们共同构成一个应用程序。他们继承了SOA的基本操作模型，但以更具声明性的方式对其进行了扩展。微服务通常被认为是一个独立的部分，由一个团队维护。为什么微服务很重要？综上所述，要更新应用，我们可以独立更新和部署微服务，而不需要重新部署整个应用。它们还允许单个微服务团队完全专注于单个业务流程，而无需了解整个应用程序。为此，微服务具有以下属性：松散耦合：每个服务都是自治的，并且只松散地连接到系统的其余部分。这意味着它有自己的生命周期，可以独立部署、更新、扩展和删除。高内聚：具有相关行为的代码被组合在一起。通过将所有相关行为组合在一起，工程师仅在需要更改特定行为时更新一处代码。信息隐藏：每个微服务只共享其他服务需要的数据，只隐藏与自己进程相关的数据。数据共享可能会无意中导致耦合，因此应始终保持谨慎。为了充当一个有凝聚力的应用程序，所有这些不同的自治服务都通过网络接口进行通信。这为大容量通信带来了新的挑战。顺便说一句，这就是服务网格发挥作用的地方。现在我们知道什么是微服务，让我们来探讨为什么组织采用微服务。微服务的好处无论是通过使服务与团队保持一致来解决“开发人员问题”，降低采用新技术的风险，还是降低部署的复杂性和提高可扩展性，采用微服务都有很多好处。让我们仔细看看：自治团队：微服务允许小团队完全拥有服务的整个生命周期。这增加了问责制、代码质量和工作满意度。对于大多数大型组织而言，这种“人员配备”是采用微服务方法的主要原因之一。技术的异构性：开发者理论上可以使用不同的语言和不同的技术来构建每个服务。这使开发人员能够为特定服务选择最佳技术，而不是更传统的标准化、放之四海而皆准的方法。降低采用新技术的风险：开发人员还可以在低风险服务中试验新技术，因为他们知道如果出现问题，不会影响系统的其余部分。由于风险是采用新技术的最大障碍，因此这是一个巨大的优势。弹性：当一个组件发生故障时，它不一定会影响系统的其余部分。但是请注意，应用程序只有在其架构允许的情况下才具有弹性。如果没有良好的编码实践，例如跟踪、可观察性和融合智慧，故障仍然会在复杂的系统中级联。可扩展性：要扩展任何一项功能，您只需扩展该微服务，而不是整个单体应用程序。易于部署：如果你更新一行代码，只需要更新和重新部署特定的微服务，而不是重新部署整个单体应用程序。相反，回滚服务比回滚整个应用程序要容易得多。Docker和Kubernetes等工具大大降低了部署和回滚的成本。可替换性：在应用程序中替换微服务比在单体应用程序中替换组件容易得多。微服务的最佳实践如上所述，SOA实施困难的原因之一是它们缺乏定义服务边界的指导。让我们看看微服务如何解决这个问题。定义服务边界每个微服务都有围绕解决特定业务问题的业务领域建模的特定功能。例如，对于Gmail，其业务领域包括使世界各地的人们能够通过电子邮件进行交流的所有功能。业务领域由限界上下文组成：与相同应用程序行为相关的代码。Gmail具有多种功能，包括文本编辑、发送和接收、归档、搜索等，所有这些都可能构成这样一个上下文。但是请注意，相关行为不一定与功能一一对应。一个高度自治的解耦系统就是能够独立地改变系统的部分而不影响系统的其他部分。服务彼此了解的越少，它们就越自主。更大的自主权带来更大的弹性。理想情况下，如果一个服务崩溃，其他服务仍将能够提供应用程序的降级版本。虽然解耦系统是最终目标，但并非总能实现100%的解耦。网络通信微服务通过其应用程序编程接口(API)通过网络进行通信。要发送和接收消息，他们必须就网络通信规则达成一致。您可能熟悉HTTP，并且还有更多此类协议。根据网络通信的方式，它们可以大致分为同步通信或异步通信。?同步模式：客户端请求需要服务器立即响应，甚至可能因等待而阻塞。?异步模式：客户端请求不会阻塞进程，服务器的响应可以是非即时同步的，有点像座机。建立连接并交换信息，连接期间无法接听其他电话。这种类型的通信通常与请求/响应消息传递一起使用，其中一个服务发送请求并等待另一个服务响应。在等待期间，两种服务都被阻止。可以想象，这只有在快速连接时才有可能。异步通信更像是电子邮件。您向某人发送一封电子邮件，通常可以继续进行其他工作。收到回复后，您将再次参与。这是异步通信的本质：服务发送消息，并继续执行其所有操作，直到收到响应。当网络不可靠或物理距离很远时，通常会使用这种类型的通信。它通常与发布-订阅（或发布-订阅）模式一起使用，其中服务发布事件并通知订阅事件的人。使用何种网络通信方式取决于实际业务场景。什么时候应该使用微服务？与处理单体应用程序相比，开发和维护微服务需要付出更多的努力。我们已经看到微服务有很多强大的优势，但这总是最好的方法吗？不，开发人员应该更喜欢单体，除非他们有令人信服的理由这样做。根据经验，单体架构最适合小型团队的小型应用程序，而微服务方法最适合由多个团队同时开发和维护的大型应用程序。组织应该从单体应用程序开始，当需要可扩展性、性能或弹性优势时，可以将其细分为微服务。何时需要拆分在很大程度上取决于您的用例。没有灵丹妙药，您必须经过深思熟虑后做出决定。您可以尽早做的是维护一个干净且模块化良好的代码库。当您开始运行和扩展您的应用程序时，这将使构建和扩展更容易，并且当您将单体分解为微服务时，它会减少您的成本和工作量。结合容器和Kubernetes如上图所示，每个微服务都放在一个容器中，这是一种新颖的封装机制，其概念类似于超轻量级虚拟机（VM），有助于微服务分布式隔离（注意尽管容器在概念上类似于VM，但它们不提供相同的隔离或安全保证）。尽管微服务早于容器，但容器使微服务更简单且更具成本效益。Kubernetes管理您的容器化服务，以确保它们有足够的资源并正常运行。它充当某种容器的数据中心操作系统。简而言之，微服务包含业务逻辑，即提供业务价值的代码。容器帮助打包微服务，使它们与系统的其余部分分离。容器和Kubernetes简化了微服务的打包和管理，这也是微服务如此受欢迎的原因之一。结论尽管微服务提供了比单体架构更大的灵活性并提供了令人难以置信的强大功能，但这些好处是以复杂性为代价的。组织必须仔细考虑采用微服务方法是否适合他们。在微服务中，您越来越多地听到容器和Kubernetes。这是因为它们是为微服务提供巨大价值的重要技术创新。如今，大多数使用微服务的组织都采用容器和Kubernetes对其进行管理。
