微服务精华问答 | 微服务如何测试？

戳蓝字“CSDN云计算”关注我们哦！

微服务(Microservice Architecture)是近几年流行的一种架构思想,关于它的概念很难一言以蔽之。今天，就让我们来看看关于微服务更加有深度的问题吧。

Q：微服务如何测试？

A：当涉及到测试时，微服务有一系列有趣的优点和缺点。一方面，测试代表定义明确功能的小型服务的单元测试可能比测试整个单一应用程序容易得多。另一方面，验证由许多微服务组成的整个应用程序的质量可能代表了大量的测试复杂性：不是运行单个命令来测试在一个进程中运行的代码，而是大量的集成相关组件先健康地运行，并在整个测试过程中保持运行。

这种新的微服务是否可以单独进行测试（使用单元测试或模拟依赖关系），还可以在更加实际的“集成”或“分段”环境中进行测试，在这种环境中，它将与生产中涉及的相同类型的服务相连接。测试是否包含性能验证和失败模式？所有的测试都会自动完成吗？还是人类必须参与运行并检查测试结果？以一种简单，快速和自动化的方式进行微服务测试将鼓励开发人员维护并防止“ 破窗 ”问题。

Q：微服务将如何配置？

A：一旦新的微服务投入生产，它的内部行为会受到什么影响?这包括基础结构的更改(例如，更改池中线程的最小数量)和一些应用程序级别的更改（例如，通过翻转功能标志来启用新功能）。对于所有这些变化，了解服务是否需要重新启动才能生效是至关重要的。

当然，如果可能的话，构建一个在其生命周期中完全不需要改变配置的服务将是最理想的方法。

Q：系统的其他部分如何消耗？

A：构建微服务没有多大意义，除非系统的其他组件使用它，因此理解它们如何使用微服务是至关重要的。

这些其他组件将同步或异步地与新的微服务交互吗?是否应该鼓励他们将响应缓存一段时间?什么是重试和幂等性？新微服务的正常运行时间SLA是否与系统中其他组件的正常运行时间SLA相匹配？

对于新微服务将提供的响应延迟，应该有明确的预期，使用微服务的组件应该知道这些预期。这样，当这些期望没有满足时，系统的其他部分可以决定触发超时、触发断路器或故障转移到服务的另一个实例。

Q：如何保证微服务的安全性？

A：除非是在高安全性环境中，否则大多数部署在防火墙后的微服务都不需要过分关注服务间安全性。在微服务之间添加大量的安全检查可以增加显著的操作复杂性，使生产问题很难调试和修复。由于维护、部署和保护一些正确签名的证书所需要的工作，甚至使用HTTP上的HTTPS进行服务间通信也可能是一个重要的维护开销。通常，更好的方法是允许流量在微服务之间畅通无阻，同时仍然应用合理的应用程序级别的身份验证和授权级别，当然还要保持非常安全的边界。

因此，系统中的其他组件很可能能够向微服务发送请求而不出问题，但它们可能仍然需要传递一些身份验证数据，这些数据表示发起外部用户，以便实际批准和处理请求。这绝不应该是明文密码数据，但它可以使用诸如JWT，OAuth，SAML或Auth0之类的技术。无论采用何种方法，该技术都必须非常清楚地记录下来，并且最好在客户端库或示例代码中捕获，以便其他开发人员可以轻松使用新的微服务。

Q：微服务将如何被发现？

A：当一个新的微服务启动时，系统中的其他组件如何找到它?发现过程越简单，它的灵活性就越低，之后会遇到更多的问题。例如，最简单的方法(同时也是一种脆弱的方法)是将微服务的地址硬编码到依赖它的其他组件的代码或配置中。这可能会一直工作到服务的地址必须更改，或者直到服务的多个实例在其他区域可用为止。这当然不是一种推荐的方法。

使用诸如DNS名称之类的间接技术来隐藏微服务的地址会更好一些，但是这也有它自己的缺点:找到一个合适的TTL值,迫使名字重做决议,使DNS缓存行为一致,等。通过设计,域名没有考虑服务的可用性,这可能导致应用程序组件遵循一条通往一个IP地址,没有监听,浪费时间,导致运行噪音,他们试图找到一个工作实例。它也会让开发人员感到非常困难，因为使用DNS作为路由机制通常会导致开发人员的/ etc / hosts文件的临时修改。

在复杂的领域，高度可用的数据存储或数据同步服务（例如ZooKeeper）可能被用作微服务的注册表，这些服务目前仍然运行良好。但仍需要更多的技术投资，并且还应该谨慎对待，以确保发现服务本身不会成为单点故障（SPOF）。当微服务启动时，它们将自己注册到这个注册服务中，当它们关闭时，它们将自己删除。如果它们意外终止或陷入死锁，也必须自动从注册表中删除它们。记住，发现不仅仅是发现正在运行的东西——发现什么是不可用的也是很重要的。

小伙伴们冲鸭，后台留言区等着你！

关于微服务，今天你学到了什么？还有哪些不懂的？除此还对哪些话题感兴趣？快来留言区打卡啦！留言方式：打开第XX天，答：……

同时欢迎大家搜集更多问题，投稿给我们！风里雨里留言区里等你~