如今,微服务可谓是风靡一时。Forrester发布的一项研究发现,76%的企业正以微服务架构为指导进行应用程序重构。
但需要强调的是,微服务绝不是什么万灵丹药。在一项面向生产环境内微服务应用的研究中,我们看到59%的受访者表示每种微服务都会给数据管理等运营事务带来新的挑战。更令人担忧的是,这份报告还提到在对不同环境内的故障排查难度进行比较时,73%的受访者表示微服务环境难度更大,只有21%的受访者认为单体式架构难度较大。
但为什么会出现这样的状况?根据BCG Digital Ventures公司工程技术培训副总裁Matthew Sinclair的解释,这是因为技术专家们总是想用最现代的技术解决问题,即使他们对很多新兴技术还没有足够的经验。“但作为工程师,我很理解其中的选择思路。这么做不是因为更安全,而是因为能让从业者学到更多新东西。”他说。
客户们在听说微服务这项新技术的消息之后,总觉得应该用新方法解决自身的整体问题。于是,他们热衷于向软件工程师介绍微服务架构,调动起工程师们的积极性,之后就是在软件工程项目中迅速添加大量微服务元素。
但问题在于,整个开发流程不可能一夜之间完成由单体式架构到微服务架构的转换。换言之,企业在微服务迁移方面往往操之过急——一听说其中的优点、了解到部分收益,就想把它全面推向各个角落。正因为如此,一些企业开始不可避免地陷入微服务误区。
那么,我们该如何避免这种误区?
我们必须意识到,微服务架构代表的是一种分布式系统,因此不妨以部分员工已经具备经验的分布式思维进行设计。此外,千万别忘了这样一条黄金准则:如非必要,勿增实体。
换句话说,大家必须明确自己为什么要构建某种事物、想要借此达成怎样的目的。这是个最基本的问题,适用于任何规模的企业。打算解决什么问题、解决之后能够给用户带来怎样的收益,才是决定是否使用某种技术的根本前提。
用户们其实也并不关心底层技术究竟是什么——他们不关心如何实现,只关心能不能解决问题。
如果唯一的实现方法就是微服务,那我们毫无疑问应该着手使用。但如果还有其他替代方法,请优先考虑这些替代方法。千万不要陷入“为了微服务而微服务”的怪圈。
总而言之,微服务是一种旨在降低复杂性的架构模式。而一旦使用,它又会在其它层面增加复杂水平。如果孤立使用微服务,那么某一维度中得以解决的复杂性,必然会在某种形式扩散到其他领域。因此,最重要的是使用多种其他工具将组织的整体复杂性控制在最低程度。
这又回到了之前的拷问:我们要解决什么问题?如果大多数企业完全可以通过传统且常规的技术搞定当前需求,那么无需选择微服务。不要看到Amazon和谷歌等科技巨头全面推行微服务,就跃跃欲试。请先问问自己,微服务对我们来说是不是正确的选择。
也有不少企业掌握着重要的旧代码库,而且与业务体系严密集成。同样的,微服务也许并不适合这种状况。因此,尽量只在云原生项目中使用微服务,同时继续沿用旧有技术处理传统IT领域的挑战。
一次又一次,我们总会回到最基本的考量:我们要用产品或技术解决什么问题?注意,不是如何解决,是解决什么。如果用户与你的产品进行交互,可以获得哪些收益?只有为这个问题找到明确的答案,大家才能判断微服务架构是否适合自己。
不过在多数情况下,各位得到的答案或许会是“可以,但没必要。”
好文章,需要你的鼓励
本文评测了六款控制台平铺终端复用器工具。GNU Screen作为老牌工具功能强大但操作复杂,Tmux更现代化但学习曲线陡峭,Byobu为前两者提供友好界面,Zellij用Rust编写界面简洁易用,DVTM追求极简主义,Twin提供类似TurboVision的文本界面环境。每款工具都有各自特点和适用场景。
韩国汉阳大学联合高通AI研究院开发出InfiniPot-V框架,解决了移动设备处理长视频时的内存限制问题。该技术通过时间冗余消除和语义重要性保留两种策略,将存储需求压缩至原来的12%,同时保持高准确性,让手机和AR眼镜也能实时理解超长视频内容。
网络安全公司Snyk宣布收购瑞士人工智能安全研究公司Invariant Labs,收购金额未公开。Invariant Labs从苏黎世联邦理工学院分拆成立,专注于帮助开发者构建安全可靠的AI代理工具和框架。该公司提供Explorer运行时观察仪表板、Gateway轻量级代理、Guardrails策略引擎等产品,并在工具中毒和模型上下文协议漏洞等新兴AI威胁防护方面处于领先地位。此次收购将推进Snyk保护下一代AI原生应用的使命。
纽约大学研究团队通过INT-ACT测试套件全面评估了当前先进的视觉-语言-动作机器人模型,发现了一个普遍存在的"意图-行动差距"问题:机器人能够正确理解任务和识别物体,但在实际动作执行时频频失败。研究还揭示了端到端训练会损害原有语言理解能力,以及多模态挑战下的推理脆弱性,为未来机器人技术发展提供了重要指导。