加入收藏 | 设为首页 | 会员中心 | 我要投稿 源码网 (https://www.900php.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 运营中心 > 建站资源 > 优化 > 正文

技术干货分享:微服务浅谈服务治理的演变过程

发布时间:2019-08-17 06:05:46 所属栏目:优化 来源:IT技术分享
导读:副标题#e# 本篇文章先简单介绍了互联网架构的演变,进而介绍了服务化,最后介绍了微服务及最新的服务网格(Service Mesh)。 互联网架构演变 一体架构 在计算机软件发展早期,一般桌面软件都是采用这种架构,不管是界面还是业务处理还是数据处理都放到一个包

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 的概念契合,结合开发会更好。

(编辑:源码网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读