SOA面向服务架构

尾部延迟（也称为高百分比延迟）是指客户端很少看到的高延迟。例如：“我的服务通常在10毫秒左右响应，但有时需要100毫秒左右”。世界上有很多导致尾部等待时间的原因，包括争用，垃圾回收，数据包丢失，主机故障以及操作系统在后台执行的奇怪操作。原因之一是现代体系结构（如微服务和SoA）往往具

微服务的流程编排将成为下一个要解决的大问题。在撰写本文时，有几种解决方案试图在该领域竞争，主要是构建自己的（文本）领域特定语言来描述业务流程。在我看来，编排应该改为在BPMN 2.x中表达，因为它是为此目的而精心设计的，易于理解且成熟的语言。

DDD（域驱动设计）是微服务体系结构的核心和最重要的基础。不了解DDD就无法掌握微服务架构真正的美丽之处。微服务架构顾名思义是一种将后端应用构建为一组小型服务的方法。每个服务都在自己的进程中运行，并使用HTTP / HTTPS，WebSocket或AMQP等协议与其他进程进行通信。每

在设计基于微服务的系统时，衡量和优化正确的指标至关重要。为每个微代码库和微团队设计本地边界绝对很容易。但是，要构建一个完整系统，我们必须将系统级别设计也考虑在内。微服务与系统级别的设计有关，而不是仅仅与单个服务有关。在基于微服务的系统中，我们通过最小化服务的公共接口（使之成为微服务）

软件架构中有一个鲜为人知的模式，值得更多关注。首次由Rajive Joshi在

本文是关于我在使用ASP.NET Core和EF Core的小型但复杂的应用程序上使用模块化单体/整体结构和域驱动设计（DDD）方法的经验。这不是有关模块化单体架构或DDD的入门知识（但每个链接都有很好的摘要），但我对每种方法的优缺点都有自己的看法。主要心得： 模块化

Wave是一家拥有70名工程师的17亿美元的公司，其产品是一个加减数字的CRUD应用程序。为了与此保持一致，我们的架构是一个标准的CRUD应用架构，一个Python单体在Postgres之上。从一个简单的架构开始，并尽可能用简单的方法解决问题，使我们能够扩展到这样的规模，而工程师们大多专注于

SAP是什么？为何价值$163B？每年公司在企业资源计划软件（通常称为ERP）上花费$ 41B 。如今，几乎每个大型企业都实施了某种ERP系统。但是，大多数小型企业通常不购买任何现成的ERP系统，而且大多数工程师可能没有看到过它们。ERP是公司存储其核心运营数据的地方，包括销

企业集成非常棘手。现在，如果我们必须集成两个（或多个）系统，我们知道：我们要么使用API​​，要么使用某些消息队列。不幸的是，世界上许多系统不支持API集成。正如我们所说的，还有许多没有API的东西。因此，当您不可避免地需要与它们集成时，以下是与遗留系统（或以遗留方式构建的非遗留系统）集成的

如果微服务将被称为业务组件，这是否会将我们的思维转向价值和业务战略，而不是泛泛而谈事物大小和Docker的大小？ 众说纷纭：大多数人通过技术关注来组织一切。 我们一直在追逐技术银弹。

转移到微服务不仅涉及将整体应用程序重新包装到容器中。架构上存在根本差异，影响到从传输数据到故障恢复的所有方面。无法解决这些差异可能导致可扩展性受限，性能下降以及意外中断。您的团队已决定将您的整体应用程序迁移到微服务架构。您已经对业务逻辑进行了模块化，对代码库进行了容器化，允许开发人员

多年来，可重用性/可复用性是软件架构设计中的一个圣杯。关于可重用软件模块的讨论在1970年代初得到了发展。例如，1974年史蒂文斯，迈尔斯和君士坦丁（Stevens，Myers和Constantine）撰写的开创性的计算机科学论文

有效的BPM治理的最终结果是对流程集（及其子流程）进行主动、有效的管理和持续改进，从而组织可以为其客户和其他利益相关者带来价值。这是BPM治理的五个关键要素： 度量 所有权 问责制 控制 支持

技术团队和管理层非常热衷于使用一个称为微服务的新流行语。但这涉及转换的成本。您如何进行这种转变？进行转换值得吗？还是继续进行一些修改以继续使用当前方法是否好？您如何决定？从遗留系统本身定义微服务的过程是一个传奇。让我们以单体/整体/旧式系统的POS应用程序域为例。这是

来自alexkrupp的这篇文章虽然是基于Django/Python编写，但是实践原则是通用的。大多数现有的软件架构建议都是为 100 亿美元以上的公司编写的，因此往往侧重于最大化性能、可扩展性、可用性、可靠性等。这实际上造成了一个巨大的问题。问题是，由于在大学学习计算机科学