servicemesh

本期主题 Rainbond与Service Mesh微服务架构 时间 2018年04月19日 本周四 晚8:00 直播大纲 浅谈微服务架构 api-gateway快速搭建微服务框架 Service Mesh加速传统应用服务化改造 通过Rainbond落地多种模式微服务 观看方式 提前五分钟加入ZOOM语音直播间 房间号 948-095-8255 直接进入 或 下载ZOOM 进入上述房间 Rainbond技术社群 微信扫描下方二维码，添加「入群接头人」并确认邀请入群 关于Rainbond Rainbond 是一款以应用为中心的开源PaaS，深度整合基于Kubernetes的容器管理、Service Mesh微服务架构最佳实践、多类型CI/CD应用构建与交付、多数据中心资源管理等技术，为用户提供云原生应用全生命周期解决方案，构建应用与基础设施、应用与应用、基础设施与基础设施之间互联互通的生态体系，满足支撑业务高速发展所需的敏捷开发、高效运维和精益管理需求。 来源： oschina 链接： https://my.oschina.net/u/584116/blog/1796784

Service Mesh（服务网格）会是今年微服务生态的主角吗？从趋势来看，众多企业正在将这项理微服务复杂性的技术/工具，搬进他们的IT“火药库”之中。 什么是Service Mesh？ 根据Linkerd CEO William Morgan定义，Service Mesh是用于处理服务间通信的基础设施层，用于在云原生应用复杂的服务拓扑中实现可靠的请求传递。在实践中，Service Mesh通常是一组与应用一起部署，但对应用透明的轻量级网络代理。 Service Mesh与传统基础设施层不同之处在于，它形成了一个分布式的互连代理网络，以sidecar形式部署在服务两侧，服务对于代理无感知，且服务间所有通信都由代理进行路由。 为什么需要Service Mesh？ “Smart endpoint and dumb pipes”是微服务架构在集成服务时采用的一个核心理念，这一理念改变了过去臃肿集中的ESB（企业服务总线），无疑是正确方向上的一大进步，但同时也给我们出了一些难题——多智能才不会过于智能，而服务轻重大小的程度如何拿捏？我们应该如何处理微服务系统中服务间交互的复杂性？放在服务内部还是外部？如果是内部，如何处理业务逻辑关系，或者应该与基础设施更为相关？如果是外部，如何避免重蹈ESB的覆辙？ 皮的不谈，先来看看处理服务间通信时需要关注的点： 服务发现 负载均衡 路由 流量控制