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在安全性、高级流量管理乃至可观察性方面做出了坚实的承诺,但具体实现却往往复杂万分。请认真规划、做好准备,尽可能走出自己的一条顺畅、甚至充满成就感的探索道路。
好文章,需要你的鼓励
尽管全球企业AI投资在2024年达到2523亿美元,但MIT研究显示95%的企业仍未从生成式AI投资中获得回报。专家预测2026年将成为转折点,企业将从试点阶段转向实际部署。关键在于CEO精准识别高影响领域,推进AI代理技术应用,并加强员工AI能力培训。Forrester预测30%大型企业将实施强制AI培训,而Gartner预计到2028年15%日常工作决策将由AI自主完成。
这项由北京大学等机构联合完成的研究,开发了名为GraphLocator的智能软件问题诊断系统,通过构建代码依赖图和因果问题图,能够像医生诊断疾病一样精确定位软件问题的根源。在三个大型数据集的测试中,该系统比现有方法平均提高了19.49%的召回率和11.89%的精确率,特别在处理复杂的跨模块问题时表现优异,为软件维护效率的提升开辟了新路径。
2026年软件行业将迎来定价模式的根本性变革,从传统按席位收费转向基于结果的付费模式。AI正在重塑整个软件经济学,企业IT预算的12-15%已投入AI领域。这一转变要求建立明确的成功衡量指标,如Zendesk以"自动化解决方案"为标准。未来将出现更精简的工程团队,80%的工程师需要为AI驱动的角色提升技能,同时需要重新设计软件开发和部署流程以适应AI优先的工作流程。
这项由德国达姆施塔特工业大学领导的国际研究团队首次发现,当前最先进的专家混合模型AI系统存在严重安全漏洞。通过开发GateBreaker攻击框架,研究人员证明仅需关闭约3%的特定神经元,就能让AI的攻击成功率从7.4%暴增至64.9%。该研究揭示了专家混合模型安全机制过度集中的根本缺陷,为AI安全领域敲响了警钟。