微服务

1 需求

a)调研微服务框架,形成调研报告。重点包括:

  • 框架核心思想
  • 适用场景
  • 主要实现方案及特点
  • 已有使用微服务的案例情况

b)搭建微服务框架环境,形成基于框架开发指导手册。

c)微服务框架环境支撑能力评估,形成支持数量、应用运行性能、扩展能力等评估报告。

2 传统微服务架构

2.1 单体应用架构

分层架构(逻辑上的分层,而非物理上的分层)

  • 所有的代码最终还是运行在同一个进程中。而这就是所谓的单块架构

    • 表示层、业务逻辑层和数据访问层,层与层之间互相连接、互相协作,构成整体
      • 表示层: 用户使用应用程序时,看到的、听见的、输入的或者交互的部分。
      • 业务逻辑层: 根据用户输入的信息,进行逻辑计算或者业务处理的部分。
      • 数据访问层: 关注有效地操作原始数据的部分,如将数据存储到存储介质(如数据库、文件系统)及从存储介质中读取数据等。
    • 优点:易于开发;易于测试;易于部署;易于水平伸缩(发布到新服务器节点)
    • 缺点:维护成本大(bug连串,不容易协作);交付周期长;新人上手慢;技术选型引入成本高;可拓展性差

通俗的来讲,all in one 是将一个应用中的所有应用服务都封装在一个应用中。
例如,数据库访问,web访问等等各个功能放在同一个war包里。

2.2 集群结构

单机处理到达瓶颈的时候,就把单机复制几份,这样就构成了一个“集群”。

集群中每台服务器就叫做这个集群的一个“节点”,所有节点构成了一个集群。

每个节点都提供相同的服务,那么这样系统的处理能力就相当于提升了好几倍。

用户的请求究竟由哪个节点来处理?负载均衡服务器来分配

2.3 微服务架构

微服务就是将一个完整的系统,按照业务功能,拆分成一个个独立的子系统,在微服务结构中,每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中,它们之间通过RPC方式通信。

  • 是一种开发软件的架构模式,相比整体式架构,其提倡将单一的应用程序划分成一组小的服务

    • 将应用程序构建为独立的组件,并将每个应用程序进程作为一项服务运行
  • 微服务的特性

    • 单一职责:高内聚、低耦合,每个服务是单一职责原则的单元,不同的服务进行组合构建系统。

    • 轻量级通信:轻量级是指与语言和平台无关的交互(格式一般是XML,JSON这种,协议基于HTTP)

    • 独立:可独立开发测试和部署
      imgimg

  • 进程隔离:单块架构整个系统运行在同一进程中,部署时需操作整个应用,无法独立部署;微服务中由多个服务组成,每个服务可以独立运行在不同进程中。
    imgimg

2.3 开源框架

当前的微服务框架有很多,但是最多的主要是两种:

Spring Cloud

Spring Cloud 为开发者提供了分布式系统配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性 Token、全局锁、决策竞选、分布式会话与集群状态等的开发工具。使用 Spring Cloud 开发者可以快速实现上述这些模式。

在基于Spring Cloud进行微服务开发时,在项目中就会通过引入“spring-cloud-starter-parent”父依赖来实现其他框架及组件的快速引入。
Spring Cloud集成并封装netfix中的ribbon,eureka,hystrix,feign和zull等十分出色的项目,为我们提供了服务注册与发现,客户端的负载均衡和路由分发等功能。
Spring Cloud除了一些核心的项目外,还有很多实现特定功能的组件框架,如Sleuth、Turbine等。

基础功能:
服务治理: Spring Cloud Eureka
客户端负载均衡: Spring Cloud Ribbon
服务容错保护: Spring Cloud Hystrix
声明式服务调用: Spring Cloud FeignAPI
网关服务:Spring Cloud Zuul
分布式配置中心: Spring Cloud Config
高级功能:
消息总线: Spring Cloud Bus
消息驱动的微服务: Spring Cloud Stream
分布式服务跟踪: Spring Cloud Sleuth

Dubbo

Dubbo 是阿里开源的一款高性能 RPC 框架,特性包括基于透明接口的 RPC、智能负载均衡、自动服务注册和发现、可扩展性高、运行时流量路由与可视化的服务治理。

Dubbo是一套微服务系统的协调者,在它这套体系中,一共有三种角色,分别是:服务提供者(下面简称提供者)、服务消费者(下面简称消费者)、注册中心。
你在使用的时候需要将Dubbo的jar包引入到你的项目中,也就是每个服务都要引入Dubbo的jar包。然后当这些服务初始化的时候,Dubbo就会将当前系统需要发布的服务、以及当前系统的IP和端口号发送给注册中心,注册中心便会将其记录下来。这就是服务发布的过程。与此同时,也是在系统初始化的时候,Dubbo还会扫描一下当前系统所需要引用的服务,然后向注册中心请求这些服务所在的IP和端口号。接下来系统就可以正常运行了。当系统A需要调用系统B的服务的时候,A就会与B建立起一条RPC信道,然后再调用B系统上相应的服务。

2.4 框架对比和选型

  • 从社区活跃度和功能完整度,再对照业务需求和团队状况进行选型。

从整体架构上来看:二者模式接近,都需要服务提供方,注册中心,服务消费方。

从核心要素来看:Spring Cloud 更胜一筹,在开发过程中只要整合 Spring Cloud 的子项目就可以顺利的完成各种组件的融合,而 Dubbo 却需要通过实现各种 Filter 来做定制,开发成本以及技术难度略高。

通信协议和性能:Dubbo 支持各种通信协议,而且消费方和服务方使用长链接方式交互,通信速度上略胜 Spring Cloud,如果对于系统的响应时间有严格要求,长链接更合适。

服务依赖:Dubbo 服务依赖略重,需要有完善的版本管理机制,但是程序入侵少。

组件运行:业务部署方式相同,都需要前置一个网关来隔绝外部直接调用原子服务的风险。

可能的选择:

  1. 基于SpringBoot快速开发、基于Dubbo的微服务化、基于Docker的容器化部署、基于Jenkins的自动化构建、用docker-compose进行服务编排
  2. 基于SpringBoot快速开发、基于Spring Cloud的微服务化、基于Docker的容器化部署、基于Jenkins的自动化构建、用docker-compose进行服务编排

服务编排:

在微服务系统的架构中,所有的服务都是无状态的。
容器编排就是针对这些无状态的服务进行的一系列操作,什么操作呢:弹性伸缩、自动扩容、健康检查、服务发现、负载均衡、自动恢复、滚动升级等等。
通俗的说,你通过编写配置文件告诉容器编排系统,我要user这个微服务初始化启动3个节点。当tps大于2000的时候自动扩容,最大可以扩容到10个节点,这个服务最大可用内存、cpu是多少等等,容器编排系统完成你需求的过程就是编排

3 K8S

3.1 Docker

Docker 的意义

  • 统一了基础设施环境(硬件、操作系统版本、运行时环境)
  • 统一了程序打包(装箱)的方式:所有语言的程序都全部变 docker镜像
  • 统一了部署方式 docker容器:docker run

单机使用docker的缺点:

  • 无法有效集群
  • 容器数量上升的同时,管理成本上升
  • 没有容灾机制
  • 没有编排模板,无法大规模快速调度
  • 没有统一的配置管理中心工具
  • 没有容器生命周期的管理工具
  • 没有图形化运维管理工具

Docker支持任何语言的镜像

Docker与宿主机进行隔离,使用平台的可移植性

当Docker服务变得越来越多之后如何进行更好的管理?:实现对Docker管理——Kubernetes

3.2 K8S

基于Docker容器引擎的开源容器编排工具:K8S

Kubernetes,就是基于Docker的集群管理平台,它的全称,是kubernetes。

一个K8S系统,通常称为一个K8S集群(Cluster)

这个集群主要包括两个部分:一个Master节点(主节点)、一群Node节点(计算节点)

利用 K8S,能够达成以下目标:

  • 跨多台主机进行容器编排。
  • 更加充分地利用硬件,最大程度获取运行企业应用所需的资源。
  • 有效管控应用部署和更新,并实现自动化操作。
  • 挂载和增加存储,用于运行有状态的应用。
  • 快速、按需扩展容器化应用及其资源。
  • 对服务进行声明式管理,保证所部署的应用始终按照部署的方式运行。
  • 利用自动布局、自动重启、自动复制以及自动扩展功能,对应用实施状况检查和自我修复。

4 如何选型

Dubbo、Spring Cloud和K8S横向对比Dubbo、Spring Cloud和K8S横向对比

Dubbo、Spring Cloud和K8S优劣比对

服务框架 生态 开发复杂度 运维复杂度 完成度
Dubbo 一般 简单 简单 开发中,不成熟
Spring Cloud 丰富 简单 复杂 正式版,成熟
Kubernetes 非常丰富 简单 非常复杂 趋于成熟

没有深入使用来对比就有一点点片面,目前综合多方面的调查和现有的对比评测,总结如下:

  • Dubbo 和 SpringCloud
    • Dubbo的关注点在于服务治理,并不能算是一个真正的微服务框架,不能完整覆盖微服务的各项功能需求。
    • Spring Cloud通过集成各种组件的方式来实现微服务,因此理论上可以集成目前业内的绝大多数的微服务相关组件,从而实现微服务的全部功能。
    • 对Dubbo而言,如果一定要应用到微服务的使用场景中的话,上表中欠缺的大多数功能都可以通过集成第三方应用和组件的方式来实现,跟Spring Cloud相比主要的缺陷在于集成过程中的便利性和兼容性等问题。
  • SpringCloud 和 K8S
    • Spring Cloud是一个基于Java语言的微服务开发框架,更多的是面向有Spring开发经验的Java语言开发者
    • Kubernetes是一个针对容器应用的自动化部署、伸缩和管理的开源系统,它兼容多种语言且提供了创建、运行、伸缩以及管理分布式系统的原语。它不是一个针对开发者的平台,它的本质是DevOps(Development and Operations)工具。
  • 传统微服务架构 和 K8S
    • 传统微服务架构需要开发者在自己的应用中集成微服务框架 SDK,从而具有服务治理相关功能
    • Kubernetes 使用 kube-dns 以及 kube-proxy 配合 service 的概念支持了服务的注册与发现,才有了可以在 Kubernetes 上构建微服务的基础。实际生产中,需要对流量进行更精细的掌控,Service Mesh工具(例如istio) 可以被使用。
    • Service Mesh工具 在对K8S 有更深入的了解之后再去熟悉吧

目前的结论

  • 选型:Spring Boot + Docker + K8S

    • 全面覆盖微服务关注点
    • 语言栈无关,非 to JAVA
    • 社区活跃,不过时的资源多
  • 使用Spring Boot提供应用的打包,Docker和Kubernetes提供应用的部署和调度。

Reference

https://www.zhihu.com/question/65502802

https://www.zhihu.com/question/65502802/answer/1371300276

https://www.zhihu.com/question/45413135

https://zhuanlan.zhihu.com/p/33296468

https://blog.csdn.net/huanglitao0912/article/details/82314123

https://www.zhihu.com/question/283286745/answer/763040709

https://zhuanlan.zhihu.com/p/53260098

https://blog.csdn.net/qq_30364013/article/details/78148016

https://blog.csdn.net/weixin_43834662/article/details/96131720

https://www.cnblogs.com/doit8791/p/9979193.html

多组件通用HTTP框架演进_最终版-孙海洲


文章作者: 长腿咚咚咚
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 长腿咚咚咚 !
评论
 上一篇
springboot springboot
1 技术栈总结1.1 之前的技术栈JavaSE(servlet tomcat) mysql + jdbc html + css +jquery + 框架 javaweb: 原始的MVC三层架构的网站 SSM: Spring + Spring
下一篇 
二分类多分类多标签分类的评估指标计算与实现 二分类多分类多标签分类的评估指标计算与实现
1 二分类1.1 二分类例子reference_list = [0, 0, 0, 0, 0, 1, 1, 1, 1, 1] prediciton_list = [0, 0, 1, 1, 1, 0, 0, 1, 1, 1] 1.2 指标计算
  目录