点击查看目录
本文为翻译文章，点击查看原文。
Aspen Mesh 的 Andrew Jenkins 说，转向微服务本身并不能消除复杂性。
在本文中，我们与 Aspen Mesh 的首席架构师 Andrew Jenkins 谈论了如何从单一应用程序转向微服务，并通过一些关于服务网格的宣传来管理微服务架构。有关服务网格的更多信息，请考虑参加于 2018 年 5 月 2 日至 4 日在丹麦哥本哈根举行的KubeCon + CloudNativeCon EU。
1.微服务解决了许多公司面临的单体架构问题。你认为其最大的价值在哪里？
Andrew Jenkins ：对我来说，这是关于最小化时间对用户的影响。向虚拟化和云转型的关键是降低与支持应用程序的所有基础架构相关的复杂性，以便您可以灵活地分配服务器和存储等。但是这种转变并不一定会改变我们构建的应用程序。现在我们有了灵活的基础架构，我们应该构建灵活的应用程序以充分利用它。
微服务是灵活的应用程序——构建小型，单一用途的模块并快速构建它们，以便您可以快速将它们交付给最终用户。组织可以使用它来根据实际用户需求进行测试并迭代构建。
2.随着企业从单体应用程序向微服务迁移，收益显而易见，但公司在采取行动时遇到的一些挑战是什么？
Jenkins ：转向微服务本身并不能消除复杂性。任何一个微服务的复杂性都很小，但是整个系统都很复杂。从根本上说，公司希望知道哪个服务正在与哪个服务对话，代表哪个服务对象，然后能够使用策略来控制该通信。
3.组织如何尝试应对这些挑战？
Jenkins ：一些公司从第一天起就将这种可见性和策略部分添加到他们构建的每个应用程序中。当公司投资于定制工具、工作流程、部署管理和 CD 管道时，这种情况尤其常见。我们也发现这些公司通常是以几种语言为导向，并且几乎写出他们自己运行的所有内容。
如果您的应用程序堆栈是多边形的，并且是新开发和迁移现有应用程序的组合，则很难证明将这些部分单独添加到每个应用程序是合理的。来自不同团队和外部开发的应用程序的应用程序更多地提高了这一点，一种方法是分别对待那些不符合要求的应用程序 - 将它们置于策略执行代理之后，或者从可见性角度将它们视为更多的黑盒子。但是，如果你不必做出这种分离，那么如果有一种简单的方法来获得任何语言的任何应用程序的原生式策略和可见性，那么你可以看到它的优势。服务网格就是这样的一种方法。
4.作为管理微服务架构的最终解决方案，围绕服务网格存在大量宣传。你的想法？
Jenkins ：是的，这绝对是攀登炒作循环曲线。它不会适合所有情况。如果你已经有微服务，并且你觉得你有很好的控制能力和可视性，那么你已经有了一个很好的开发人员工作流程，那么你就不需要把所有东西都撕掉，并且明天在服务网格中填充。我建议你可能仍然想知道里面的内容，因为当你的团队处理新的语言或环境时它可能会有帮助。
我认为我们应该了解服务网格如何将功能集成到一个一致的层中。我们都喜欢保持我们的代码干爽（不要重复自己）。我们知道两个相似的实现永远不会完全相同。如果您可以利用服务网格来获得一个可以在整个基础架构中运行的重试逻辑的实现，那么真正简化了开发人员，操作人员以及与该系统一起工作的每个人的操作。我敢打赌，你的团队中没有人想再写一个重试循环的副本，特别是没有人想调试用 go 编写的文件和用 python 编写的文件之间的细微差别。
5.随着要监控的服务数量的增加，这些服务中的每一个很可能：
- 使用不同的技术/语言
- 住在不同的机器/容器上
- 拥有自己的版本控制
服务如何解决这些差距？
Jenkins ：Service mesh 的第一个承诺是为任何语言编写的微服务（对于任何应用程序堆栈）执行相同的操作（即可见性和控制部分）。接下来，当您考虑不同的容器互相交谈时，服务网格可能会帮助与该层相关的许多内容。例如，你是否相信保护每个单独运行的容器而不是外围（防火墙）安全？然后使用服务网格提供从容器到容器的 mTLS。
我还看到，版本控制差异是更深的应用程序生命周期差异的表现。所以这个团队使用这样的版本控制，广泛的资格认证阶段和谨慎的升级策略，因为他们提供了每个人都依赖的最核心的服务之一。另一个从事全新原型服务的团队有一个不同的政策，但您肯定希望确保他们不写入生产数据库。将他们的“方形挂钩工作流程”装入你的“圆孔工艺”并不是正确的。
您可以使用服务网格以适合他们的方式将这些不同的应用程序和服务移植到系统中。现在显然你想要使用一些判断，而不是为每一个小的微服务定制固定，但我们听到很多关于服务网格的兴趣，以帮助消除这些生命周期和期望之间的差异。再次，它的全部是提供快速迭代，但不放弃可见性和控制。
6.控制平面与数据平面：服务网格为每个平面提供值？
Jenkins ：今天开始制作网络服务是多么容易。您可以将代码放入推文中。虽然这不是真正的 Web 服务。为了使其具有弹性和可扩展性，您需要在应用程序的数据平面添加一些内容。它需要做 TLS，它需要重试失败，它只需要接受来自这个服务的请求，但不是那个，并且它需要检查用户的认证，等等。服务网格可以帮助您获得数据平面功能，而无需向应用添加代码。
而且，由于现在已经在数据平面层中，因此可以在不修改应用程序的情况下升级和增强该层。
服务网格为您的微服务带来了控制平面的一致性。像 Kubernetes 这样的容器编排系统提供了描述你想要运行哪些容器的常用方法。这并不是说你不能在没有它们的情况下运行容器，那是因为一旦你运行了一些容器，你就需要一个一致的方式来运行它们。服务网格就是这样，用于容器之间的通信。
7.服务网格的流行语是“可观察性”。你能分享一下真实世界中的可观察性提供的好处吗？
Jenkins ：我们曾与一个团队谈过，他们告诉我们他们花了几个小时的时间在电话上试图解决一些跨越很多服务和组件的问题。他们从每项服务中收集了大量数据，他们知道答案是在某处的大量数据中。但是他们花了很多时间在信息的每个快照之间进行翻译。他们不相信翻译中的每一步都是正确的 - 毕竟，如果他们明白发生了什么事情，他们首先会设计出这个问题。最重要的是，哪里开始寻找并不总是很清楚。
他们要求的是一种观点 - 一个地方收集的所有服务信息，以及他们问题最重要的信息。同样，服务网格不是万能的，我不会保证你永远不必再看日志文件。但我的目标是，一旦这个团队拥有一个服务网格，他们总是有信心，他们已经对每一个微服务进出的内容有了很好的观察，并且服务网格已经指出他们正确的方向。
对我而言，可观察性不仅仅是收集大量数据点。这是为了尽快将智能大脑应用于系统中的真实故障。
8.您对服务网格的未来有什么看法？
Jenkins ：我认为各种实现都提供了一个引人注目的策略和组件工具箱。我很高兴我们正在利用从微服务的先驱获得的经验教训来构建这个通用服务网格层。
下一步将选择如何使用该工具箱来解决问题。组织希望在部署策略方面保持一定的一致性：面临的挑战是将应用开发者，信息安全平台和平台团队的利益结合起来，以便他们的所有策略都融合在服务网格中。
在技术细微差别上，我们已经看到了服务网格，它们利用所谓的 Sidecar 模型来集成和服务没有的网格。Sidecar 对于应用增强层感觉很自然，但我们并不习惯于那些我们认为是基础设施的层。
一旦我们从第一天开始依赖服务网格来编写应用程序，我们就有机会对应用程序进行细粒度但高级别的控制。每一个应用程序都将具有先进的重试逻辑、安全性、可见性等，从第一天开始。首先，这将改变我们开发和测试应用程序的方式。我认为这也将为我们还没有想到的跨应用策略敞开大门。