微服务是一种利用多个小组件(每个组件执行单个功能,例如身份验证、通知或支付流程)构建大型复杂应用的软件架构方法,亦指这些小组件本身。每个微服务都是软件开发项目中的一个独立单元,具有自己的代码库、基础架构和数据库。微服务协同工作,通过 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 Plus 和 NGINX 在 Dropbox、Netflix 和 Zynga 等高流量网站中有着广泛的应用。全球超过 3.5 亿个网站都使用 NGINX Plus 和 NGINX 开源版快速、可靠、安全地交付网站内容。
作为基于软件的应用交付控制器 (ADC),NGINX Plus 可提供对现代微服务架构至关重要的速度、可配置性及可靠性:
NGINX Management Suite 为 NGINX 微服务解决方案提供了应用交付管理。
当容器化是您微服务之旅的一部分时,NGINX Ingress Controller 和 NGINX Service Mesh 可为您的容器化微服务提供管理解决方案,并为异构的微服务环境之间的对接提供解决方案。