什么是微服务架构？
微服务架构是一种技术，通过将应用程序分解为实现特定业务功能的离散服务，为现代开发人员提供了设计高度可扩展、灵活的应用程序的方法。这些服务通常被称为 “松散耦合”，可独立构建、部署和扩展。
每项服务都通过标准化的应用程序编程接口 (API) 与其他服务进行通信，使服务能够以不同的语言或基于不同的技术编写。这与作为整体结构构建的系统完全不同，整体结构中的服务是相互联系、密不可分的，只能一起扩展。
由于每项服务的功能有限，因此它的规模和复杂性都要小得多。微服务一词源自这种独立的功能设计，而不是其物理规模。
为什么要使用微服务架构？
微服务架构越来越受欢迎，原因在于其模块化特性可带来灵活性、可扩展性并减少开发工作量。其部署灵活性以及云原生无服务器和功能即服务部署选项（例如 AWS Lambda 和微软 Azure 云功能）的出现，为微服务在当今 IT 格局下蓬勃发展创造了完美环境。这些云平台使微服务和功能可从非活动状态扩展到高容量并恢复，而客户只需为他们使用的计算容量付费。
随着企业不断寻求提高敏捷性、减少瓶颈以及缩短应用程序交付时间，微服务架构越来越受到欢迎。
微服务架构的好处
- 应用程序组件可以用不同的编程语言构建
- 可以维持单独的持续开发和部署流
- 可以构建极具可扩展性的应用程序
- 可以使用云原生功能即服务部署选项
- 通常会降低运营成本
- 隔离和松散耦合实现了分区升级和增强功能
微服务架构使用案例示例
- 采用云原生部署选项：利用无服务器和功能即服务实现更高效、可扩展的运营。
- 从原有应用程序迁移功能：从大型整体结构应用程序中分解服务，以便能够独立对其进行维护和扩展。
- 利用现代应用程序架构：采用事件驱动的松散耦合微服务应用程序模式，并能够根据用例需求利用不同的编程语言。例如，选择计算量大的函数，使用 Node.js 用于快速 Web 应用程序等。
什么是 DevOps 以及为什么常与微服务相关联？
DevOps 可以解释为以工具为中心的意识形态。从本质上讲，工具/技术用于简化需要由开发人员完成的工作。除了改进工具之外，运营和开发团队之间的合作有助于推动项目更加快速高效地完成。
例如，假设您正在构建一个允许用户检查帐户余额的应用程序。在过去，应用开发周期通常让开发人员构建应用程序，然后将其移交给运营团队，无需对最终结果负责；运营团队的任务是使其运作。在一个更具凝聚力的 DevOps 环境中，双方协同工作。开发人员将从头到尾拥有应用程序的生命周期，例如，在发布期间随时待命。两个团队之间必须保持一致的沟通，以确保一切顺利并获得 DevOps 的好处（加快上市速度、简化开发周期、便于问责等）。
新的 DevOps 工作流模型带来了重大的文化转变。仅使用新工具并不能使 DevOps 计划成功。如果有什么新工具可能会阻碍成功，如果它们使您毫无疑问地相信一切都会适当地实施。
由于微服务的性质，部署通常必须具备强大的 DevOps 流程。更多使用工具和较强的共享实践缓解了团队疲于应对小型移动零件的压力。在继续获得好处的同时，您可以降低这种转变带来的干扰或负担。
未来：事件驱动的微服务、无服务器计算和常见问题解答
当人们第一次开始尝试微服务时，他们通常默认使用熟悉的技术，例如 RESTful API。REST 基于请求-响应类型的通信运行。这种同步方法的问题在于您必须等待响应；服务变得相互依赖。如果一个服务运行速度较慢或没有响应，这意味着调用它的服务会运行速度较慢或失败。这种耦合可能会导致失去微服务体系架构的一些好处，进而创建了更为相互依赖的结构，与面向服务的体系结构 (SOA) 风格相似。
如果您使用事件驱动模型设计服务，您可以确保应用程序的某些部分继续运作，而其他部分可能不用参与，而不是整个应用程序无法响应。以 Netflix 为例。有时，您可能会注意到 “继续观看” 按钮没有出现。这是因为特定的服务不可用。但是，这并不意味着 Netflix 的所有服务都停止。用户仍然可以浏览节目和观看预览，因此即便 Netflix 有一项服务可能无法使用，其他服务仍可用。
完全采用微服务方法的开发人员意识到，通过松散耦合和事件驱动架构可实现真正的可扩展性。服务可以是异步的，可以执行操作、广播消息以及继续使用其主要功能，无需等待其他服务的响应。