标签：blog man min 布莱恩特 级别 sys 范式 reac cto
java分布式系统开发
感觉像是对微服务的炒作正在慢慢地落到实处，并且我们的行业开始意识到，根据微服务背后的体系结构范式无法通过仅在现有组件之上公开一些HTTP接口来轻松创建一个系统。 。 我们似乎确实同意必须进行服务优化的基础架构，文化和组织变革，以及最后但并非最不重要的是这些架构的外部架构或业务流程。 许多Java开发人员似乎仍在苦苦挣扎的部分是具体的系统体系结构，以及事实上，微服务只不过是分布式系统而已。 不幸的是，正是这些知识领域决定了项目失败的成功。 对于一些背景知识，我建议您阅读
丹尼尔·布莱恩特（Daniel Bryant） 对Uwe和Adrian进行的InfoQ精彩采访 。
为什么再次使用微服务？ 我不能只是高兴地写EJB和Servlet吗？
微服务的关键思想是支持其余应用程序环境的独立性和快速可扩展性的属性。 此外，与基于应用程序服务器的应用程序相比，它们应独立扩展并需要更少的资源。 在不断变化的业务需求和不断增长的应用程序客户端数量的世界中，集中式基础架构的运营成本日益高昂，并朝着无法预测的负载或负载高峰扩展。 如果所有人都被应用服务器所困扰，那么就不会有Netflix，Twitter或Amazon。 所以：不。您不能只呆在原地。
微服务是分布式系统。 他们有什么特别之处？
分布式系统的原始定义是：“分布式系统是一种模型，其中位于联网计算机上的组件通过传递消息来通信和协调其动作。” （ Wikipedia ）这正是基于微服务的体系结构中发生的事情。 各个服务被部署到物理上在某个地方运行的云实例，并且它们交换消息。 这与我们用来构建集中式应用程序的方式有很大的不同。 现在，我们不再拥有代表我们处理各种同步，事务和故障转移方案的服务器，而是拥有独立发展且相互独立的独立服务。 分布式计算存在一些独特的基本挑战。 其中包括容错，同步，自我修复，反压，网络分裂等。
分布式系统不是每个人都称为React式系统吗？
比这更复杂。 老实说，这些天“React性”这个词本身有很多事情。 要使用单个微服务构建应用程序或系统，您需要使用一组设计原则，使它们具有响应性，弹性，弹性和消息驱动性。 如果听起来很熟悉，那可能是对的。 来自的定义
React式宣言 。 实现了《React式宣言》的四个特征的分布式系统就是所谓的
React系统 。 您可以在Jonas的书中阅读有关React式微服务系统设计原理的更多信息。 Lagom框架是基于这些原则构建的，但是让我清楚一点，您不一定需要特定的框架或产品来构建此类应用程序。 其中一些只是使您的地狱工作效率更高，而您的操作也会更有效。 休·麦基（Hugh McKee）有一本关于基于Actor的系统的设计原理的免费书籍 。
构建基于微服务的系统有哪些选择？
我个人看到解决今天与微服务有关的问题的两种不同趋势。 首先是将问题归结为业务流程或数据中心操作或云系统，例如DC / OS，OpenShift，Cloudfoundry等。 第二种解决方案是在应用程序或框架级别上本机处理它们（Akka，Vert.x等）。
每次服务一个容器，或者为什么Anaconda 不应该 吞下马匹。
让我们更详细地介绍第一种方法。 编写微服务，将其与运行时一起打包在一个小容器中，然后将其推送到云中。 由于如今我们都是开发人员全力以赴，DevOps开发人员很容易创建基于云的运行时所需的元信息。 多亏了我的引导性服务，所有相关的监视信息已经公开，并且我可以轻松地检测到失败的服务并重新启动它们。 这肯定可以工作。 您甚至可以将功能齐全的应用程序服务器用作微服务运行时。 此外，还有许多魔术框架（NetflixOSS）可帮助应对分布式系统的挑战。对我个人而言，缺点是在这种情况下与基础架构紧密耦合。 您的系统只能在所选平台上运行，而不能在其他平台上运行。此外，他们建议您只需要使用容器来解决微服务领域中的所有问题。 回顾一下React式宣言，这些类型的系统将无法帮助您满足在服务之间使用消息传递的要求。
没有容器的微服务？ 那就是没有黄油的花生！
真正。 容器做得很好。 将整个堆栈以可控制的方式打包到可部署的单元中。 它们是基础架构级别的隔离机制。 拥有容器标准实际上可能是一件好事。 因此，请保留您的容器。 但是，您还需要更多。
因此，构建具有复原力的自我修复系统的关键是允许对故障进行以下处理：将故障包含在内，将其整化为消息，发送给其他组件（充当主管）并从发生故障的组件外部的安全上下文中进行管理。 在这里，以消息为驱动力是推动力：摆脱每个人都学会了遭受...或无视的强烈耦合，脆弱，深度嵌套的同步呼叫链。 想法是将故障管理与呼叫链分离，使客户端从处理服务器故障的责任中解放出来。 没有容器或业务流程编制工具可以帮助您将其集成。 您正在寻找事件源。 的
使用事件源的事件驱动架构的设计概念与微服务架构模式非常吻合。
响应式编程，系统，流：不是全部一样吗？
React性已经成为一个超负荷的术语，并且现在已经与不同的人联系在一起，与好几个人相关联，例如“流”，“轻量级”和“实时”。 “响应式编程通过性能和资源效率提高了开发人员在内部逻辑和数据流管理的组件级别上的生产力。Reactive Systems通过系统级别的弹性和弹性为架构师和DevOps提供生产力，以构建Cloud Native或其他大规模分布式系统。 您应该真正花时间阅读一下JonasBonér和Viktor Klang如何解释他们之间的个体差异 。
在哪里可以了解有关如何设计React式微服务的更多信息？
詹姆斯·罗珀（James Roper）在去年的React式峰会上做了精彩的演讲，并亲身研究了系统的体系结构（包括数据流，所使用的通信类型以及将系统分解为组件的方式）如何需要在将整体分解为基于React式微服务的系统时会发生变化。
我在CJUG上进行了有关Java开发人员的CQRS的演讲 ，向您进行了介绍。 如果您有感兴趣的特定主题，请在评论中让我知道。
为您提供更多阅读
java分布式系统开发_从微服务到分布式系统-Java开发人员生存指南
标签：blog man min 布莱恩特 级别 sys 范式 reac cto
原文地址：https://www.cnblogs.com/java998/p/13580082.html
