服务网格架构激活了容器网络管理—来自于服务网格创建者们的见解与展望
本文将是您了解和评估何时以及如何采纳服务网格的最佳参考资料。本文回顾了服务网格的历史,并采访了创造Service Mesh一词的Buoyant创始人,Istio的产品经理,Enovy的架构师Matt Klein,分别就谁应该何时以何种方式采纳服务网格给出了意见并展望了服务网格的未来。
本文将是您了解和评估何时以及如何采纳服务网格的最佳参考资料。本文回顾了服务网格的历史,并采访了创造Service Mesh一词的Buoyant创始人,Istio的产品经理,Enovy的架构师Matt Klein,分别就谁应该何时以何种方式采纳服务网格给出了意见并展望了服务网格的未来。
这是介绍服务网格的架构系列的第二篇文章,本文讲解了Service Mesh术语的含义,为什么说节点代理和Sidecar模型是微服务的新模式和未来。
本文是谐云科技CTO丁轶群博士对Istio 0.8版本代码中的pilot-discovery的深度源码解析。
本文是谐云科技CTO丁轶群博士对Istio 0.8版本代码中的pilot-agent的深度源码解析。
2018年7月6日,Linkerd博客再次更新,宣布Conduit 0.5发布:在翻炒了无数次Prometheus支持的冷饭之后,终于发布了新的功能——TLS支持。紧接着一个更加重磅的消息:0.5将是Conduit最后一个版本,未来将作为Linkerd 2.0的基础继续存在——Conduit 的 Github 项目将会转移为Linkerd2。
在本速率限制系列的第一篇文章中,介绍了实施速率限制的动机,并讨论了几种实施方案(取决于你是否同时作为通信的发送端和接收端)以及相关的权衡。本文会更加深入地探讨 API 网关速率限制的需求。
借助 eBPF,作为 Service Mesh 的数据转发层,对接 Pilot、Mixer 等控制面,实现策略、流量和安全管理,是不是一种更高效的方式?这会比 Envoy 拥有更好的性能,虽然性能未必是 Mesh 首要考虑的问题,本文中讲述使用 Cilium 的尝试。
在计算领域,速率限制通常用于控制服务发起或消耗的操作速率,或者是请求发送或接收的流量。如果你有一年以上的软件开发经验,那么你应该会遇到这个概念。但是,和很多软件架构所面临的挑战一样,比起实际出现的问题,需要思考的问题会更多。本文概述了现代分布式应用程序中的一些关于速率限制的实现方案、优势和挑战。
本文是InfoQ对Serivce Mesh业界领袖Matt Klein、Dan Berg、Priyanka Sharma、Lachlan Evenson、Varun Talwar、Oliver Gould的采访,几位大咖分别就Service Mesh的定义及其在微服务交互和治理方面带来的优势、服务网格与ESB的区别,谁应该关心服务网格,服务网格的运行方式、sidecar以及学习曲线展开了讨论。
Copyright ©️ 2018, ServiceMesher all rights reserved.
模板来自 Bootstrapious. 移植到 Hugo 来自 DevCows