这篇文章主要讲解了“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在安全性、高级流量管理乃至可观察性方面做出了坚实的承诺，但具体实现却往往复杂万分。请认真规划、做好准备，尽可能走出自己的一条顺畅、甚至充满成就感的探索道路。
感谢各位的阅读，以上就是“Service Mesh实践之如何避坑”的内容了，经过本文的学习后，相信大家对Service Mesh实践之如何避坑这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是编程网，小编将为大家推送更多相关知识点的文章，欢迎关注！
