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标头，那么代理的介入很可能破坏其基本功能。请确保代理通信造成的细微差别不致破坏您的应用程序，同时着手调整代理或应用程序本体以匹配生态系统的实际特性。

（编辑：唐山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!