【.com快译】今天，微服务框架已经逐渐从炒作变成了实用的解决方案。整个技术行业已经开始意识到，我们很难仅仅通过在现有组件之上开放HTTP接口来构建满足微服务规范要求的系统。尽管很多组织已经明确架构及其编排的重要性不亚于基础设施优化、文化转型甚至组织调整，但对于大多数Java开发人员来说，掌握具体的系统架构还是比较困难的，或者很难微服务有别于分布式系统。而这些认知恰好是项目成败的关键。在今天的文章中，我们将以一问一答的形式对此进行说明。为什么要重新审视微服务？不能继续写EBJ和Servelet吗？微服务的关键是以独立的方式支持应用的快速演进。此外，它应该能够独立扩展并且比基于服务器的应用程序具有更低的资源需求。考虑到不断变化的业务需求和不断增加的应用程序客户端数量，集中式基础架构的运营成本和适应不可预测的负载甚至负载峰值的成本都将高得令人望而却步。如果您坚持使用应用程序服务器，那么像Netflix、Twitter或Amazon这样的解决方案根本不可能实现。微服务是分布式系统。前者有什么特别之处？分布式系统的最初概念是：“分布式系统是一种模型，其中组件位于联网的计算机中，并通过发送消息相互通信和协作。”这同样适用于微服务架构。各个服务部署在云实例中，通过交换信息实现操作功能。这种想法与集中式应用程序构建有很大不同。我们现在不再在数据中心设置大量服务器来处理各种同步、事务和故障场景，而是开始以独立的形式开发各个服务，互不影响。当然，分布式计算也带来了一些特殊的基础性挑战，包括容错、同步、自愈、背压、网络分区等。分布式系统是人们所说的反应式系统吗？现实要复杂得多。坦率地说，如今许多概念中都使用了“反应性”一词。要使用多个独立的微服务构建应用程序或系统，您需要利用各种设计原则来实现相互反应、弹性和消息驱动的功能。也许这听起来很熟悉——是的，ReactiveManifesto给出的定义就是这样。能够实现ReactiveManifesto提出的四个特性的分布式系统就可以称为反应式系统。比如Lagom框架就是基于这些基本原理，但具体来说，你不需要使用特定的框架或产品来构建这样的应用，因为这样的框架或产品只是为了提高执行效率。我们可以使用哪些选项来构建基于微服务的系统？我个人认为微服务在解决问题上呈现出两种趋势。一种是将问题向下移动，以便由编排、数据中心或云系统处理。第二种解决方案是基于应用程序或框架级别的本地解决方案。每个服务一个容器，为什么容器不能容纳更多的应用元素？这里先讨论上面提到的第一种方法。编写一个微服务，将其与运行时一起打包在一个小容器中，然后将其推送到云端。作为全栈DevOps开发人员，您应该能够轻松创建云运行时所需的元信息。此外，我们可以通过详细的监控信息轻松检测并重启失败的服务。此外，还有很多神奇的框架（NetflixOSS）可以帮助应对分布式系统中的各种挑战。我个人认为这种方法的缺点是缺乏与基础设施的紧密耦合。这意味着整个系统不能在所选平台之外运行。另外，有人认为容器技术可以解决微服务领域的所有问题。但是通过回顾ReactiveManifesto，你会发现这类系统无法帮助我们实现服务之间的信息传递需求。没有容器作为辅助的微服务？这可能吗？当然，容器技术有一个很大的优势：以可控的方式将整个堆栈打包为一个可部署的单元。它可以看作是基础架构级别的隔离机制。容器标准本身就是一个优势，这意味着我们的容器更易于存储和使用。但这还不够。要构建一个有弹性和自我修复的系统，我们需要能够包含错误，将它们定义为消息，将消息发送到其他组件（即监控组件）并在故障组件之外安全地管理它们。而这一切都需要信息驱动的机制来实现：远离强耦合、脆弱和深度嵌套的同步调用链，而是让每个组件都具备容错……或者忽略能力。我们的想法是将调用链中的故障管理机制解耦，这意味着客户端不再需要负责处理服务器故障。显然，没有容器或编排工具可以达到这种效果。每个人都需要做事件追踪。事件驱动架构与微服务架构模式配合得很好，因为在设计理念中考虑了事件溯源。响应式编程、系统、流程：它们都是一回事吗？Reactive已经成为一个被过度使用的词，现在不同的人有不同的理解——在好的企业中，它代表“流式”、“轻量级”和“实时”等含义。响应式编程可以从性能和资源效率的角度提高开发人员的生产力，并且基于内部逻辑和数据流管理的组件级别。响应式系统基于云原生或其他大型分布式系统的系统构建层次，通过弹性能力帮助架构师和DevOps团队提高生产力。原标题：从微服务到分布式系统：JavaDevs的生存指南原作者：MarkusEisele
