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