使用 Docker 构建微服务架构,服务与服务之间的通信有什么最佳实践?

兔大叔提问于 2018-01-22 09:27
1 个回答
  • waiting2018-01-22 11:22

    介绍最新才出现的一个概念 - SERVICE MESH(服务网格) ,对于 Kubernetes 和 Cloud Native 的拥趸而言,它值得关注。



    这个概念是开发 Linkerd 的 Buoyant 公司率先使用,其定义是提供安全的、快速的、可靠地服务间通讯,对应用透明。潜台词就是所有应用流量的控制都可以在 Service Mesh 中实现。



    A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware. ————What's a service mesh? And why do I need one?



    Service Mesh 简单架构如下:




    大量服务相互调用时,Service Mesh 架构如下:





    目前比较火的 Service Mesh 开源项目是 Istio,由 Google、IBM、Lyft 共同开发,它提供了一个完整的解决方案,通过为整个服务网格提供行为洞察和操作控制来满足微服务应用程序的多样化需求。



    Istio官方文档中文版介绍,Istio 逻辑上分为数据面板和控制面板。




    • 数据面板由一组智能代理(Envoy)组成,代理部署为边车,调解和控制微服务之间所有的网络通信。


    • 控制面板负责管理和配置代理来路由流量,以及在运行时执行策略。





    Istio 目前仅支持在 Kubernetes 上的服务部署,但未来版本中将支持其他环境。



    Service Mesh 的更详细解读,可以参考以下文章:







    微服务架构越来越复杂的情况下,Service Mesh 能够让很多工作变得更简单。Kubernetes 被 Google 硬生生推进了 AWS 和 Azure,Azure Container Service(ACS)都变成以 Kubernetes 为主的 AKS 了。Istio 的前途,还是很值得期待的。



    当然,英国互联网金融初创公司 Monzo 因为特定版本 Kubernetes 和 Linkerd 的不兼容引发的血案再次告诉我们,新技术应用到生产环境之前要经过缜密的论证,然而技术人员对新技术的发展,始终要保持开放的心态去了解的。