目前,微服务的架构方式在企业中得到了极大的发展,主要原因是其解决了传统的单体架构中存在的问题。
当单体架构拆分成微服务架构就可以高枕无忧了吗? 显然不是的。
微服务架构体系中同样也存在很多的挑战,比如:
没错,Service Mesh就是为了解决以上问题才出现的。这就是我们学习本套课程的目的。
第一个计算机网络诞生于1969年,也就是美军的阿帕网,阿帕网能够实现与其它计算机进行联机操作,但是早期仅仅是为了军事目的而服务
2000年初,中国的网民大约890万,很多人都不知道互联网为何物,因此大多数服务业务单一且简单,采用典型的单机+数据库模式,所有的功能都写在一个应用里并进行集中部署。
说明:论坛业务、聊天室业务、邮箱业务全部都耦合在一台小型机上面,所有的业务数据也都存储在一台数据库上。
优点:应用间进行了解耦,系统容错提高了,也解决了独立应用发布的问题。
应用垂直拆分解决了应用发布的问题,但是随着用户数量的增加,单机的计算能力依旧是杯水车薪。
用户量越来越大,就意味着需要更多的小型机,但是小型机价格昂贵,操作维护成本高。
此时更优的选择是采用多台PC机部署同一个应用的方案,但是此时就需要对这些应用做负载均衡,因为客户端不知道请求会落到哪一个后端PC应用上的。
负载均衡可以分为硬件层面和软件层面。
硬件层面:F5
软件负载层面:LVS、Nginx、Haproxy
负载均衡的思想:对外暴露一个统一的接口,根据用户的请求进行对应规则转发,同时负载均衡还可以做限流等等
有了负载均衡之后,后端的应用可以根据流量的大小进行动态扩容,我们称为"水平扩展"。
阿里巴巴在2008提出去“IOE”,也就是IBM小型机、Oracle数据库,EMC存储,全部改成集群化负载均衡架构,在2013年支付宝最后一台IBM小型机下线。
优点:通过水平扩展,增强了系统的并发能力。
虽然系统经过了垂直拆分,但是拆分之后发现在论坛和聊天室中有重复的功能,比如,用户注册、发邮件等等,一旦项目大了,集群部署多了,这些重复的功能无疑会造成资源浪费,所以会把重复功能抽取出来,名字叫"XX服务(Service)"。
为了解决服务跟服务如何相互调用,需要一个程序之间的通信协议,所以就有了远程过程调用(RPC),作用就是让服务之间的程序调用变得像本地调用一样的简单。
优点:在前面的架构之上解决了业务重用的问题。
随着业务的增大,基础服务越来越多,调用网的关系由最初的几个增加到几十上百,造成了调用链路错综复杂,需要对服务进行治理。
服务治理要求:
典型框架比如有:Dubbo,默认采用的是Zookeeper作为注册中心。
微服务是在2012年提出的概念,微服务的希望的重点是一个服务只负责一个独立的功能。
拆分原则,任何一个需求不会因为发布或者维护而影响到不相关的服务,一切可以做到独立部署运维。
比如传统的“用户中心”服务,对于微服务来说,需要根据业务再次拆分,可能需要拆分成“买家服务”、“卖家服务”、“商家服务”等。
典型代表:Spring Cloud,相对于传统分布式架构,SpringCloud使用的是HTTP作为RPC远程调用,配合上注册中心Eureka和API网关Zuul,可以做到细分内部服务的同时又可以对外暴露统一的接口,让外部对系统内部架构无感,此外Spring Cloud的config组件还可以把配置统一管理。
Spring Cloud微服务架构存在的不足:
Service Mesh主要解决的问题就希望开发人员对于业务的聚焦,服务发现、服务注册、负载均衡等对于开发人员透明,可以更加专注业务逻辑的实现。
如果将为微服务提供通信服务的这部分逻辑从应用程序进程中抽取出来,作为一个单独的进程进行部署,并将其作为服务间的通信代理,可以得到如下图所示的架构:
Sidecar,翻译成中文是边车,非常的形象。
当服务大量部署时,随着服务部署的Sidecar代理之间的连接形成了一个如下图所示的网格,该网格成为了微服务的通讯基础设施层,承载了微服务之间的所有流量,被称之为Service Mesh(服务网格)。
服务网格中有数量众多的Sidecar代理,如果对每个代理分别进行设置,工作量将非常巨大。为了更方便地对服务网格中的代理进行统一集中控制,在服务网格上增加了控制面组件。
服务网格用来描述组成这些应用程序的微服务网络以及它们之间的交互。随着服务网格的规模和复杂性不断的增长,它将会变得越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、度量和监控等。服务网格通常还有更复杂的运维需求,比如 A/B 测试、金丝雀发布、速率限制、访问控制和端到端认证。
CNCF 是一个开源软件基金会,致力于使云原生计算具有普遍性和可持续性。 云原生计算使用开源软件技术栈将应用程序部署为微服务,将每个部分打包到自己的容器中,并动态编排这些容器以优化资源利用率。 云原生技术使软件开发人员能够更快地构建出色的产品。
官网:https://www.cncf.io/
常用的已经毕业的云原生项目:
Linkerd是Buoyant公司2016年率先开源的高性能网络代理程序,是业界的第一款Service Mesh产品,甚至可以说Linkerd的诞生标志着Service Mesh时代的开始,其引领后来Service Mesh的快速发展。
其主要用于解决分布式环境中服务之间通信面临的一些问题,比如网络不可靠、不安全、延迟丢包等问题。Linkerd使用Scala语言编写,运行于JVM,底层基于Twitter的Finagle库,并对其做相应的扩展。
最主要的是Linkerd具有快速、轻量级、高性能等特点,每秒以最小的时延及负载处理万级请求,易于水平扩展,经过生产线测试及验证,可运行任何平台的产线级Service Mesh工具。
Envoy也是一款高性能的网络代理程序,于2016年10月份由Lyft公司开源,为云原生应用而设计,可作为边界入口,处理外部流量,当然,也作为内部服务间通信代理,实现服务间可靠通信。
Envoy的实现借鉴现有产线级代理及负载均衡器,如Nginx、HAProxy、硬件负载均衡器及云负载均衡器的实践经验,同时基于C++编写及Lyft公司产线实践证明,Envoy性能非常优秀、稳定。
Envoy既可用作独立代理层运行,也可作为Service Mesh架构中数据平面层,因此通常Envoy跟服务运行在一起,将应用的网络功能抽象化,Envoy提供通用网络功能,实现平台及语言无关。
2017年5月24日,Google, IBM 和 Lyft 共同发布 Istio 的第一个公开版本(0.1)。Istio为一款开源的为微服务提供服务间连接、管理以及安全保障的平台软件,支持运行在Kubernetes、Mesos等容器管理工具,但不限于Kubernetes、Mesos,其底层依赖于Envoy。
Istio提供一种简单的方法实现服务间的负载均衡、服务间认证、监控等功能,而且无需应用层代码调整。其控制平面由Pilot、Citadel 和 Galley组成,数据平面由Envoy实现,通常情况下,数据平面代理Envoy以sidecar模式部署,使得所有服务间的网络通信均由Envoy实现,而Istio的控制平面则负责服务间流量管理、安全通信策略等功能。
Conduit于2017年12月发布,作为由Buoyant继Linkerd后赞助的另一个开源项目。Conduit旨在彻底简化用户在Kubernetes使用服务网格的复杂度,提高用户体验,而不是像Linkerd一样针对各种平台进行优化。
国内很多团队也已经在着手研究了,这些团队主要分为四类体系:
本文由传智教育博学谷 - 狂野架构师教研团队发布
如果本文对您有帮助,欢迎关注和点赞;如果您有任何建议也可留言评论或私信,您的支持是我坚持创作的动力
转载请注明出处!