文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

不管你是开发还是运维,微服务这些你得知道!

2024-12-03 03:10

关注

架构模式有很多,微服务不是唯一的选择也不是什么银弹。国内绝大多数中小公司引入微服务都是在盲目追新,也能看出做此种技术选型的工程师基础架构素质的不足。

“你必须长的足够高才能使用微服务”。微服务基础设施,尤其是容器技术、自动化部署、自动化测试这些不完备,微服务形同虚设,不会带来什么质的提升。

微服务架构的关键不在于具体的实现,而在于如何合理地划分服务边界以及组织架构是否相匹配。不考虑研发团队的规模和组成就盲目上微服务是不良的技术选型。

Spring Boot是Spring全家桶的上层封装,并不是什么崭新的技术,也不是什么值得觉得成为自己杀手锏的技术。

Spring Cloud中Spring Cloud Netflix的组件是经过生产环境验证的,其他的则建议慎重选择。

一、微服务是什么

微服务起源于2005年Peter Rodgers博士在云端运算博览会提出的微Web服务(Micro-Web-Service),根本思想类似于Unix的管道设计理念。2014年,由Martin Fowler 与 James Lewis共同提出了微服务的概念,定义了微服务架构风格是一种通过一套小型服务来开发单个应用的方法,每个服务运行在自己的进程中,并通过轻量级的机制进行通讯(HTTP API)。关键的三点是small、automated以及lightweight。

对比SOA,微服务可以看做是SOA的子集,是轻量级的SOA,粒度更细的服务,独立进程、数据分离,更注重敏捷、持续交付、DevOps以及去中心化实践。其共同的架构原理:

特点:

优缺点如下

优点:

缺点:

二、为什么要采用微服务

是否选择微服务取决于你要设计的系统的复杂度。微服务是用来把控复杂系统的,但是随之而来的就是引入了微服务本身的复杂度。需要解决包括自动化部署、监控、容错处理、最终一致性等其他分布式系统面临的问题。即使已经有一些普遍使用的解决方案,但是仍然是有不小的成本的。

生产力和复杂度的关系如图所示,可见系统越复杂,微服务带来的收益越大。此外,无论是单体应用还是微服务,团队的技能都需要能够把控住。

马丁.福勒的一个观点是:除非管理单体应用的成本已经太复杂了(太大导致很难修改和部署),否则都不要考虑微服务。大部分应用都应该选择单体架构,做好单体应用的模块化而不是拆分成服务。

因此,系统一开始采用单体架构,做好模块化,之后随着系统变得越来越复杂、模块/服务间的边界越来越清晰,再重构为微服务架构是一个合理的架构演化路径。

四个可以考虑上微服务的情况:

微服务的三个阶段

三、微服务架构

先决条件

此外,根据康威定律和逆康威定律(技术架构倒逼组织架构改进),组织架构也是一个很关键的因素。对应于微服务架构,组织架构需要遵循以下原则:

基础设施

微服务的推行需要依赖于很多底层基础设施,包括提供微服务的编译、集成、打包、部署、配置等工作,采用PaaS平台解决微服务从开发到运行的全生命周期管理,同时提供异构环境管理、容器资源隔离与互通、服务伸缩漂移、服务升级与回退、服务熔断与降级、服务注册与发现。

最基本的基础设施

提升外部服务对接效率和内部开发效率

提升测试和运维效率

进一步提升运维效率

在微服务数量很少的情况下,以上基础设施的优先级自上而下降低。否则,仅仅依赖人工操作,则投入产出比会很低。

还需要提到的是Docker容器技术。虽然这个对于微服务并不是必须的,但是容器技术轻量级、灵活、与应用依存、屏蔽环境差异的特性对于持续交付的实现是至关重要的,即使对于传统的单体应用也能够给其带来交付效率的大幅提升。

四、架构设计模式

在引入微服务之后,传统的单体应用变为了一个一个服务,之前一个应用直接提供接口给客户端访问的架构不再适用。微服务架构下,针对不同设备的接口做为BFF层(Backend For Frontend),也叫做用户体验适配层,负责聚合、编排微服务的数据转换成前端需要的数据。服务之间的调用则在允许的情况下(允许延迟)尽可能使用异步消息传递方式,如此形成面向用户体验的微服务架构设计模式。如下图所示:

  1. Client -> API Gateway -> BFF(Backend For Frontend) -> Downstream Microservices 

五、服务拆分

微服务架构最核心的环节,主要是对服务的横向拆分。服务拆分就是讲一个完整的业务系统解耦为服务,服务需要职责单一,之间没有耦合关系,能够独立开发和维护。

服务拆分不是一蹴而就的,需要在开发过程中不断地理清边界。在完全理清服务之前,尽量推迟对服务的拆分,尤其是对数据库的拆分。

拆分方法如下

其中,对于无法修改的遗留系统,采用绞杀者模式:在遗留系统外面增加新的功能做成微服务方式,而不是直接修改原有系统,逐步的实现对老系统替换。

拆分过程需要遵守的规范如下

六、微服务框架

上面讲述了微服务架构的众多基础设施,如果每一个基础设施都需要自己开发的话是非常巨大的开发工作。目前市面上已经有不少开源的微服务框架可以选择。

Spring Boot

Spring Boot是用来简化新Spring应用的初始搭建以及开发过程的。其虽然不是微服务框架,但其设计的初衷本质就是微应用的底层框架,因此非常适合用于微服务基础设施的开发以及微服务的应用开发。尤其对于Spring技术栈的团队来说,基于Spring Boot开发微服务框架和应用是自然而然的一个选择。

Dubbo&&Motan

Dubbo阿里开源的服务治理框架。其出现在微服务理念兴起之前,可以看做是SOA框架的集大成之作。但其仅仅包含了微服务基础设施的部分功能,诸如熔断、服务跟踪、网关等都没有实现。

Motan则是微博开源的类似Dubbo的RPC框架,与Dubbo相比更轻量级。

Spring Cloud

Spring Cloud是基于Spring Boot实现的微服务框架,也可以看做一套微服务实现规范。基本涵盖了微服务基础设施的方方面面,包括配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等。其基于Spring生态,社区支持非常好。但其很多组件都没有经过生产环境验证,需要慎重选择。

Spring Cloud Netflix是Spring Cloud的一个子项目,是Spring对Netflix OSS的集成实现。基于Netflix的大规模使用,其中的已经被广泛使用的组件包括:

此外,另一个子项目Spring Cloud Alibaba则是Alibaba开源的基于Spring Boot的微服务框架,主要是对阿里云服务的支持。

Service Mesh

上述的微服务框架都是侵入式的,服务化的过程都需要进行代码改造。Service Mesh则是下一代微服务架构,最明显的特征就是无入侵。采用sidecar模式来解决系统架构微服务化后的服务间通信和治理问题。如下如所示:

目前主流的开源实现包括:

限于Service Mesh带来的性能延迟的开销以及sidecar对分布复杂性的增加,其对大规模部署(微服务数目多)、异构复杂(交互协议/开发语言类型多)的微服务架构带来的收益会更大。

Linkerd和Envoy:以 sidecar 为核心,关注如何做好proxy,并完成一些通用控制平面的功能。缺乏对这些sidecar的管理和控制。

Istio和Conduit:目前最为流行的Service Mesh实现方案,集中在更加强大的控制平面(sidecar被称为数据平面)功能。前者由Google和IBM合作,并使用了Envoy作为sidecar部分的实现;后者则是Linkerd作者的作品。相比起来,Istio有巨头背景,功能强大,但可用性和易用性一直不高,Conduit则相对简单、功能聚焦。

Sofastack

蚂蚁金服开源的构建金融级分布式架构的一套中间件。包括微服务开发框架、RPC框架、服务注册中心、全链路追踪、服务监控、Service Mesh等一整套分布式应用开发工具。

特别值得一提的是SOFAMesh。其实对下一代微服务架构Service Mesh的大规模落地方案实践,基于 Istio改进和扩展而来,应该是国内最为成熟的开源Service Mesh方案。

此外,需要提到Kubernetes(K8s),其本身提供了部分的微服务特性支持(通过域名做服务发现),对代码无侵入。但服务调用、熔断这些都需要自己实现。

综上,目前公司技术团队技术栈是Spring,并且已有服务的实现都是基于Dubbo,因此选择Spring Cloud Netflix做为基础的微服务框架,对其中不成熟或者缺乏的组件,选择业界更为成熟的组件替代即可。

 

来源:民工哥技术之路内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯