我们再来回顾一下架构发展历程,从前往后的顺序依次为单机小型机->垂直拆分->集群化负载均衡->服务化改造架构->服务治理->微服务时代
垂直拆分:随着应用的日益复杂和多样性,对系统容灾、伸缩和业务响应能力有了更高的要求。单机小型机架构中如果小型机和数据库任何一个出现故障或宕机,整个系统都会奔溃;若某个板块的功能需要更新,那么整个系统也需重新发布,显然这在业务快速发展的万物互联网时代是不被允许的。需要将系统进行拆分,拆分为多个子应用。
集群化负载均衡:随着用户数量的增加,单个小型机的计算能力依旧是杯水车薪,无法应对业务的增加的需要。且小型机的价格比较昂贵,维护成本较高。在此时更优的选择是采用多台PC机部署同一个应用的方案,考虑到客户端不知道那个请求需要落在哪一个后端PC应用上,因此引入负载均衡的机制。负载均衡思想是对外暴露一个统一的接口,根据用户请求进行相应规则的转发,而这样后端的应用可以根据流量的大小进行动态扩容或者成为水平扩展。国内阿里巴巴在2008年提出去IOE(也即为IBM小型机、Oracle数据库、EMC存储),全部改为集群负载均衡架构,到2013年最后一批IBM小型机下线。
负载均衡主要分为硬件层面和软件层面均衡:
优点:在垂直拆分优点基础上增加水平扩展来支持大流量业务。
服务化改造架构:虽然有垂直拆分,但是拆分之后发现论坛和聊天室中有重复功能,比如登录、用户注册、发邮件等等,重复功能会造成资源的浪费,因此服务化改造会把重复的功能抽取出来做成Service服务的形式来调用,为了解决服务之间的相互调用就有了RPC(远程调用)的通信协议,作用就是让服务之间的调用就像本地调用一样的简单。
服务治理:随着业务增加,基础服务也越来越多,服务之间调用关系越来越错综复杂,对此有了服务治理的需求。服务治理基本要求如下,基于Java技术栈在这一阶段典型的框架有Dubbo,默认采用Zookeeper作为注册中心。
微服务时代:微服务希望一个只负责一个独立的功能并可以做到独立部署和运维。比如用户中心,对于为服务来说还可以分为卖家服务、卖家服务、商家服务等。基于Java技术栈这一阶段典型的代表就是SpringCloud,默认使用HTTP协议作为RPC,增加分布式配置中心、分布式事务、分布式消息队列等融合。
Spring Cloud Alibaba组件:
Spring Cloud Netflix Ribbon:客户端负载均衡器,Nacos客户端中已默认集成Ribbon。
Spring-Cloud-OpenFeign:是一个声明式的伪RPC(Feign英文意思为“假装,伪装,变形”)的REST客户端,它用了基于接口的注解方式,可以以Java接口注解的方式调用Http请求,从而将请求模块化。
Spring Cloud Gateway:提供了一个在Spring WebFlux上构建API网关的库,旨在提供一种简单而有效的方式来路由到api,并为它们提供横切关注点,如安全性、监控/指标和弹性。
Apache SkyWalking:国产优秀开源的分布式系统的应用程序性能监控工具,特别为微服务,云本地和基于容器(Docker, Kubernetes, Mesos)架构设计。
上一张接着微服务时代继续说,之前文章也介绍SpringCloud Alibaba一站式微服务解决方案入门示例(后续文章我们会详细介绍相关的微服务组件),有了一定理解,但这些微服务存在以下问题,因此可以说Service Mesh概念提出的初衷就是来解决这些问题的。
Service Mesh解决思路
Sidecar降低了与微服务架构相关的复杂性,并且提供负载均衡、服务发现、流量管理、电路中断、故障注入等特点。该种模式允许向应用无侵入的添加多种功能,避免为满足第三方组件需求而对应用添加额外的配置代码。其借鉴了Proxy代理模式,代表产品有 Lyft 构建的Envoy、Netflix的Prana。
Sidecar为了通用基础设置而设计,服务的业务代码与Sidecar绑定在一起,每个服务配置一个Sidecar代理,每个服务所有流量都要经过Sidecar,控制服务流量的进出,Sidecar帮我们屏蔽通信的细节,开发人员只需关注业务代码实现,通信的工作就交由Sidecar处理,做到与技术框架无侵入性。
Envoy是一个开源的边缘和服务代理,专为云本地应用设计用于云原生应用,云原生基金会 CNCF 项目。 最初是在 Lyft 构建的,它是为单一服务和应用程序设计的高性能 C++ 分布式代理,以及为大型微服务 Service Mesh 体系结构设计的通信总线和通用数据平面。目前最新版本为1.21.1.特点:
Envoy是为大型现代面向服务架构设计的L7代理和通信总线,Envoy是一个自包含的进程,旨在与每个应用程序服务器一起运行。所有的envoy都形成了一个透明的通信网络,每个应用程序在其中向本地主机发送和接收消息,并且不知道网络拓扑。
L3/L4 filter architecture
HTTP L7 filter architecture
First class HTTP/2 support
HTTP/3 support (currently in alpha):
HTTP L7 routing
gRPC支持
服务发现和动态配置
运行状况检查
负载平衡
前/边缘代理支持
最好的观察性
Service Mesh(服务⽹格)是一种控制应用程序不同部分彼此共享数据的方式,旨在以减少管理和编程开销的形式来连接微服务。主要目的是让开发⼈员更专注的聚焦到业务上,以代码无侵入形式实现微服务中的服务发现、服务注册、负载均衡等常用功能。Service Mesh的核心思想是将为微服务提供通信服务的这部分逻辑从应⽤程序进程中抽取出来,作为⼀个单独的进程进⾏部署,并将其作为服务间的通信代理当服务⼤量部署时,随着服务部署的Sidecar(边⻋,很形象的翻译)代理之间的连接形成⽹格结构并成为了微服务的通讯基础设施层,承载了微服务之间的所有流量。
特点:基础设施、云原生、网络代理、对应用透明
Buoyant公司的Linked为第一个意义上的Service Mesh项目,由Twitter开发,很好结合了K8S的云原生概念,无侵入业务代码就能管理服务的流量,兼容K8S提供全部功能。设计思想如下图:
但Linked部署较为繁琐,且只是实现数据层面的问题,缺乏对于数据层的管理。国外Service Mesh产品发展还是非常迅猛的,NginxMesh,F5的AspenMesh、HashiCorp的Consul Connect、Kong、AWS的AppMesh和微软发起的一项标准化各种服务网格接口的倡议SMI。后面我们再来说说Istio-毫无疑问当前最主流的ServiceMesh产品。
这里我们也提一下国内在ServiceMesh方向上实践的一些公司,有时间也可以去了解下
Istio GitHub地址 https://github.com/istio
ServiceMesh:现代应用程序通常被架构为分布式的微服务集合,每个微服务集合执行一些的业务功能。服务网格是一个专用的基础设施层,可以添加到应用程序中。它允许您透明地添加如可观察性、流量管理和安全性等功能,代码无侵入。“服务网格”描述了用于实现该模式的软件类型,以及在使用该软件时创建的安全或网络域。
随着分布式服务(比如基于kubernetes的系统)的部署规模和复杂性的增长,它可能会变得更难理解和管理,如服务发现、负载平衡、故障恢复、指标和监控。服务网格还可处理更复杂的操作需求如A/B测试、金丝雀部署、速率限制、访问控制、加密和端到端身份验证。
服务到服务通信使得分布式应用程序成为可能,随着服务数量的增长,在应用程序集群内部和跨应用程序集群路之间的通信变得越来越复杂,Istio有助于降低这些部署的复杂性,并减轻开发团队的压力。
Istio是由Google、IBM和Lyft共同发起的开源服务网格项目,由go语言编写,但又不仅仅是服务网格那么简单。Istio的目的是解决当单体应用程序向分布式微服务架构过渡时开发人员和运营商所面临的挑战。Istio透明地分层到现有的分布式应用程序上,通过在部署的每个应用程序中添加代理“sidecar”,Istio允许您在网络中编程应用程序感知的流量管理、不可思议的可观察性和健壮的安全功能;能够成功且高效地运行分布式微服务架构,并提供保护、连接和监控微服务的统一方法。Istio提供了对整个服务网格的行为洞察和操作控制的能力,以及一个完整的满足微服务应用各种需求的解决方案。
Istio 可以轻松地创建一个已经部署了服务的网络,比如实现负载平衡、服务到服务身份验证和监视的服务的代码只需很少更改甚至无需更改。Istio极大的减少了应用程序代码,底层平台和策略之间的耦合,使微服务更容易实现了!通过在整个环境中部署一个特殊的 sidecar 代理为服务添加 Istio 的支持,而代理会拦截微服务之间的所有网络通信,然后使用其控制平面的功能来配置和管理 Istio控制平面的特点:
Istio 为可扩展性而设计,可以满足不同的部署需求。
Istio由数据平面和控制平面两部分组成:
Istio是一个开放平台,提供统一的方式来集成微服务、管理跨微服务的流量、执行策略和聚合遥测数据。Istio的控制平面在底层集群管理平台(如Kubernetes)上提供了一个抽象层,Istio由以下组件组成
下一篇我们再来部署和简单实战Istio
**本人博客网站 **IT小神 www.itxiaoshen.com
手机扫一扫
移动阅读更方便
你可能感兴趣的文章