您可能已经听说过，微服务架构风格在过去几年中一直在增长，并且越来越多地被使用。 为什么？ 单片式广泛采用的样式发生了什么？ 微服务体系结构是否解决了整体设计带来的所有问题？ 不，它不能解决所有问题，但是即使如此，微服务还是一种出色的体系结构设计，我对此表示欢迎。 我告诉你为什么。
微服务风格有助于克服单片内部的若干问题，例如效率低下的扩展和卡在一个技术堆栈中。 微服务还减少了模块之间的高度耦合，并具有独立可伸缩性等新功能。 不仅如此，它还与业务领域驱动的设计相得益彰，这对您的组织可能非常有用。
但是，为什么要使用微服务？ 您已经知道的整体样式有什么问题？ 整体架构是当前最常用于开发应用程序的设计，但是在使用该架构时会遇到以下缺点：
- 适用于所有业务逻辑的单个繁重的项目：您可能习惯于处理单个大型项目，将其作为一个单元进行部署，然后需要几分钟才能在本地环境中启动并运行。 仅运行您感兴趣的模块并在不到一分钟的时间内准备好它不是很酷吗？
- 高耦合模块：将不同的模块集成到同一项目中时，经验不足或无知的开发人员很容易在完全不同的模块中重用不同的功能。 虽然重用代码是一种明智的做法，但是错误地使用代码会导致将来的麻烦和许多重构。 将所有代码和模块按仅属于它们的业务逻辑正确分组，这不是很酷吗？
- 仅一种技术：对于整体项目，后端项目只采用一种技术是很正常的。 您想过多少次，使用与您项目当前使用的技术完全不同的技术从积压的模块中实现一个模块是多么容易？
- 缺乏重新部署的能力：由于只有一个项目，并且是通过模块构建的，因此代码中的重大更改甚至有时只有一个项目，都迫使您重新部署整个应用程序。 在您的生产环境中这样做有多困难？ 您很有可能已经拥有克服这些众所周知的问题的机制，但是，仅将生态系统的单个部分重新部署不是理想的选择吗？
那么，什么是微服务？ 它的功能是什么？它们如何帮助您克服整体式方法的弱点？
首先让我说一下，由于它是相对较新的，因此对微服务架构没有确切的定义。 但是，我发现有一个非常准确的定义：
“微服务是处理明确定义的需求的独立流程。” [1]
这个定义乍看起来似乎很神秘，但是我喜欢它，因为它强调了必须从生态系统设计之初就采取的简单方法。 重要的是要注意， 微服务中的“微”是指业务范围，而不是应用程序的大小。
- 自治：分布式，独立，可更改和可部署的服务。 因此，在任何给定时间，您的一项服务是否比其他项得到更多的要求？ 使用微服务，无需扩展所有服务，只需扩展所需的服务，这就是独立的可扩展性！ 只需复制，升级和更改所需的服务。 不仅如此，还会发生错误，并且如果您的一项服务中断了，您就可以轻松隔离出故障的服务，而不会影响整个生态系统！
- 较短的时间 ：开始使用新的品牌项目时，一开始就可以在几秒钟内启动并运行。 但是随着时间的推移，随着待办事项负载的增长，它需要的时间越来越长。 微服务并非如此！ 微服务保持相对较小的大小常数，因为它一次仅满足一个明确定义的要求； 这也直接影响您的开发时间。 您可以使用一项服务来对其进行测试，也可以只检查所做的最小更改，而该更改始终与初始设置一样快。
- 多种语言 ：微服务对于实现多种语言生态系统不是必需的，但是，它使该选项更容易获得和实现。 如果需要，可以选择插入真正隔离的服务的能力，该服务是用与事实不同的技术创建的。 但是请记住，不建议您仅仅因为可以而兴旺发展所有使用不同技术创建的服务。 但是，如果您的团队对这是最好的选择达成了共识，那么集成使用其他语言制作的服务就不会是一个疯狂的主意。
许多公司和组织已经在体验微服务的力量，他们正在分享他们的经验以及在实施微服务架构时所使用的设计。 Netflix是一个很好的例子。 Netflix目前是成功实现单片并将其迁移到微服务的领先公司之一。
在整个勇敢的旅程中，Netflix创造了克服微服务架构挑战的软件。 他们的创作是经过考验的组件，可以轻松应用与分布式系统相关的模式（例如服务发现，断路器，智能路由和客户端负载平衡），允许他们监督其庞大的微服务生态系统健康状况的软件以及工具管理并提供其云资源的广泛可见性）。 幸运的是，对于我们其他人而言，Netflix已将其内部项目的几个部分开源了[2]，这可以帮助其他人克服使用这种出色架构时面临的潜在挑战。
由于许多原因，微服务比单片式计算机更具优势，并且随着时间的流逝，微服务将继续如此。 但是，值得注意的是，当人们走较少的路时，它们必然会一路颠簸。 开始学习使用此体系结构可能并不容易。 当然，您将需要学习一些技术，模式和实践。 但是，当我说微服务将带来一切改变时，请相信我！
[1]保罗·查普曼https://spring.io/blog/2015/07/14/microservices-with-spring
[2] https://github.com/Netflix
