如今,微服务可谓是风靡一时。Forrester发布的一项研究发现,76%的企业正以微服务架构为指导进行应用程序重构。
但需要强调的是,微服务绝不是什么万灵丹药。在一项面向生产环境内微服务应用的研究中,我们看到59%的受访者表示每种微服务都会给数据管理等运营事务带来新的挑战。更令人担忧的是,这份报告还提到在对不同环境内的故障排查难度进行比较时,73%的受访者表示微服务环境难度更大,只有21%的受访者认为单体式架构难度较大。
但为什么会出现这样的状况?根据BCG Digital Ventures公司工程技术培训副总裁Matthew Sinclair的解释,这是因为技术专家们总是想用最现代的技术解决问题,即使他们对很多新兴技术还没有足够的经验。“但作为工程师,我很理解其中的选择思路。这么做不是因为更安全,而是因为能让从业者学到更多新东西。”他说。
客户们在听说微服务这项新技术的消息之后,总觉得应该用新方法解决自身的整体问题。于是,他们热衷于向软件工程师介绍微服务架构,调动起工程师们的积极性,之后就是在软件工程项目中迅速添加大量微服务元素。
但问题在于,整个开发流程不可能一夜之间完成由单体式架构到微服务架构的转换。换言之,企业在微服务迁移方面往往操之过急——一听说其中的优点、了解到部分收益,就想把它全面推向各个角落。正因为如此,一些企业开始不可避免地陷入微服务误区。
那么,我们该如何避免这种误区?
我们必须意识到,微服务架构代表的是一种分布式系统,因此不妨以部分员工已经具备经验的分布式思维进行设计。此外,千万别忘了这样一条黄金准则:如非必要,勿增实体。
换句话说,大家必须明确自己为什么要构建某种事物、想要借此达成怎样的目的。这是个最基本的问题,适用于任何规模的企业。打算解决什么问题、解决之后能够给用户带来怎样的收益,才是决定是否使用某种技术的根本前提。
用户们其实也并不关心底层技术究竟是什么——他们不关心如何实现,只关心能不能解决问题。
如果唯一的实现方法就是微服务,那我们毫无疑问应该着手使用。但如果还有其他替代方法,请优先考虑这些替代方法。千万不要陷入“为了微服务而微服务”的怪圈。
总而言之,微服务是一种旨在降低复杂性的架构模式。而一旦使用,它又会在其它层面增加复杂水平。如果孤立使用微服务,那么某一维度中得以解决的复杂性,必然会在某种形式扩散到其他领域。因此,最重要的是使用多种其他工具将组织的整体复杂性控制在最低程度。
这又回到了之前的拷问:我们要解决什么问题?如果大多数企业完全可以通过传统且常规的技术搞定当前需求,那么无需选择微服务。不要看到Amazon和谷歌等科技巨头全面推行微服务,就跃跃欲试。请先问问自己,微服务对我们来说是不是正确的选择。
也有不少企业掌握着重要的旧代码库,而且与业务体系严密集成。同样的,微服务也许并不适合这种状况。因此,尽量只在云原生项目中使用微服务,同时继续沿用旧有技术处理传统IT领域的挑战。
一次又一次,我们总会回到最基本的考量:我们要用产品或技术解决什么问题?注意,不是如何解决,是解决什么。如果用户与你的产品进行交互,可以获得哪些收益?只有为这个问题找到明确的答案,大家才能判断微服务架构是否适合自己。
不过在多数情况下,各位得到的答案或许会是“可以,但没必要。”
好文章,需要你的鼓励
IBM Spyre加速器将于本月晚些时候正式推出,为z17大型机、LinuxONE 5和Power11系统等企业级硬件的AI能力提供显著提升。该加速器基于定制芯片的PCIe卡,配备32个独立加速器核心,专为处理AI工作负载需求而设计。系统最多可配置48张Spyre卡,支持多模型AI处理,包括生成式AI和大语言模型,主要应用于金融交易欺诈检测等关键业务场景。
加拿大女王大学研究团队首次对开源AI生态系统进行端到端许可证合规审计,发现35.5%的AI模型在集成到应用时存在许可证违规。他们开发的LicenseRec系统能自动检测冲突并修复86.4%的违规问题,揭示了AI供应链中系统性的"许可证漂移"现象及其法律风险。
意大利初创公司Ganiga开发了AI驱动的智能垃圾分拣机器人Hoooly,能自动识别并分类垃圾和可回收物。该公司产品包括机器人垃圾桶、智能盖子和废物追踪软件,旨在解决全球塑料回收率不足10%的问题。2024年公司收入50万美元,已向谷歌和多个机场销售超120台设备,计划融资300万美元并拓展美国市场。
这项由剑桥大学、清华大学和伊利诺伊大学合作的研究首次将扩散大语言模型引入语音识别领域,开发出Whisper-LLaDA系统。该系统具备双向理解能力,能够同时考虑语音的前后文信息,在LibriSpeech数据集上实现了12.3%的错误率相对改进,同时在大多数配置下提供了更快的推理速度,为语音识别技术开辟了新的发展方向。