微服务是一种利用多个小组件（每个组件执行单个功能，例如身份验证、通知或支付流程）构建大型复杂应用的软件架构方法，亦指这些小组件本身。每个微服务都是软件开发项目中的一个独立单元，具有自己的代码库、基础架构和数据库。微服务协同工作，通过 Web API 或消息队列进行通信，以对传入事件作出响应。
在《构建微服务》一书中，Sam Newman 简单明了地将微服务定义为“协同工作的小型自主服务”——这个定义包含了微服务的三个要素。微服务的代码库很“小”，因为它专注于一项功能；“小规模”意味着单个开发人员或小型团队即可创建并维护代码。“自主”意味着微服务可按需部署和扩展，当微服务内部发生变化时，无需咨询负责其他微服务的团队。这之所以成为可能，是因为当微服务“协同工作”时，它们通过明确定义的 API 或不会暴露微服务内部工作原理的类似机制进行通信。
使用微服务进行开发
随着项目的发展，微服务架构经常被用于解决其他架构模型出现的问题。传统的单体架构可能在逻辑上将功能分成各个组件模块，但所有模块都被置于单个代码库中，而且它们之间的相互依赖关系通常非常复杂，因此很难在不分解其他模块的情况下更改一个模块的代码。即使开发人员只专注于利用几个模块，他们也必须花费时间和精力来跟踪整个代码库的变化，因为其他模块的变更可能会影响其所用模块。雇用新的开发人员来加快项目发展速度会很快导致回报缩水，因为他们需要很长时间才能掌握庞大的代码库，然后方可安全地添加功能或修复错误。
将软件功能组件化为微服务有助于更轻松地扩展项目。借助面向不同系统的单独代码库，开发人员可以更轻松地推断代码变更的影响。通过支持不同服务的单独部署和基础架构，DevOps 团队能够更轻松地仅在需要的位置添加更多计算资源。
构建基于微服务的应用需要了解应用的组件如何协同工作，并设计这些组件的接口，以便将其分解。正如 Netflix 前首席云架构师 Adrian Cockcroft 所说，在微服务架构中，目标是在松散耦合和独立性方面，让应用中的组件微服务彼此间的交互，与您的服务和来自外部服务提供商的系统之间的交互一样。
管理微服务
微服务经常与某种形式的容器化相结合，而大多数 service 的管理工具均侧重于容器管理和扩展。Kubernetes 和 Docker Swarm 等常见管理工具在设计时均将微服务考虑在内。微服务通常部署在用于管理容器或虚拟机的平台上（例如 Amazon Elastic Container Service (ECS) ），但更常见的是部署在托管 Kubernetes 云平台上（例如 Amazon Elastic Kubernetes Service (EKS)、Azure Kubernetes Service (AKS) 及 Google Kubernetes Engine (GKE) ），或者部署在 Kubernetes PaaS 平台，例如 Red Hat OpenShift 容器平台和 Rancher。
部署微服务通常是从单体架构切换所面临的最大挑战之一，因为需要考虑一些对于单体架构而言不成问题的问题，比如 API 版本和跨多个域的集成测试。因此，自动化监控对于微服务部署至关重要，这可确保每个组件都能平稳运行。微服务应用中发生的局部故障比单体应用更为常见，而且系统需要在设计时充分考虑故障管理。
NGINX 如何助一臂之力？
作为出色的负载均衡解决方案，NGINX Plus 和 NGINX 在 Dropbox、Netflix 和 Zynga 等高流量网站中有着广泛的应用。全球超过 3.5 亿个网站都使用 NGINX Plus 和 NGINX 开源版快速、可靠、安全地交付网站内容。
作为基于软件的应用交付控制器 (ADC)，NGINX Plus 可提供对现代微服务架构至关重要的速度、可配置性及可靠性：
- NGINX Plus 提供了动态重新配置功能以支持实现简单的服务管理，并可轻松集成常见的微服务管理工具，例如 Kubernetes。Netflix 等领先公司均使用 NGINX 作为其微服务部署的核心。
- 大规模运营需要细致监控。NGINX Plus 提供了实时活动监控，支持您查看 service 对负载的响应情况，并将资源集中在所需的位置。
- 作为基于软件的负载均衡器，NGINX Plus 非常适合在配置不断变化的多服务部署中实现服务发现。
NGINX Management Suite 为 NGINX 微服务解决方案提供了应用交付管理。
当容器化是您微服务之旅的一部分时，NGINX Ingress Controller 和 NGINX Service Mesh 可为您的容器化微服务提供管理解决方案，并为异构的微服务环境之间的对接提供解决方案。
