本文来自微信公众号“开源云中文社区”。
当人们谈论云原生应用程序开发时，微服务是一个热门话题——这是有充分理由的。
微服务架构是一种结构化的方式，用于在组织中部署一组自包含和独立的服务。与过去的一些应用程序开发方法相比，它们正在改变游戏规则，允许开发团队在云原生规模上独立工作。
让我们深入了解应用程序开发的历史、微服务的特点以及这对云原生可观察性的意义。
微服务架构与单体架构
了解微服务架构的最简单方法是将其与单体架构进行比较。
单体架构
正如前缀“mono”所暗示的那样，单体架构是一种将所有组件组合成一个可执行文件的软件。这种架构通常有三个优点：
——易于开发。许多开发工具支持创建单体应用程序。
——易于部署。将单个文件或目录部署到运行时。
——易于缩放。通过在某种负载均衡器后面运行多个副本，可以轻松地扩展应用程序。
微服务架构
微服务是关于小型、独立的服务。其优点是这些服务具有高度可维护性和可测试性，与其他服务松散耦合，可独立部署，并由小型、高效的开发团队开发。微服务架构的一些服务类型可能包括以下示例。
——客户端。客户端服务用于收集客户端请求，例如搜索、构建等请求。
——身份提供程序。在发送到API网关之前，来自客户端的请求由身份提供者处理，身份提供者是一种创建、验证和管理数字身份信息的服务。
——API网关。API（应用程序编程接口）是允许两个服务相互对话的中间系统。在微服务的情况下，API网关就像一个入口点：它接受来自客户端的请求，从后端收集完成这些请求所需的服务，并返回正确的响应。
——数据库。在微服务中，每个微服务通常都有自己的数据库，通过API服务进行更新。
——消息格式。服务以两种类型的方式进行通信：同步消息和异步消息。
同步消息用于客户端等待响应时。这种类型包括REST（表示状态传输）和HTTP协议。异步消息传递适用于客户端不等待服务立即响应的场景。此类消息传递的常见协议包括AMQP、STOMP和MQTT。
——静态内容。一旦微服务完成通信，任何静态内容都会被发送到基于云的存储系统，该存储系统可以直接将该内容传递给客户端。
——管理。在微服务结构中有一个管理元素可以帮助监控服务并识别故障，以保持一切顺利运行。
——服务发现。对于客户端和服务器端服务，服务发现是一种在特定网络上定位设备和服务的工具。
单体模型更为传统，当然也有一些优点，但微服务在云原生环境中越来越普遍。以下是两种模型之间最明显的区别。
微服务架构的好处
微服务在现代云原生企业中取得了巨大成功。企业从使用这种架构中受益有很多原因。
——灵活性：因为每个服务都是独立的，所以编程语言可以在所有微服务之间变化（尽管在一种现代编程语言上尽可能标准化是明智的）。
——更快的部署：对于大多数开发人员来说，微服务不仅更容易理解，而且部署速度也更快。将代码中的一件事更改为单体结构，它会影响所有方面。微服务是独立部署的，不会影响其他服务。
——可扩展性：如果你通过一个应用程序运行所有内容，那么随着应用程序的增长，很难管理大规模的服务。相反，微服务架构允许团队修改单个服务的功能，而不是重新部署整个系统。这甚至适用于应用程序中每个服务的规模。例如，如果一个支付服务比其他服务的需求量更大，则可以根据需要扩展该微服务。
——孤立故障：对于单体架构，一个服务中的故障可能会危及整个应用程序。微服务隔离每个组件，因此，如果一个服务失败或出现问题，其他应用程序仍然可以运行，尽管可能处于降级状态。
最后，微服务架构节省了团队的时间，为每个服务提供了更精细的修改，并可根据每个服务和接口的整体需求进行扩展。
挑战
微服务非常有用，但它们也有自己的挑战。
——增加了复杂性和依赖关系问题：微服务的设计有利于单个服务，但这也增加了用户数量、用户行为的多样性以及服务之间的交互。这使得从前端到后端跟踪单个流量变得更加困难，并可能导致服务之间的依赖关系问题。当微服务彼此如此独立时，管理兼容性以及不同现有版本和工作负载造成的其他影响并不总是容易的。
——测试：在整个应用程序中进行测试可能很困难，因为每个执行的服务路由都可能不同和不同。灵活性是微服务的一个重要元素，但在分布式部署中很难一致地观察到相同的多样性。
——管理通信系统：即使服务可以轻松地相互通信，开发人员也必须管理服务通信的架构。API在服务之间可靠有效的通信中起着至关重要的作用，这需要API网关。这些网关很有用，但它们可能会失败，导致依赖关系问题或通信瓶颈。
——可观察性：因为微服务是分布式的，所以监控和可观察性对于开发人员和可观察团队来说是一个挑战。重要的是考虑一个监控系统或平台来帮助监督、排除故障和观察整个微服务系统。
应该采用微服务架构吗？
有时，单体结构可能是一条路，但微服务架构的发展是有原因的。问问自己：
应用程序在什么环境中工作？
因为大多数云原生架构都是为微服务而设计的，所以如果你想获得云原生环境的全部好处，微服务是最佳选择。随着应用程序转向基于云的设置，应用程序开发倾向于微服务架构，并将继续这样做。
团队如何运作？
在微服务架构中，代码库通常可以由较小的团队管理。然而，开发团队还需要工具来识别、监控和执行不同组件的活动，包括它们是否以及如何相互交互。团队还需要确定哪些服务是可重用的，因此在构建新服务时不必从头开始。
应用程序有多灵活？
如果你必须不断修改应用程序或进行调整，微服务方法将是最好的，因为可以编辑单个服务，而不是整个单体系统。
有多少项服务，还会有更多吗？
如果你有很多服务或计划继续增长（在基于云的平台中，你应该期待增长），那么微服务架构也是理想的，因为单体应用软件不能很好地扩展。
带微服务的Chronosphere
微服务架构旨在使云原生环境中的应用软件开发更简单，而不是更困难。随着管理每一项服务所带来的挑战，团队拥有可观察性解决方案以适应其业务的增长更为关键。
Chronosphere专注于云原生世界的可观察性，因此团队在应用程序开发的每一个级别都有更好的控制、可靠的功能和灵活的可扩展性。使用可靠且灵活的平台监控微服务可以大大降低风险，有助于预测故障，并使开发团队能够了解其数据。
