在本文中，我们将讨论微服务的优缺点，以便您可以做出更好的决定。在此之后，我们将通过一个例子来了解微服务架构。
硬件的进步幅度已经赶上了应用程序变复杂的脚步。然而却没有赶上互联网流量变化的脚步。 因此需要改变架构和web接口，我们有许多技术来解决这个问题，现在后端单体程序几乎不存在。
我们将在这里讨论微服务的优缺点。
优点：
您可以使用各种语言的最新技术栈。
可以使用应用隔板（Bulkhead），这样如果一个系统失效，其他系统还能有效服务。
动态可扩展
组合而成的应用程序， 发布周期不会很长。
应用程序将是一组独立的系统，部署过程将更加平滑。
有助于有效利用人力和技术资源。
缺点：
这对于小型应用来说非初始成本非常高。
集成和测试工作可能会增加。
有时开发者会抱怨重复的工作。
增加服务API可能非常复杂。 内存消耗可能很高
引用Martin Fowler的话：
我们听到的一个合理的论点是，你不应该从微服务架构开始。取而代之的是单体应用，保持它的模块化，一旦单体应用出现问题，就将它分割成微服务
如果你已经开始使用微服务，那么它的优势就很明显了。如果应用程序变得庞大而复杂，那么随着应用程序逐渐模块化，然后转向微服务。因为微服务在技术，工作量和架构设计水平方面非常的要求很高。
我们将创建一个项目来演示。 微服务是一种架构风格，其实现由许多框架支持，即。Dropwizard，Vertx，Spring Boot，Restlet，Spark + Unirest（REST客户端，Spark本身不提供REST客户端）等。这里我们将使用Spring引导。 这是微服务最流行的框架，因为我们知道它由Spring提供支持。
在这个项目中，我们将使用Eureka服务器，它仅仅是一个服务注册中心实现。 在这种情况下，每个微服务都被注册，客户端通过查找Eureka服务器来查找相关的微服务。 我们试图模仿这里的真实世界场景，其中Eureka服务器和不同的微服务分别部署。
初始化Eureka服务
对于我们的演示目的，我们仅仅使用Eureka作为我们的服务注册服务器。 为此，您只需使用正确的依赖关系并在应用程序yaml或属性文件中指定Eureka属性。
Eureka POM
application.yaml
以下是将您的应用程序主要配置
一旦我们启动应用程序，Eureka服务器将显示所有已注册和可用服务的详细信息。
目前没有任何已注册的服务，因此您会看到警告。
微服务客户端
我们将定义两个简单的项目：员工服务和雇主服务。 这两个服务将向Eureka服务器注册。 这些项目的核心将是它的应用程序属性，它们将定义它们将在服务器上注册的名称和其他参数。
员工服务
雇主服务
一旦我们启动了程序，他们就会在Eureka上注册。
请注意，警告已消失。
使用已发布的微服务
客户都注册了不同的名称。 这些名称将用于在其他客户端查找服务。 在我们的例子中，EMPLOYEE-SERVICE返回静态数据。 此数据在EMPLOYER SERVICE中获取并显示。
员工服务
我们只有2个预定义的数据集，我们将仅从此集返回。
雇主服务
请注意雇主服务如何访问员工服务。 它没有使用任何主机或端口。 基于服务名称，它设法找到并使用该服务。
输出
结论
在这里我们看到了基于Spring Boot的微服务最小功能实现。 这里服务与服务器配置和部署非常隔离。
您可以从GitHub Repository下载完整的代码[1]
文中链接：
[1] https://github.com/pavansolapure/opencodez-samples/tree/master/microservices
閱讀更多 高可用架構 的文章
