Service Mesh所应对的8项挑战

Lori Macvittie

微服务架构是把双刃剑，我们享受它带来的开发速度（development velocity），却也不得不面对服务间通讯带来的复杂性问题。

目前大多数扩展容器化微服务的架构多是基于proxy-based复杂均衡器实现的。在这些架构的问题在于，容器环境内部伸缩往往依赖于IP tables，并受制于传统网络层。

所有这些代理提供相同的核心功能：扩展容器环境中的分布式服务。这些服务是一种短暂的构建（ephemeral constructs），实际上并不存在——除了在定义它们的资源（配置）文件中。基于IP tables的扩展解决方案的问题是，这些服务是7层(HTTP)构造，通常充当单个API调用的“后端”，而非整个应用程序。

正如我们所知道的，从客户端显示为单个、整体构造的应用，实际上由许多不同的(和分布式的)微服务组成。有些服务是纯内部的，供其他服务使用，这意味着要在容器环境中进行大量的service-to-service通信。

在这些环境中，一切都是HTTP/HTTP2之上的api，因此我们需要L7(HTTP)路由。我们还需要一致的安全、身份验证和策略执行。所有这些都是基于IP tables的方法无法实现的。

针对种种微服务架构服务间通讯的问题和难点，目前出现的一些Service Mesh相关开源项目已经开始着手解决这些挑战，核心集中于以下8个方面：

• 构建 - 除了将策略与CI/CD工具链集成并确保配置的声明性模型，以便将service mesh视为一层基础设施之外，构建并不是Service Mesh的“强项”
• 测试和集成 – Service Mesh可以帮助确保开发、测试、生产之间一致的策略。分阶段部署这种方法在过去运作良好，但它是将延迟插入部署过程的障碍之一。企业正在寻找一种将服务直接部署到生产的方法，并采用流量控制和回滚机制来处理故障。
• 版本控制 - 服务网格可以作为基本API网关，根据API版本等变量路由流量，甚至可以翻译版本，以便在API版本过渡期间提供帮助。客户端升级并不总是强制的，这意味着会存在多个版本。Service Mesh可以将对旧API版本的请求转换为最新版本，以帮助降低维护同一API的多个版本的成本和负担。
• 部署 - 得益于HTTP能力，Service Mesh是实现蓝/绿部署，金丝雀测试和流量控制的好方法。
• 日志记录 - 分布式日志记录始终是一个问题，而且在实例生存时变化很大的环境中，它会更加麻烦。Service Mesh提供了一个通用的集中位置来实现日志记录以及执行请求跟踪等功能的能力。
• 监控 - 监控是应用扩展的核心之一。虽然应用可以通过实现某些功能（重试、断路等）来处理服务不可避免的故障，但会给应用带来不必要的负担。Service Mesh承担了service-to-service通信的负担，并提供监控，其目标是在生产中专注于MTTD和MTTR，因为在生产中运行很困难，故障是不可避免的。
• 调试 - 系统越复杂，调试就越困难。Service Mesh可以帮助进行根本原因分析，使用分析和遥测提供统计数据和故障前通知，并隔离容器（而不是杀死容器），以便对其进行彻底检查。这在由于内存泄漏缓慢导致故障的情况下特别有用。
• 网络 - 网络仍然是容器的关键，可能比在不太复杂的环境中更为重要。从该网络中抽象服务的愿望意味着您不希望在每个服务中实现许多移动部件：服务发现、SSL和证书管理、断路器、重试、健康监控等。引入需要包含与网络相关的功能会增加微服务，并引入额外的架构和技术债务。服务网格承担了这些功能，并提供了所需的规模和安全性，而不影响开发。

Service mesh是一个令人兴奋的演变，它结合了云和容器的现代原则和坚实的规模基础。随着2018年以来容器技术的普以及对企业级应用扩展和支持的需求，Service Mesh的未来值得期待。