服务器之家:专注于服务器技术及软件下载分享
分类导航

PHP教程|ASP.NET教程|Java教程|ASP教程|编程技术|正则表达式|C/C++|IOS|C#|Swift|Android|VB|R语言|JavaScript|易语言|vb.net|

服务器之家 - 编程语言 - 编程技术 - Service Mesh 实践之避坑指南

Service Mesh 实践之避坑指南

2021-02-22 22:29至顶网 编程技术

Service Mesh在实践层面往往难于管理、过分复杂。为了避免掉坑,我们必须采取一系列步骤简化这个过程。

Service Mesh已经成为微服务领域的热门议题,同时也被广泛视为云原生应用程序的指导性架构。Service Mesh环境在理论上能够增强微服务通信的流量管理与安全水平,提供关于应用程序运行状态的全面情况,但在实践层面却往往难于管理、过分复杂。为了避免掉坑,我们必须采取一系列步骤简化这个过程。

Service Mesh 实践之避坑指南

确定重要事项、规划探索旅程

在踏上Service Mesh旅程之前,我们首先需要确定最重要的事项,并由此规划探索道路。

对多数企业而言,在微服务之间建立零信任通信已经成为一种当务之急,但不同组织的需求往往不尽相同。也许您希望Service Mesh提供高级流量管理功能,也许希望通过边车代理强化可观察性。

无论您有哪些需求,都必须首先确定优先级,并在起步之前获得开发人员、SRE工程师与安全运营(SecOps)团队的理解与支持,集中精力完成工作。请注意,不要指望整个流程能够一蹴而就,否则Service Mesh的实现之路必然陷入困境。

一旦确定了正确的目标优先次序,我们即可为Service Mesh旅程建立一份路线图。作为前进的指引,这份路线图应该列出实施举措的具体次序,并确定各个步骤该如何与IT及业务目标保持一致。例如,您可以对希望增强的可观察性方向做出排序,用以加快问题解决速度,并改善应用程序的正常运行时间,借此超越预定的流量管理目标。通过这种排名,您可以专注于解决Service Mesh应当实现的目标、获取与之对应的回报。

明智选择Service Mesh解决方案

目前市面上存在多种Service Mesh控制平面,不同解决方案之间总有优劣差异。在选择Service Mesh时,请首先保证其能够支持您的运行环境。如果您已经部署有Mesos等系统、内部专有/遗留架构或者特定公有云平台,请确保选择的Service Mesh能够与之兼容。

其次,确定部署哪一种Service Mesh控制平面。虽然各类Service Mesh控制平面都提供相似的基础功能,但不同方案在功能与成熟度方面总有区别。要确定Service Mesh的控制平面是否适合您的用例,并研究如何设计整个技术堆栈。在这些方面,Istio整体表现更好。例如,Istio在服务双向TLS方面占据领先地位,而其他Service Mesh的微服务零信任实现能力仍然有待提高。

第三,评估您的现有技能与资源能够从容管理多少复杂性因素。在添加功能时,随着Service Mesh规模与集群数量的增长,整个体系会变得越来越复杂。请注意,我们往往会低估发展过程中的复杂度水平,实际上我们很难预测未来会发生什么,因此必须设定极限并留有缓冲。

在选择Service Mesh时,请关注几项“必要因素”:可观察性、安全性与流量管理、组织内已经具备的技能、选择最佳Service Mesh架构等等。另外请询问自己,您是否真的需要为每个pod提供边车代理,或者是否需要满足Citrix® Service Mesh lite等替代或变种架构的需求。

为意外与复杂性制定规划

无论如何严密制定计划,您在实现Service Mesh时总会遇到意外。但这并不是说计划无用——计划得越是完善,您在应对意外时才会更从容。

代理并不是那么透明

有时候,代理的透明度可能相当差。一般来说,当微服务尝试调用某些并不存在、或者暂时负载压力较大的资源时,就会引发超时。但代理的存在会扭曲应用超时,导致每项微服务都误以为其请求已经被即时接收。为此,我们必须认真调整应用程序中的超时机制。

另外,代理对于HTTP流量同样不够透明。很多代理会将HTTP标头转换为小写形式以保持合规性、一致性并降低资源消耗。实际上,HTTP/2规范要求标头必须小写。如果您的应用程序仍然通过大小写来区分HTTP标头,那么代理的介入很可能破坏其基本功能。请确保代理通信造成的细微差别不致破坏您的应用程序,同时着手调整代理或应用程序本体以匹配生态系统的实际特性。

早测试、勤测试

我们无法预测未来,也不可能预见哪些组件会出问题。Service Mesh是一种复杂的分布式系统,包含大量活动部件,其中每个部件都有可能发生故障。如果应用程序出现问题,我们面对的就是应用程序本体、连带工具乃至其他故障源。为此,大家务必要逐步实施、持续监控并保证频繁测试。

为此,您需要建立起完备的可观察性堆栈,具体涵盖日志记录、指标、分布式跟踪与服务图。分布式跟踪与服务图又是服务可观察性中的关键要素。分布式跟踪能够监控流经微服务架构的请求流,通过各个微服务跃点建立起延迟映射,借此帮助您快速解决延迟问题。服务图则是各微服务之间依赖关系以及运行状态的动态图形表达,能够以简便方式实现环境可视化并帮助您发现一切问题。

另外需要注意的是,请务必坚持部署持续测试,引导项目始终处于正轨之上。大家不妨考虑建立一项端到端24/7全天候测试服务,用于持续测试您的微服务体系。

为大量修订工作做好准备

今天的小作坊,明天可能发展成大企业,我们必须提前做好准备。您可能需要调整默认的CPU与内存分配机制,尽可能降低资源消耗。同样的,一旦开始部署Service Mesh,修订需求就将如潮水般涌来。如果没有完善的计划,持续运作的应用程序将很快升级出无数个边车代理,万万不可打无把握之仗。

智慧是汲取自错误的教训,但真正的智慧应该是从他人的错误中吸取教训。Service Mesh在安全性、高级流量管理乃至可观察性方面做出了坚实的承诺,但具体实现却往往复杂万分。请认真规划、做好准备,尽可能走出自己的一条顺畅、甚至充满成就感的探索道路。

延伸 · 阅读

精彩推荐