迁移到微服务体系结构不仅仅是用HTTP请求替换方法调用的问题。欢迎来到容器、反应式的世界。

感觉微服务的大肆宣传正在慢慢落到实处。我们的行业开始意识到，根据微服务背后的架构范例，仅仅在现有组件之上公开一些HTTP接口是不容易创建系统的。我们似乎同意有必要对服务进行优化的基础设施、文化和组织变革，最后但并非最不重要的是这些架构的外部架构或编排。许多Java开发人员似乎仍在努力解决的问题是具体的系统架构，以及微服务只不过是分布式系统这一事实。不幸的是，正是这些知识领域决定了项目的成败。作为一点背景知识。

为什么又是微服务？我就不能快乐地写EJB和Servlets吗？

微服务的关键思想是支持它们独立于应用程序环境的其他部分和快速发展。此外，它们应该独立扩展，并且比基于应用服务器的应用程序需要更少的资源。在一个业务需求不断变化、应用程序客户机数量不断增加的世界中，集中式基础设施的运营成本越来越高，无法向不可预测的负载或负载峰值扩展。如果我们只能使用应用服务器，就不会有Netflix、Twitter或Amazon。所以。。。不，你不能呆在原地。

微服务是分布式系统。他们有什么特别之处？

分布式系统的最初定义是：“分布式系统是一种模型，在这种模型中，网络计算机上的组件通过传递消息进行通信并协调它们的操作。”（Wikipedia）而这正是基于微服务的体系结构中发生的事。

各个服务被部署到云实例，在它们交换消息时在某处物理运行。这与我们以前构建集中式应用程序的方式有很大区别。我们的数据中心不再有一堆服务器代表我们处理各种同步、事务和故障转移场景，我们现在有了独立发展的独立服务，彼此之间没有联系。分布式计算有一些独特的基本挑战。其中包括 容错 、 同步 、 自愈 、 背压 、 网络分裂 等等。

分布式系统不就是大家所说的反应式系统吗？

比这更复杂。老实说，现在“反应性”这个词本身有很多变化。要从单个微服务构建应用程序或系统，需要使用一组设计原则，使它们具有 反应性 、 容错性 、 弹性 和 消息驱动性 。如果这听起来很耳熟，你可能是对的。这是反应宣言中的定义。

一个分布式系统实现了反应性宣言的四个特征，这就是所谓的反应性系统。

构建基于微服务的系统有哪些选择？

我个人认为解决当今微服务相关问题有两种不同的趋势。第一种是将问题向下推到编排或数据中心或云系统，如DC/OS、OpenShift、Cloudfoundry等。第二种解决方案是在应用程序或框架级别对它们进行本地处理（ Akka ， Vert.x 等）。

每次服务一个容器

让我们更详细地看一下第一种方法。编写一个微服务，将它与运行时打包在一个小容器中，并将其推送到云上。由于我们现在都是全栈DevOps开发人员，创建基于云的运行时所需的元信息很容易。多亏了我的bootiful服务，所有相关的监控信息都已经公开了，我可以很容易地检测到失败的服务并重新启动它们。这肯定管用。您甚至可以使用成熟的应用程序服务器，如microservice运行时。此外，还有许多神奇的框架（netflixos）可以帮助应对分布式系统的挑战。

我个人的缺点是在这种情况下与基础设施的紧密耦合。你的系统只能在你选择的平台上运行。进一步说，他们建议您只需要使用容器来解决微服务世界中的所有问题。回顾一下被动声明，这些类型的系统不会帮助您满足在服务之间使用消息传递的需求。

没有容器的微服务？那是没有黄油的花生！

是的。容器可以很好地完成一件事： 以一种可控的方式将整个堆栈打包成一个可部署的单元。它们是基础设施级别的隔离机制。有一个容器标准实际上可能是一件好事。所以，保留你的容器。但你需要更多。因此，构建具有弹性的自愈系统的关键是允许故障被包含、细化为消息、发送给其他组件（充当监管者），并从故障组件外部的安全上下文中进行管理。在这里，被消息驱动是使能器：远离强耦合的、脆弱的、深度嵌套的同步调用链，每个人都学会了忍受。。。或者忽略。其思想是将故障管理与调用链分离，从而将客户机从处理服务器故障的责任中解放出来。没有任何容器或编排工具可以帮助您集成此功能。你正在寻找活动来源。使用事件源的事件驱动体系结构的设计概念与微服务体系结构模式非常一致。

反应式编程、系统、流：这不都一样吗？

反应性已经成为一个超负荷的术语，现在它与一些不同的事物联系在一起，比如“流媒体”、“轻量级、，反应式编程通过组件级的内部逻辑和数据流管理的性能和资源效率，为开发人员提供了生产力。反应式系统通过系统级的弹性和弹性为架构师和DevOps提供生产力，以构建云本地或其他大规模分布式系统。

那到底什么是分布式应用？

分布式应用程序是由多个客户端组成的应用程序，这些客户端通过网络与服务器或机器通信。

如何使用分布式应用程序？

分布式应用程序可以以多种方式使用，从电子商务平台到桌面应用程序。当谈到如何利用或应用分布式体系结构时，您确实需要了解要将哪种类型的系统应用于您的应用程序。

在决定应用程序适合哪种体系结构之前，您确实需要一个适当的概念分解计划。这将远远超过您希望使用的任何技术或体系结构。那么开发人员可以创建哪些类型的分布式应用程序呢？让我们看几个例子。

分布式应用示例

对于分布式应用程序，有三种主要的应用程序体系结构：client-server体系结构、代理模式或面向服务的体系结构。显然，现在有许多方法可以将client-server分布式应用程序从两层系统生成为具有n个层的多层系统。

基于您需要达到的任何级别的需求，将在很大程度上取决于您选择的路线。至于代理模式，实际上有一种主要的技术产生它们，称为公共对象请求代理体系结构（ CORBA ）方法。而面向服务的体系结构（ SOA ）设计实际上是代理和客户机-服务器体系结构的结合。

client-server体系结构

在我们深入了解客户机-服务器体系结构涉及哪些不同的层系统之前，首先我们需要了解。为Java应用程序创建客户机-服务器体系结构需要什么？设计客户机-服务器体系结构的最简单方法是将框架分割为不同的任务或工作负载，这些任务或工作负载由服务器或服务请求者（客户机）提供。

因此，名为client-server的体系结构是这样的：一方的客户机正在创建某个请求，在该请求中，服务器充当请求的函数并完成任务。在这种情况下，客户机促进了与服务器端的所有通信，因此客户机端不会与其他客户机共享任何原因。

代理模式体系结构

那么，什么是经纪人模式？基本上，代理模式应用程序是一个分布式系统，它使用解耦的组件，这些组件通过远程服务调用相互交互。使代理模式独特的是代理组件，它协调解耦组件的通信。当客户机请求应用程序中的任务时，代理将接收该任务或服务，然后将该任务重定向到相应的服务器以执行该任务。

实现这种设计的主要方法是创建CORBA。CORBA是由对象管理组（OMG）定义的一种标准实践，它们有助于促进这些复杂系统的技术通信。

面向服务的体系结构

SOA是一种设计策略，其中应用程序使用网络中可用的服务。这些服务中的每一个都可以组成一个应用程序。SOA确实有以下必要要求：

• 标准化服务合同
• 松耦合
• 抽象
• 可重用性
• 自治
• 可发现性
• 可组合性

上面的需求描述了组成SOA的组件。但是SOA应用程序也定义了不同的角色。这些角色的范围可以很广，但一般来说，大多数都是服务提供者、服务使用者/请求者和服务代理的三个角色。

这些角色是非常不言自明的，但是服务提供者充当服务注册中心信息的生产者，服务代理帮助确保服务使用者可以使用来自服务提供者的信息。基本上，责任成为两种结构的混合体，其中客户机服务器现在有一个稍微解耦的服务充当代理。

何时使用以及何时不使用分布式应用程序体系结构

不是所有的应用程序体系结构都使用分布式应用程序体系结构，因此肯定有一些缺点，对吧？当然，也有一些主要的好处。确定这些优缺点是显而易见的，为什么应用程序体系结构有如此多的责任。

何时使用分布式应用程序体系结构

分布式应用程序体系结构为您的应用程序提供了许多好处，包括 可伸缩性 、 可恢复性 、 资源共享 、 灵活性 和 并发性 。可伸缩性在现代应用程序开发中非常重要，它允许团队在这么多级别上使用应用程序，从而消除了许多技术债务。分布式应用程序将具有弹性，这意味着即使应用程序的某些部分出现故障，应用程序也可以连续运行。

• 资源共享
• 开放性
• 并发
• 可扩展性
• 容错

使用这种体系结构，应用程序可以保持运行，但也可以通过共享软件和硬件资源来提高应用程序性能，从而在系统上实现更好的开销。由于这些系统中的许多系统独立于每一个系统而工作，因此它允许重用服务或技术的灵活性，或者允许为工作使用正确的软件或硬件的能力。

最后，分布式应用程序允许一致的更改和更新，因此应用程序版本更具迭代性和并发性。这将导致更好的应用程序性能和更频繁的更新交付。

何时不使用分布式应用程序体系结构

从理论上讲，如果您可以创建每个应用程序，而不使用任何规模的分布式系统，那么您的应用程序将更容易、更快，而且总体上更可预测。然而，实际情况是，您的应用程序最需要一些级别的系统负载，这需要拆分应用程序。

现在这肯定会带来一些问题，因为复杂程度和整体设计本身就使得应用程序很难创建。而非分布式应用程序可能更简单，需要的故障排除也更少。

应用程序从一台服务器向另一台服务器发送任何信息的任何时候都会带来一定程度的安全问题。当然，如果您的应用程序不希望拥有更大的用户群，并且担心安全性，那么您可能会发现分发不是一种选择。在大多数情况下，独立应用程序往往属于这类非分布式应用程序。

构建分布式Java应用程序的工具和技术

构建分布式Java是出了名的困难，其中包含了大量的细微差别、技巧和知识。不过，这里有一些工具可以为我未来的设计计划提供一些帮助或有趣的帮助。

• Docker-Docker是集装箱化的事实标准
• Kubernetes是容器编排的事实标准
• JRebel—在Java开发期间跳过重新部署
• XRebel-分布式应用程序中的端到端跟踪请求。

最后的想法

总的来说，研究不同类型的分布式系统并试图理解什么对您或现在或将来有意义是非常有趣的。有了使用和创建分布式Java应用程序更容易的技术，想到这些系统可能如何发展就很激动人心了。