微服务浅谈&服务治理的演变过程

  • 时间:
  • 浏览:0
  • 来源:大发时时彩官网_大发时时彩平台有哪些_大发时时彩正规平台

这半个月对互联网的架构演变进行了简单了解,并对微服务的出現很感兴趣,许多许多对相关知识进行了简单的埋点与总结。

本篇文章先简单介绍了互联网架构的演变,进而介绍了服务化,最后介绍了微服务及最新的服务网格(Service Mesh)。

---------------------

互联网架构演变

一体架构

在计算机软件发展早期,一般桌面软件都不 采用许多架构,不管是界面还是业务防止还是数据防止都倒入一个多多 包中。许多着实谈不上架构,但有有助于有有助于 说是很好的架构,可能性它足够简单。

mvc架构

但随着浏览器的出現便产生了web应用,web应用的特点是界面累积是显示在浏览器中,服务防止是在服务容器中的,页面显示一般用css+js+html技术来防止,而后端还可不可不都可以够 用java、php等语言,这就产生了前后端分离。对于web系统,一体架构难以满足前后端分离的开发需求,因而便产生了MVC架构。

 

MVC才算的上真正意义上的架构,可能性它除了防止了前后端分离问提,还引入了两种全新的开发模式,用两种业务逻辑、数据、界面显示分离的法子 组织代码,使得整个应用层次更加分明,并且各个层次之间不但减低了耦合性,还提高了各个层次的可重用性。

但随着应用规模的不断扩大,应用模块不断增加,整个应用也显得这麼臃肿,维护起来也更加困难,并且便又产生了多应用架构。

多应用架构

多应用架构很简单,许多许多把这麼 的应用按照业务特点拆分成多个应用。比如一个多多 大型电商系统可能性中有 用户系统、商品系统、订单系统、评价系统等等,亲戚亲戚我们歌词 都我们歌词 都还可不可不都可以够 把亲戚亲戚我们歌词 都我们歌词 都独立出来形成一个多多 个单独的应用。多应用架构的特点是应用之间本人独立 ,不相互调用。

 

多应用着实防止了应用臃肿问提,但应用之间相互独立,许多并肩的业务或代码无法复用。

分布式架构

对于一个多多 大型的互联网系统,一般会中有 多个应用,并且应用之间往往还处在并肩的业务,并且应用之间还处在调用关系。除此之外 ,对于大型的互联网系统还有许多其它的挑战,比如怎么可不都可以应对急剧增长的用户,怎么可不都可以管理好研发团队快速迭代产品研发,怎么可不都可以保持产品升级更加稳定等等 。

并且,为了使业务得到很好的复用,模块更加容易拓展和维护,亲戚亲戚我们歌词 都我们歌词 都希望业务与应用分离,某个业务不再属于一个多多 应用,许多许多作为一个多多 独立的服务单独进行维护。应用两种不再是一个多多 臃肿的模块堆积,许多许多由一个多多 个模块化的服务组件组合而成。

服务化

服务化的特点

底下介绍的分布式架构即服务化。亲戚亲戚我们歌词 都我们歌词 都再总结一下,服务化主要有如下特点:

  • 应用按业务拆分成服务
  • 各个服务均可独立部署
  • 服务可被多个应用共享
  • 服务之间还可不可不都可以够 通信

服务化的好处

这麼企业采用服务化有那先 好处呢?

  • 架构上系统更加清晰
  • 核心模块稳定,以服务组件为单位进行升级,防止了频繁发布带来的风险
  • 开发管理方便
  • 单独团队维护、工作分明,职责清晰
  • 业务复用、代码复用
  • 非常容易拓展

服务化实现法子

可能性要实现服务化话语,最常用的法子 许多许多利用RPC框架。可能性服务组件一般分布在不同的服务器上,许多许多要实现服务化还可不可不都可以够防止的第一个多多 问提许多许多RPC**远程服务调用**。同类于RPC方案有许多许多,比如:

  • Java RMI
  • WebService
  • Hessian
  • Http
  • Thrift
  • … …

服务化面临的挑战

底下提到要实现服务化首先还可不可不都可以够防止远程服务调用问提,除此之外,还有许多许多许多问提还可不可不都可以够防止。

  • 服务这麼来太多,配置管理复杂性
  • 服务间依赖关系复杂性
  • 服务之间的负载均衡
  • 服务的拓展
  • 服务监控
  • 服务降级
  • 服务鉴权
  • 服务上线与下线
  • 服务文档
  • … …

服务治理

底下提到了服务化,着实要想服务化,服务治理是关键。这麼有这麼好的服务治理方案呢?答案是有的,并且许多有人都不 用许多框架,他许多许多-dubbo。dubbo许多许多一个多多 中有 服务治理功能的RPC框架。

 

dubbo提供了一套较为全版的服务治理方案,许多许多企业可能性要实现服务化话语,dubbo 是很好的一个多多 选用。这里简单介绍一下dubbo服务治理相关方案。

服务发现注册

服务治理领域最重要的问提许多许多服务发现与注册。dubbo中引入了一个多多 注册中心的概念,服务的注册与发现主要就依赖许多服务中心。

 

dubbo注册中心服务注册发现的具体过程:

服务提供者启动,向注册中心注册被委托人提供的服务

消费者启动,向注册中心订阅被委托人还可不可不都可以够的服务

注册中心返回服务提供者的列表给消费者

消费者从服务提供者列表中,按照软负载均衡算法,选用一台发起请求

服务监控

集群容错

 

负载均衡

  • Random Loadbalance
  • RoundRobin
  • LeastActive
  • ConsistentHash

dubbo服务治理优势

  • 注册中心只负责注册查找,不负责请求转发,压力小
  • 注册中心宕机影响消费者,消费者本地缓存服务地址列表
  • 注册中心对等集群,宕掉一台自动切换到另外 一台
  • 服务提供者无状态,可动态部署,注册中心负责推送
  • 统计无压力,本地内存中累计次数,每分钟发送注册中心
  • 消费者调用服务者,自动软负载均衡
  • 通过服务中心可追踪依赖关系
  • 监控中心为扩容和降级提供法子
  • 可启用acl机制进行鉴权
  • 与Spring整合,接入简单松耦合
  • 多种序列化协议支持

dubbo的过高

  • 消费者仍还可不可不都可以够依赖配置中心
  • 消费者仍还可不可不都可以够依赖jar包配置provider
  • 提供者文档管理功能缺失
  • 无统一入口
  • 不支持OAuth2.0
  • 內部鉴权不方便管理
  • 无內部应用鉴权
  • 接口基本裸奔,无法直接对外暴露服务
  • IT治理不方便

微服务

现在许多有人都不 谈微服务,这麼到底那先 是微服务呢?这里谈谈我对微服务的理解。

微服务有一个多多 核心:

  • 微:服务的粒度要细,即服务要细化到API
  • 服务:提供好服务,要让用户感到好用(要做到许多点很不容易)

微服务(Microservices)是两种架构风格,一个多多 大型复杂性软件应用由一个多多 或多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有状态下,每个任务代表着一个多多 小的业务能力。

微服务架构 ≈ 模块化开发 + 分布式计算

 

从底下这幅图看出,微服务有点硬简单(好的架构就应该简单),亲戚亲戚我们歌词 都我们歌词 都把服务再拆分成一个多多 个API,API是一个多多 全版的功能。并且亲戚亲戚我们歌词 都我们歌词 都把API扔到一个多多 “云上”,并且用户就还可不可不都可以够 到“云上”获取所有API的服务,许多“云”保证能提供好的服务。

亲戚亲戚我们歌词 都我们歌词 都还可不可不都可以够 看到,有了微服务事先,服务对用户来说变得有点硬简单,并且底下dubbo的过高 之处在微服务这里都防止了。使用者不再还可不可不都可以够依赖任何jar包,不再还可不可不都可以够去注册中心查找服务,不再去做鉴权防止,我太多 担心服务挂掉,我太多 担心我太多 使用服务,所有的问提许多“云”都防止了。这也是微服务的核心之一,提供好服务。

说到这里,亲戚亲戚我们歌词 都我们歌词 都就应该大体知道该怎么能在么在做微服务了,图中的“云”是关键。下面亲戚亲戚我们歌词 都我们歌词 都就慢慢拨开这朵云。

微服务的实现

微服务的关键是服务网关,许多许多,底下提到的“云”许多许多服务网关。要做微服务,亲戚亲戚我们歌词 都我们歌词 都先定义一下微服务还可不可不都可以够具备的特点。

常见的微服务组件及概念:

  • 服务注册:服务提供方将被委托人调用地址注册到服务注册中心,让服务调用方有有助于方便地找到被委托人。
  • 服务发现:服务调用方从服务注册中心找到被委托人还可不可不都可以够调用的服务的地址。
  • 负载均衡:服务提供方一般以多实例的形式提供服务,负载均衡功还可不可不都可以够 够让服务调用方连接到大慨的服务节点。并且,节点选用的工作对服务调用方来说是透明的。
  • 服务网关:服务网关是服务调用的唯一入口,还可不可不都可以够 在许多组件是实现用户鉴权、动态路由、灰度发布、A/B 测试、负载限流等功能。
  • 配置中心:将本地化的配置信息(properties, xml, yaml 等)注册到配置中心,实现线程池包在开发、测试、生产环境的无差别性,方便线程池包的迁移。
  • API 管理:以方便的形式编写及更新 API 文档,并以方便的形式供调用者查看和测试。
  • 集成框架:微服务组件都以职责单一的线程池包对外提供服务,集成框架以配置的形式将所有微服务组件(有点硬是管理端组件)集成到统一的界面框架下,让用户有有助于在统一的界面中使用系统。
  • 分布式事务:对于重要的业务,还可不可不都可以够通过分布式事务技术(TCC、高可用消息服务、最大努力通知)保证数据的一致性。
  • 调用链:记录完成一个多多 业务逻辑时调用到的微服务,并将许多串行或并行的调用关系展示出来。在系统出错时,还可不可不都可以够 方便地找到出错点。
  • 支撑平台:系统微服务化后,系统变得更加碎片化,系统的部署、运维、监控等都比单体架构更加复杂性,这麼,就还可不可不都可以够将大累积的工作自动化。现在,还可不可不都可以够 通过 Docker 等工具来中和那先 微服务架构带来的弊端。 同类持续集成、蓝绿发布、健康检查、性能健康等等。严重点,以亲戚亲戚我们歌词 都我们歌词 都两年的实践经验,还可不可不都可以够 这麼说,可能性这麼大慨的支撑平台或工具,就并不使用微服务架构。

微服务架构的优点:

  • 降低系统复杂性度:每个服务都比较简单,只关注于一个多多 业务功能。
  • 松耦合:微服务架构法子 是松耦合的,每个微服务可由不同团队独立开发,互不影响。
  • 跨语言:并且符合服务 API 契约,开发人员还可不可不都可以够 自由选用开发技术。这就意味开发人员还可不可不都可以够 采用新技术编写或重构服务,可能性服务相对较小,许多许多这并我太多 对整体应用造成这麼来太多影响。
  • 独立部署:微服务架构还可不可不都可以够 使每个微服务独立部署。开发人员我太多 协调对服务升级或更改的部署。那先 更改还可不可不都可以够 在测试通事先立即部署。许多许多微服务架构也使得 CI/CD 成为可能性。
  • Docker 容器:和 Docker 容器结合的更好。
  • DDD 领域驱动设计:和 DDD 的概念契合,结合开发会更好。

微服务架构的缺点:

  • 微服务强调了服务大小,但实际上这并这麼一个多多 统一的标准:业务逻辑应该按照那先 规则划分为微服务,这两种许多许多一个多多 经验工程。许多开发者主张 10-30 行代码就应该建立一个多多 微服务。着实建立小型服务是微服务架构崇尚的,但要记住,微服务是达到目的的手段,而都不 目标。微服务的目标是充分分解应用线程池,以有有助于于敏捷开发和持续集成部署。
  • 微服务的分布式特点带来的复杂性性:开发人员还可不可不都可以够基于 RPC 可能性消息实现微服务之间的调用和通信,而这就使得服务之间的发现、服务调用链的跟踪和质量问提变得的相当棘手。
  • 分区的数据库体系和分布式事务:更新多个业务实体的业务交易相当普遍,不同服务可能性拥有不同的数据库。CAP 原理的约束,使得亲戚亲戚我们歌词 都我们歌词 都不得不放弃传统的强一致性,而转而追求最终一致性,许多对开发人员来说是一个多多 挑战。
  • 测试挑战:传统的单体WEB应用只需测试单一的 REST API 即可,而对微服务进行测试,还可不可不都可以够启动它依赖的所有许多服务。许多复杂性性不可低估。
  • 跨多个服务的更改:比如在传统单体应用中,若有 A、B、C 一个多多 服务还可不可不都可以够更改,A 依赖 B,B 依赖 C。亲戚亲戚我们歌词 都我们歌词 都只需更改相应的模块,并且一次性部署即可。并且在微服务架构中,亲戚亲戚我们歌词 都我们歌词 都还可不可不都可以够仔细规划和协调每个服务的变更部署。亲戚亲戚我们歌词 都我们歌词 都还可不可不都可以够先更新 C,并且更新 B,最后更新 A。
  • 部署复杂性:微服务由不同的一定量服务构成。累积服务可能性拥有被委托人的配置、应用实例数量以及基础服务地址。这里就还可不可不都可以够不同的配置、部署、扩展和监控组件。此外,亲戚亲戚我们歌词 都我们歌词 都还还可不可不都可以够服务发现机制,以便服务还可不可不都可以够 发现与其通信的许多服务的地址。并且,成功部署微服务应用还可不可不都可以够开发人员有更好地部署策略和深层自动化的水平。
  • 总的来说(问提和挑战):API Gateway、服务间调用、服务发现、服务容错、服务部署、数据调用。

微服务要防止的问提

底下提到了,dubbo还处在许多问提 ,着实dubbo处在的问提 许多许多 微服务要防止的问提,这里 再总结一下。当然,dubbo和微服务的侧重点不一样,dubbo侧重于內部接口之间的RPC,而微服务则侧重于对外提供服务。

  • 统一入口
  • 安全控制:防刷限流
  • 统一鉴权:应用鉴权、用户鉴权、OAuth鉴权、ACL
  • 协议转换:http、dubbo、Protobuf
  • API配置管理
  • API上线、下线
  • API与服务接口映射
  • 监控与报警
  • 整体架构的可拓展、高并发、分布式
  • 服务容器自动收缩、扩容

实现方案

  • 负载均衡层:nginx/lvs/F5
  • 微服务层

    高性能服务网关;

    统一入口、API配置管理、分流鉴权、服务监控、协议转换;

    API映射、OAuth2.0、API文档管理;

    分布式、可拓展;

  • 服务治理层

    心智心智性心智心智成熟是什么是什么 图片 是什么是什么是什么图片 图片 的服务治理框架dubbo;

    MQ服务之间解耦;

  • 弹性云

    服务docker化;

    基于访问压力的实时集群调度与管理;

弹性云

这里简单介绍一下弹性云的概念,微服务要想提供好服务,保证API还可不可不都可以够了挂掉并且有好的性能,还可不可不都可以够很高的运维要求。这里的弹性云便是自动化运维防止方案,对访问压力进行监控,根据监控防止调度应用的发布和回收。

服务网格(Service Mesh)

2017 年底,非侵入式的 Service Mesh 技术从萌芽到走向了心智心智性心智心智成熟是什么是什么 图片 是什么是什么是什么图片 图片 。

Service Mesh 又译作“服务网格”,作为服务间通信的基础设施层

可能性用话语来解释那先 是 Service Mesh,还可不可不都可以够 将它比作是应用线程池可能性说微服务间的 TCP/IP,负责服务之间的网络调用、限流、熔断和监控。对于编写应用线程池来说一般并不关心 TCP/IP 许多层(比如通过 HTTP 协议的 RESTful 应用),同样使用 Service Mesh 也就并不关系服务之间的那先 这麼 是通过应用线程池可能性许多框架实现的事情,比如 Spring Cloud、OSS,现在并且交给 Service Mesh 就还可不可不都可以够 了。

Service Mesh 的来龙去脉:

  1. 从最原始的主机之间直接使用网线相连
  2. 网络层的出現
  3. 集成到应用线程池內部的控制流
  4. 分解到应用线程池內部的控制流
  5. 应用线程池的中集成服务发现和断路器
  6. 出現了专门用于服务发现和断路器的软件包/库,如 Twitter 的 Finagle 和 Facebook 的 Proxygen,这事先还是集成在应用线程池內部
  7. 出現了专门用于服务发现和断路器的开源软件,如 Netflix OSS、Airbnb 的 synapse 和 nerve
  8. 最后作为微服务的底下层 Service Mesh 出現

Service Mesh 有如下有几次特点:

  • 应用线程池间通讯的底下层
  • 轻量级网络代理
  • 应用线程池无感知
  • 解耦应用线程池的重试/超时、监控、追踪和服务发现

Service Mesh 架构图:

关于微服务和服务网格的区别,我的许多理解:微服务更像是一个多多 服务之间的生态,专注于服务治理等方面,而服务网格更专注于服务之间的通信,以及和 DevOps 更好的结合



---------------------

Reference: 1,微服务架构初探

2,浅谈服务治理与微服务 

3,那先 是Service Mesh(服务网格)