微服务架构

我收到了许多高级Java开发人员的询问，他们渴望成为软件架构师或解决方案架构师，他们能做什么才能成为软件架构师？哪些书籍，资源或认证可以提供帮助？还有一般性的询问，例如您需要多少经验才能成为软件架构师等。过去，我一直向他们建议一些书籍以供阅读，以扩展他们的知识库，并从体系结构和设计的角度来看

与复杂性作斗争是软件开发中经常出现的主题，我已经看到过一遍又一遍在各个级别上争论不休：在函数和方法中应该进行多少注释？理想的抽象量是多少？框架什么时候开始具有“太多的魔力”？组织中什么时候出现太多语言？我们试图摆脱复杂性，控制它，并寻求简单性。我认为这种逃避复杂性的方式进行构架是错误

在过去的几年中，我已经对处于数字化转型过程中的多个产品团队进行了架构审查。大多数团队都在按照微服务架构构建产品。他们有使用基于微服务的体系结构的所有正确意图-更快的开发，更好的可伸缩性，更小的独立团队，独立的部署，使用正确的技术来完成工作，等等。但是，我经常发现团队在微服务方面苦苦挣扎。他们

通过DJL和Spring Boot进行机器学习是一种简单而强大的方法，通过DJL和DJL提供的便捷抽象层，将现有的经过实践测试的微服务技术堆栈SpringBoot与MXNet，PyTorch和Tensorflow等最成熟的深度学习框架相结合。Spring Boot是用于微服务开发的最

项目是我们正在进行的较大项目之一。最后，它将为成千上万的用户提供服务，处理大量的财务交易，并且需要即时创建独立于租户的安装。一个关键要求是，可以轻松地报告和跟踪整个历史记录，即企业的核心产品订购流程。同时，也拥有一个易于使用的产品管理系统。

随着越来越多的Java开发人员学习

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

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

在面向租户的微服务体系结构中，将租户上下文如tenant-id附加到传入请求，并在请求的整个生命周期中传播该上下文，这使用户能够基于该上下文路由请求。当请求调用链中任何服务收到请求时，某些服务可能会评估请求上下文以绕过某些业务逻辑。例如，验证用户电话号码的审核服务可能希望绕过测试流量的检查，

Monzo是一家伦敦数字银行，它们是如何在1600种微服务上运行其银行系统？

在HelloFresh，我们运行数百种微服务，这些微服务可以完成从供应链管理和付款到保存客户偏好的所有工作。大规模运行微服务并非没有挑战，许多公司开始经历复杂性的痛苦。像许多其他微服务采用者一样，我们发现随着服务数量的增长，越来越难以理解所有这些服务之间的交互。当微服务领域出现问题时，很难确

微服务架构倾向于在整个组织中分配数据责任。这对确保删除数据提出了挑战。常见的解决方案是为每个数据集或每个记录保留设置组织范围的标准。但是，始终会有跨越多个数据集和记录的数据。这些数据通常分布在您的微服务体系结构中，需要系统和团队之间的协调才能将其删除。一种解决方案是将数据删除不视为事

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

当服务的多个实例可以调用指定的外部服务，在这些服务实例中都要定制断路策略很浪费，比如调用外部服务一段时间后进行关闭处理逻辑等。他们可以统一共享调用同一个外部服务的统计信息，这样一个调用失败以后，其他服务实例就不要再重试一遍，这是使用分布式断路器的地方。由于找不到现有解决方案，我们决定

我们收集了从业者在技术讲座，博客和白皮书中提出的无服务器模式。目的是通过对分类进行分类并报告可能的收益和问题，以支持从业人员理解不同的模式。我们采用了多语言文献复审过程，调查了同行评议和灰色文献，并对模式（解决常见问题的通用解决方案）进行了分类，并附带了收益和问题。在24部精选作品中，我们确