微服务架构

领域驱动设计的作者埃里克·埃文斯（Eric Evans）在前几天Explore DDD上的主题演讲中，邀请听众积极参与改进在建模和设计复杂系统时使用的语言。埃文斯（E

Micronaut是一个类似Spring Boot的微服务框架，Eventuate Tram是提供事务性消息的框架，提供事务发件箱模式，也就是将发送的消息首先存储到带有主键的关系数据库，然后通过消息系统发送到接收者，保证近似正好一次的传递，该机制类似Apache Kafka事务性消息，只不过

在本教程中，我们将了解了解如何在Spring Boot的帮助下应用十二因子方法开发微服务。 什么是十二因子方法论？十二因子方法论是一组十二种最佳实践，用于开发开发为作为服务运行的应用程序。该文件最初是由He

Bootique是一个

我们试图在IT方面加快步伐。我们提出了微服务，它需要容器(Docker)，需要调度程序(Kubernetes)，这需要......

这里有一些关于DDD的想法。我真的很喜欢DDD（领域驱动设计）的思想和原则，我真的建议你去研究它。这就是为什么现在是新博客的时候了。我们称之为C＃开发人员DDD的实用介绍。这是系列的第一篇文章。这篇文章介绍了DDD以及如何构建领域模型。那么，什么是DDD？您可能知道缩写的含义

让我们跳过微服务的推销 - 你已经知道它们是什么以及为什么它们有意义。事实上，近年来几乎没有什么话题能够获得如此多的报道，因为将一件大东西分解成许多小东西可以让它更容易处理。麻烦的是：一旦我们打碎了我们的单体巨石，我们如何将它重新组合成一个仍然有意义的更大的系统？尽管Istio，Ko

像亚马逊这样的大多数公司都是以单体（中台）方式开展业务，因为它是最快，最容易开发的系统。但是，将进程紧密组合并将它们作为单个服务运行是存在问题的，如果一个中台应用进程遇到需求高峰，则必须扩展整个架构以处理该一个进程的负载。此外，随着代码库的增长，添加和改进功能变得更加复杂，使得难以试

将Zeebe作为工作流引擎，您可以： 以您选择的编程语言构建应用程序（Zeebe提供Java，

Kubernetes改变了我运行软件的方式，但是，当我编写软件时，Kuberentes会让事情变得更难。在这篇文章中，我想叙述我自己在Kubernetes上开发软件时遇到的所有问题。完全披露：虽然我在Tilt工作是我工作的一部分，我们的目的是解决其中的一些问题，但我的另一部分工作是编写在Ku

两年多来，我一直在帮助宣传服务网格和Envoy Proxy。看到社区是如何发展的，更重要的是组织如何开始使用它来解决困难的生产和运营问题，这真是令人惊喜。凭借我在Red Hat和现在的Solo.io的时间经历，我很幸运能够与各组织密切合作，共同开展服务网络采用之旅。在这段实际，我开发

系统出现严重的问题，马上公开披露技术细节，而不是让民间流言替代真相，这样的分享值得点赞：7月29日从大约13:10开始，你可能会遇到Monzo的一些问题：可能无法： 登录应用程序 发送和接收付款，或从ATM取款 查看应用中的准确余额和交易

我们构建软件的方式正在发生变化。现在，由于API平台的激增，公司将以更快的速度推出市场并以前所未有的速度构建功能。API经济近年来爆炸式增长，数以千计的新API进入市场并重塑了开发人员构建软件的方式。几乎所有需求都有API解决方案：支付API，通信API，运输API以及数千种

“单体与微服务”的争论通常集中在技术方面，而忽略了战略和团队动力。但是，思维敏捷的组织不是从技术入手，而是以团队的认知负担作为有效交付和运行现代软件系统的指导原则。 

康威定律的核心是人的组织架构决定技术物理结构，这一规律不但在软件技术行业存在，而且存在其他行业，例如城市发展，从古罗马到现代的亚特兰大，城市的形状已经被允许通勤者在大约30分钟内上班的技术所定义：现代亚特兰大可能与过去几千年的城市几乎没有什么相似之处，但它目前的居民与遥远过去的都市人

— 使用一个共享数据库可以实现系统之间的集成 — 大声笑，你疯了吗？ — 好吧，那让我们使用一个二进制日志binlog在服务之间共享数据— 您一生中从未读过工程学的书吗？ — 让我们将二进