微服务：更愉快还是更嘈杂？

微服务的部署规模在不断扩大。容器架构的采用和随后的微服务部署并不是按下一个简单的按钮就能完成的，这是一个持续演变的过程。这个演变过程发生在应用程序开发、架构、打包和基础设施的各个方面。软件的创建和交付方式在过去几年中发生了重大转变。

随着团队在这个持续演化的软件生命周期环境中不断地探索，他们所在组织的一些独特方面——他们个人的集体体验和特定的项目需求——正塑造着这个演化旅程，也就是说，并非每一条通向云原生的道路都是相同的。应用程序和团队将利用其中一种或一些甚至是全部方法开启走向云原生的道路。

在这里，我们将专注于微服务。并非所有尝试创建微服务的应用程序或团队（从头开始或拆解单体）都能够真正意识到微服务架构的好处。通常，由于应用程序设计要求具备前所未有的监控和管理水平，团队一般都未能取得显著成功。从建立能够支持分布式系统问题的环境和基础设施，到组织和培训团队、培养文化和制定运营实践，再到应用可观察性和基础设施即代码，以及融入现代 DevOps 监控工具，团队的第一次微服务体验可能是非常混乱的。然而，一旦形成了持续交付的稳定节奏，它们的好处（例如交付速度）却是其他企业架构应用程序所无法比拟的。

微服务可以帮助团队实现更快的交付和迭代。微服务为独立的服务开发团队带来语言和技术选择的民主化——团队一边迭代和持续交付软件（通常作为服务），一边快速地创建新功能。作为一种设计可扩展、可独立交付的服务的云原生方法，微服务让团队可以以最佳的方式确定服务需求的优先级。这种提供松散耦合功能的做法推动了敏捷性和迭代交付，并强制实现它们所暴露的 API 的“契约义务”。

来自各个方面的挑战

由于每个微服务都需要对外暴露 API，微服务行为的一致性和版本控制方案的一致性就成了部署微服务时需要面临的两大挑战。大量的微服务不仅加剧了在一致的环境中创建功能、注入 DevOps 文化和实践的挑战，还加剧了确保多个新服务具备互操作性的挑战。部署的微服务越多，这些挑战就越严峻。

在部署微服务时，更多的移动部件和额外的服务增加了监控的难度。想象一下：你有一个由五个服务组成的应用程序，每个服务又由大约 10 个容器组成。你对应用程序的物理拓扑及其服务间的逻辑交互的了解很快就会过时，因为它的组件会移动。与传统监控工具支持的静态虚拟机不同，微服务的监控工具需要支持临时构造和原生服务发现。如果你正在使用过时的监控工具，无异于在蒙着眼睛走钢丝。

微服务部署还可能带来额外的组织开销和复杂性。专注于一个服务而不是多个服务可以实现持续交付和敏捷，同时也允许开发人员和运营团队彼此独立工作。因此，团队之间必须保持持续的沟通和协作，才能确保快速迭代服务，而不是去否定 DevOps 文化。

考虑到所有这些因素，服务团队应该如何避免责任和工作的扩散，以确保跨微服务的成功交付和运营？

缓解挑战以获得收益

虽然服务网格不是什么银弹，但它却试图解决一个众所周知的分布式系统的核心挑战（即没有同质、可靠、不变的网络）。为了直接解决这些挑战，服务网格提供了一层新的云原生可见性、安全性和控制。

服务网格是一个新兴的领域，虽然它没有被纳入云原生应用程序，但为非容器化、非微服务工作负载提供了很多价值。这个额外的工具层为微服务提供了基于策略的网络，描述了网络在面对不断变化的条件和网络拓扑时的行为。

最后，服务网格提供了一种服务优先的网络，将应用程序开发人员从基础设施问题中解放出来，如果你愿意，还可以通过为服务管理提供可独立寻址的工具层（Layer 5）来扩展服务管理职责。服务网格创建了一个网络，让运营人员能够定义细粒度的流量控制，在不需要与开发人员交互的情况下影响应用程序的行为。通过声明性策略，运营人员可以重新控制流经其基础设施的服务请求。

服务网格提供分布式应用程序服务的可见性、弹性、流量和安全控制，并提供对请求数量、分布式跟踪和延迟的可观测性。通过在服务网格上部署微服务，DevOps 团队可以立即获得指标、日志和跟踪信息，而无需更改应用程序代码。服务网格有助于了解应用程序运行缓慢的原因，这个问题是服务所有者面临的最麻烦的问题之一，因为他们不知道是什么导致应用程序执行缓慢。

DevOps 团队可以从大多数服务网格提供的增强安全性中受益。服务网格可以帮助 DevOps 团队识别出不良参与者、标记并阻止用户发送大量的非法请求、控制经过身份验证但没有调用服务权限的人。

在实践时，你需要知道些什么

有很多服务网格部署模型可用在你的微服务架构中。你可以尝试遵循一些最佳实践：

衡量必要性：当服务网格变成一种必需品时，这是一种进步。环境越动态，服务越复杂，服务网格的价值就越大。团队通常先从单个节点的几个容器开始，当需要扩展到几个节点来获得弹性时，需要进行容器编排，然后进入服务网格部署阶段，因为随着部署的增长，他们最终将面临更加严峻的挑战。

了解你的应用场景：了解对服务网格的依赖程度，以及需要让服务网格做些什么，这是使用服务网格的第一步。先从小规模开始，并在进一步深入之前确保它能为你提供你想要的价值。你的基础设施类型和服务类型将有助于确定要使用哪种服务网格。

例如，某些网格更多地关注容器化环境，而其他网格则更适用于直接在虚拟机或裸机操作系统上运行的服务。你需要知道你的环境中适合部署哪种服务网格（有些服务网格比较简单，有些服务网格更容易部署），以及服务网格需要具备哪些功能。 Layer5.io 为此提供了一些有用的见解。

搞清楚你对网络和应用程序的期望是什么：你希望从连接微服务的网络中得到什么好处？你可能希望你的网络尽可能智能和弹性，让流量远离故障以提高集群的总体可靠性，避免不必要的开销，如高延迟路由或具有冷缓存的服务器。你可能希望你的网络能够确保服务之间的流量可以抵御来自外界的攻击。你可能希望你的网络能够通过突显意外的依赖关系和服务通信故障为你提供见解。你可能希望你的网络能够自行收集有关请求的服务级度量指标。

结论

成功部署微服务或采用容器架构并非一蹴而就的事情，大多数团队肩负维护现有基础设施和服务的重担。因此，你可能是循序渐进地转向云原生。微服务具有显著的优势，并且服务网格可能是解决问题的最佳工具。在实现或考虑使用服务网格时，首先要衡量必要性。在确定有必要使用服务网格之后，请在选择部署模型之前考虑你的应用场景。如果控制和管理得当，微服务架构会让你变得更加愉快。

英文原文： https://containerjournal.com/2018/12/05/microservices-the-more-the-merrier-or-meshy-er/