微服务好在哪里，我们为什么要使用微服务？_为什么要学微服务-优快云博客

本文链接：https://blog.youkuaiyun.com/u013643074/article/details/130367177

微服务的力量，这就是应该使用它的原因。

微信搜索关注《Java学研大本营》，加入读者群，分享更多精彩

什么是微服务？简而言之，微服务是一种将应用程序设计和构建为小型、独立运行的服务集合的方式。一个单一的、整体的应用程序很像野外的孤独动物——比如北极熊——它需要它的所有身体部位完全正确地工作，并且作为一个单一的实体完全正确地工作，才能茁壮成长。相比之下，微服务就像一个蜂箱。每个微服务都有自己的应用程序编程接口 (API)，并且可以独立访问和测试，并且像蜜蜂一样，让许多小工人执行相同的几个简单的互连任务可能比一个强大的个体执行更复杂的任务更有效率。

传统应用程序可能被设计为由模块组成的大型代码库。微服务采用这些模块并将它们分成单独的微服务，每个微服务代表一个责任区域，例如登录、搜索、订购和运输。这些微服务中的每一个都通过它们的 API 与另一个微服务进行通信。每个服务都在一个狭窄范围的域中运行，并且旨在很好地执行该任务。

为什么这很重要？

如果您的应用程序是使用微服务组件构建的，那么您就不会出现单点故障——您的整个应用程序不会崩溃，因为您的登录微服务无法正常工作。当出现问题时，您的开发人员可以快速介入，识别问题，修复问题，并让您的应用程序启动并运行。此外，可以以最小的风险更新和部署微服务。

为什么是微服务？

微服务有助于解决一些非常常见的问题，例如水平扩展和松散耦合。

水平扩展是增加服务实例的数量以适应更多的用户/事务。例如，假设我们正在运行三个登录服务实例，但我们在黑色星期五和网络星期一等假期遇到使用高峰。为了应对峰值，我们可能会预先扩展至 12 个实例，并根据需要将其设置为自动扩展至最多 24 个实例。现在，登录服务可以在不崩溃的情况下处理交易的增加，并且在购买高峰期间，企业和客户都很满意。我们可以通过微服务来做到这一点。

松耦合允许服务减少对另一个服务的依赖，这允许更新或替换一个服务而不影响其他服务。例如，服务可以以不同的方式、不同的语言或不同的内部技术实现，但由于外部 API 保持不变，微服务之间的功能不会中断。

一切都应该是微服务吗？

不必要。微服务通常设计用于完成特定工作，例如独立功能。微服务通常仍然与其他非微服务一起工作并依赖于其他非微服务，例如 Web 服务器、队列、缓存、数据库和通知服务。当扩展大量事务对业务很重要时，微服务是一个很好的选择；金融服务组织社交媒体和在线零售等行业是微服务的早期采用者。

微服务挑战

虽然我们喜欢在 PVM 中使用它们，但微服务显然并不适合所有情况。它们的设计确实存在缺陷，但有解决这些挑战的方法。让我们探索一些可追溯性、测试和更新。

可追溯性

可追溯性是通过系统从头到尾跟踪交易的能力。微服务通常将它们的日志聚合到一个地方——那么你将如何跟踪这个事务呢？一种解决方案是引入跟踪 ID，然后可以在整个生命周期中跟踪事务。有时，微服务日志信息会让人感到不知所措。但是，如果您只是适当地标记和组织日志，这不一定是问题。

测试

此外，测试可能需要对微服务进行一些重组。除了标准单元测试、回归/集成/端到端测试和冒烟测试之外，现在还可以单独测试微服务。API 功能可以使用PostMan、Insomnia等工具进行测试，也可以使用Apache JMeter等工具进行非功能（性能）测试。

更新

最后，适用于多个微服务的更新可能意味着多次执行相同的更改。一种更有效地工作的方法是重构微服务以使用可以在微服务之外进行更新的通用库。

与传统的单体应用程序相比，微服务的一个优势是，当对非微服务进行更改时，必须重新部署整个应用程序，这存在崩溃、错误和延迟的风险。对一个微服务的更改可能意味着对该服务的局部更改以及更小、风险更低的重新部署。

PVM 中的微服务

作为Palantir 的首选提供商，PVM 被授权与 Palantir Gotham 和 Palantir Foundry 一起运营、维护和开发，这些都是基于微服务原则构建的。作为Amazon 合作伙伴，PVM 拥有基础和技术级别的认证，可以帮助您使用微服务开发、构建、部署和运行您的应用程序。

对于微服务开发人员来说，一个值得一提的重要资源是十二要素应用程序宣言，它是由早期的软件即服务 (SaaS) 提供商 Heroku 开发的。他们提炼了将应用程序部署到平台的经验教训，并将这 12 个因素作为指导新服务设计的原则。我们 PVM 的工程师在一些项目中使用了这个宣言，我们在下面强调了我们常用的两个指导原则：

因素 3：配置对构建过程很重要。宣言将配置描述为部署之间不同的任何内容。配置因素指出，微服务需要“将配置与代码严格分离”。这种分离有助于清楚地传达配置的内容，并防止配置值在源代码中被硬编码——本质上是分离组件，这样它们就不会破坏源代码。
因素 11：宣言指出，无论微服务的规模有多大或多小，所有日志都应显示应用程序的输出和错误。这集中了信息并汇总了数据，以便能够实时监控它。然后，开发人员可以在一个中心位置快速查看错误和输出，而无需为每项服务挖掘不同的存储磁盘。

微服务是否适合您的组织？您是否看到它们可能如何在您的某些系统或应用程序中实现？我们希望如此。