微服务是当今构建软件系统的流行方式。随着公司变大并使用更多云计算，微服务帮助应对复杂性。
在本期文章中，我们回顾一些关键微服务概念和面试中常见的问题：
- 什么是微服务？
- 微服务旨在解决什么问题？
- 微服务引入了什么新挑战？
- 一些流行的微服务解决方案是什么？
- 微服务的监控和告警如何工作？
- 日志如何收集和分析？
- 什么是服务注册表？
什么是微服务？
我们可以引用 Martin Fowler 和 Adrian Cockcroft 关于微服务关键方面的定义。
Martin Fowler：
“微服务架构风格是一种将单个应用开发为一套小型服务的方法，每个服务在自己的进程中运行，并通过轻量级机制（通常是 HTTP 资源 API）通信。这些服务围绕业务能力构建，可通过全自动部署机制独立部署。这些服务最少集中管理，可以用不同编程语言编写，使用不同数据存储技术。”
Adrian Cockcroft：
“微服务是带有边界上下文的松散耦合服务导向架构。”
从 Martin Fowler 和 Adrian Cockcroft 的深刻定义中，我们可以总结微服务架构的这些关键方面：
将单体应用分解为小型独立服务：这允许不同产品团队开发、测试和部署与特定业务能力对齐的服务。对大型组织分解单体系统和提高生产力有用。
通过 API 松散耦合的服务：前端/后端组件通过 REST 通信，而服务间通信使用 RPC 进行高效请求/响应。
围绕边界上下文精心设计：每个服务有清晰的模块边界和封装的领域逻辑，避免服务间紧密耦合。
实现有效 DevOps 实践：这是微服务开发方法的重要组成部分。小型全栈团队完全端到端拥有特定服务。容器化、自动化和容器编排用于有效部署微服务。
按设计水平可扩展，抗故障：服务可根据需要独立扩展。内置容错。
去中心化治理和灵活性：团队可以选择对其服务有意义的任何技术。
需要广泛监控和仪器化：
- 服务增长 - 随着单体分解为许多独立服务，要跟踪的组件数量快速增长
- 通过容器/编排器的基础设施抽象 - 如 Kubernetes 等运行时平台处理基础设施。所以监控必须使用 sidecars 在应用代码级别聚合日志、指标和追踪
SOA vs. 微服务
服务导向架构（SOA）和微服务架构风格是软件架构演进中的重要里程碑。下图显示了关键架构风格的演进。
服务导向架构在 1990 年代末出现，帮助管理企业软件系统日益增长的复杂性。在 2000 年代，SOA 获得更多行业关注和企业采用。然而，SOA 面临实现复杂性挑战。
然后在 2010 年代，微服务架构作为对 SOA 局限性的响应出现。许多大型互联网公司开始采用微服务将服务分解为更小组件。随着云计算的演进，微服务获得动力，容器和编排工具使微服务的开发、部署和监控更容易。
让我们更详细比较它们的差异。下图列出了一些差异。
SOA 架构风格提供粗粒度服务，通常是集中式方法，服务按业务功能分组并在多个应用间共享。微服务风格通过去中心化方法提供细粒度服务粒度，小型独立服务在应用上下文中执行特定功能。
通信方法也随时间演进。SOA 强调统一通信协议和标准化接口供服务交互。微服务倾向于多样化通信协议和接口，通常基于 REST 或消息队列。
云计算已从基础设施即服务（IaaS）演进到平台即服务（PaaS）再到基于容器的 PaaS。所以微服务应用默认部署在容器上。
随着技术架构变化，组织结构镜像它（康威定律）。所以使用微服务，团队结构需要多功能产品团队。每个团队专注于特定领域。
本文为学习目的的个人翻译，译文仅供参考。
原文链接：7 Microservices Interview Questions。
版权归原作者或原刊登方所有。本文为非官方译本；如有不妥，请联系删除。