微服务架构

上下文映射，最早是由Eric Evans在领域驱动设计中描述的，是一种轻量级的方法，用来描述系统和系统的一部分之间的关系。 它本身不是技术性的。它暴露了组织的政治和构建系统的团队。当你开始绘制时，连接两个系统的每条边都定义了一个上游和一个下

微服务应用程序可以以多种方式运行，每种方式都有不同的权衡和成本结构。适用于跨越几个服务的小型应用程序可能不足以用于大型系统。 从简单到复杂，以下是运行微服务的五种方式：单机多进程：购买或租用服务器并将微服务作为进程运行。<

微服务听起来很棒，它们是模块化的、可扩展的和容错的。很多公司都使用这种模型取得了巨大的成功，因此微服务可能自然会成为卓越的架构和启动新应用程序的最佳方式。然而，大多数在微服务方面取得成功的公司并不是从它们开始的。考虑一下 Airbnb 和 Twitter 的例子，它们在超越了单体应用

你的团队决定是时候摆脱那个旧的、笨重的单体了，它运行得很好，但是单体已经变得如此之大，以至于你花费更多的精力来维护它而不是添加功能。这里有 12 个技巧，可帮助您尽可能顺利地过渡到微服务。 #1 确保你知道你在做什么

在过去的 10 年中，我曾参与过多次扩大规模的工作，因此我采用了一些原则来扩大技术和产品团队的规模。 第一个，是组织跨职能的团队。通常，要构建任何产品，您需要产品经理代表业务，产品设计师代表客户和工程师来构

单体应用很简单。浏览器向 webapp 端点发送请求；后者从数据库中获取数据并返回响应。移动客户端与微服务的兴起破坏了这种简单性，这篇文章中讨论一种处理复杂性的解决方案。 系统架构的复杂性增加1、移

一、概述在本教程中，我们将使用 Hexagonal Architecture 的原理，使用 CLI 使用者实现一个简单的 Java CMS 应用程序。主要思想是尽可能保持业务逻辑分离，并使用SOLID原则中的“ D”依赖反转原则来防止层之间的耦合。<

让我们一起来看看我们如何使用 sidecar 来解决微服务架构中横切关注点，例如授权、缓存、配置秘密管理和可观察性。 跨领域问题让我们从解释横切关注点开始。应用程序的不同层需要应用程序业务代码之外的

亮点：微服务并不能确保良好的模块化：如果您使用微服务足够多，您可能会构建或借用一些不错的工具来简化服务之间的通信。但是，如果你不小心，你最终会得到一个紧密耦合的微服务式单体，每个函数都有大量的 HTTP 调用和要处理的版本控制。 在 Web 软件架

本文将教您如何在 Kubernetes 上运行 ActiveMQ，并通过 Spring Boot 将其与您的应用程序集成。我们将使用专门的操作员部署一个集群的 ActiveMQ 代理。然后我们将构建并运行两个 Spring Boot 应用程序：第一个在多个实例中运行并从队列接

CQRS 是一种微服务架构模式，它代表命令和

如果我可以推荐一本专业书籍给任何从事 IT 工作的人阅读，那就是Mathew Skelton 和 Manuel Pais 的《团队拓扑》。顾名思义，主题是关于组织业务

分布式事务管理问题：如何处理跨多个服务的事务？

Cloudflare 自 2014 年以来一直在生产中使用 Kafka。从那时起，我们已经取得了长足的进步，目前跨多个数据中心运行 14 个不同的 Kafka 集群，大约有 330 个节点。在他们之间，在过去八年中处理了超过一万亿条消息。 Clou

当提到 "公共基础设施 "时，人们通常会想到道路、桥梁、铁路、水坝、发电厂、城市照明。这些都是公共资助/拥有/管理的推动者，它们使更多的老百姓能够做生意，并满足基本需求。公共基础设施有时是免费的，但并不总是如此（你支付电费和过路费；当然有人会正确地指出，没有什么是免费的，因为我们通过税收支付

毋庸置疑，应用程序的架构在最近几年发展迅速。经典的单体架构已经被分解为微服务的集合，它更灵活，更容易部署。然而，虽然微服务已经变得非常流行，但使用这种架构也有一些弊端。最近，一种更细化的分布式应用组件的方法正变得流行，称为纳米服务。纳米服务并不是微服务的替代品，但它们能很好地解决微服务的一些