专栏名称: 聊聊架构
在这里煮酒聊架构。
目录
相关文章推荐
字节跳动技术团队  ·  ByteBrain团队EuroSys25 ... ·  昨天  
InfoQ Pro  ·  充电计划 | 反卷“大”模型 ·  昨天  
字节跳动技术团队  ·  基于LLM的AI应急:多模态信息智能化分析整 ... ·  2 天前  
51好读  ›  专栏  ›  聊聊架构

Google、IBM和Lyft开源其大型微服务系统管理工具Istio

聊聊架构  · 公众号  · 架构  · 2017-05-25 11:53

正文

请到「今天看啥」查看全文


编写具备高可靠性、松散耦合的微服务式生产级应用程序往往存在一定程度的挑战。随着整体式应用程序被拆分为微服务,软件团队必须面临并应对在分布式系统当中实现服务集成所带来的诸多难题:其必须考虑服务发现、负载均衡、容错性、端到端监控、面向功能实验的动态路由以及最为重要的两大前提——合规性与安全性。

目前行业中处理上述挑战的方法多种多样,往往由各类库、脚本乃至 Stack Overflow 片段拼凑而成,这直接导致其包含大量不同编程语言与运行时,功能可观察性差且往往会令最终安全性受到负面影响。

其中一类解决方案在于立足常规 RPC 库(例如 rRPC)实施标准化调整,但其全面采用会给企业带来高昂成本,同时亦会迫使其放弃部分根本无法变更的旧有应用程序。很明显,运营人员需要一套灵活的工具包,确保其微服务始终具备安全性、兼容性、可追踪性以及高可用性 ; 与此同时,开发人员则需要能够在生产环境中尝试不同功能或者部署金丝雀版本(canary releases),并保证其不会影响到整体系统。

解决方案:服务网格

想象一下,如果我们能够以透明化方式在服务与网络之间插入一个基础设施层,借此为运营人员提供必要的控制能力,同时帮助开发人员不必在其代码当中引入分布式系统带来的专用解决方案,那么前面提到的诸多挑战将迎刃而解。正如微服务架构能够帮助各功能团队实现彼此解耦,服务网格则能够帮助运营人员从应用程序功能开发与发布流程当中解耦出来。Istio 项目即因此而生,它能够以系统化方式将代理机制接入至网络路径当中,从而将不同微服务转化为综合性服务网格。







请到「今天看啥」查看全文